Remote Method Invocation (RMI)

The goals for supporting distributed objects in the Java programming

language are:
1.
Support seamless remote invocation on objects in different
virtual machines
2.
Support callbacks from servers to applets
3.
Integrate the distributed object model into the Java
programming language in a natural way while retaining most of the Java
programming language's object semantics
4.
Make differences between the distributed object model and
local Java platform's object model apparent
5.
Make writing reliable distributed applications as simple as
possible
6.
Preserve the type-safety provided by the Java platform's
runtime environment
7.
Support various reference semantics for remote objects; for
example live (non persistent) references, persistent references, and lazy
activation
8.
Maintain the safe environment of the Java platform provided
by security managers and class loaders
Underlying all these goals is a general requirement that the RMI model be
both simple (easy to use) and natural (fits well in the language).
In the Java platform's distributed object model, a remote object is one
whose methods can be invoked from another Java virtual machine, potentially
on a different host. An object of this type is described by one or more remote
interfaces, which are interfaces written in the Java programming language that
declare the methods of the remote object.
Remote method invocation (RMI) is the action of invoking a
method of a remote interface on a remote object. Most importantly, a
method invocation on a remote object has the same syntax as a method
invocation on a local object.
The Distributed and Nondistributed Models Contrasted
The Java platform's distributed object model is similar to the Java
platform's object model in the following ways:
A reference to a remote object can be passed as an argument or
returned as a result in any method invocation (local or remote).
A remote object can be cast to any of the set of remote interfaces
supported by the implementation using the syntax for casting built into the
Java programming language.
The built-in instanceof operator can be used to test the remote
interfaces supported by a remote object.
The Java platform's distributed object model differs from the Java
platform's object model in these ways:
Clients of remote objects interact with remote interfaces, never with the
implementation classes of those interfaces.

Non-remote arguments to, and results from, a remote method

invocation are passed by copy rather than by reference. This is because
references to objects are only useful within a single virtual machine.
A remote object is passed by reference, not by copying the actual
remote implementation.
The semantics of some of the methods defined by class
java.lang.Object are specialized for remote objects.
Since the failure modes of invoking remote objects are inherently more
complicated than the failure modes of invoking local objects, clients must deal
with additional exceptions that can occur during a remote method invocation.
RMI Details
RMI Is a part of Java Development Kit (JDK). Allows developing
distributed applications.
Distributed system requires computations that are running in different
address space i.e. on different machines, must be able to communicate with
one machine & another.
RMI is platform independent. Can communicate only from one java
virtual machine to another.
RMI application is divided into objects. The object communicates with
each other through an interface. This interface is used to access the remote
object & its methods.
A client can invoke the methods of remote object, with same syntax,
that is used to invoke methods on a local object.
RMI API provides classes & methods that handle all communication
parameter requirements of accessing remote method.
Other Distributed Applications, alternative to RMI1. Sockets
Used to establish communications between two processes in same machine.
In socket architecture, developer can write data to socket & read from socket
hence called Socket program. Not well suited to use complex data type. It is
not suited when objects are developed in different language because the API
for socket programming is low-level. This technique is unsuited for developing
complex distributed applications.
2. CORBA
Is common object request broker architecture. It is a middleware technique;
fundamental to CORBA is Object Request Broker (ORB). ORB is a separate
s/w component used to communicate between objects. The Internet ORB
protocol enables, object to interact across a network. For CORBA architecture,
it uses interface defination language to specify interfaces between CORBA
objects. It is language independent, because of interface defination language.
Advantagesa. Faster than socket.
b. Enables us to access software running on different platform.
Limitations

a. We have to use ORB to connect two objects.

b. We have to pay money for buying ORB.
c. The developer should know interface defination language to specify
interface.
3. DCOM- Distributed Component Object Model
It needs three-component serversa. Inprocess server to implement DLL.
b. Outprocess server to implement EXE file.
c. Remote server to establish communication between components.
Advantages
Language independent hence it is powerful technology to develop distributed
application.
LimitationsIt can communicate only with applications developed in windows environment.
Layers in RMI
Application Layer

Application Layer

Client

Server

Proxy Layer

Proxy Layer
Stub

Skeleton
TCP

Remote Reference Layer

Transport Layer

JVM

Remote Reference Layer

Transport Layer

JVM

1. Application layer- Actual implementation of client & server application.

- There high-level calls are made in order to access & export remote
objects. The client can access the remote method through an interface
that extends java.rmi.Remote., when we want to define a set of
methods that are remotely called they must be declared in one or more
interfaces that should extend java.rmi.Remote.
- Application server is registering it with naming server or registry. This is
use by client to obtain the reference of the object on client side. A client
simply request remote object from either a registry or a reference of
remote object, which is already there. After waiting the reference the
proxy layer has to perform the role of communication between client &
server.
2. Proxy layer- Refers to stub & skeleton created using RMI compiler. These
are simple class files that represent the client & server side of a remote object.
a. Stub class- class is use a client side proxy of remote object.
- It represents the same remote interface there fore is equivalent to
remote object.

