Remote Objects Communication in RMI-P4 

Purpose

RMI-P4 employs a standard mechanism for the communication between remote objects using stubs and skeletons. A stub is a local representation of the remote object residing on the client JVM. It serves as a proxy responsible for transmitting the client call to the implementation of the remote object. The purpose of the stub is to hide the serialization processes of the call parameters and details of the low transport level, thus providing application developers with a simple communication mechanism.

The skeleton is located in the JVM where the remote object resides. It is responsible for “unmarshalling” the parameters of the remote call and passing them to the remote object implementation. In this sense, it plays the role of an intermediary between the implementation of the remote object and the implementation of the P4 protocol.

Process Flow

The following figure provides an overview of the information flow in the communication process between remote objects:

As depicted on the figure above, the client calls methods of the stub. The stub then performs the following actions:

...

       1.      Initializes connection to the JVM where the remote object resides.

       2.      Marshals the parameters of the call and transmits them to the remote JVM.

       3.      Waits for the result of the call.

       4.      Reads the returned result.

       5.      Delivers the result to the client.

The skeleton performs the following actions when it receives the client call:

...

       1.      Reads the parameters of the call.

       2.      Passes them to the appropriate method on the implementation of the remote object.

       3.      Marshals the returned value of the method (or the exception) and sends it to the stub in the client JVM.

Generation of Stubs and Skeletons

There are two options to generate RMI-P4 stubs and skeletons.

The first option is when you generate them against the implementation of the remote object using the J2EE Engine’s RMIC tool. They reflect the specifics of the remote object’s implementation. Therefore, they allow for faster transformation and transmission of information from the client call, minimize the creation of helper objects for the communication process, and simplify the handling of exceptions. A disadvantage of this option that you have to generate them again each time you change the inherited remote interface, or the signatures of any of the remote object’s methods.

The other option is to let the system generate the stubs and skeletons dynamically at runtime. This simplifies the development of remote objects by eliminating the need to generate and maintain such additional classes. However, dynamically generated stubs and skeletons are based on the java.lang.reflect mechanism. The latter reduces their productivity in terms of facilitating the remote objects communication, and imposes creation of several helper objects.