The Remote Method Invocation

While the RMI technology is similar to CORBA, it operates only in the Java programming environment. RMI enables the programmer to develop distributed applications based on methods of Java objects that can be invoked from other Java virtual machines, which can be located on different computers and maybe different operating systems ( products/rmi/). RMI provides a simple and direct model for developing distributed applications using Java objects. An RMI client can make calls to an RMI server object and use its behavior as if it were local to it. The RMI technology is a sophisticated mechanism that allows Java objects to communicate amongst them. The mechanism and the communication protocol are well-defined and standardized. A Java object can communicate with another Java object without knowing before hand the protocol used.

During the remote communication between two Java objects, the one that makes the remote call is referred to as the client object and the one that responds to the remote call is referred to as the server object. Note that the relationship client-server is valid only for this particular call. An object that plays the role of the client in one call may be playing the role of the server in another call.

RMI uses several layers to achieve the communication between remote objects. These layers are:

1. Client's stubs and server's skeletons; these objects are used to hide the remoteness and make transparent the communication between objects over a network connection.

2. The remote reference layer that handles the packaging of the method call and its parameters and returns the results of method's execution over the network connection.

3. The transport layer that is the actual network connection linking systems together.

To better understand the collaboration between client and server objects using RMI, we will consider a simple example of collaboration between a server object referred as SoilRMIServer, which provides its services remotely and a client object referred to as SoilClient that invokes a method call on the remote server. The services offered by object SoilRMIServer are the same ones that object CORBASoilServer, presented in the previous section, provides. Implementing the same example in two different technologies allows us to better understand the similarities and differences between these technologies.

The stubs and skeletons are automatically generated by the RMI compiler when compiling the server class. Figure 11-11 shows the stub and skeleton classes that are generated for class SoilRMI.

:ri-Ed SoilRMI.jpr

% SoilRMI.html


Figure 11-11. Stubs and skeletons created by Java compiler for class SoilRMI.

Stub classes reside with the client and skeletons reside with the server. Stubs and skeletons are involved when a client invokes a remote method on the remote server. The stub object serves as a proxy (see Section 4.2, The Proxy pattern, in Chapter 7) for the server and resides with the client. The client's call goes to the stub object that has encapsulated all the names of the methods provided by the server object, as shown in Figure 11-12. Lines 3 through 6 show the names of methods implemented by the server object.

1 public final class SoilRMIServerJStub extends java.rmi.server.RemoteStub implements SoilRMIInterface, java.rmi.Remote {

2 private static final java.rmi.server.Operation[] operations = {

3 new java.rmi.server.Operation("double getSoilDepth()"),

4 new java.rmi.server.Operation("double getWiltingPoint()M),

5 new java.rmi.server.Operation(,!void initialize()")

Figure 11-12. Partial Java code for class SoilRMI_Stub.

After receiving the remote call, the stub creates a block of information containing an identifier of the remote object to be used, a description of the method to be called and the marshalled parameters of the remote method. This block of information is sent to the server object using the network connection. On the server side, this information is received by the skeleton which is a server-side object that contains a method that dispatches calls to the actual server object implementation. Skeletons communicate with clients using the JRMP (Java Remote Method Protocol) protocol.

When the skeleton object receives the block of information sent by the stub object, it unmarshals the parameters of the remote call. Then, using the object identifier sent by the stub object, it identifies the remote object responsible for executing the remote call and invokes the method. The result of the remote call is packaged in a block of information and it is sent back to the stub object. Although the communication between client and server objects is complex, it is transparent to the programmer. As previously mentioned, remote objects are used as they were local objects; even the syntax of a remote call is the same as for a local call. Figure 11-13 shows the sequence diagram for the collaboration between the client and the server objects.

Figure 11-13. Collaboration between client and server objects using RMI.

As shown in Figure 11-13, object SoilClient invokes the message getSoilDepthQ on the remote server object SoilRMI. First, the message is sent to the stub object created by the RMI compiler. The stub object creates a block of information and sends it to server object using the JRMP protocol. This block of information is received by the skeleton object that unmarshals it and invokes the method call on the server object. The return of the method call, the value of soil depth, is packaged again in a block of information and is sent back to the stub object by the skeleton object. The stub object unmarshals the return value and sends it to the client object. In the next two sections, we will show a simple example of implementation of a SoilRMI server and a SoilClient.

Was this article helpful?

0 0

Post a comment