Remote Method Invocation

RMI

Introduction
Any large and complicated problem can be sorted out easily if we were to break it up and divide the work between a number of people. When one person cannot cope with a huge problem due to time or physical constraints, the best solution is spilt the work among two or more persons.

 In the world of computers, instead of investing millions on massive computers, it is economically wiser to spilt the computations among several smaller computers. Distributed computing is a technology which solved by a number of computers and later integrating them into a solution for the problem. By using the resources of many computers we can make better use of computing that world probably have been underutilized.

 Distributed object systems apply the principles of object oriented programming to distributed computing such that objects on remote systems can be accessed with the same ease as those on local systems. The advantages of distributed object systems are scalability easier to build ntier systems using this technology, minimizing bandwidth requirements and making it easier for the programmer by handling or hiding complexities across systems.

Java Distributed Object Model

The various models for developing distributed object applications that exist in the industry today are : Distributed Component Object Model(DCOM): This is Microsofts approach to developing distributed applications. Common Object Request Broker Architecture(CORBA): This provides another approach to developing distributed applications. Visigenics VisiBroker for Java: This is Visigenic approach to distributed object systems. Remote Method Invocation(RMI): This is Sun Microsystems approach to developing distributed applications.

 All these methods of developing distributed applications allow objects on one host to invoke methods of objects on other computers or even computers on a different network. DCOM and CORBA are standards of developing distributed applications and can be developed in any language, whereas RMI is specific to developing distributed applications in Java.

RMI
Due to the advancement in science and technology, distances are no longer an issue. Physical boundaries no longer act as barriers in the world of telecommunication. People are able to communicate with each other with great ease. One computer can talk to another computer, which is remotely located, or to a computer in the same room, which the same ease. RMI is a technology introduced by JavaSoft that allows objects in one JVM to invoke methods of objects in a separate JVM. These separate JVMs may execute as a different process in the same computer or on a remote computer. Java employs the policy of Write Once, Run Anywhere. Whith RMI the java model is extended to Run Everywhere.

 Distributed object systems require that objects running in different address spaces(potentially on different hosts) be able to communicate with each other. This can be done through socket communication, which is, however suitable only when we want to exchange files or small amount of data. When we have to exchange formatted data for example, information about a book, this mechanism becomes very tricky, since we have to do some stream parsing on the server side and some string parsing on the client side. RMI makes this very easy because we can directly have a method that returns a book object. The RMI system takes care of sending the object from the server to the client.

The essence of RMI

Database Client Applet rmi Database Server Application Data Store

RMI Architectute
In the RMI architecture the code that defines the behavior and the code that implements the behavior remain separate and run on separate JVMs. In RMI, the definition of a remote service is coded using a java Interface. The implementation of the remote service is coded in a class. Therefore, the interfaces define behavior and classes define implementation.

The RMI system consists of three layers in its architecture

The stub/skeleton layer: stubs are local copy

or proxy for the remote object. Skeleton is the remote proxy for the remote object.

The remote reference layer: supports

communication between stub and skeleton.

The transport layer: sets up and manages

connections between different JVMs.

The client objects invoking the remote object using stub, skeleton, and remote reference layer and transport layer are shown diagrammatically
Client Application Stub Layer Remote Reference Layer Transport Layer

Server
Application Skeleton Layer Remote Reference Layer Transport Layer

Stub and Skeleton Layer

Before a client can invoke a method on a remote object, it must acquire a reference to the remote objects. Once it has the reference it can invoke any method that the remote object supports. The invocation from the client actually results in an invocation on the stub; the stub forwards the request to the remote reference layer, which in turn forward the request to the transport layer.

The transport layer then contacts the skeleton through the remote reference layer on the server. The skeleton then contacts the remote registry to see if the object, which is called, is registered. If it is registered then the object method is called and the result passed back to the stub using the remote reference layer and the transport layer finally to the stub and then to the client object.

There are some concepts that are common to all the distributed systems. Every distributed system will have stubs and skeletons. We have to put a stub on the client machine that acts like a proxy for the server object when we compile the client. This leads the compiler into believing that all method calls are being made locally. Similarly when compile the server code we put a skeleton on the server and lead the compiler into believing that the method calls are originating from the same machine.

Remote Reference Layer

