Communications in Java RMI

RMI (Remote Method Invocation) is a java-based high-level communication mechanism. RMI enables us to invoke methods on remote machines (or processes) and get the invocation results.

In RMI, a Remote interface is defined, and a Remote object (sometimes referred as the server) implements it. Since it is defined as a ‘remote interface’, any Java process (sometimes referred as the client) may invoke methods on the Remote object.

After the remote object is created, it should bind itself to a Name Server (rmiregistry), so the clients can look it up. The name server acts as a phone guide: each remote object binds itself with a unique name, and the clients can connect to the name server and ask for that remote object. The name server returns a stub for the remote object; the stub is an implementation of the remote interface which is automatically created and takes care of the communication between the client and the remote object.

A typical life cycle of a RMI system is as follows:The name server (rmiregistry) is started on the server’s machine. The server starts, creates a remote object and binds it to the name server. The client starts, connects to the name server and asks for the server’s remote object. In order to do so, the client must know the address of the name server (host & port), and the name of the remote object.

knows

lookupbind

implements

Remote Object (server) extends UnicastRemoteObjectimplements the Remote interface

Remote Interfaceextends Remote

Client

Name Server

First example – Time ServerSource files are located on the timeServer/ directory.This server, when queried by the client, will return the current time and date.

1. Define a remote interface (TimeService.java)2. Implement the server (TimeServer.java)3. Implement the client (TimeClient.java)4. Compile the code5. Run the RMI registry6. Run the server7. Run the client

RMI registry

The RMI registry listens to a given port on the remote machine. The default port of RMI is 1099. To launch the RMI registry type:

rmiregistry &or, if you wish to listen to a port other than the default one, simple provide the port number:

rmiregistry 1234 &

Keep in mind that the RMI registry will continue to work, even when your session terminates, so be kind and kill (-9) the process before you leave.

Note: the rmiregistry provided with the free (‘academic’) JVM is limited, and can only register Remote Objects that are running on the local machine. This is the reason we start the rmiregistry and the server on the same machine. The commercial version of rmiregistry can handle remote objects from other machines as well.

Additional JVM properties

There are additional JVM properties need to be set so the system can run. A JVM property is defined using the –D flag when activating java.

java.rmi.server.codebase=CODEBASE_URLThis property provides a URL of the remote classes needed for the application to run. In our case, all the classes are stored on a local file system, but on other systems where the server is located on a dedicated machine codebase should be specified so the client can download it.

Script files

In order to simplify the usage of the system, we have provided script files that allow convenient invocation of the registry, server and client. These scripts are stored in the scripts directory.

Second ExampleSource files are located on the stringServer/ directory.In this example we’ll implement an interface of a string container. The server holds a string container, and can send it to the client. Is it passed by value or by reference?In RMI, objects are serialized on the sender side, sent via the network and deserialized on the receiver side, so the client has a copy of the original container. Any methods that the client invokes on this container will act on its copy only! the server’s container remains untouched.

Third ExampleSource files are located on the stringServer-remote/ directory.This example is similar to the second example, but this time we wish that the methods we invoke on the container on the client’s side will take effect on the server’s container as well. For this purpose, we will make the following modifications:

Let the IContainer interface extend java.rmi.Remote Let the Container object extend java.rmi.UnicastRemoteObject

That’s it! the server will now return a stub to the container. When the client invokes the setValue method, the stub will contact the original container and invoke the method on it. Note there is no need to bind the container to any name server – it is returns by the server (which is bound to the name server).

Additional links

http://java.sun.com/j2se/1.5.0/docs/guide/rmi/index.htmlRMI tutorial

http://java.sun.com/j2se/1.5.0/docs/guide/rmi/codebase.htmlcodebase description