A Guide to Client/Server Computing: Part Two

Supported by the Java Remote Method Protocol (JRMP), RMI is a mechanism for enabling an object in one Java Virtual Machine (JVM) to communicate remotely with an object in another JVM. That is, a client can call a server in separate JVMs as if the server is residing in the same JVM as the client. Remote Method Invocation (RMI) is Java’s solution for inter-JVMs object communication. What RMI does is to make objects in separate JVMs behave like local objects in the same JVM.

Let us consider two objects: Client C and Server S. Client C resides on JVM 1 and Server S resides in JVM 2. The two JVMs are connected via a network. Server S publishes a public interface that Client C can use to communicate with Server S. An interface defines the methods that a client can invoke but the methods are without their implementations. In the code below (Code 2.1), we define an interface AddServer with a method add() that takes in two parameters n1 and n2; this method returns a double number.

Code 2.1: Interface AddServer

public interface AddServer extends Remote {

double add(double n1, double n2) throws RemoteException;

}

The interface does not define how add() is implemented. Implicit in the interface definition is the notion of a contract between the client and server that implements the interface. The client can only call the remote AddServer object using the add() method with two double numbers. In return, the server object promises to return a double number as the sum of the two double numbers it receives from the client. The implementation of the AddServer interface is provided by the server object in a separate class not known to the client. The client is also not aware of how the server object implements the add() method.

As Client C and Server S reside remotely from one another, additional programming is required to resolve the communication between the two objects. Two additional objects, Stub and Skeleton, are created by Server S to fulfill this need. These two objects are responsible for masking the network communication from the client and server respectively. Figure 2.1 illustrates the communication process between Client C and Server S with the help of Stub and Skeleton objects.

A Stub and Skeleton object is produced by Server S. The Stub is passed over to Client C. Client C uses the Stub, which behaves as a client-side proxy object of the remote Server S in JVM 2, to communicate with Server S. The Stub knows how to call the server over the network using sockets; it marshalls the parameters required in the communication and unmarshalls the return value from the remote object. To marshall is to convert a Java representation of data to the corresponding network representation (in the form of byte stream). To unmarshall is to convert a network representation of data to the respective Java representation (in the form of object). The Stub calls a Skeleton over the network. The Skeleton behaves as a server-side proxy object of the remote Server S in JVM 2. It knows how to receive calls on a socket. It unmarshalls the parameters received from the Stub and marshalls the return value to the Stub when the Server S object has completed the execution of the called method.

When a method call is received at the server machine, the Skeleton in JVM 2 delegates the method call to Server S. When the latter has completed the execution of the called method, it returns control to the Skeleton. The Skeleton then returns control together with the marshaled return value to the Stub. The Stub in JVM 1 receives control from the Skeleton, unmarshalls the return value, and returns control to Client C.

In our next article “Client/Server Computing Part 3: An RMI Application”, we will explain the steps involved in writing a distributed application using Java RMI.