Introduction to RMI

RMI is a JavaSoft API, which provides for remote (across a network) method calls. RMI provides for location transparency by allowing client applications to access Java objects on remote servers by invoking similar syntax as they would to access local objects.

This RMI paradigm enables even entry-level programmers to easily develop distributed applications. Local applications are provided with a reference to objects that reside on remote servers, thus providing for remote method invocation as depicted in Figure 11.1.

Notwithstanding transparency, there are some differences between using local and remote objects:

• Local objects are defined and implemented by local Java objects. However, remote objects are defined by local interfaces, but are implemented by remote objects that implement the local interfaces.

• Local objects are referenced directly via their objects' references; remote objects are referenced indirectly via local proxy stub references that contain instructions on how to connect to the remote object implementations.

• If implemented, local objects' finalize() methods are called before consideration for garbage collection as usual (assuming that all references to the local objects have been dropped). Remote objects may implement the Unreferenced interface, which is called when all references to the remote objects have been dropped. If all references to local objects are dropped and there are no further references to remote objects, the remote objects are then subject to garbage collection.

• Remote objects have a lease. If the specified leased time elapses, the lease expires, and references to remote objects are dropped, which qualifies the remote objects for garbage collection. Prudent developers should code for this situation; that is, a local object reference is available, but the associated remote object reference disappears.

• Local objects handle exceptions as usual; remote objects must also specifically handle RemoteException(s).

The methods of remote objects are defined within a Java remote interface that resides on the client side. Implementation classes, classes that implement methods of remote interfaces, reside on the server side.

The remote architecture is physically implemented by client-side proxy classes (stubs) that act as proxies for remote objects, and server-side implementation classes (skeletons) that implement the server-side code functionality. This stub-skeleton layer is depicted in Figure 11.2.

Client-side applications issue method invocations on proxy classes, and proxy classes then send requests to remote server-side implementations. Those remote implementations invoke associated server-side methods and send any return values back to client-side proxies, which in turn provide results of these method invocations to the client-side applications.

These remote invocations are propagated over three layers. It is within the previous stub-skeleton layer that client-side (stub) method invocations are redirected to server-side (skeleton) remote objects. Beneath this layer is a remote reference layer that manages references and connections between clients and remote objects. The final layer within the physical implementation of the RMI architecture is the transport layer. The transport layer uses TCP/IP stream–based connections to provide network (or internal) connectivity between the client and remote hosts.

WebLogic's RMI Implementation

The WebLogic 8 series RMI implementation provides for client-side proxy classes and server-side objects (bytecode) as opposed to the client-side stub and server-side skeletons common in generic RMI implementations. The client executes method calls on client-side proxies; the requests are serialized and transported to WebLogic Server. In WebLogic Server, client requests are deserialized and processed against implementing objects. The results of the method invocations are then serialized and transported back to the client-side proxies. Client-side proxies then deserialize and forward results to the client.

WebLogic's implementation of JavaSoft's RMI API is a Java-to-Java remote method invocation solution. WebLogic's RMI implementation differs from the generic Sun RMI implementation by using proprietary features such as the WebLogic T3 protocol for communications (as opposed to the TCP/IP used in generic RMI solutions). Other WebLogic enhancements over the generic Sun RMI implementation are discussed throughout this chapter and especially under the "Performance Issues" section. RMI clients, coded in Java, must implement the RMI specification.

WebLogic's implementation of RMI-IIOP extends RMI object access to non-Java clients such as C, C++, Smalltalk, and COBOL, as depicted in Figure 11.3.

RMI-IIOP uses IIOP for communications, as opposed to the T3 protocol used for pure Java-Java RMI solutions. Clients must be a one of the following: a J2EE application thin client using CORBA 2.4; a J2EE non-thin client using CORBA 2.3; a Java client coded to the RMI-IIOP specification; a CORBA/IDL client (C, C++, Smalltalk, or COBOL) coded to the CORBA 2.3 or higher specification (using Interface Definition Language [IDL]); or a Tuxedo 8.0–compliant client (C, C++, COBOL, Java, or any language that Tuxedo can map to OMG IDL). The RMI-IIOP Tuxedo client uses the Tuxedo General Inter-Orb Protocol (TGIOP) for communications. The WebLogic 8.1 RMI-IIOP implementation supports any CORBA ORB that implements the Object Management Group's Objects-by-Value specification.

WebLogic 8 series implementation of RMI and RMI-IIOP assumes JDK 1.4.1_02 or higher. For further detailed information about WebLogic's implementation of the JavaSoft RMI API, refer to the BEA documentation site at http://edocs.beasys.com/wls/docs81.For JavaSoft RMI documentation, refer to the Sun documentation site at http://java.sun.com/j2se/1.4/docs.