RMI Specification (6) - (10)

xiaoxiao2021-03-06 157

RMI Specification (6) Register Service Program ----------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -------------------------------------------------- ---------------- Chapter 6

The RMI system uses the java.rmi.registry.registry interface and the Java.rmi.registry.locat EREGISTRY class to provide a well-known bootstrap service in name retrieval and registration objects.

Registry is a remote object that maps the name to the remote object. All server processes support their own registration service programs or a single registration service that can be used for the host.

The LocateRegistry method is used to enable the registration service program to run in a specific host or host from the port. The Java.rmi.naming class method is used to call a remote object that implements the Registry interface with the appropriate Locat EREGISTRY.GETREGISTRY method.

Topic: Registry interface LocateRegistry class RegistryHandler interface

RMI Specification (7) Remote Object Activation -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ----------------------------

-------------------------------------------------- ---------------------------- Chapter 7

Topic: Overview Activation Protocol "Activable" Realization Model Activation Interface

RMI specification (8) Chapter 8 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ ------------------------------------- -------------------------------------------------- ----------------

This chapter contains the interfaces and classes used by the RMIC STUB compile generated.

Topic: Remotestub Class RemoteCall Interface RemoteRef Interface ServerRef Interface Skeleton Interface Operation Class

RMI specification (9) Chapter 9 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ ---------------------------------------------------- -------------------------------------------------- ----------------?

The interfaces in this chapter are used in the distributed garbage collector (DGC) of RMI.

Topic: Interface DGC Lease class OBJID class UID class VMID class

-------------------------------------------------- ------------------------------------------------- -------------------------------------------------- -------- ------------------------------------------------------------------------ -------------------------------------------------- -------------------------------------------------- ------------------------------------------------- --------------------------------------?

RMI Specification (6) Register Service Program ----------------------------------------- ------------------------------------- Chapter 6

The RMI system uses the java.rmi.registry.registry interface and the Java.rmi.registry.locat EREGISTRY class to provide a well-known bootstrap service in name retrieval and registration objects.

Topic: Registry interface LocateRegistry class RegistryHandler interface

6.1 Registry interface java.rmi.registry.registry Remote Interface The Remote Interface can provide a method for providing queries, binding, re-binding, unbinding, and listing registered service programs. The java.rmi.naming class provides a URL-based naming with the Registry remote interface.

Package java.rmi.registry;

public interface Registry extends java.rmi.Remote {public static final int REGISTRY_PORT = 1099; public java.rmi.Remote lookup (String name) throws java.rmi.RemoteException, java.rmi.NotBoundException, java.rmi.AccessException; public void bind (String name, java.rmi.Remote obj) throws java.rmi.RemoteException, java.rmi.AlreadyBoundException, java.rmi.AccessException; public void rebind (String name, java.rmi.Remote obj) throws java.rmi. RemoteException, java.rmi.AccessException; public void unbind (String name) throws java.rmi.RemoteException, java.rmi.NotBoundException, java.rmi.AccessException; public String [] list () throws java.rmi.RemoteException, java. Rmi.accessException;

Registry_port is the default port of the registered service.

The Lookup method returns a remote object that is bound to the specified Name, while the remote object implements a set of remote interfaces. The client can convert remote objects to the desired remote interface type (this mandatory type conversion may fail with its common failure in the Java language). Bind method associates the NAME with the remote object OBJ. If the name is bind to an object, throw AlreadyBoundExcepton. Rebind method associates NAME with the remote object OBJ. All bindings before the name will be discarded. UNBIND method Removes the binding between Name and Remote object OBJ. If the name is not binding to an object, throws notboundexception.

The List method returns a strings array that contains snapshots that are tied in the registration service. This return value contains a snapshot of the registered service program content. The client can access the registration service program using the LocateRegistry and Registry interfaces or methods of URL-based Java.rmi.naming classes. The registration service program only supports Bind, Unbind, and Rebind with clients located on the same host. All hosts can perform query operations.

.2 LocateREGISTRY JAVA.RMI.REGISTRY.LOCATEREGISTRY Class is used to get a reference to a specific host (including local host), a reference (creating stub), or create remote object registration services that can be called at specific ports. program.

The registration service program implements a simple named syntname with the remote object name (string) with the remote object reference. The server restart does not remember the binding between these names and remote objects.

Note that getRegistry call does not act with a remote host connection. It simply establishes local references to the remote registration service, and even if there is no registration service in the remote host, it will succeed. Therefore, when the method is called as a remote registration service program returned by the return value, it may result in failure.

Package java.rmi.registry;

public final class LocateRegistry {public static Registry getRegistry () throws java.rmi.RemoteException; public static Registry getRegistry (int port) throws java.rmi.RemoteException; public static Registry getRegistry (String host) throws java.rmi.RemoteException; public static Registry getRegistry (String host, int port) throws java.rmi.RemoteException; public static Registry getRegistry (String host, int port, RMIClientSocketFactory csf) throws RemoteException; public static Registry createRegistry (int port) throws java.rmi.RemoteException; public static Registry CreateRegistry (int port, rmiclientsocketfactory csf, rmiserversocketfactory ssf) throws remoteexception;}

The first four getRegistry methods returned to the current host, the current host, specified port, or a registration service program reference to a specified Host or a specific port of the specified host. The returned remote STUB is a registration service program with a specified host and port information.

The fifth getRegistry method (RMICLIENTSOCKETFACTORY) returns a remote STUB created locally, which corresponds to the remote object Registry, which specifies Host and Port. When communicating with the remote registration service program for constructing STUB using this method, the supplied RMICLIENTSOCKETFAACTORY, CSF will be used to create a Socket connection to the registration service program for the remote host and port. -------------------------------------------------- ------------------------------

Note - The registration service that is returned from the getRegistry method is a special constructed STUB containing known object identifiers. There is still no support to pass the registration service program Stub from a virtual machine to another (its validity will depend on the implementation). Use the LocateRegistry.getRegistry method to get the corresponding registration service program of the host.

-------------------------------------------------- ------------------------------

CreateRegistry method creates and exports a registration service program for local hosts for specific ports.

The second CreateREGISTRY method is more flexible when communicating with the registration service program. This call will create and export registry in the local host, and the local host uses a custom socket factory for communications with the registration service. The created registration service program uses the Serversocket listening from RMiserVersocketFactory on a given port. The client receiving the registration service program reference will use the socket created from RMICLIENTSOCKETFACTORY.

-------------------------------------------------- ------------------------------

Note - Start the registration service program with the CreateRegistry method cannot keep the server process activity.

6.3 RegistryHandler interface

-------------------------------------------------- ----------------

Note - The RegistryHandler interface is not encouraged in JDK1.2. In JDK1.1, it is only used internally by the RMI, and cannot be used for applications.

-------------------------------------------------- -----------------

Package java.rmi.registry;

public interface RegistryHandler {Registry registryStub (String host, int port) throws java.rmi.RemoteException, java.rmi.UnknownHostException; Registry registryImpl (int port) throws java.rmi.RemoteException;}

Method RegistrySTUB returns a Stub that is contacted with a remote registration service program located at the specified host and port.

Method RegistryImpl will construct and export the registration service program located at the specified port. The port must be non-zero.

Chapter 7

Topic: Overview Activation Protocol "Activable" Realization Model Activation Interface

.1 Overview The distributed object system is designed to support long-term persistent objects. It is assumed that these systems will consist of thousands (perhaps to 10,000) such objects, and the implementation of the object is activated in the infinite period of time and keeps the activity state is unreasonable. This will occupy valuable system resources. In addition, the client needs to save the ability to persist in the object, so that the communication between the objects can be re-established after a system crash, as the reference to a distributed object is only valid when the object is active when the object is active. Object activation is a mechanism for providing implementation of the object's persistent reference and management object. In RMI, activation allows objects to start executing as needed. When the "Activated" remote object is activated, if the remote object is currently not executed, the system will start execution of the object in the appropriate Java virtual machine.

7.1.1 Termatic objects are remote objects that are instantiated and exported in some systems's Java virtual machines. Non-active objects have not been instantiated (or export) in the virtual machine, but can become a remote object of the active state. Activation is the process of transforming non-active objects into active objects. Activation requires objects associated with a virtual machine, which will likely need to load the objects of the object into the virtual machine, while the object also restores its persistent state (if any).

In the RMI system, we use inert activation. The inert activation is to delay an activation of an object to the client machine (that is, when the first method is called).

7.1.2 inert activation The inert activation of the remote object is achieved with imperfect remote references (sometimes called incomplete blocks). Improvement of remote objects When the remote reference is a reference to the active object, "Perfect" is a reference to the active object. Each imperfect reference maintains a persistent handle (activation identifier) and transient remote reference to the target remote object. The activation identifier of the remote object contains sufficient information to activate the third part. Transient reference is a "activity" reference for active remote objects that can be used to perform the execution object.

In the imperfect reference, if the live reference to the remote object is empty, the target object is not considered active. In the method call, the unbaptive reference (the object) will be added to the activation protocol to obtain "live" reference, which is a remote reference for newly activated objects (such as a remote reference) of the Unicast). Once the reference is not perfect, the unbained reference will call the method to pass the remote reference to the underlying, and the remote reference is transmitted to the remote object.

Specifically, the Stub of the remote object contains a "imperfect" remote reference type, including:

The activation identifier of the remote object includes "live" reference (possibly empty), which contains a "active" remote reference type of the remote object (for example, a remote reference type with single transmission semantic).

-------------------------------------------------- -------------------- Note - the RMI system retains "up to one" semantics for remote calls. In other words, the call to active or single-channel transmission remote object will be sent once. Therefore, if the call to the remote object fails (by throwing RemoteException exception), the client will get the following guarantee: the execution of the remote method will not exceed once, or even at all.

7.2 Activation Protocol During the remote method call, if the "live" reference of the target object is unknown, the activation protocol is not perfected. Activation protocols include the following entities: the activation group in the Java virtual machine is not perfected, the activation of the activated remote object.

