Implementing Java Distributed Application with RMI

Java RMI (remote method invocation) is implemented in JDK1.1 with Java, which greatly enhances the ability of Java to develop distributed applications. Java as a rage network development language, its great power is embodied in its powerful development of distributed network applications, and RMI is the development of pure Java Network Distributed Application System is one of the core solutions. It can actually be viewed as a Java version of RPC. However, traditional RPC does not apply well to distributed object system. Java RMI, however, supports communication between program-level objects stored in different address spaces to achieve seamless remote invocation between remote objects. RMI is currently communicating using the Java Remote Message Exchange Protocol (JRMP) (Java sqlremote messaging Protocol). JRMP is a protocol designed specifically for Java remote objects. As a result, Java RMI has the advantages of "Write Once,run Anywhere" in Java and is a 100% pure Java solution for distributed Application systems. Application systems developed with Java RMI can be deployed on any platform that supports JRE (Java Run Environment Java, running environment). However, since JRMP is specifically designed for Java objects, RMI has insufficient support for application systems developed in non-Java languages. You cannot communicate with objects that are written in a non-Java language. This paper introduces how to use RMI to implement Java distributed application from the point of view of program.

Operating mechanism of RMI system

RMI applications typically include two separate programs: Server programs and client programs. A typical server application will create multiple remote objects so that the remote objects can be referenced, and then wait for the client to invoke the methods of these remote objects. Typically, a client program obtains a reference to one or more remote objects from the server, and then invokes the method of the remote object. RMI provides a mechanism for both server and client communication and information delivery.

In communication with remote objects, RMI uses the standard mechanism: stub and skeleton. The stub of the remote object serves as the client local representative or agent role for the remote object. The calling program will call the method of the local stub, and the local stub will be responsible for executing the method call to the remote object. In RMI, the stub of a remote object is the same as the set of remote interfaces that the remote object implements. When you call a stub's method, the following actions are performed: (1) Initializing the connection to the remote virtual machine that contains the remote object; (2) The parameters of the remote virtual machine are grouped (written and transmitted), (3) The result of the method call is awaited, (4) The return value or the exception returned, (5) The value is returned to the calling program. To show a simpler invocation mechanism to the caller, the stub hides the details of the serialization of parameters and network-level communication. In a remote virtual machine, each remote object can have a corresponding skeleton (no use of skeleton in a JDK1.2 environment). Skeleton is responsible for assigning the call to the actual remote object implementation. It performs the following actions when receiving a method call: (1) decoding (reading) The parameters of the remote method, (2) Invoking the method on the actual remote object implementation, (3) marshalling (writing and transmitting) The result (the return value or exception) to the calling program. Stubs and skeleton are generated by the Rmic compiler.

Using RMI to write distributed object applications needs to do the following: (1) Locate the remote object. An application can use one of two mechanisms to get a reference to a remote object. It can either register its remote object with the RMI simple naming tool rmiregistry, or it may pass and return the remote object reference as part of a regular operation. (2) Communication with the remote object. The details of communication between remote objects are handled by RMI, and for programmers, remote communication looks like a standard Java method call. (3) Load the class byte code for an object passed as a parameter or return value. Because RMI allows callers to pass a pure Java object to a remote object, RMI provides the necessary mechanism to load both the object's code and the object's data. When the RMI distributed application runs, the server invokes the registration service to associate the name with the remote object. The client uses the name of the remote object to locate the remote object in the registry service on the server, and then calls its method.

Second, the serialization of objects

In RMI Distributed Application Systems, the Java objects passed between the server and the client must be serializable objects. An object that is not serializable cannot be passed in the object stream. Object serialization extends the core Java input/output class and also supports objects. Object serialization supports the encoding of objects and the encoding of objects through which they can be accessed, as well as the complementary reconfiguration of object graphics in the stream. Serialization is used for lightweight persistence and communication with the aid of sockets or remote method calls (RMI). The serialization now includes an API (application programming Interface, Application Interface) that allows the class-independent domain to specify the serialized data for the object, and allows the serialization data field to be written to or read from the stream using an existing protocol. To ensure compatibility with the default read-write mechanism.

To write applications, you must have the ability to store and retrieve Java objects in addition to most transient applications. The key to storing and retrieving objects in a serialized way is to provide enough object state to reconstruct the object. Objects stored to the stream may support either Serializable (serializable) or externalizable (externalized) interfaces. For Java objects, the serialization form must be able to identify and validate the Java class that the object that stores its contents belongs to, and revert the content to a new instance. For serializable objects, the stream will provide enough information to restore the stream's domain to a compatible version of the class. For an Externalized object, the class is solely responsible for the external format of its contents. The purpose of serialization of Java objects is: Provides a simple but extensible mechanism to maintain the type and security attributes of Java objects in a serialized manner, with extended capabilities to support marshalling and reconciliation to meet the needs of remote objects; scalability to support simple persistence of Java objects; You need to provide serialization implementations for each class, and allow objects to define their external formats.