RMI

 RMI is an API used to build distributed applications

 It provides remote communication between java programs
 It is provided in the package java.rmiv .*;
 RMI divided into two parts –client program and server program
 Client part is called stub and server part is called skeleton
 Server program creates some remote object
 Client program make request for remote object on server and invoke method on them

Remote interface

Adder

Public int add(x,y)

client server server

Proxy object adder implementation

Stub

The stub is an object, acts as a gateway for the client side. All the outgoing requests are routed
through it. It resides at the client side and represents the remote object. When the caller
invokes method on the stub object, it does the following tasks:

1. It initiates a connection with remote Virtual Machine (JVM),

2. It writes and transmits (marshals) the parameters to the remote Virtual Machine (JVM),
3. It waits for the result
4. It reads (unmarshals) the return value or exception, and
5. It finally, returns the value to the caller.
skeleton

The skeleton is an object, acts as a gateway for the server side object. All the incoming
requests are routed through it. When the skeleton receives the incoming request, it does the
following tasks:

1. It reads the parameter for the remote method

2. It invokes the method on the actual remote object, and
3. It writes and transmits (marshals) the result to the caller.

ARCHITETURE OF RMI

A remote method can be invoked by referring to the remote object. All interactions with the
remote object will be performed through the interface only. Basically, this interface describes
the methods, which can be invoked remotely, and the remote object then implements it.
When a remote object is referenced, the object is not sent over the network to the client that
requests it. Instead, a proxy object (often referred to as stub), which is a client-side proxy for
the remote object, is sent. The client interacts only with this stub class. The stub class is
responsible for handling data between the local and the remote systems. One remote object
can be referenced by many clients. In that case, each client has its own stub object, which
represents that remote object.

The actual implementation of the client-server application takes place at the Application layer.
Any application that makes some of its methods available to its remote clients must first
declare the methods in an interface that extends java.rmi.Remote, which is an empty interface.
The main difference between the remote and normal interface is that the remote interface
throws the remote exception. If a class is to implement these remote interfaces, it must first
implement the UnicastRemoteObject in the java.rmi.server package.
Working of an RMI Application
The following points summarize how an RMI application works −
 When the client makes a call to the remote object, it is received by the stub which
eventually passes this request to the RRL.
 When the client-side RRL receives the request, it invokes a method called invoke() of
the object remoteRef. It passes the request to the RRL on the server side.
 The RRL on the server side passes the request to the Skeleton (proxy on the server)
which finally invokes the required object on the server.
 The result is passed all the way back to the client.
The Java RMI architecture consists of three layers:
(i) Proxy Layer (or Stub/Skeleton layer)
(ii) Remote Reference Layer (RRL)
(iii) Transport Layer
Proxy Layer (or Stub/Skeleton layer)
The proxy layer is responsible for managing the remote object interface between the server
and client. In this layer, the stub class is the client-side Proxy for the remote object. stub is
responsible for initiating a call to the remote object it represents and is the application
interface to that object. It is also responsible for marshalling the method arguments to a
marshal stream. Both the stub and skeleton classes use this stream to communicate with each
other. Once the results are returned to the client stub, the results are un-marshalled.
The skeleton class is similar to the stub class in many ways. The only difference is that it
exists on the server side. The responsibility of the skeleton class is to send parameters to the
method implementation and sending the return values
Remote Reference Layer (RRL)
It is the layer which manages the references made by the client to the remote object.
Transport layer
The transport layer is responsible for setting up the connection and transportation of
data from one machine to another. The default connection is set up only in the
TCP/IP protocol.
Marshalling and Unmarshalling
Whenever a client invokes a method that accepts parameters on a remote object, the
parameters are bundled into a message before being sent over the network. These parameters
may be of primitive type or objects. In case of primitive type, the parameters are put together
and a header is attached to it. In case the parameters are objects, then they are serialized. This
process is known as marshalling.
At the server side, the packed parameters are unbundled and then the required method is
invoked. This process is known as unmarshalling.
RMI Registry
RMI registry is a namespace on which all server objects are placed. Each time the server
creates an object, it registers this object with the RMIregistry
(using bind() or reBind() methods). These are registered using a unique name known as bind
name.
To invoke a remote object, the client needs a reference of that object. At that time, the client
fetches the object from the registry using its bind name (using lookup() method).
The following illustration explains the entire process −
Goals of RMI

 To minimize the complexity of the application.

 To preserve type safety.
 Distributed garbage collection.
 Minimize the difference between working with local and remote objects.
Steps to implement a RMI application

 Define the remote interface

 Develop the implementation class (remote object)
 Develop the server program
 Develop the client program
 Compile the application
 Execute the application

1.Defining the Remote Interface

A remote interface provides the description of all the methods of a particular remote object.
The client communicates with this remote interface.
To create a remote interface −
 Create an interface that extends the predefined interface Remote which belongs to the
package.
 Declare all the business methods that can be invoked by the client in this interface.
 Since there is a chance of network issues during remote calls, an exception
named RemoteException may occur; throw it.
Following is an example of a remote interface. Here we have defined an interface with the
name Hello and it has a method called printMsg().
import java.rmi.*;

public interface Hello extends Remote

{
void printMsg() throws RemoteException;
}
2.Developing the Implementation Class (Remote Object)

Following is an implementation class. Here, we have created a class

named ImplExample and implemented the interface Hello created in the previous step and
provided body for this method which prints a message.
public class ImplExample implements Hello
{
public void printMsg()
{
System.out.println("This is an example RMI program");
}
}