RMI supports only unicast objects. The term unicast stands for communication between a single sender and a single receiver over a network. The remote reference layer is responsible for unicast point-to-point method invocation. The remote reference layer may deactivate an object and store the data of the object in a file or a database so that it can be reactivated at some later point of time.if the server is down, the remote reference layer may try to look for some alternatives to fulfill the request.

Transport Layer
RMI currently uses TCP/IP to communicate client transport layer and server transport layer. The transport layer uses TCP sockets by default to communicate between the client and server transport layer. The transport layer has been designed in such a way that we can implement protocols such as TCP and UDP. The transport layer takes care of multiple connections from the client.

Remote Registry
If a server object has to be accessed remotely, it has to register itself with the remote registry. The remote registry maintains a database of all the objects that can be called remotely and the name with which they can be called remotely.the remote registry is always stored on the server. The rmiregistry program listens on port 1099 for incoming request.

Packages of RMI
The RMI API has mainly five packages, which are
java.rmi java.rmi.registry java.rmi.server java.rmi.activation java.rmi.dgc

The java.rmi package

This package declares
The Remote interface The MarshalledObject class The Naming class The RMISecurityManager class Number of Exceptions classes

 The Remote Interface must be implemented by all remote object. This interface does not have any methods, it is used only to indicate that the class which implements this interface can be accessed remotely. The Naming class provides following static functions for accessing objects using RMI
Bind() Rebind() Lookup()

The java.rmi.registry package

This package provides
Registry interface RegistryHandler interface LocateRegistry class These interfaces and class are used to handle remote objects by name and also to register those remote objects.

The java.rmi.server Package

This package implements several interfaces and classes that support both client and server aspects of RMI like a class implementation of Remote interface, client stub, server skeleton and so on. This package provides
RemoteObject class RemoteServer class UnicastRemoteObject RemoteStub RmiClassLoader RmiSocketFactory Skeleton interface

The java.rmi.activation Package

This package provides support for RMI Object Activation. It provides a number of classes and interfaces for this purpose. Some of them are:
Activatable class ActivationGroup class ActivationGroupDesc class ActivationID class

The java.rmi.dgc package

This package provides classes and interface for RMI distributed garbage-collection(dgc). It has one interface and two classes which are:
DGC interface: is used for the server side of the distributed garbage collection algorithm. A Lease class object: contains a unique VM identifier and a lease duration. A VMID class object: is an identifier that is unique across all Java Virtual machines.

Implementing the RMI Server

The steps involved in creating and registering a remote object are as follows:
Create the remote interface Create a class that implements the Remote interface Create the stub and Skeleton classes Copy the Remote interface and stub file to the client. Create and register the Remote object.

Create the Remote interface

import java.rmi.*; public interface myrem extends Remote { public String display(String nm)throws RemoteException; }

Create a class that implements the Remote interface

import hava.rmi.*; import java.rmi.server.*; public class remclass extends UniCastRemoteObject implements myrem { public remclas()throws RemoteException { super(); } public String display(String nm) throws RemoteException { return welcome+nm+ to rmi programming; } }

Create the Stub and Skeleton Classes

The above class now has to be registered with the remote registry. To achieve this we use a tool provided by Java, which generates the Stub and Skeleton classes. The tool, which we use, is rmic compiler. The usage of this is shown here rmic <classname> Run the compiler in the directory, which has the remclass. The rmic compiler generates following two files
remclass_stub.class remclass_skel.class

Copy the Remote interface and the stub file to the client
The remote interface and the stub file need to be copied to a directory, which is in the classpath on the client machine. This is required to compile and run the client class. In out example, we need to copy the myrem.class and remclass_stub.class to the client machine.

Create Server side program

import java.rmi.*; import java.net.*; public class rmiserver { public static void main(String args[]) { try { remclass rc = new rmiclass(); Naming.rebind(rcobj,rc); System.out.println(remote method is bound); } catch(RemoteException e) { } catch(MalFormedURLException e) { } } }

Create and register the Remote object

Once the skeleton and stub are generated and the files copied to the client machine, then start the RMI registry by executing the following command. Start rmiregistry After starting the rmiregistry, we execute the rmiserver.class like any other java program.

Create a client program

import java.rmi.*; import java.net.*; public class client { public static void main(String args[]) { try { myrem rm; rm = (myrem)Naming.lookup(rmi://localhost/remobj); System.out.println(value getting from remote method.); System.out.println(rm.display(satyam)); } catch(Exception e) { } } }