Activator (usually one of each host) is an entity, responsible for activation, which is: mapping the activation identifier to the information required for activation objects (objects, location - URL path - loaded from it, Objects may need to be used for specific data for bootstrap, and the Java virtual machine manager, which launches the virtual machine (if necessary) and the object activation request (and the necessary information) is transmitted to the remote The correct activation group in the virtual machine. Note: The activator always saves the current mapping of the active identifier to the active object in the cache, so there is no need to query the group for each activation request.

Active group (one of each Java virtual machine) is such an entity that receives the request to activate the object in the Java virtual machine and return the activated object to the activator.

The activation protocol is as follows. Do not improve the reference to activate the identifier to activate the object associated with the identifier. The activation descriptor (previously registered) activation descriptor (previously registered). The descriptor of the object includes:

The object's group identifier (specifying the virtual machine in which the object is activated), the object's class name, URL path, the class code of the object is loaded, the object-specific initialization data (for example, the initialization data may be The name of the file containing the target persistent state). If the activation group of the object should be accommodated, the activator transmits the activation request to the group. If the activation group does not exist, the activator will start the virtual machine to perform the activation group, and then transfer the activation request to the group.

The activation group will load the class's class and instantiate the object with a specific constructor. This constructor has multiple parameters, including previously registered activation descriptors.

When the object is activated, the activation group will reference the group object reference to the active, then the activator records the activation identifier and the activation reference pair, and the active (live) reference will not be referred to. Subsequently, it is not perfected (in STUB) to pass the method call to the remote object directly through the activity reference.

-------------------------------------------------- -------------------- Note - In JDK, RMI provides the implementation of the activation system interface. To use activation, you must first run the system daemon (daemon) RMID.

7.3 "Activated" Remote Object Implementation Model In order to make the remote object accessible by activating the identifier are not subject to time, the developer must do:

Registering a activation descriptor for this remote object In the class, a dedicated constructor is included, which will call it when the RMI system activates the active object.

The following methods can be used to register the activation descriptor (ActivationDesc):

Call class ACTIVATABLE The Static Register method of the Activatable is created with the first or second constructor of the Activatable class Explicitly exports the "activatable" object. This process can be implemented with the first or second EXPO RTOBJECT method of Activatable, which is the implementation and port number of ActivationDesc, Remote object.

For a particular object, only one of the three methods described above can be used to register the activation object. For examples of how to implement an activatable object, see the "Constructure Activated Remote Object" later.

7.3.1 ActivationDesc class ActivationDesc Contains information needed to activate the object. It contains an object's activation group identifier, object's class name, and a CodeBase path (or URL) of the load object code (or URL), and MarshalledObject (which can contain object specific initialization data used during each activation). The descriptor registered in the activation system is queried during the activation process to obtain relevant information to re-create or activate the object. The MarshalledObject in the descriptor of the object will be transmitted to the constructor of the remote object as the second parameter for use in the activation process.

Package java.rmi.activation;

public final class ActivationDesc implements java.io.Serializable {public ActivationDesc (String className, String codebase, java.rmi.MarshalledObject data) throws ActivationException; public ActivationDesc (String className, String codebase, java.rmi.MarshalledObject data, boolean restart) throws ActivationException; public ActivationDesc (ActivationGroupID groupID, String className, String codebase, java.rmi.MarshalledObject data, boolean restart); public ActivationDesc (ActivationGroupID groupID, String className, String codebase, java.rmi.MarshalledObject data); public ActivationGroupID getGroupID () Public string getclassname (); public string getLocation (); public java.rmi.marshalledObject getdata () public boolean getrestMode ();

The first constructor of ActivationDesc constructs an object's object descriptor. The class of this object is classname (loaded from a CodeBase path), its initialization information (group form) is DATA. If this form of constructor is used, the group identifier of the object defaults to the current identifier of the virtual machine ActiVationGroup. All objects with the same ActivationGroupID will be activated in the same virtual machine. If the current group is active or unable to create a default group, the Activat IONEXCEPTION will be thrown. If GroupID is NULL, IllegaAralgumentException will be thrown. ?

-------------------------------------------------- ------------------------------

Note - as a sub-effect that creates ActivationDesc, if the virtual ActivationGrou P is not currently not active, the default ActivationGroup will be created. The default activation group will use java.rmi. RMISecurityManager as the security manager and set the properties in the activation group virtual machine to the current attribute in the virtual machine during reactive. If the application needs to use a different security manager, you must set the group of the virtual machine before creating the default ActivationDesc. For more information on how to create an ACT IVATIONGROUP for a virtual machine, see Method ActivationGroup.createGroup. -------------------------------------------------- ------------------------------

The ActivationDesc second constructor constructor descriptor is the same as the first constructor, but must provide additional parameter restart. If the object requires restart service, this means that the object will automatically restart when the activator is newly activated (the inert activation is reversed as needed). At this point, RESTART should be True. If restart is false, the object will only be activated (passing the remote method) when needed.

The third constructor of ActivationDesc constructs an object descriptor for an object. The group identifier of this object is GroupID, and its class name is classname (which is loaded from the CodeBase path), its initialization information is DATA. All objects with the same groupID will be activated in the same Java virtual machine.

The ActivationDesc Fourth Constructor Construction Object Descriptor is the same as the third constructor, but it allows the specified restart mode. If the object needs to be restarted (defined above), RESTART should be true.

The getGroupID method returns the group identifier of the object specified by the descriptor. The group can provide a method of polymerizing an object to a single Java virtual machine.

The getClassName method returns the class name of the object specified by the activation descriptor.

GetLocation method Returns the CodeBase path for downloading the class.

The getData method returns a "group object" that contains data for initialization (activation) the object specified by the description.

The GetrestartMode method returns true when the restart mode of the object is enabled, otherwise false.

7.3.2 ActivationID class Activation protocol utilizes an activation identifier to indicate an activated remote object that is not subject to time. Activate identifier (instance of class ActivationID) contains several information required to activate the object:

The unique identifier of the remote reference object of the object activator. The active identifier of the object can be obtained by registering an object to the activation system. Registration can be accomplished with one of the following methods (as described above):

Through the first or second ActivATable constructor (all of which are registered with three parameters and export objects) through the Activatable.Register method (them to activate the descriptor, the object implementation and port " For parameters, and register and export objects).

Package java.rmi.activation;

public class ActivationID implements java.io.Serializable {public ActivationID (Activator activator);. public Remote activate (boolean force) throws ActivationException, UnknownObjectException, java.rmi RemoteExcep tion; public boolean equals (Object obj); public int hashCode (); } ActivationID constructor accepts parameter Activator, which specifies a remote reference for the actuator (responsible for activating the object associated with the activation identifier). An instance of ActivationID is the only one. The Activate method activates the object associated with the activation identifier. If the Force parameter is True, the activator will treat any cache references of the remote object as outdated, so that the activator is in contact with the group when activating the object. If force is false, return an acceptable cache value. If the activation fails, throw an ActivationException. If the activator cannot identify the object identifier, the method will throw unknownObjectException. If the remote call of the activator fails, it throws RemoteException. The equals method can achieve equivalent comparison based on content. If all domains are equal (exactly the same or from Object.equals semantics in various domains), it will return True. If P1 and P2 are examples of class ACT IVATIONID, the HashCode method returns the same value when p1.equals (p2) returns TRUE.

7.3.3 Activatable class Activatable class provides support for remote objects that require persistent access, while being activated by the system. Class Activatable is a major application interface for developers to implement and manage activatable objects. Note that the activation system daemon RMID must be run first before you can register and / or activate the object.

package java.rmi.activation; public abstract class Activatable extends java.rmi.server.RemoteServer {protected Activatable (String codebase, java.rmi.MarshalledObject data, boolean restart, int port) throws ActivationException, java.rmi.RemoteException;

protected Activatable (String codebase, java.rmi.MarshalledObject data, boolean restart, int port, RMIClientSocketFactory csf, RMIServerSocketFactory ssf) throws ActivationException, java.rmi.RemoteException;

Protected active (activationid id, int port) throws java.rmi.remoteexception;

Protected Activatable (ActivationID ID, INT Port, RMICLIENTSOCKETFAACTORY SSF) throws java.rmi.RemoteException;

Protected activationid getId ();

public static Remote register (ActivationDesc desc) throws UnknownGroupException, ActivationException, java.rmi.RemoteException; public static boolean inactive (ActivationID id) throws UnknownObjectException, ActivationException, java.rmi.RemoteException;

Public Static Void Unregister (ActivationID ID) THROWS UNKNOBJECTEXCEPTION, ACTIVATIONEXCEPTION, JAVA.RMI.RemoteException;

Public Static ActivationId ExportObject (Remote Obj, String Codebase, MarshalledObject Data, Boolean Restart, Int port) throws activationException, java.rmi.RemoteException;

public static ActivationID exportObject (Remote obj, String codebase, MarshalledObject data, boolean restart, int port, RMIClientSocketFactory csf, RMIServerSocketFactory ssf) throws ActivationException, java.rmi.RemoteException;

Public Static Remote ExportObject (Remote Obj, ActivationID ID, INT Port) throws java.rmi.RemoteException;

Public Static Remote ExportObject (Remote Obj, ActivationID ID, INT Port, RMICLIENTSOCKETFAACTORY CSF, RMISERVERSOCKETFACTORY SSF) THROWS JAVA.RMI.RemoteException;

Public Static Boolean UnexportObject (Remote Obj, Boolean Force) THROWS JAVA.RMI.NOSUCHOBJECTEXCEPTION;

The implementation of the remote object can be activated may expand or do not extend class Activatable. The remote object implementation of the ActivATAB LE class will inherit the corresponding definition in the Hashco DE and Equals methods from the superclass java.rmi.server.RemoteObject. Therefore, the two remote references that reference the same ActiVATable remote object are equal (the Equals method returns TRUE). Similarly, the example of class Activatable will "equals" the corresponding STUB object of the instance (ie, if the Object.Equals method is called as a parameter with the implementation of the STUB object, it will return True. Virtue).

The first constructor of the Activatable class method Activatable class is used to register and export objects on the specified port (if the P ORT is zero, select an anonymous port). The URL path of the downloaded class code object is CODBASE whose initialization data is DATA. If restart is True, the object will automatically restart when the activator restarts or group failure. If restart is false, the object will be activated as needed (by calling the remote method of the object). The specific subclass of the ACTIVATABLE class must call the constructor to register and export the object during the initial construct. As the sub-efficiency when constructing the active object, the remote object will be "registered" to the activation system and "export" (if the port is zero, then exported at anonymous port) to the RMI run, so that it can accept from the client The arrival call.

If the registration object to the activation system failed, the constructor will throw an ActivationException. If you fail to export objects to RMI runtime, RemoteException will be thrown.

The second constructor is the same as the first ActivATable constructor, but it allows the client and server set factory specification to communicate with the activable object. For more information, see "RMI Socket Factory".

The third constructor is used to activate the object and export it from the specified port (with ActivationID, ID). When the object itself is activated by its dedicated "activation" constructor, the specific subclass of the ACTIVATABLE class must call the constructor. The parameters of the "activation" constructor must be:

The object's activation ID and the initialization / bootstrap data of the object (MARSHALLEDOBJECT). As the sub-effects of the configuration, the remote object will be "exported" to the RMI runtime (from the specified port) and accept calls from the client. If the object is derived to the RMI runtime, the constructor will throw RemoteException.

The fourth constructor is the same as the third constructor, but it allows the client and server socket factory specification to communicate with the activable object.

GetID method Returns the activation identifier of the object. This method is protected, so only subclasses can obtain the identifier of the object. The object's identifier is used to report the non-active state of the object or the activation descriptor of the logout object.

The REGISTER method is an activatable remote object to the activation system registration object descriptor DESC, so that the object can be activated when needed. This method can be used to register activaneous objects without creating this object first. It returns the Remote Stub that activates objects, so it can be saved and called in the future to force the first time to create / activate the object. This method will throw unknownGroupException if the group identifier in the DESC is not activated. If the activation system is not running, the ActivationException is thrown. Finally, if the remote call of the activation system fails, the RemoteException is thrown.

The Inactive method is used to notify the system that has the object with the corresponding activation ID is currently non-active. If this object is currently active, the object will be exported from the RMI runtime environment (only when there is no call or executed), so that the call can no longer receive. This call will also notify the virtual machine A CTINGROUP that is inactive; and the group will notify its ActivationMonito R. If the call is successful, then the activation request for the activator will result in reactivation of the object. If the object is prevented from successively (meaning that it does not pend or performs calls), the INACTIVE method returns true; if the object is called in the process, it cannot block the object from being exported, then the Fa LSE is returned. If the object is unknown (it might be non-active), the method will throw unknownObject Texception; if the group is inactive, throw an ActivationException; if the notification display fails, throw RemoteException. This operation will still be successful if the object is considered to be active but has prevented itself. The Unregister method is used to undo the previous registration of the activation descriptor associated with the ID. Objects cannot be activated with this ID. If the object ID is unknown for the activation system, you will throw unknownObje CTexception. If the activation system is not in a running state, the ActivationException is thrown. If the remote call of the activation system fails, it throws RemoteException.

The first ExportObject method can be "activated" but does not extend an object explicit call of the Activatable class, its purpose is: a) To activate the activation descriptor DESC to activate the system, constructed by the supplied COD EBASE and DATA configuration (so The object can be activated); b) Export remote object OB J (if the port is zero, the anonymous port) is selected from the specified port. Once the object is exported, it can be received.

The ExportObject method returns the activation identifier obtained when the system registration descriptor DESC is activated. If the activation group is not active in the virtual machine, throw an ActivationException. If the object registers or exports, it throws RemoteException.

If the OBJ extension Activatable, this method is not required because the first ActivAtable constructor will call the method.

The second ExportObject method is the same as the first, but it allows the client and server socket to communicate with the activatable object.

The third ExportObject method exports the "activatable" remote object (not necessarily a ctivatable type) of the identifier ID to the RMI runtime, so that the object OBJ can receive calls. If the Port is zero, the object will be exported at an anonymous port.

When activated, the "activation" object that does not extend the Activatable class should explicitly call this ExportObje CT method. It does not need to call the Activatable class to call the method directly; it will be called by the third constructor above (the subcategory should be called from its dedicated activation constructor).

The ExportObject method will return Remote STUB that activatable object. If the export of the object is lost, the method will throw RemoteException.

The fourth ExportObject method is the same as the third, but it allows clients and server sockets to communicate with this activaneous object. UNEXPORTOBJECT method makes the remote object OBJ cannot receive calls. If the parameter force is true, the object will also be forced to block the export even if there is a call to the remote object to be called or the remote object is called in the process. If the parameter force is false, it is only blocked only when there is no call to the object's pending call or in the process. If the export of the object is successfully blocked, the RMI will delete it from its internal table. Using this mandatory approach to delete objects from the RMI may enable the client's overtime remote reference. If the object is not previously exported to the RMI runtime, the method will throw java.rmi.nosuchobjectException.

Constructing an active remote object To enable object activation, "Activable" object implements the class regardless of whether or not the ACTIVATABLE class must define a special public constructor. The common constructor has two parameters: Activate identifier (type ActiVationID) and activation data java.rmi.marshalledObject (provided in the activation descriptor used in registration). When an activation group activates a remote object within its virtual machine, it will use this special constructor to construct the object (later will be described in detail). Remote object implementation can be initially used with activation data. Remote objects may also want to retain their activation identifiers so that the activation group can be notified when it becomes non-active (by calling the ACTIVATABLE. Inactive method).

The first and second form of the ACTIVATABLE constructor is used to register with the specified port and export activatable objects. This constructor should be used when constructed the object; the third form of the constructor will be used when reactive objects.

The specific subclass of ACTIVATABLE must call the first or second constructor during the initial construct to quench and export objects. The constructor first creates an activation descriptor (ActivationD ESC), the CodeBase and Data (the activation group for the virtual machine) provided by the object. The constructor will then register the descriptor to the default ActivationSystem. Finally, the constructor is on a particular port (if the port is zero, select anonymous port) to export the active object to the RMI run, and report the object as an ActiveObject to the local ActivationGroup. If an error occurs during registration or export, the constructor throws RemoteException. Note that the constructor also initializes its ActiVationID (obtained by registering), so the call to the protected method GetID will return the activation identifier of the object.

The third form of the Activatable constructor is used to export objects from the specified port. The third constructor must be called when the specific subclass of the ActivATAB LE is activated by the object's own "activation" constructor. This "activation" constructor is two parameters:

The initialization data of the object's ActivationID object, a MARSHALLEDOBJECT object This constructor only exports the active object from a particular port (if the Port is zero, select anonymous port) to export to the RMI runtime, and does not notify ACTIVATIONGROUP This object is already an active Object. Because it is activationGroup to activate the object, it naturally knows that the object is active.

Below is an example of implementing ServerImpl for remote object interface Server and extended Activatable classes: package example;

Public Interface Server Extends Java.rmi.Remote {Public Void Doimportantstuff () THROWS JAVA.RMI.RemoteException;

public class ServerImpl extends Activatable implements Server {// initial configuration, constructors public ServerImpl (String codebase, MarshalledObject data) at the time of registration and export throws ActivationException, java.rmi.RemoteException {// activate the system to register the object, and then in // Export Super (CodeBase, Data, False, 0) on anonymous port;

// Activate and export constructor. This constructor is called during the activation process by // ActivationInstantiator.newinstance / / method to construct the object public serverImpl (ActivationID ID, MarshalledObject Data "throws java.rmi.RemoteException {// call the parent class constructor's constructor to // Object exports to RMI runtime. Super (ID, 0); // Initialize the object (for example, using data)}

Public void doimportntsTUFF () {...}}

Objects will be responsible for exporting yourself. The constructor of the Activatable is responsible for exporting objects to RMI runtime with active reference type UnicastRemoteObject, so the object to extend Activatable does not have to care about explicitly export objects (not calling the corresponding superclass constructor) specific details. If the object is not extended class Activatable, the object must explicitly export the object by calling an Activatable.exp ORTObject static method.

In the following example, ServerIMPL does not extend Activatable, but an extension of another class. Therefore, Serveri MPL is responsible for exporting themselves during initial constructing and activation. The following class definition gives the initial constructor of ServerIMPL and its special "activation" constructor, and corresponding calls for exporting objects in each constructor:

Package examples;

public class ServerImpl extends SomeClass implements Server {// constructor public ServerImpl (String codebase, MarshalledObject data) throws ActivationException, java.rmi.RemoteException {// register and export the object Activatable.exportObject (this, codebase, data at the time of initial creation, False, 0);

// Activated constructor PUBLIC ServerImpl (ActivationID ID, MarshalledObject Data) throws java.rmi.RemoteException {// Export Object Activatable.ExportObject (this, ID, 0);}

Public void doimportntsTUFF () {...}}

If the registration activation descriptor is registered without creating an object, the programmer is registered to activate the remote object without creating an object, and the programmer only needs to activate the object of the object (instance of class ActivationDesc). The activation descriptor contains all the information required, so the system can activate the object if necessary. The following method can be used to register the activation descriptor (ignore the exception handling): Server Server; ActivationDesc Desc; string codebase = "http: // zaphod / cod ebase /";

MarshalledObject Data = New MarshalledObject ("Some Data"); Desc = New A CTINVATIONDESC ("Examples.ServerImpl", CodeBase, DATA); Server = (Server) Activatable.Register (DESC);

The Register call returns a Remote Stub (which is the S TUB of the Examples.serverImpl object) and implements a set of remote interfaces that are implemented with Examples.serverImpl (ie, Stub implementation Remote Interface Server). The STUB object (the object of the forced type conversion and assignment to the Server) can be called as a parameter to be transmitted to any method of the object that implements an object of an Examples.server remote interface.

7.4 Active Interface In the RMI Activation Protocol, in order to make the system are operating normally, the activator must ensure that the following two points:

Like all system daemons, the activator must keep the active state activator when the computer is in an open state. The activator will maintain a corresponding information database for groups and objects it want to activate.

7.4.1 Activator Interface Activator is one of the entities involved in the activation process. As mentioned earlier, the imperfection reference in STUB will obtain "live" references to activate remote objects by calling the activator's Activate method. After the activator is connected to the activation request, the activation descriptor of the activation identifier ID is started to determine which group to activate the object, and then call the NewInstance method of the instantifier of the activation group (ActivationGROUP will be behind Description). The activator will start the execution process of the activation group as needed. For example, if the activation group of the resulting group descriptor has not yet run, the activator will generate a sub-virtual machine for the activation group to establish the group in the new virtual machine.

The activator will be responsible for monitoring and detecting when the activation group failed to remove the outdated remote reference from its internal table.

Package java.rmi.activation;

public interface Activator extends java.rmi.Remote {java.rmi.MarshalledObject activate (ActivationID id, boolean force) throws UnknownObjectException, ActivationException, java.rmi.RemoteException;}

Activate method activates the object associated with the activation identifier ID. If the actuator knows that the object is already an active object, and the force parameter is false, it will immediately contain the "live" references to the call to the call; if the activator does not know the corresponding remote object is the active or Force parameter is True, The activator will utilize activation descriptor information (previously registered with the ID) to determine which group (virtual machine) should be activated in which group (virtual machine) should be activated. If the corresponding activation of the object group already exists, the activator will call the NewInsta NCE method of the activation instantiator by passing the ID and an activation descriptor. If the active instantifier (group) of the object group descriptor is not existed, the actuator will initiate a new Activ ATIONInstantiator avatar implementation process (eg, by generating a sub-process). When the activator rebuilds ActivationInstantiator for a group, it must increase the number of the avatar of the group. Note that the number of avatars starts with 0. Activate the system used to detect the later Activationsystem.ActiveGroup and ActivationMonitor.inActiveGroup calls. The activation system will discard the call of the current number of the avatar than the group. -------------------------------------------------- ------------------------------

Note - Activator must communicate with the identifier, descriptor and avatar of the activation group when starting a new activation group. The actuator will generate an activation group in a separate virtual machine (e.g., as a separate process or child process). Therefore, it must pass the information to specify the information required to create the group with the ActivationGroup.createg Roup method. The activator does not specify how this information is transmitted to the generated process. This information can be sent to the standard input of the child process in the form of a group object.

-------------------------------------------------- ---------------------------- When the activator receives the callback of the activation group (via the ActivationSystem.activeGroup method, the callback can be indicated When the number of activation groups and the number of avatars can call the N E-EWInstance method of the activation instance device to forward each pending activation request to the activation instantiator, and will result (a packet remote object Quote, a stub) returns to each call.

Note that the activator receives the MarshalledObject object rather than the Remote object. Therefore, the activator does not need to load the code of the object, nor does it need to participate in distributed garbage collection of the object. If the activator retains a strong reference to the remote object, the activator will prevent the object from being treated as garbage under normal distributed garbage collection mechanism.

If the activation fails, the Activate method will throw an ActivationException. Activation may fail because of the following reasons: can't find the class, can not get in touch with the activation group. If you have not previously registered to the activation descriptor for the activation identifier ID, the Activate method will throw unknownObject Exception. If the remote call to the activator fails, the RemoteException is thrown.

7.4.2 ActivationSystem Interface Activationsystem provides a method for grouping and activatable objects (these objects will be activated in these groups). ActivationSystem and Activator and ActivationMonitor work closely together. The former is responsible for activating the objects registered by ActivationSystem; the latter is responsible for obtaining information about the activity object, the non-active object, and the non-active group. Package java.rmi.activation;

Public interface activationsystem extends java.rmi.remote {public static final int system_port = 1098;

ActivationGroupid RegisterGroup (ActivationGroupDesc DESC) THROWS ACTIVATIONException, Java.rmi.RemoteException;

ActivationMonitor ActiveGroup (ActivationGroupid ID, ActivationInstantiator Group, Long Incarnation) throws unknownGroupException, ActivationException, Java.rmi.RemoteException;

Void UnregisterGroup (ActivationGroupid ID) Throws ActivationException, UNKNOWNGROUPEXCEPTION, JAVA.RMI.RemoteException;

ActivationID RegisterObject (ActivationDesc Desc) throws ActivationException, UNKNOWNGROUPEXCEPTION, JAVA.RMI.RemoteException;

Void UnregisterObject (ActivationID ID) Throws ActivationException, UNKNOWNOBJECTEXCEPTION, JAVA.RMI.RemoteException;

Void shutdown () throws java.rmi.remoteexception;

-------------------------------------------------- ------------------------------

Note - As a security measures, all of the above methods (RegisterGroup, ActiveGroup, UnregisterObject, and shutdown) are called by the client, and the host is different from the host and the activation system, will throw Java. Rmi.accessex Ception. This exception is the subclass of java.rmi.RemoteException.

-------------------------------------------------- ------------------------------

The RegisterObject method is used to register the activation descriptor DESC and also obtain the activation identifier for the activated remote object. ActivationSystem creates an Activative NID for the object specified by the descriptor DESC, and records the activation descriptor and its identifier in a stable repository for future use. When Activator receives an Activate request of a particular identifier, it looks for the activation descriptor of the specified identifier (previously registered), and uses this information to activate the object. If the group referenced in D ESC does not register to the system, the method will throw unknownGroupexcepti ON. If registration fails (for example, database update fails, etc.), throw ActivationException. If the remote call fails, it throws the RemoteException. The UnregisterObject method is used to delete an active identifier ID and a related descriptor that previously annotated to the Activationsystem. After this call is completed, the object cannot be activated again. If the ID of the object is unknown (not registered), the method will throw unknownObjectExce Partion. If the logout failed (for example, the update failed by the database, the method will throw Activa TionException. If the remote call fails, it throws the RemoteException.

The RegisterGroup method is used to activate the activation group specified to the activation system registration group descriptor DESC and return to the ActivationGroupID assigned to the group. The activation group must be registered with the Activationsystem to register the object in this group. If the group's registration fails, the method will throw an Activati Onexception. If the remote call fails, it throws the RemoteException.

The ActiveGroup method is a callback from ActivationGroup (with identifier ID) to notify the activation system: The group is now active, and also the virtual machine ActivationInstant Iater. This callback is performed inside the ActivationGroup.createGroup method to get ActiVationMonitor. The group will use the ActivationMonitor to update the system on the status of objects and groups (ie, groups and objects in this group have become non-active). If the group is not registered, you will throw unknownGroupexception. If the group is already active, the ActivationException is thrown. If the remote call of the activation system fails, the RemoteException is thrown.

The UnregisterGroup method will delete the activation group with the identifier ID from the activation system. The activation group will make this callback to notify the activator to destroy the group. If this call is successfully completed, you will not be able to register and activate the object in this group. All information about this group and its related objects will be removed from the system. If the group is not registered, the method will throw unknownGroupexception. If the remote call fails, it throws the RemoteException. If the logout failed (such as database update fails, etc.), throw an ActivationException.

The shutdown method will terminate the activation system and all related activation processes (activators, monitors, and groups) in an appropriate asynchronous manner. All groups generated by the activation daemon will be destroyed, and the activation daemon will also exit. To turn off the activation system daemon RMID, execute the command: rmid -stop [- port number]

This command will turn off the activation daemon on the specified port (if not specified port, turn off the daemon on the default port).

7.4.3 ActivationMonitor class ActivationMonitor is ActivationGroup unique, which can be obtained by calling ActivationSy Stem.ActiveGroup to report a group (this call is performed inside the ActivationGroup.crea tegroup method). The activation group is responsible for notifying Activationmon ITOR: its objects have become an active object, non-active object, or the group has become non-active.

Package Java.rmi.Activation; Public Interface ActivationMonitor Extends Java.rmi.Remote {

Public Abstract Void InactiveObject (ActivationID ID) THROWS UNKNOBJECTEXCEPTION, RemoteException;

Public void ActiveObject (ActivationID ID, Java.rmi.MarshalledObject Mobj) throws unknownObjectException, java.rmi.RemoteException;

Public void inactivegroup (activationgroupid ID, long incarnation) throws unknownGroupException, java.rmi.remoteexception;}

When an object in the activation group becomes a non-active (deactivated), the activation group will call the INA CTINBJECT method of its monitor. The activation group discovered whether objects in its virtual machine (this object participated in activation) were inactive by calling its InactiveObject method.

InactiveObject Call will notify the ActivationMonitor that the remote object reference with the object with the activation identifier ID is no longer valid. The monitor will treat the reference to the ID as outdated. Since this reference is cited as an outgoing reference, the ACTIVAT E calls performed after the same activation identifier will cause remote objects to be reactivated. If the object is unknown to the ActivationMonitor, this method will throw unknownObjectException. If the remote call fails, the RemoteExce Ption is thrown.

ActiveObject call Notification ActivationMonitor and ID The object is now active. Parameter OBJ is a group representation of the STUB of the object. If an object in the group is activated through other methods, not by the system (that is, the object is registered and "activating" yourself), the ActivationGroup must notify the monitor. If the identifier of the object is not registered, the method will throw unknownObjectException. If the remote call fails, it throws the RemoteException.

InactiveGroup call notification Monitor The group specified by ID and Incarnation is now inactive. Once the next request appears in the request of the active object in this group, the group will be renovated with a larger avatar. When all objects in the group report that they have been inactive, the group becomes a non-active group. If the ID is not registered, or the number of body is smaller than the current number of inclusions of the group, the method will throw unknownGroupexception. If the remote call fails, the RemoteExcepti ON is thrown. 7.4.4 ActivationInstantiator class ActivationInstantiator is responsible for creating an instance of an active object. The specific subclasses of ActivationGroup implements the NewInstance method to control the process of creating objects within the group.

Package java.rmi.activation;

Public Interface ActivationInstantiator Extends Java.rmi.Remote {Public MarshalledObject NewInstance (ActivationID ID, ActivationDesc Desc) Throws ActivationException, Java.rmi.RemoteException;}

In order to recreate an object with an activation identifier ID, a descriptor DESC, the activator needs to call the NewInstance method of the instantifier. The instance is responsible:

Use the getClassName method of the descriptor to determine the class of the object; the class (with getLocation method) is loaded from the CADEBase path obtained by the descriptor; the instance of this class is created by the special "activation" constructor of the class class. . This special constructor has two parameters: one is an object's ActivationID, and the other is a MARSHALLEDOBJECT containing an object-specific initial data; returns a MarshalledObject that contains the remote object it creates. The instance device is also responsible for reporting when it created or activated is no longer an active object, so it can perform the corresponding INACTIVEOBJECT call (details, see the ActivationGroup class) on its ActivationMonitor.

If the activation of the object fails, the NewInstance method will throw an ActivationException. If the remote call fails, the method will throw RemoteException.

7.4.5 ActivationGroupDesc Class Activation Group Descriptor ActivationGroupDesc The information you need to create or recreate the activation group (which will activate the same Java virtual machine on the activation group).

This descriptor contains:

The class name of the group, the group's CADEBase path (location of the group), "Group" object, which can contain object-specific initialization data. The class of objects must be a specific subclass of ActivationGroup. ActivationGroup subclasses are created or recreated with an ActivationGroup.createGroup static method, which will call special constructors containing the following two parameters:

The group's ActivationGroupId, the initialization data of this group (in java.rmi.marshalledObject)

Package java.rmi.activation;

Public Final Class ActivationGroupDesc imports java.io.serializable {

public ActivationGroupDesc (java.util.Properties props, CommandEnvironment env) ;; public ActivationGroupDesc (String className, String codebase, java.rmi.MarshalledObject data, java.util.Properties props, CommandEnvironment env);

Public string getclassname ();

Public string getLocation ();

Public java.rmi.marshalledObject getdata ();

Public commandenvironment getcommandenvironment ();

Public Java.util.properties getPropertiesoverrides ();

} The first constructor will create a group descriptor that uses the default value of the system to the implementation and code location. Each property specifies the Java environment overlay (it will override the system properties in the virtual machine). The command environment can control the exact commands / options used when the promoter virtual machine can also be NULL to accept the default value of the RM ID.

The second constructor is the same as the first, but it allows the specified Properties and Commandenvironm Ent.

GetClassName method returns the group name.

GetLocation method Returns the CADEBASE path to load the class of the group.

The getData method returns the initialization data of the group in group form.

The getcommandenvironment method returns the command environment (possibly null).

The GetPropertiesoverrides method returns the properties of the descriptor (possibly null).

7.4.6 ActivationGroupDesc.comMandenvironment class Commandenvironment class Allows overwriting the default system properties and can specify options defined by the implementation for ActivationGrou P.

Public Static Class Commandenvironment

implements java.io.Serializable {public CommandEnvironment (String cmdpath, String [] args); public boolean equals (java.lang.Object); public String [] getCommandOptions (); public String getCommandPath (); public int hashCode (); }

The constructor will create Commandenv Ironment with the give command cmdpath and another command line option args.

Equals implement the content equivalent operation of the command environment object. Appropriate implementation of the HashCode method can be stored in the hash table when necessary.

GetCommandOptions method Returns the command line option for the environment object.

GetCommandPath method Returns the command string of the environment object.

7.4.7 The identifier of the activation group registered by the ActivationGroupID class can have the following uses:

The unique identifier of the group is uniquely identified in the activation system contains references to the group's activation system, and thus the component can contact it to activate the system. ActivationGroupID will be returned while calling Activationsystem.RegisterGroup and is used to identify the group within the activation system. When creating or recreating activation groups, the group identifier will be made as a special constructor for the active group.

Package java.rmi.activation;

Public class activitygroupid item java.io.serializable {public activity intersystem; public activationsystem getSystem ();

Public Boolean Equals (Object Obj);

Public Int hascode ();

The ActivationGroupID constructor creates a unique group identifier. The Activationsys Tem of this identifier is System.

GetSystem method returns to the group's activation system.

The HashCode method returns the hash code of the group identifier. Two group identifiers to the same remote group will have the same hash code.

The equals method compares the equivalence of the contents of the two group identifiers. If the following two conditions are established, the method will return TRUE: 1) Two unique identifiers are equivalent to the content. 2) The activation system specified in each identifier is referenced by the same remote object.

7.4.8 ActivationGroup class ActivationGroup is responsible for creating a new instance of the "Activated" object in its group, and notifies its ActivationMonitor when the following is the following: The object is turned into activity or non-active, or the entire group becomes non-active.

ActivationGroup was originally created by one of the following methods:

As the departure of the "Default" ActivationDesc, a "default" ActivationDesc, creating an explicit call to the ActivationGroup.createGroup method, is created as a deputy efficiency when the first object is activated in the group (which is only ActiVationGroupDesc registered). create. Only the activator can recreate ActivationGroup. If necessary, the actuator will generate a separate virtual machine (e.g., as a sub-process) for each registered activation group and direct the active request to the corresponding group. The way to generate virtual machines is related to implementation. The activation group is created by the ActivationGroup.createGroup static method. The CreateGroup method has two requirements for the upcoming group: 1) This group must be a specific subclass of ActivationGroup; 2) This group must have a constructor that takes the following two parameters:

The ActivationGroupId of the group, the initialization data (included in MarshalledObject) is created, and the default implementation of ActivationGroup will set the system properties to force system properties when creating the group's ActivationGroupDesc, and set the security manager to Java. Rmi.rmisecu RityManager. If the application requires some specific properties when the object is activated in the group, the application should set these properties before creating ActivationDesc (before the default ActivationGroupDesc created).

Package java.rmi.activation;

Public Abstract Class ActivationGroup Extends UnicastRemoteObject Implements ActivationInstantiator {Protected ActivationGroup (ActivationGroupid GroupID) THROWS JAVA.RMI.RemoteException;

Public Abstract MarshalledObject NewInstance (ActivationID ID, ActivationDesc Desc) Throws ActivationException, Java.rmi.RemoteException;

public abstract boolean inactiveObject (ActivationID id) throws ActivationException, UnknownObjectException, java.rmi.RemoteException; public static ActivationGroup createGroup (ActivationGroupID id, ActivationGroupDesc desc, long incarnation) throws ActivationException;

Public static activationgroupid currentGroupId ();

Public Static Void Setsystem (ActivationSystem System) Throws ActivationException;

Public static activationsystem getSystem () throws activityException;

Protected Void ActiveObject (ActivationID ID, Java.rmi.MarshalledObject Mobj) Throws ActivationException, UNKNOWNOBJECTEXCEPTION, JAVA.RMI.RemoteException;

Protected void inactivegroup () throws unknownGroupException, java.rmi.RemoteException;

Activation activates an object with activation descriptor DESC by calling the NewInstance method of the activation group. The activation group is responsible:

The class of the object is determined by the getClassName method of the descriptor; load this class from the URL path obtained in the descriptor by the getLocation method; instance of this class is created by calling the special constructor of the object class. This constructor takes two variables: object's ActivationID and MarshalledObject containing object initialization data; the serialization version of the remote object that will be created is returned to the activator. If you cannot create an instance of the descriptor, the method will throw an ActivationException.

The call to the inactiveObject method for this group is indirect by calling the active.inactive method. When the remote object is deactivated (this object is considered non-active), the implementation of the object must call the Activatable INact. If the object does not call Activatable.i Nactive when non-active, the object will never be collected as garbage because the group will reserve strong references to the object it created.

The group's INACTIVEOBJECT method prevents the remote object associated with the ID from the RMI runtime (only when there is no call to the object to be determined or being executed). Make the object will not be able to receive the RMI call. If the object is currently available or being called, INACTIVEOBJECT will return false and do not take any action.

If UNEXPORTOBJECT operations success, it means that the object does not have a call to be determined or being executed. This time group will notify its ActivationMonitor that the remote object is currently non-active by the monitor's INACTIVEOBJECT method so that the activator will re-activate the remote object when receiving the next activation request. If the operation is successful, INACTIVEOBJECT will return True. If the object is considered active by ActivationG Roup but has been prevented from being exported, the operation will still be successful.

If the activation group does not know the object (for example, the object has previously reported to be non-active, or if the activation group is not active, the inactiveObject method will throw unknownObjectEx Ception. If the non-active operation fails (for example, the remote call of the actuator or activation group fails), the RemoteException will be thrown. The CreateGroup method will create and set up the activation group for the current virtual machine. It can only be set to it if the activation group is currently not set. When Activator starts a recreation process of an activation group in order to perform the Activate request, the activation group is set by the CreateGroup method. The group must first register a descriptor to the Activationsystem, and then you can create the group with this method (passing the ActivationID to it).

The group specified by ActivationGroupDesc (ie DESC) must be the specific subclass of ActivationGroup and has a common constructor. The common constructor takes two parameters: one is a group's Activative NGroupID; the other is MarshalledObject, which contains the group's initialization data (obtained from the group's Activ atGroupDesc). Note: If the application wants to create its own custom activation group, the group must set the security manager in the constructor. Otherwise, the object will not be activated in this group.

After creating a group, the ActivationSystem This group has been activated by calling the ActiveGroup method (this method will return the ActiVationMonitor). Applications do not have to be called alone because the CreateGroup method will be responsible for this call.

Once the group is created, subsequent calls to the currentgroupID method will return the identifier of the group until the group becomes a non-active group. At that time, the currentgroupid method returned NULL.

Parameters incarnation indicates the current grouping, that is, the number of times the group is activated. Once the group is created, the avatar is used as the parameter used as the ActiveGroup method. The number of avatars starts with 0. If the group already exists, the CreateGroup method will throw an ActivationE Xcection.

Setsystem method is used to set up ActivationSystem (System) of the virtual machine. The activation system can be set to the activation system only if there is currently no grouping event group. If you do not have an activation system by explicitly calling SetSystem, the getSystem method will try to get a reference to Activationsystem by checking the name java.rmi.activation.activationsystem in an Activator's registration service program. By default, the port number used to find the activation system will be defined by ActivationSystem.SYST EM_PORT. This port can be overwritten by setting the properties java.rmi.activation.port. If you call SetSystem, the activation system has been set, then the method will throw an ActivationExce Ption.

The GetSystem method returns the activation system of the virtual machine. The activation system can be set by the setsystem method (aforementioned).

The ActiveObject method is a protected approach. Subclasses will use it to make an Active Object callback to the group monitor to notify the monitor with a remote object that specifies the activation ID and its stub is now active. This call just forwards the ActivationMonitor to the group. The InactiveGroup method is a protected approach. Subclasses use it to notify the group monitor This group has become non-active. When the objects that activate the activity in the group in the group become non-active, the subclasses are called.

7.4.9 MARSHALLEDOBJECT class MarshalledObject is a container for an object, which allows the object as a parameter when the RMI call is performed, but it delays the sequence recovery of the object in the receiving end until the application explicitly requests This object (by calling the container object). The sequential object contained in this MarshalledObject is serialized and serially recovered (requests when transmitting parameters in the RMI call) (request). That is, any of the remote objects in MarshalledObject can be shown as a serialization example of its STUB. The objects included in MarshalledObject can be a full graphic for remote objects, non-remote objects, or remote objects and non-remote objects.

When the object is placed in the Wrapper of MarshalledObject, the sequence form of the object will be commented as CADEBASE URL (which can be loaded); also, when the object is removed from the Wrapper from the object's MarshaledObject, if the local does not The code of the object is used to locate and load the byte code of the object class using the URL (serialized).

Package java.rmi;

Public Final Class MarshalledObject Implements Java.io.Serializable {Public MarshalledObject (Object Obj) THROWS JAVA.IOEXCEPTION;

Public Object Get () throws java.io.ioException, ClassNotFoundException

Public int hashcode ();

Public Boolean Equals ();

The constructor of MarshalledObject will serve as a single parameter, and store the group of objects in the byte stream. The object's group indicates the semantics that the object is transmitted when the object is transmitted during the RMI call:

Each class in the stream is annotated as its CADEBASE URL to find the byte code of each class when reconstructing the object (by calling the GET method); the remote object is replaced by their proxy server stub. When the instance of the class MarshalledObject is written in java.io.ObjectOutputStream, the group form (created in the configuration) is also written in the stream. Therefore, only word throttle is serialized.

When you read MarshaledObject from Java.io.ObjectInputStream, the included object sequence is not returned to a specific object; the object will always maintain its group representation until the GET method of the set group object is called.

The GET method always uses the form of the object contained to reconstruct the object. The internal representation will be serialized with the semantics used in the decnation parameter (for RMI call). Therefore, the sequence of sequence represented by the object will be loaded with the URL annotation in the stream of the target (if there is no code). The HashCode represented by the object group is the same as the object passed to the constructor. If the group representation of the comparison object is equivalent, the Equals method will return true. The equals method is annotated than the CADEBASE of the ignored class, that is, in addition to the CADEBASE of each class in serialization, only two objects have the same serialization, the two objects are equivalent.

RMI Specification (8) Chapter 8

This chapter contains the interfaces and classes used by the RMIC STUB compile generated.

Topic: Remotestub Class RemoteCall Interface RemoteRef Interface ServerRef Interface Skeleton Interface Operation Class

8.1 RemoteStub class java.rmi.server.Remotestub class is a general superclass for remote object stub. The Stub object is a proxy, which is the same as defined by the remote interface set and the actual implementation of the remote object.

package java.rmi.server; public abstract class RemoteStub extends java.rmi.RemoteObject {protected RemoteStub (); protected RemoteStub (RemoteRef ref); protected static void setRef (RemoteStub stub, RemoteRef ref);}

The first constructor of RemoteStub will create stub with empty remote reference. The second constructor will create stub with a given remote reference REF.

Use (and not supported) SetRef methods in JDK1.2.

8.1.1 The type of remote object and the Type of the Stub class can interact with the Stub (Agent) object, which is identical to the remote object class as defined by the remote object class. Since the STUB class is generated by the implementation class essence that implements one or more remote interfaces, the Stub class does not include the non-remote portion of the class level (the type of object of the object). For example, if c extension B is expanded A, but only b implements a remote interface, Stub will be generated by B, not C.

Since the STUB implements the same remote interface set as the remote object class, the Stub has the same type as the remote portion of the server object type map from the view of the Java system. In this way, the client can use the built-in Java operation to check the type of the remote object, and can also convert from a remote interface to another remote interface.

STUB is generated with the RMIC compiler. 8.1.2 Declaring Semantic Semantic Semantic Ways The following method is declared in the java.lang.object class as the final FINAL, so it cannot be overwritten by any implementation:

The default implementation of GetClass Notify NotifyAll Wait getClass is suitable for all Java objects (local or remote); for remote objects, this method does not require specialized implementation. The GetClass method is used on remote stub, which reports the exact type of the STUB object generated by the RMIC. Note that the Stub type only reflects the remote interface implemented by the remote object, not the local interface.

The WAIT and Notify methods of java.lang.object will process the waiting and notifications in the Java language thread model context. While using these methods for remote STUBs do not violate the Java thread model, the semantics of these methods will be different from the semantics used for local Java objects. In particular, when using these methods, it will be a client-specific object of remote objects, not the actual object of a remote site. 8.2 RemoteCall Interface RemoteCall is the abstract interface used by the Stub and Skeleton of the remote object to perform calls to the remote object.

-------------------------------------------------- ------------------------------

Note - RemoteCall interface is not encouraged in JDK 1.2. The JDK 1.2 Stub protocol has no longer use this interface. Now, STUB uses a new Invoke method in JDK 1.2, which does not need to use RemoteCall as a parameter.

-------------------------------------------------- ------------------------------

Package java.rmi.server; import java.io. *;

public interface RemoteCall {ObjectOutput getOutputStream () throws IOException; void releaseOutputStream () throws IOException; ObjectInput getInputStream () throws IOException; void releaseInputStream () throws IOException; ObjectOutput getResultStream (boolean success) throws IOException, StreamCorruptedException; void executeCall () throws Exception; Void done () throws oException;

Method GetputstReam returns the output stream. Stub will group parameters to group, or Skeleton will group the result.

Method ReleaseoutputStream releases the output stream. In some transmissions, this will result in release flow.

Method GetInputStream Returns INPUTSTREAM. STUB solves the result, or Skeleton is interpreted from the parameters.

Method ReleaseInputStream releases the input stream. This will allow some to transfer the input of the connection in advance.

Method GetResultStream returns the output stream (after writing the title information related to the call success). Each remote call will only get a result stream. If SUCCESS is true, the result to group is normal to return; otherwise the result is exception. If the result stream of the remote call has been obtained, StreamCorruptedException is thrown.

Methods EXECUTECALL does the invocation that can be performed.

The method DONE allows clearance after completing the remote call. .3 RemoteRef interface server Remoteref represents the handle of the remote object. Each STUB includes an instance of RemoteRef, including specific representation of references. This remote reference will be used to perform remote modes on its representative remote objects.

Package java.rmi.server;

public interface RemoteRef extends java.io.Externalizable {Object invoke (Remote obj, java.lang.reflect.Method method, Object [] params, long opnum) throws Exception; RemoteCall newCall (RemoteObject obj, Operation [] op, int opnum, long hash) throws RemoteException; void invoke (RemoteCall call) throws Exception; void done (RemoteCall call) throws RemoteException; String getRefClass (java.io.ObjectOutput out); int remoteHashCode (); boolean remoteEquals (RemoteRef obj); String remoteToString ( }

The first invoke method calls the agent to the remote reference of Stub (obj), and allows the reference to establish a connection to the remote host, group some representations of the Method and Parameters Params, and then use the method call to communicate with the remote host. This method returns the method of the method calling the remote object on the remote host, or throws RemoteException when the call fails, and throws the application-level exception when the remote call is thrown out. Note that the operation number OPNUM represents a hash method signature to encode the method to be transmitted.

OPNUM's method has a 64-bit (long) integer, which is based on the security hash algorithm (SHA-1) of the National Standard Technology Bureau (SHA-1), calculated using the first two 32-bit values of the word current flow message. Come. The byte stream contains a UTF encoding of a string composed of a remote method descriptor (see a description of the method descriptor, see Section 4.3.3 of the Java Virtual Machine Specification). The hash value will be worth it from the first and second 32-bit of the SHA-1.

Long Hash = SHA [1] << 32 SHA [0]

-------------------------------------------------- ------------------------------

Note - NewCall, Invoke, and Done methods are not encouraged in JDK 1.2. These methods are not used by RMIC. The call sequence consisting of NewCall, Invoke, and D One has been replaced by the new INVOKE method, which makes the Method object as a parameter.

-------------------------------------------------- ------------------------------

Method NewCall will create a corresponding call object to a new remote method on the remote object OBJ. The operating array OP contains an available operation on the remote object. The operation number OPNUM is an index of an operator array, which specifies the specific operation of the remote call. Transfer Operation Arch and Index Enables the STUB generator to assign an operation index and explain. Remote references may require an operation instructions to encode in the call.

Method INVOKE is responsible for performing remote calls. Invoke will produce "users" exceptions that can be passed through and not captured by Stub. If an exception is generated during the remote call, INVOKE should be noted to clear the connection before generating "user exception" or RemoteException.

Method DONE allows remote reference to clear (or reuse) connections. DONE should only be called only when the Invoke call has been successfully (non-abnormal) returns Stub. Method GetRefClass returns a full name that will be serialized to the reference type of the reference type of OUT.

Method RemoteHashCode returns the hash code of the remote object. Two remote objects of the same remote object will have the same hash code (to support the remote object as a key value) in the hash table). Remote Object will forward the call to its HashCode method to the remote reference RemoteHashCode method.

Method Remoteequals compares the equivalence of two remote objects. If the two remote objects reference the same remote object, they think they are equivalent. For example, if the two stub references the same remote object, they are considered to be equivalent. RemoteObject will forward the call to its equals method to the R Emoteequals method for remote references.

Method RemoteTString returns a String that represents the reference to the remote object.

8.4 ServerRef interface interface serverRef represents the server-side handle implemented by the remote object.

Package java.rmi.server;

Public interface serverref extends remotref {

Remotestub ExportObject (java.rmi.remote obj, object data) throws java.rmi.remoteException;

String getClientHost () throws serverNotactiveException;}

Methods ExportObject will implement OBJ lookup or create a client St UB object for the Remote object provided. Parameter data contains information required to export objects (such as port numbers).

Method getClientHost returns the host name of the current client. When it is currently handling thread calls that are handled by the remote object, the client host name that is executed is returned. Call ServerNotActiveException if the current remote method call is not in service.

8.5 The Skeleton interface interface Skeleton can only be implemented by the RMIC compiler. The SKE LETON of the remote object is an entity of the server, which will assign allocation calls for actual remote objects.

-------------------------------------------------- ------------------------------

Note - The Skeleton interface is not encouraged in JDK1.2. This interface is implemented for each 1.1 (and the Skeleton) SK Eleton class generated by the RMIC STUB compiler (and the default RMIC -VCompat generated by default RMIC -VCompat). The JDK1.2 compatible version is assigned a remote method call will no longer need Ske Leton. To generate STUB compatible with JDK1.2 or higher, use the command RMIC with option -V1.2.

-------------------------------------------------- ------------------------------

Package java.rmi.server;

Public interface skeleton {

Void Dispatch (Remote Obj, RemoteCall Call, INT OPNUM, Long Hash) THROWS EXCEPTION; Operation [] getOperations ();

The Dispatch method will decnation parameters in the input stream obtained in the CALL object, call the method on the actual remote object real OBJ (represented by the operation number OPNUM), and then group the return value. If an abnormality occurs during the transfer process, the exception is thrown. The GetOperations method returns an array of operation descriptors that contain remote object methods. 8.6 Operation Class Operation contains a description of the Java method for the remote object.

-------------------------------------------------- ------------------------------

Note - The Operation interface is not encouraged in JDK 1.2. The JDK 1.2 Stub protocol no longer uses the original, with Operation as the parameters of the Remoteref.invoke method. Stub uses a new Invoke method in JDK 1.2, which no longer requires Operation as a parameter.

-------------------------------------------------- ------------------------------

Package java.rmi.server;

Public class operation {

Public operation (String OP);

Public String getoperation ();

Public String toString ();

It usually has a method signature when constructing an Operation object.

Method GetOperation returns the content of the operation descriptor (the value used when initialized).

Method TOSTRING also returns a string representation of the operation descriptor (usually a method signature).

RMI Specification (9) Chapter 9

The interfaces in this chapter are used in the distributed garbage collector (DGC) of RMI.

Topic: Interface DGC Lease class OBJID class UID class VMID class 9.1 Interface DGC DGC Abstract server side for distributed garbage collection algorithm. This interface contains two methods: Dirty and Clean. DIRTY is called when the remote reference is on the client (the client is represented by VMID). When there is no longer there is a reference to the remote reference, the corresponding cleanup call is performed. Failed D Irty calls must be scheduled to be a Strong (Strong) Clean call to retain the call sequence number, from the detection, after the disorderly call received by the distributed garbage collector.

References to remote objects will have this reference to client rental (Leased) for a while. The rental period begins when the Dirty is received. The client must call DIRTY again on the remote reference before lease expires for renewal. If you don't renew until the expiration, the distributed garbage collector believes that the client will no longer reference the remote object.

Package java.rmi.dgc; import java.rmi.server.objid;

Public Interface DGC Extends Java.rmi.Remote {

Lease Dirty (Objid [] iDS, long seat lese) throws java.rmi.remoteexception;

Void Clean (Objid [] iDS, Long Seqnum, VMID VMID, Boolean Strong) THROWS JAVA.RMI.RemoteException;}

Method DIRTY requests the rental object reference associated with an object identifier contained in array parameter IDs. Lease contains the client unique virtual machine identifier (VMID) and the rented rent period. The garbage collector will preserve a Reference List (Reference List)-Save the referenced client list for the remote objects exported in each local virtual machine. If you are giving, the garbage collector will add the client VMID into the reference list of each remote object indicated in the I DS. SequenceNum is used to detect and discard the sequence number of the post-lateral garbage collector call. Each time you call the garbage collector, the sequence number will increase. Some clients cannot generate unique VMIDs. This is because only the unique unique identifier when the VMID contains the True host address. Some clients will not be able to get the address due to security restrictions. In this case, the client can use empty VMID. Distributed garbage collectors will assign VMIDs to clients.

Dirty calls will return the Lease object, which contains the VMID and permitted rents used by remote references (the server can decide to grant a breech period than the client requests). The client must use the VMID used in the garbage collector to perform the corresponding Clean calls when the client releases the remote object reference.

Customer virtual machines only need initial Dirty calls for remote references referenced in each virtual machine (even if it is a multiple reference to the same remote object). In addition, the client must also call DIR TY to renew the rental of remote references before lease expire. When the client does not have any references to a specific remote object, the object IDs associated with this reference must be scheduled for a Clean call.

The Clean call removes the VMID from the reference list of the remote object specified by the IDS. The sequence number is used to detect the following cleanup operation. If the parameter strong is true, the CLEAN call is the result of a failed DI RTY call. At this point, you should remember the sequence number of the client VMID.

9.2 Lease class lease contains a unique virtual machine identifier and a rent period. Lease objects are used to request and grant rental of remote object references.

Package java.rmi.dgc;

Public Final Class Lease IMPLEments Java.io.SeriRizable {

Public Lease (VMID ID, long duration);

Public vmid getVmid ();

Public long getValue ();

The Lease constructor creates rental with specific VMID and rent period. VMID can be NULL.

GetVMID method Returns the client VMID associated with the lease.

GetValue method Returns the rental period.

9.3 Objid class OBJID is used as a unique identifier for remote objects as a virtual machine. Each identifier contains an object number and a unique address space identifier on a particular host. The object identifier will assign the object when exporting the remote object.

Objid consists of a unique identifier (UID) of the object number (long) and address space.

Package java.rmi.server;

Public Final Class Objid Implements Java.io.Serializable {

Public Objid ();

Public Objid (int Num);

Public void write (ObjectOutput out) throws java.io.ioException;

Public Static Objid Read (ObjectInput in) THROWS JAVA.IO.IEXCEPTION;

Public int hashcode ()

Public Boolean Equals (Object Obj)

Public String Tostring ()}

The first form of the OBJID constructor will generate a unique object identifier. The second constructor generates a known object identifier (eg, the identifier used by the registration service program and distributed garbage collector), and uses the known object number as a parameter. The known object ID generated by the second constructor does not conflict with the object ID generated by the default constructor; for forced implementation, the object number of the Objid will be set to "known" in the constructor. At the same time all UID domains will be set to zero. Method WRITE groups the representation of the object ID into the output stream.

Method Read constructs an object ID whose content reads from the specified input stream.

Methods HashCode returns the object number as a HashCode.

If the OBJ is the same as the OBJID content, the equals method returns True.

The TOSTRING method returns a string containing the object ID representation. The address space identifier will be in a string representation only when the object ID comes from a non-local address space.

.4 UID class UID is an abstract class that creates a unique identifier for generating its host. It will be in the form of address space identifiers in Objid. The UID is consisting of a unique number (int), time (long), and counting on the host.

Package java.rmi.server;

Public Final Class Uid Implements Java.io.Serializable {

Public UID ();

Public UID (Short Num);

Public int hashcode ();

Public Boolean Equals (Object Obj);

Public String Tostring ();

Public void write (DataOutput out) throws java.io.ioException;

Public Static Uid Read (DataInput in) THROWS JAVA.IO.IEXCEPTION;

The first form of the constructor will create a unique pure identifier generating its host. This UID has uniqueness under the following conditions: a) The computer takes a second or more time to restart, b) The computer's clock will never be adjusted forward. In order to construct the global unique UID, simply pair the UID and INetAddress respectively.

The second form of constructor will create a known UID. IDs are known to have 216 -1 possible. The ID generated by this constructor does not conflict with the ID conflicts generated by the default UID constructor. The default constructor generates a true unique identifier on the host.

Methods HashCode, Equals and Tostring are defined for UID. If the two UIDs are the same, they are considered equivalent.

Method Write will write the UID to the output stream.

Method Read constructs a UID whose content will be read from the specified input stream.

RMI Specification (10) RMI Communication Protocol

10.1 Overview The RMI protocol uses the other two protocols as its in communication format: Java object serialization and HTTP. Object serialization protocol is used to group calls and return data. The HTTP protocol is used for "transmission" remote method calls and returns data when cases allow. Each protocol has a special grammar document. Non-end symbols in the product rules may reference the rules managed by other protocols (object serialization or HTTP). The subsequent product will use the embedded protocol when crossing the protocol boundaries.

Description of the symbols We use similar symbols in the Java Language Norm (see Section 2.3 of JLS). The control code in the stream is represented by the text value of the hexadecimal form. Some non-final symbols in the syntax indicate values related to the application provided in the call. This definition of this non-end synonym consists of its Java type. The syntax is behind these non-terminating characters to the corresponding type of table. 10.2 RMI Transfer Protocol RMI communication format is represented by stream. The term used herein is from the perspective of the client. OUT refers to the output message, and IN fingers enter a message. The content of the transfer title is not formatted with object serialization. Stream: Out in

The inputs and output streams used by RMI are paired. Each OUT stream has a corresponding IN stream. In the grammar, the OUT flows into the output stream (from the client angle). Inflow (in the grammatical) will match the input of the corresponding socket. Since the output and input stream are paired, the only header information in the input stream is a confirmation that represents whether to understand the protocol; other title information (such as magic numbers and version numbers) will be impossible to the context of the flow.

10.2.1 Output stream in the output stream format RMI consists of a message sequence after transmitting title information. In addition, the output stream can also include calls embedded in the HTTP protocol.

Out: Header Messages httpMessage

Header: 0x4a 0x52 0x4d 0x49 Version Protocol

Version: 0x00 0x01

Protocol: streamprotocol Singleopprotocol MultiplexProtocol

StreetProtocol: 0x4b

SINGLEOPPROTOCOL: 0X4C

MultiplexProtocol: 0x4D

Messages: Message Messages Message

Messages will be packaged in the specific protocol specified by Protocol. For SingleopProtocol, the HE ADER may have only one message, and the Message is not packaged in other data. Single Opprotocol is used in the HTTP request, where requests and responses can only be one.

For StreamProtocol and MultiplexProtocol, the server must use byte 0x4e (indicate support protocol) and EndPointIdentifier (including host name and port number, the server can see if they are used by the client). If this is not performed due to safety reasons, the client can use this information to determine its hostname. Subsequently, the client must respond with another EndPointIdentifier that contains default endpoints that accept the connection. For MultiplexProtocol, the server can use it to identify the client.

For streamprotocol, after this endpoint negotiation, Messages will be sent on the output stream without further packaging the data. For MULTIPLEXPROTOCOL, the socket will be used as a specific connection to multiplexed connections, as described in Section 10.6 "RMI Multiplex Protocol". The virtual connection initialized in this multiplexing connection is composed of a series of Messages, as described below.

There are three output messages: Call, Ping and DGCACK. Call will encode method calls. PIN G is a transmission-level message for testing activity of remote virtual machines. DGCACK is a confirmation of a distributed garbage collector for a server indicating that the client has received a remote object in the server return value.

Message: Call Ping DGCACK

Call: 0x50 CallData

PING: 0x52dgcack: 0x54 UniqueIdentifier

10.2.2 Input flow format The current input information has three: Returndata, httpreturn, and pingack. Returndata is the result of "Normal" RMI call. HTTPRETURN is the return result of embedded calls in the HTTP protocol. P IngAck is a confirmation for ping messages.

In: Protocolack Returns protocolnotsupported httpreturn

Protocolack: 0x4e

Protocolnotsupported: 0x4f

Returns: Return Returns Return

Return: Returndata pingack

Returndata: 0x51 ReturnValue

Pingack: 0x53 10.3 RMI Use the call and return data in the RMI call of the object serialization protocol to format the Java object serialization protocol. Each method called CallData is expressed as ObjectIdentifier (called target), Operation (representing the number to call the method), is HASH (check whether the client stub is used by the remote object SKELETON using the same Stub protocol), followed by the zero called the call Or list of multiple parameters.

In the JDK1.1 Stub protocol, the Operation represents the method number (allocated by the RMIC), and Hash is a STUB / SKELETON hash, which is the STUB interface hash. In the JDK1.2 Stub Protocol (using the RMIC generated JDK1.2 STUB with -V1.2 option), the value of Operation is -1 and hash represents the hash of the method to call. Hands will be described in the "Remoteref Interface" section.

CallData: ObjectIdentifier Operation Hash Argumentsopt

Objectidentifier: ObjectNumber UniqueIndifier

UNIQUEIDENTIFIER: NUMBER TIME COUNT

Arguments: Value Arguments Value

Value: Object Primitive

RETURNVALUE called by RMI is composed of UN iQUEIDentifier that indicates the return code that is returned by normal or exception, and is used to return the result of the following returns to the following returns to the following return results when necessary: returned or thrown.

ReturnValue: 0x01 UniqueIdentifier Valueopt 0x02 UniqueIdentifier Exc Eption

-------------------------------------------------- ------------------------------

Note - ObjectIdentifier, UniqueIdentifier, and EndPointIdIndiDentifier are not written in default, but each uses their own WRITE method (but not used by the WriteObject method used); each identifier's WRITE method continuously Add to the output stream.

-------------------------------------------------- ------------------------------

10.3.1 Class Note and Class Loading RMI covers the AnnotateClas S and ResolVeclass methods of ObjectOutputStream and ObjectInputStream, respectively. Each class uses the CodeBase URL (where the location of this class) is used. The Query of this class is loaded in the AnnotateClass method to obtain its CodeBase URL. If the class loader is non-empty and its CodeBase is also non-empty, the CodeBase is written in the stream using the ObjectOutputStream.wr IteObject method; otherwise use the WriteObject method to write a null value. Note: It is best not to annotate classes in the "Java" package because they are always available for recipients. Class Note is parsed by ObjectInputStream.ResolVeclass method during serialization recovery. The resolveclass method first reads note using the ObjectInputStream.ReadObject method. If the CodeBase URL is non-empty, it gets the URL class loader and attempts to load the class. Using the Java.Net.urConnection to get the class byte, the class can be loaded (the same as the mechanism used to the web browser Applet class loader).

10.4 RMI The use of the HTTP POST protocol In order to call remote methods through the firewall, some RMI calls use HTTP protocols, especially HTTP POST. The URL specified in the transfer title can be one of the following:

http: //: / http: /// cgi-bin / java-rmi? Forward =

The first URL is used to communicate directly with the RMI server on a particular Host and Port. The second form of URL is used to invoke the "CGI" script on the server, which will forward the call to the server on the specified port.

HttppostHeader is a standard HTTP title for POST requests. HTTPRESPONSEHEADER is a standard HTTP response to the delivery process. If the response status code is not 200, it is considered not to return a value. Note You can only embed an RMI call in an HTTP POST request.

HttpMessage: httppostheader header message

Httpreturn: httpresponseheader return

-------------------------------------------------- ------------------------------

Note - Only SingleopProtocol appears in the title of HttpMessage. HTTPRETURN does not include bytes for confirming the protocol.

-------------------------------------------------- -------------------- ---------- 10.5 RMI's value related to the application of this table lists the representatives and applications used by RMI Non-final symbol of the value. This table maps each symbol to the corresponding type. Each symbol is used to format the protocol it embedded.

Count Short

Exception java.lang.exception

Hash long

Hostname UTF

Number Int

Object java.lang.Object

Objectnumber Long

Operation Int

Portnumber Int

Primitive Byte, int, short, long ...

Time long

10.6 The purpose of the multi-channel multiplex protocol multi-channel multiplexing is to provide a model, two endpoints can open a plurality of full-duplex connections to the other endpoint, and in the same environment, use other tools (for example When the TCP connection is connected, only one endpoint can open such a two-way connection. With this simple multiplex protocol, RMI can allow customers to connect to RMI's server objects in the case where certain other protocols are unable to force. For example, some security managers of some applets do not allow the server that can be created to listen to to prevent this APPL ET from exporting RMI objects from direct sockets and providing remote call services. However, if the app LET can open the normal socket connection of its CodeBase host, it can use multiple multiplex protocols on this connection to allow the CodeBase host to call the role of the RMI object exported by the applet. This section describes the formats and rules of multiplex protocols. ?

10.6.1 Definition This section defines the terminology that will be used in the rest of the protocol.

Endpoint is one of two users connected to multiplex protocols.

The multiplex protocol must be on the existing two-way reliable byte stream, assuming that one endpoint is initialized to the other endpoint. In the current RMI usage, it is usually a TCP connection, which is created by the Java.NET.SOCK ET object. This connection is called a specific connection.

The multiplex protocol helps the virtual connection. The virtual connection itself is a two-way reliable byte stream that represents a specific session between two endpoints. A virtual connection set between two endpoints constitutes a multi-channel multiplex connection. Using multiple multiplex protocols, virtual connections can be opened and closed by any endpoint. The virtual connection relative to the status of the given end is defined by multiple multiplex protocol elements transmitted and received on a specific connection. This state involves the connection whether the actual data and related stream control mechanisms are turned on or off. If there is no specification, the rest in this section will use the term connection to the virtual connection.

The virtual connection within the given multiplexing connection is identified by a 16-bit integer identifier called a connection identifier. Thus, there may be 65,536 virtual connections in a multiplexed connection. Implementation may limit the number of virtual connections that can be used at the same time.

10.6.2 Connection status and flow control connection are controlled by various operations defined by multiplex protocols. Below is the operand defined by the protocol: Op En, Close, Closeack, Request, and Transmit. Accurate format and rules for all operations will be described in detail in Section 10.6.3 "Protocol Format".

Open, Close and Closeack operate the open and off, and the REQUEST and TRANSM IT operations are used to transmit data on the open connection in the limit of the flow control mechanism.

Connection state If the endpoint transmits the OPEN operation or the connected OPEN operation (and then there is no closed it), the virtual connection is turned on relative to the end point. The following describes different protocol operations.

If the endpoint sends a connection to the CLOSE operation, the CLOSE or CLOSE ACK operation is not received, the virtual connection is waiting to be closed relative to the endpoint.

If the endpoint has never opened the connection or receiving the connected close or Closeack operation (and then no open), the virtual connection is closed relative to the endpoint.

Stream Control Multiplexing Protocol Use a simple packet flow control mechanism to allow multiple virtual connections to be connected to the same specific connection. Advanced requirements for stream control mechanisms are independent status of all virtual connections; a status of a connection does not affect other connections. For example, if the data buffer that processes data from a connection is full, the data transfer and processing of other connections should not be made. This will be critical if the connection continues to depends on the end of another connection (for example, when recursive RMI calls). Thus, its practical significance is that all multi-multiplexing agreements that must be intensive and processed in a specific connection (assuming it to follow this specification). Each endpoint has two status values associated with each connection: the endpoint has requested but has not received the number of data bytes (input request) and the number of data bytes requested by the other endpoint but the endpoint has not provided (output Number of requests).

The output request of the endpoint will increase when receiving the Request operation from other endpoints, and will decrease when it sends a TR ANSMIT operation. The number of input requests for endpoints will increase when it sends a Request operation, and will decrease when it receives the Transmit operation. These values will violate the protocol if it is negative.

If the endpoint sends a request operation, its input request is increased and the number of bytes exceeds its currently no blocking process, it violates the protocol. However, if the connected user is waiting to read the data, make sure that its input request is greater than zero.

If the TRANSMIT operation sent by the endpoint contains more bytes than its output request, it violates the protocol. It can buffer external data until the user requests explicit refresh written to the connection to the connection. However, if the data must be transmitted on the connection because the explicit refresh or implementation of the input buffer, the connection user may be blocked until there is enough Transmit operation.

Under the premise of satisfying the above rules, implementation can be relatively free to send Request and Transmit operations. For example, if its input buffer is not empty, the endpoint can request more data of the connection.

10.6.3 The byte stream format of the protocol format multiplex protocol consists of a continuous variable length record sequence. The first byte recorded is an opcode that identifies the recorded operation and determines the format of its contents. We define the following legal opcode:

Value name

0xE1 Open

0xE2 Close

0xe3 Closeck

0xE4 Request

0xE5 Transmit

If the first byte of the record is not the defined opcode, the protocol is violated. The following sections describe the record format of each opcode.

Open operation below is the record format of the OPEN operation:

Size (byte) name description

1 OPCODE Operation Code (Open)

2 ID connection identifier

The endpoint will send the OPEN operation to open the specified connection. If the ID points to a connection that is now turned on or closes the send endpoint, it violates the protocol. After opening the connection, the input and request number status of the connection is zero on both endpoints.

The OPEN operation is received indicates that the other endpoint is opening the specified connection. Once the connection is opened, the output and request status of the connection are zero at both endpoints.

To prevent identifier between the two end points, the effective connection identifier space will be divided into two halves according to the value of the highest bit. Each endpoint only allows you to open a high level as a certain particular value. The endpoint that starts the specific connection must only open the connection in the nose as the identifier, and the other endpoint must only open the connection of zero. For example, if the RMI applet that cannot be created the server socket starts a multiplex connection to its CodeBase host, the applet can open the virtual connection of 0x8000-7FFF in the identifier range, and the server can open the identifier range of 0- 0x7FFF virtual connection.

CLOSE Operation The following is a recording format of a Close operation:

Size (byte) name description

1 OPCode Operation Code (OPEN) 2 ID Connection Identifier

The endpoint sends a Close action to close the specified connection. If the ID points to the connection to the transmit endpoint, it is currently closes or closes (if it has transmitted the Close operation of this connection, it may be a connection to the receiving endpoint, the connection is closed, and the protocol is violated. After sending a Close, the connection is a connection to the sending endpoint is about to turn off. Therefore, the endpoint will not reopen the connection until it receives the CLO SE or Closeack from the other endpoint.

The reception of the Close operation indicates that the other end point has turned off the specified connection, so the connection has been turned off on the receiving endpoint. Although the receiving endpoint may no longer send other operations for this connection (until it is opened again), it should still provide data in the implementation input buffer for this connection. If the connection has been turned on (instead of being closed), the receiving endpoint must be actuated with a Closeack operation.

Closeack Operation The following is a record format of a Closeack operation:

Size (byte) name description

1 OPCode Operation Code (OPEN)

2 ID connection identifier

The endpoint sends a Closeack operation to indicate that a Close operation from the received endpoint has been received. If the connection pointing to the ID point is not the connection to the receiving endpoint, it violates the protocol.

Receiving a Closeack operation can change the status of the specified connection from soon as it is closed, so the connection can be reopyed later.

REQUEST Operation The following is a recording format of the request operation:

Size (byte) name description

1 OPCode Operation Code (OPEN)

2 ID connection identifier

4 count number of number of bytes requested

Endpoint sends a request operation to increase the number of input requests for the specified connection. If the ID does not point to the connection to the send end point, it violates the protocol. The number of input requests for endpoints are incremented by values. The value of count is 32-bit symbolic integers. If it is negative or zero, it violates the protocol.

The received request will increase the output request of the specified connection by count. If the receiving endpoint is about to close, the request operation will be ignored.

TRANSMIT Operation The following is a record format for Transmit operations.

Size (byte) name description

1 OPCODE Operation Code (Open)

2 ID connection identifier

4 counts of COUNT transmission

Count Data Transport Data

After the endpoint sends a Transmit operation, it is only true to transfer data on the specified connection. If the ID does not point to the connection to the send endpoint, it violates the protocol. The output request of the endpoint is decremented by value count. The value of count is 32-bit symbolic integers. If it is negative or zero, it violates the protocol. If the transmit operation causes the number of output requests to be negative, the protocol is also violated.

The byte queue read from the connection will increase the data of the count byte when the Transmit operation is received. The number of input requests for the receiving endpoint is decremented by value count. If this makes the number of input requests become zero, and the connected user attempts to read more data, then the endpoint applies another request operation as a response. If the receiving endpoint is about to turn off, the Transmit operation will be ignored.

Violation of the protocol If the above violation of the protocol, or the communication error is detected in a specific connection, the multiplexed connection is turned off. The actual connection will be terminated, while all virtual connections are also closed immediately. The connected user can read the data that already read in the virtual connection.

转载请注明原文地址:https://www.9cbs.com/read-127733.html

9cbs

New Post(0)