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.

Remote Objects Communication Process in RMI-P4

Process Flow

A stub performs the following actions when a client makes a call to one of its methods:

...

       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.

A 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 send it to the stub in the client JVM.

Types of Stubs and Skeletons

With RMI-P4 you can differentiate between two types of stubs and skeletons.

The first type is when you generate them against the implementation of the remote object using the SAP RMIC tool. Because of this, they reflect the specifics of the remote object implementation and therefore they allow for the information from the client to be transformed and transmitted faster from the client call, minimize the creation of helper objects for that process, and simplify the handling of exceptions. A disadvantage of this type of stubs and skeletons is that developers have to generate them again each time they change the remote interface that the remote object implements, or the signatures of any of its remote methods.

The other type of stubs and skeletons are dynamically generated at runtime by the system. They significantly simplify the development of remote objects by eliminating the need to generate and maintain such additional classes. However, these types of stubs and skeletons are based on the java.lang.reflect mechanism, which reduces their productivity in terms of facilitating remote objects communication, and refer to the creation of several helper objects.