It works with Java Virtual Machine & rmi system on client machine to
serialize any arguments to a remote method called & sends this
information to server machine.
- The stub receives any result from result method & returns to client.
b. Skeleton class- it is a server side proxy of remote object. The
responsibilities are- It receives the remote method called by any associated argument. It
works with JVM & rmi system on server machine to serialize any
arguments for this remote method call.
- It invokes the appropriate method in class using these argumentsRmis <classname>
-

3. Remote Reference Layer- It is efficient between stub & skeleton classes &
the transport layer, which is to handle the actual communication protocol.
- When transmitting the parameter or object through network it should be
in the form of string. JVM works with java byte code & gets stringoriented data from transport layer & give it to proxy layer & vice versa.
- This layer is use to handle replicated object & responsible for
establishing persistence & strategies for recovery of lost connection.
4. Transport Layer- responsible for handling actual machine-to-machine
communication (default is TCP/IP), it creates a stream that is accessed by
remote reference layer to send & receive data to & from the machine.
- It sets up, manages, & monitors connection on machine. The transport
layer can be modified to handle encrypted stream compression
algorithm & number of another security enhancement; hence this layer
is independent of another three layers.
RMI flow
When client needs to communicate with remote object or method the RMI or
system follows certain steps1. Server creates remote object
2. Server registers the object with RMI registry.
3. Client gives a request for object to the RMI registry. RMI registry
will return the remote interface to the stub.
4. Client invokes the stub method, which is proxy for the server.
Stub passes the request to skeleton.
5. Skeleton invokes the remote object method.

Packages required by RMI1. java.rmi.*;

Interfacejava.rmi.Remote Interface In RMI, a remote interface is an interface that declares a set of methods
that may be invoked from a remote Java virtual machine. A remote interface
must satisfy the following requirements:
A remote interface must at least extend, either directly or indirectly, the
interface java.rmi.Remote.
Each method declaration in a remote interface or its super-interfaces
must satisfy the requirements of a remote method declaration as follows:
A remote method declaration must include the exception
java.rmi.RemoteException (or one of its super classes such as
java.io.IOException or java.lang.Exception) in its throws clause, in addition to
any application-specific exceptions (note that application specific exceptions
do not have to extend java.rmi.RemoteException).
In a remote method declaration, a remote object declared as a
parameter or return value (either declared directly in the parameter list or
embedded within a non-remote object in a parameter) must be declared as
the remote interface, not the implementation class of that interface.
The interface java.rmi.Remote is a marker interface that defines no methods:
public interface Remote { }
Classes1. RemoteException
The java.rmi.RemoteException class is the superclass of exceptions
thrown by the RMI runtime during a remote method invocation. To ensure the
robustness of applications using the RMI system, each remote method
declared in a remote interface must specify java.rmi.RemoteException (or one
of its superclasses such as java.io.IOException or java.lang.Exception) in its
throws clause.
The exception java.rmi.RemoteException is thrown when a remote
method invocation fails for some reason. Some reasons for remote method
invocation failure include:
1. Communication failure (the remote server is unreachable or is
refusing connections; the connection is closed by the server, etc.)
2. Failure during parameter or return value marshalling or unmarshalling
Protocol errors
The class RemoteException is a checked exception (one that must be
handled by the caller of a remote method and is checked by the compiler), not
a RuntimeException.
2. Naming
- used to interact with registry.
- Contains methods that can be used to add objects to registry or to
remove object.
- This class can not be extended as it is final classPublic final class Naming extends Object
{ }

Methods1.
public static void bind(String URL, Remote Object) throws
AllreadyBoundException, RemoteException, UnknownHostException
- used to register an object with a specified registry. URL String contains
URL to registry server & object contains reference to an object which
should get registered.
2.
3.
4.
5.
-

public static void rebind(String URL, Remote Object) throws

RemoteException, UnknownHostException
Works same as bind(), except rebind()will replace an object that is
already bound with registry with new object.
Can be called only from application that are running on same physical
machine as registry.
public static void unbind(String URL, Remote Object) throws
NotBoundException, RemoteException, UnknownHostException
will remove object reference from registry.
URL string contains URL name object in registry.
Can be called only from application that are running on same physical
machine as registry.
public static String[] list (String URL) throws RemoteException,
UnknownHostException
used to query a registry for list of remote objects that are bound.
public static Remote lookup (String URL) throws NotBoundException,
RemoteException, UnknownHostException
used to get remote object from Registry server, lookup is passed with a
String containing URL to a remote object reference on a registry server,
if the object get bound into a registry, it returns a stub to remote object.

2. java.rmi.server.*;
Class- UnicastRemoteObject
Public class UnicastRemoteObject
RemoteException
-

implements

RemoteServer

throws

this is a base class for most userdefined user objects.

It supplies TCP based point-to-point object reference.
Remote implementation use UnicastRemoteObject as a valid class,
which creates Remote Server Objects.

Interface - RemoteServer
- Extends RemoteObject class, it provides framework to support wide
range of remote references

