Remote Method Invocation (RMI) allows objects running in one Java virtual machine to invoke methods on objects running in another Java virtual machine. RMI uses object serialization to marshal and unmarshal parameters and supports true object-oriented polymorphism. RMI is implemented using three layers - stub, remote reference, and transport connection layers. The stub and skeleton hide the underlying network implementation details and allow remote objects to be called similar to local objects. Security is an important consideration in RMI and a security manager must be installed and permissions configured to control access to remote objects and classes.

1. Remote Method Invocation
Abstract—Recently The Java Remote
Method Invocation (RMI) system allows
an object running in one Java virtual
machine to invoke methods on an object
running in another Java virtual machine.
RMI provides for remote communication
between programs written in the Java
programming language.
I. INTRODUCTION
The
RMI
Java
Remote
Method
Invocation Application Programming Interface (API),
or Java RMI, is a Java API that performs the objectoriented equivalent of remote procedure calls (RPC),
with support for direct transfer of serialized Java
objects and distributed garbage collection.
The original implementation depends on Java Virtual
Machine (JVM) class representation mechanisms and
it thus only supports making calls from one JVM to
another. The protocol underlying this Java-only
implementation is known as Java Remote Method
Protocol (JRMP).
In order to support code running in a nonJVM context, a CORBA version was later
developed.
In order to support code running in a
non-JVM context, a CORBA version
was later developed.
II.WHAT IS RMI?
Remote Method Invocationis a mechanism that allows
object to interact which are locate in different
computer in different network.RMI is a package for
writing, executing java program.Provides framework
for developing & running servers.A true distributed
computing application interface for Java, written to
provide easy access to objects existing on
remotevirtual machines. Helps provide access to
objects existing on remote virtual machines.Remote
objects
can be treated similarly to local objects.Handles
marshaling, transportation, and garbage collection of
the remote objects.Became part of the JDK with
version 1.1
III.WHAT IS RMI NOT?
Not an all-purpose ORB architecture likeCORBA and
DCOM.Not language independent.Limited only to
Java.Interfaces to remote objects are defined using
ordinary Java interfaces (rather than having to use a
special purpose interface definition language).Can
provide more advanced features like serialization and
security.
IV. WHAT IS JAVA RMI?
JAVA RMI hides all the aspects of d.s & provides a
uniform way by which object can be access.Java
Remote Method Invocation (Java RMI) enables the
programmer to create distributed Java technologybased to Java technology-based applications, in which
the methods of remote Java objects can be invoked
from other Java virtual machines, possibly on different
hosts. RMI uses object serialization to marshal and
marshal parameters and does not truncate types,
supporting true object-oriented polymorphism.Java
RMI is included with Java SE and is available as
a separate download for Java ME.Eg: RMIServer.java
provide methods string gets(),void gets(s).
client may use 2 methods for retrieving &
storing a string in s.
client may modify & inspect local state of
server object.
V.RMI IS IMPLEMENTATION AS THREE
LAYERS:
A stub program in the client side of the client/server
relationship, and a corresponding skeleton at the
server end. The stub appears to the calling program to
be the program being called for a service. (Sun uses
the term proxy as a synonym for stub.)
A Remote Reference Layer that can behave differently
depending on the parameters passed by the calling

2. program. For example, this layer can determine
whether the request is to call a single remote service or
multiple remote programs as in a multicast.
VII. JAVA RMI ENVIRONMENT:
A Transport Connection Layer, which sets up and
manages the request. A single request travels down
through the layers on one computer and up through the
layers at the other end.
RMI is supplied as part of Sun Microsystem's Java
Development Kit (JDK).
VI. DIAGRAMATIC REPRESENTATION OF
LAYERS OF RMI:
Fig 3: Java RMI environment.
XI. WORKING OF RMI:
Connections made when client uses RMI:
Fig 1: Layers of RMI.
VII. ARCHITECTURE OF RMI:
Fig 4: Working of RMI
Java1.1 Remote Method Invocation allows you to send
a message to some objects living on another machine
and get a result as if the object lived on your local
machine.
Let we see how to create our own RMI objects.
a.
REMOTE INTERFACES:
When you create a remote object, you mask the
underlying implementation by passing around an
interface.
Fig 2: ARCHITECTURE OF RMI
When you create a remote interface, you must
follow these guidelines:
The remote interface must be public.
The remote interface must extend the
interface java.rmi.Remote