3.Developing the Server Program

An RMI server program should implement the remote interface or extend the implementation
class. Here, we should create a remote object and bind it to the RMIregistry.
To develop a server program −
 Create a client class from where you want invoke the remote object.
 Create a remote object by instantiating the implementation class as shown below.
 Export the remote object using the method exportObject() of the class
named UnicastRemoteObject which belongs to the package java.rmi.server.
 Get the RMI registry using the getRegistry() method of the LocateRegistry class
which belongs to the package java.rmi.registry.
 Bind the remote object created to the registry using the bind() method of the class
named Registry. To this method, pass a string representing the bind name and the
object exported, as parameters.
import java.rmi.*;

public class Server extends ImplExample

{
public Server()
{}
public static void main(String args[])
{
Try
{
ImplExample obj = new ImplExample();
Hello stub = (Hello) UnicastRemoteObject.exportObject(obj, 0);
Registry registry = LocateRegistry.getRegistry();
registry.bind("Hello", stub);
System.err.println("Server ready");
} catch (Exception e) { }
}}

Developing the Client Program

Write a client program in it, fetch the remote object and invoke the required method using
this object.
To develop a client program −
 Create a client class from where your intended to invoke the remote object.
 Get the RMI registry using the getRegistry() method of the LocateRegistry 
 Fetch the object from the registry using the method lookup() of the class Registry 
 The lookup() returns an object of type remote, down cast it to the type Hello.
 Finally invoke the required method using the obtained remote object.
Following is an example of an RMI client program.
import java.rmi.*;
public class Client {
private Client()
{}
public static void main(String[] args) {
try {
Registry registry = LocateRegistry.getRegistry(null);
Hello stub = (Hello) registry.lookup("Hello");
stub.printMsg();
} catch (Exception e) {
System.err.println("Client exception: " + e.toString());
e.printStackTrace();
}
}
}

Compiling the Application

To compile the application −

 Compile the Remote interface.

 Compile the implementation class.
 Compile the server program.
 Compile the client program.

RMI REGISTRY SERVICES

RMI Object Services

RMI provides some basic object services on top of its remote object architecture that can be
used by the distributed application designer. These services are:
1. Naming/Registry Service
 A server process needs to register one (or more) RMI-enabled objects with its
local RMI registry (represented by the Registry interface) using a name that
clients can use to reference it.
 A client can obtain a stub reference to the remote object by asking for the object
by name through the Naming interface. The Naming.lookup() method takes the
name of a remote object and locates the object on the network. The object’s
name is in a URL-like syntax that includes the name of the object’s host and the
object’s registered name.
 Once the lookup() method locates the object’s host, it consults the RMI registry
on the host and asks for the object by name. If the registry finds the object, it
generates a remote reference to the object and delivers it to the client process,
where it is converted into a stub (local) reference that is returned to the caller.
2. Distributed Garbage Collection
 This is an automatic process that the application developer does not have to worry
about.
Description:

Every server that contains RMI-exported objects automatically maintains a list of

remote references to the objects it serves. Each client that requests and receives a
reference to a remote object is issued this remote reference through the remote reference
layer of the object’s host process. The reference layer automatically keeps a record of
this reference in the form of an expirable lease on the object.

When the client is done with the reference it allows the remote stub to go out of
scope and notifies the server that it is done with the reference to the object. Then the
reference layer on the server automatically deletes the record of the remote reference
and informs the client’s reference layer that this remote reference has expired. Should
the lease on the object expire then the reference layer on the server also deletes the
record of the remote reference. This is used to deal with situations when a client or
network failure prevents a client from notifying the server that it is done with its
reference to an object.

When an object has no further remote references recorded in the remote reference
layer, it becomes a candidate for garbage collection. If there are also no local references
to the object then this object is picked up the garbage collector in the next run of the
system garbage collector.

3. Object Activation Service

 This service is new to RMI as of version 1.2 of the Java 2 platform. It provides a
way for a server object to be activated automatically when a client requests it.
Without remote activation, a server object has to be registered with the RMI registry service
from within a running JVM. If the server VM crashes, the server object becomes
unavailable and any existing client references to the object are lost.
With remote activation, a server object can be created within a new or existing VM and
a reference to this newly created object can be obtained for the client that caused the
activation. A server object that wants to be activated automatically needs to register an
activation method with the RMI activation daemon (rmid) running on its host.

Factory Classes
 When a reference to a remote object is obtained through the RMI registry and then used
to request additional remote references, the registered remote object is referred to as a
factory class.
 Using remote references obtained through method calls on factory objects, client
applications can dynamically request the creation of new remote objects, without the
objects being registered individually with the server registry.

Example
Say we’re building a remote banking system using the Account object. The server
provides services to remote clients running on PCs, embedded in ATMs etc. On the server, we
could run an RMI registry, create an Account object for every account we have on record, and
register each one with the RMI registry using the account name.

Registry local = LocateRegistry.getRegistry();

local.bind(“Abrams, John”, new AccountImpl(“John Abrams”));

local.bind(“Adams, John”, new AccountImpl(“John Adams”));

Dynamically Loaded Classes
 The RMI runtime system provides its own dynamic class loader, the RMIClassLoader,
to load stubs and skeletons for remote interfaces, as well as the classes for objects used
as arguments of remote methods or return values.
A client needs the interface class for the remote object and its stub class. On the server side,
the skeleton class for the remote object and the implementation class, need to be loaded in
order to run the server object that is being remotely exported.