RMI Class loaderExtends object class, which provides static methods for loading classes
from a network location & obtain location from which an existing class can be
loaded.
RMI registryAllows remote clients to get reference to remote object.
Start rmiregistry- is an simple server to enable application to lookup object that
are exported for remote method invocation.
The registry keeps tracks or address of remote object which has unique name
& are be exported by their application.
Garbage collection
In a distributed system, just as in the local system, it is desirable to
automatically delete those remote objects that are no longer referenced by
any client. This frees the programmer from needing to keep track of the
remote objects' clients so that it can terminate appropriately. RMI uses a
reference-counting garbage collection algorithm similar to Modula-3's Network
Objects.
RMI uses a standard mechanism (employed in RPC systems) for
communicating with remote objects: stubs and skeletons. A stub for a remote
object acts as a client's local representative or proxy for the remote object.
The caller invokes a method on the local stub which is responsible for carrying
out the method call on the remote object. In RMI, a stub for a remote object
implements the same set of remote interfaces that a remote object
implements.
When a stub's method is invoked, it does the following:
1. initiates a connection with the remote JVM containing the remote object,
2. marshals (writes and transmits) the parameters to the remote JVM,
3. waits for the result of the method invocation,
4. unmarshals (reads) the return value or exception returned, and
5. returns the value to the caller.
The stub hides the serialization of parameters and the network-level
communication in order to present a simple invocation mechanism to the
caller.
In the remote JVM, each remote object may have a corresponding skeleton (in
Java 2 platform-only environments, skeletons are not required). The skeleton
is responsible for dispatching the call to the actual remote object
implementation.
When a skeleton receives an incoming method invocation it does the
following:
1. unmarshals (reads) the parameters for the remote method,
2. invokes the method on the actual remote object implementation, and
3. marshals (writes and transmits) the result (return value or exception) to
the caller.

In the Java 2 SDK, Standard Edition, v1.2 an additional stub protocol was
introduced that eliminates the need for skeletons in Java 2 platform-only
environments. Instead, generic code is used to carry out the duties performed
by skeletons in JDK1.1. Stubs and skeletons are generated by the rmic
compiler.

Example:
Step 1. All Remote interfaces must extends the Remote, which is a part
of java.rmi.Remote. All remote methods can throw a remote exception.
import java.rmi.*;
public interface helloinfo extends Remote
{
public void hello() throws RemoteException;
}
Step 2. Implements remote interface. All remote objects must extend
UnicastRemoteObject, which provides functionality that is needed to
make objects available from remote machines.
import java.rmi.*;
import java.rmi.server.*;
public class helloimpl extends UnicastRemoteObject implements helloinfo
{
public helloimpl() throws RemoteException
{ }
public void hello() throws RemoteException
{ System.out.println(hello & welcome); }
}
Step 3. Contains main program for server m/c. The main function is to
update RMI registry on that m/c & done by rebind() method of naming
class.
import java.rmi.*;
public class helloserver
{
public static void main(String args[])
{
try
{
helloimpl h=new helloimpl();
Naming.rebind(helloserver,h);
// or rmi://localhost/helloserver

}
catch(Exception e) { }
}
}
Step 4. Client implementation
import java.rmi.*;
public class helloclient
{
public static void main(String args[])
{
try
{
helloinfo h1=(helloinfo) Naming.lookup(helloserver);
h1.hello();
}
catch(Exception e) { }
}
}
To run the above example follow the steps:

Create a directory like rmiprg\msg.

Store all programs in this folder.
In each prg use package msg;
Set classpath=c:\rmiprg
Compile all java prgs in msg directory.
C:\rmiprg> rmic msg.helloimpl
Start rmiregistry on DOS prompt.
C:\rmiprg> java msg.helloserver
C:\rmiprg> java msg.helloclient

Example: Take 2 float numbers from client, call a remote method add(),
display addition of numbers.
Step 1.
import java.rmi.*;
public interface addserverintf extends Remote
{
public double add(double d1, double2) throws RemoteException;
}
Step 2.
import java.rmi.*; import java.rmi.server.*;
public class addserverimpl extends UnicastRemoteObject implements
addserverintf
{
public addserverimpl() throws RemoteException
{ }
public double add(double d1, double d2) throws RemoteException
{ return d1+d2; }
}
Step 3.
import java.rmi.*; import java.net.*;
public class addserver
{
public static void main(String args[])
{
try
{
addserverimpl as1=new addserverimpl();
Naming.rebind(addserver,as1);
// or rmi://localhost/helloserver
}
catch(Exception e) { }
}
}
Step 4. Client implementation
import java.rmi.*;
public class addclient
{
public static void main(String args[])
{
try
{
addserverintf as2=(addserverintf) Naming.lookup (addserver);
System.out.println(first number:+args[0]);

double d1=Double.valueOf(args[0]).doubleValue();
System.out.println(Second number:+args[1]);
double d2=Double.valueOf(args[1]).doubleValue();
System.out.println(sum is:+as2.add(d1,d2));
}
catch(Exception e) { }
}
}