3. Each method in the remote interface must
declare java.rmi.RemoteException in
its throws clause, in addition to any applicationspecific exceptions.
A remote object passed as an argument or return
value must be declared as the remote interface,
not the implementation class.
Examples:
InterCCRead.java
InterCCWrite.java.
b.
IMPLEMENTING
INTERFACE:
THE
REMOTE
The
server
must
contain
a
class
that
extends UnicastRemoteObject and implements the
remote interface. This class may also have additional
methods, but only the methods in the remote interface
will be available to the client, of course, since the
client will get only a handle to the interface, not the
actual class that implements it.You must explicitly
define the constructor for the remote object, even if
you are only defining a default constructor that just
calls the base-class constructor.
d.
CREATE
THE
SKELETONS::
STUBS
AND
THE
You must create the stubs and the skeletons that
provide the network connection operations and allow
you to pretend that the remote object is just another
local object on your machine.You invoke the rmic tool
on your compiled code, and it creates the necessary
files.
Note: The rmic tool is particular about packages and
classpaths.
You don't have to be in the directory containing
TheServer.class when you execute this command, but
the results will be placed in the current directory.
When rmic runs successfully, you'll have two new
classes
in
the
directory:
TheServer_Stub.class
TheServer_Skel.class.
Now you're ready to get the server and client to talk to
each other.
IMPLEMENTATION MODEL OF JAVA RMI
USING STUBS AND SKELETON:
Examples:
TheServer.java
RServer.java
SMO.java
c.
SET UP THE REGISTRY:
In the server codes, you see a call to the static
method Naming.bind().However, this call requires that
the registry be running as a separate process on the
computer.
The bind() command becomes:
Naming.bind("//machine_name/TheServer",service_na
me);
Naming.bind("TheServer", service_name);
The important thing is that it's a unique name in the
registry that the client knows to look for to procure the
remote object. If the name is already in the registry,
you'll get an AlreadyBoundException.To prevent this,
you can always use rebind() either adds a new entry or
replaces the one that's already there.
Fig 5: Implementation of Java RMI model.
e.
USING THE REMOTE OBJECT:
The whole point of RMI is to make the use of remote
objects very simple.The only extra thing you must do
in your client program is to look up and fetch the
remote interface from the server.From then on, it's just
regular java programming: sending messages to
objects.
Example:
TheClient.java

4. X. PROGRAMMING A CLIENT:
Having described how to define Remote and
Serializable classes, we now discuss how to program
the Client and Server.The Client itself is just a Java
program.The name of a remote object includes the
following information:
The Internet name (or address) of the machine
that is running the Object Registry with which
the remote object is being registered. If the
Object Registry is running on the same
machine as the one that is making the request,
then the name of the machine can be omitted.
The port to which the Object Registry is
listening. If the Object Registry is listening to
the default port, 1099, then this does not have
to be included in the name.
The local name of the remote object within the
Object Registry.
The Naming.lookup method obtains an object handle
from
the
Object
Registry
running
on ortles.ccs.neu.edu and listening to the default
port.The remote method invocation in the example
Client is hello.say(). It returns a String which is then
printed
XI. PROGRAMMING A SERVER:
The Server itself is just a Java program.
Here is the example Server:
/*** Server program for the "Hello, world!" example.
* @param argv The command line arguments which
are ignored. */
public static void main (String[] argv)
{
Here is the example Client program:
try
/**
* Client program for the "Hello, world!"
example.
{
* @param argv The command line arguments which
are ignored.
Naming.rebind
("Hello",
new
Hello
("Hello,
world!"));
System.out.println ("Hello
Server is ready.");
*/
public static void main (String[] argv)
}
{
catch (Exception e)
try
{
{
HelloInterface hello =
(HelloInterface) Naming.lookup
("//ortles.ccs.neu.edu/Hello");
System.out.println ("Hello
Server failed: " + e);
System.out.println (hello.say());
}
}
catch (Exception e)
{
System.out.println
exception: " + e);
}
}
}
("HelloClient
The rmiregistry Object Registry only accepts requests
to bind and unbind objects running on the same
machine, so it is never necessary to specify the name
of the machine when one is registering an object.The
code for the Server can be placed in any convenient
class. In the example Server, it was placed in a
class HelloServer that contains only the program
above.

5. XII. STARTING A SERVER:
Before starting the Server, one should first start the
Object Registry, and leave it running in the
background. One performs this by using the
command:
rmiregistry
}
Here is the file:=
Hello.java:
import java.rmi.*;
import java.rmi.server.*;
The Server should then be started; and, like the Object
Registry, left running in the background. The example
Server is started using the command:
java HelloServer
/**
* Remote Class for the "Hello, world!" example.
*/
XIII. RUNNING A CLIENT:
The Client is run like any other java program.The
example Client is executed using:
public class Hello extends UnicastRemoteObject
implements HelloInterface
{
private String message;
java HelloClient
/**
* Construct a remote object
XIV. EXAMPLE:
In the example program, we need a Remote class and
its corresponding Remote interface. We call
these Hello and HelloInterface, respectively. Here is
the file:-=
* @param msg the message of the remote object,
such as "Hello, world!".
* @exception RemoteException if the object handle
cannot be constructed.
*/
HelloInterface.java:
public Hello (String msg) throws RemoteException
import java.rmi.*;
/***Remote Interface for the "Hello, world!" example.
{ message = msg; }
*/
/**
public interface HelloInterface extends Remote
* Implementation of the remotely invocable method.
{
/**
* Remotely invocable method.
* @return the message of the remote object, such as
"Hello, world!".
* @return the message of the remote object, such as
"Hello, world!".
* @exception RemoteException if the remote
invocation fails.
*/
* @exception RemoteException if the remote
invocation fails.
public String say() throws RemoteException
{return message; }
*/
}
public String say() throws RemoteException;

