Remote Method Invocation (RMI)

Java Remote Method Invocation is a mechanism for communicating between two machines running Java Virtual Machines. RMI allows one object to invoke a method on an another object existing in other location. The other location could be on the same machine or a different one. The RMI mechanism is basically an object-oriented RPC mechanism. Remote Method Invocation (RMI) facilitates object function calls between Java Virtual Machines (JVMs). JVMs can be located on different computers - even one JVM can invoke methods belonging to an object stored in another JVM.

How RMI differs from CORBA?

CORBA is another object-oriented RPC mechanism. CORBA differs from Java RMI in a number of ways:

1. CORBA is a language-independent standard.
2. CORBA includes many other mechanisms in its standard (standard for TP monitors)

none of which are part of Java RMI.
3. There is also no notion of an "object request broker" in Java RMI.

Java RMI has recently been evolving toward becoming more compatible with CORBA. In particular, there is now a form of RMI called RMI/IIOP ("RMI over IIOP") that uses the Internet Inter-ORB Protocol (IIOP) of CORBA as the underlying protocol for RMI communication.

How RMI Works ?

Consider Java code on machine A needs a service or a method, respectively, of objB (remote Java object) on machine B it starts a remote method invocation. It does this the same way as invoking a local Java object's method.The whole communication behind the remote invocation is done by the RMI mechanism.

When referencing a remote object residing on machine B from code being on machine A there are always two intermediate objects actually handling the communication: a stub object and a skeleton object. When a remote method invocation comes up the following tasks are handled by these two objects:

The stub object (on machine A) has to

* build an information block thats consists of

o an identifier of the remote object to be used,

o an operation number describing the method to be called and

o Marshalled parameters (method parameters have to be encoded
into a format suitable for

transporting them across the net)

* send this information to the server

The skeleton object (on machine B) will

* to unmarshal the parameters,

* to call the desired method on the real object lying on the
server,

* to capture the return value or exception of the call on the
server,

* to marshal this value,

* to send a package consisting of the value in the marshalled
form back to the stub on the

client, machine A.

The stub object unmarshals the return value or exception from the server. This value becomes the return value of the remote method invocation. Or, if the remote method threw an exception, the stub (object) rethrows it in the process space of the caller.

There are three components that participate in supporting remote method invocation.

1. The Client is the process that is invoking a method on a remote object.

2. The Server is the process that owns the remote object. The remote object is an ordinary

object in the address space of the server.

3. The Object Registry is a name server that relates objects with names. Objects are registered

with the Object Registry. Once an object has been registered, one can use the Object

Registry to obtain access to a remote object using the name of the object.

The object registry process has to be started at first. It observes a specific port for bindings between logical names and real objects. Afterwards the server process is started on the same machine. It gives the binding information to the registry process by sending them to the corresponding port. Then everything has be done on server side. Now any client process can be started. It will send lookups to the port of the registry process. Now a connection via a stub object and a skeleton object becomes established.

There are two kinds of classes that can be used in Java RMI.

Remote class is one whose instances can be used remotely. An object of such a class can be referenced in two different ways:

a. Within the address space where the object was constructed, the object is an ordinary object

which can be used like any other object.

b. Within other address spaces, the object can be referenced using an object handle. While there

are limitations on how one can use an object handle compared to an object, for the most part

one can use object handles in the way as an ordinary object.
For simplicity, an instance of a Remote class will be called a remote object.

Serializable class is one whose instances can be copied from one address space to another. An instance of a Serializable class will be called a serializable object. In other words, a serializable object is one that can be marshaled. This concept has no connection to the concept of serializability in database management systems.

If a serializable object is passed as a parameter (or return value) of a remote method invocation, then the value of the object will be copied from one address space to the other. By contrast if a remote object is passed as a parameter (or return value), then the object handle will be copied from one address space to the other.

RMI OverView:

• RMI is an object-oriented implementation of the Remote Procedure Call model; it is an API for

Java programs only
• Using RMI, an object server exports a remote object and registers it with a directory service.

The object provides remote methods, which can be invoked in client programs
• A remote object is declared with a remote interface
• The remote interface is implemented by the remote object
• An object client accesses the object by invoking the remote methods associated with the objects