Remote Method Invocation

Introduction Remote Method Invocation (RMI) is a distributed systems technology that allows one JVM to invoke object methods that will be run on another JVM located elsewhere on a network. This technology is very important for the development of large-scale systems, as it makes it possible to distribute resources and processing load across more than one machine.

RMI is a Java technology that allows one JVM to communicate with another JVM and have it execute an object method. Using RMI, objects can invoke methods on other objects located remotely as easily as if they were on the local host machine.

Object main(String[ ] args) Method request RemoteObject method1(…) Java Virtual Machine Object main(String[ ] args) Method request Java Virtual Machine RemoteObject method1(…) method2(…) Method response

Each RMI service is defined by an interface, which describes object methods that can be executed remotely. This interface must be shared by all developers who will write software for that service. More than one implementation of the interface can be created, and developers do not need to be aware of which implementation is being used or where it is located.

How Does RMI Work? Systems that use RMI for communication typically are divided into two categories: Servers A server provides an RMI service Clients A client invokes object methods of this service.

RMI servers must register with a lookup service, to allow clients to find them, or they can make available a reference to the service in some other way. The Java platform includes an application called rmiregistry (which runs as a separate process). This application allows other applications to register RMI services or obtain a reference to a named service.

Each service registration is associated with a name to allow clients to select the appropriate service. If a service is moved to another server, the client need only look up the registry again to find the new location. RMI REGISTRY RMI Server RMI Server RMI Server

Once a server has registered, it will then wait for incoming RMI requests from clients.

RMI clients will send RMI messages to invoke an object method remotely RMI clients will send RMI messages to invoke an object method remotely. However, a client must first obtain a reference for the remote object which is normally done by looking up a service in the RMI registry. The client requests a particular service name, and receives a URL to the remote resource. The URL has the following format: rmi://hostname:port/servicename

Once an object reference is obtained, the client can then interact with the remote service. The networking details of requests are completely transparent to the application developer. This is achieved through a division of the RMI system into two components i.e. the stub and the skeleton.

The stub object acts as a proxy object, conveying object requests to the remote RMI server. It implements a particular RMI interface, which the client application can use just like any other object implementation. When the stub object receives a request, it passes a message to a remote RMI service, waits for a response, and returns the response to the calling method.

Hence, the application developer need not be concerned about where the RMI resource is located, on which platform it is running, or how it will fulfill the request. The RMI client simply invokes a method of the proxy object which handles all the implementation details.

stub object somemethod(…) request skeleton object response RMI client application stub object somemethod(…) request RMI server skeleton object somemethod(…) response

At the RMI server end, the skeleton object is responsible for listening for incoming RMI requests and passing these on to the RMI service. Note that the skeleton object does not provide an implementation of an RMI service. It only acts as a receiver of requests and passes these requests on further to the actual implementation object that implements the RMI interface. The implementation object executes the appropriate method and pass the results back to the stub object in the RMI client.

TCP sockets are used in the communication that occurs between stub and skeleton.

LightBulb Example: Defining an RMI Service Interface Any system that uses RMI will use a service interface. An RMI service interface defines the object methods that can be invoked remotely. Stub and skeleton objects, as well as the RMI service, must implement this interface.

All RMI service interfaces extend the java.rmi.Remote interface. Only methods defined in a java.rmi.Remote interface (or its subclasses) may be executed remotely - other methods of an object are hidden from RMI clients.

Example: Note that remote methods must be declared as "throws java.rmi.RemoteException" as network errors might occur during communication. import java.rmi.*; public interface RMILightBulb extends Remote { public void on() throws RemoteException; public void off() throws RemoteException; public boolean isOn() throws RemoteException; }

LightBulb Example: Implementing an RMI Service Interface Once a service interface is defined, the next step is to implement it. The implementation not only implements each method in the RMI interface but can also define additional methods. However, only those methods defined in the RMI interface will be accessible remotely. RMILightBulbImpl.java

LightBulb Example: Creating Stub and Skeleton Classes Stub and skeleton classes are responsible for dispatching and processing RMI requests. Developers should not write these classes. They should be generated using the rmic tool provided in the JDK. Compile the RMI interface and implementation. Run the rmic tool as follows: rmic RMILightBulbImpl

Two files will be produced: RMILightBulbImpl_Stub.class RMILightBulbImpl_Skeleton.class

LightBulb Example: Creating an RMI Server The RMI server is responsible for creating an instance of a service implementation and then registering it with the RMI registry. LightBulbServer.java

LightBulb Example: Creating an RMI Client An RMI client needs to obtain an object reference to the remote interface, and doesn't need to be concerned with how messages are sent or received or the location of the service. To find the service initially, a lookup in the RMI registry is made, and after that, the client can invoke methods of the service interface just as if it were a local object. LightBulbClient.java

LightBulb Example: Running the RMI System The following steps should be followed: Copy all necessary files to a directory on the local file system of all clients and the server. Check that the current directory is included in the classpath, or an alternate directory where the classes are located. Change to the directory where the files are located, and run the rmiregistry command. Run the RMI server: java LightBulbServer Run the RMI client: java LightBulbClient