6. All of the Remote interfaces and classes should be
compiled using javac.Once this has been completed,
the stubs and skeletons for the Remote interfaces
should be compiled by using the rmic stub compiler.
The stub and skeleton of the example Remote
interface are compiled with the command:
rmic Hello.
a java.rmi.server.RemoteObjectInvocationHandler as
its invocation handler.An existing application can be
deployed to use dynamically generated stub classes
unconditionally (that is, whether or not pregenerated
stub classes exist) by setting the system
property java.rmi.server.ignoreStubClasses to "true".
If this property is set to "true", pregenerated stub
classes are never used.
XV. ENHANCEMENTS IN JavaTM SE
DEVELOPMENT KIT (JDK) 6
java.rmi.MarshalledObject is now generic.
The class MarshalledObject
now has a type
parameter representing the type of the contained
serialized object:Bug fix: Explicit TCP ports freed
after remote objects unexported.Bug fix: Garbage
collection of client socket factories Default GC
interval lengthed to one hour
ENHANCEMENT & CHANGES IN PREVIOUS
RELEASES:
Dynamic Generation of Stub Classes (since 5.0)
XVI. SECURITY:
One of the most common problems one encounters
with RMI is a failure due to security constraints.One
sets the security policy by constructing a
SecurityManager
object
and
calling
the setSecurityManager method of the System class.
For example,
RMI will download a Serializable class from another
machine only if there is a security manager and the
security manager permits the downloading of the class
from that machine.The RMISecurityManager class
defines an example of a security manager that
normally permits such downloads.
The following code illustrates how to do this:
System.setSecurityManager (new
RMISecurityManager()
{
public void checkConnect (String host, int
port){}
public void checkConnect (String host, int
port, Object context) {} });
XVII. ENHANCEMENT IN SECURITY:
Fig 6: Enhancement and changes in RMI model
This release adds support for the dynamic generation
of stub classes at runtime, obviating the need to use
the Java Remote Method Invocation (Java RMI) stub
compiler, rmic, to pregenerate stub classes for remote
objects. When an application exports a remote object
and a pregenerated stub class for the remote object's
class cannot be loaded, the remote object's stub will
bea java.lang.reflect.Proxy instance (whose class is
dynamically
generated)
with
Defining and installing a security manager was the
original technique for specifying a security policy in
Java. Unfortunately, it is very difficult to design such a
class so that it does not leave any security holes. For
this reason, a new technique was introduced in Java
1.2, which is backward compatible with the old
technique. In the default security manager, all check
methods (except checkPermission) are implemented
by calling the checkPermission method. The type of
permission being checked is specified by the
parameter
of
type
Permission
passed
to
the checkPermission method.

7. For example,
The checkConnect methodcalls checkPermission with
a SocketPermission object.
The
default
implementation
of checkPermission is
to
call
the checkPermission method of the AccessController
class. This method checks whether the specified
permission is implied by a list of granted permissions.
The Permissions class is used for maintaining lists of
granted permissions and for checking whether a
particular permission has been granted.
CONCLUSION:
Remote Method Invocation is A mechanism that
allows object to interact which are locate in different
computer in different network.Provides framework for
developing & running servers.Helps provide access to
objects existing on remote virtual machines.Handles
marshalling, transportation, and garbage collection of
the remote objects. Became part of the JDK with
version 1.1.
Acknowledgement:
I will like to thank our Prof. for giving the chance to
explore oneself.
References:
http://en.wikipedia.org/wiki/Java_remote_method_inv
ocation
http://www.google.co.in/?gws_rd=cr&ei=bKEmUsrk
D5HjrAeB84DwBw#q=layers%20in%20rmi%20archi
tecture
http://www.java2all.com/1/5/21/110/Technology/RMI
/RMI-Introduction/RMI-Architecture