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.

1. Distributed System:
Remote Method Invocation
PRESENTED BY:SONALI PARAB, 32

2. Introduction:

The 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 Protocols (JRMP).

In order to support code running
a COBRA version was later developed.
in
a
non-JVM
context,

3. What is Remote Method Invocation?
A
mechanism that allows object to interact which are
locate in different computer in different network.
 A package
for writing, executing java program.
 Provides
framework for developing & running
servers.

4.  A true
distributed computing application interface for
Java, written to provide easy access to objects
existing on remote virtual machines.
 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.

5. Restrictions on Remote Method
Invocation?
►
Strictly Java. Cannot use with other code outside
Java
 Cannot
guarantee that a client will always use the
same thread in consecutive calls. Meaning you need
to write a mechanism for identifying the client
yourself

6. 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 technology-based 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 unmarshal
parameters and does not truncate types, supporting true object-

7. WHAT IS JAVA RMI?
•
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.

8. Implemented of RMI in 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 program.
For example, this layer can determine whether the request is
to call a single remote service or multiple remote programs as

9. Implemented of RMI in three layers:
•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).

10. DIAGRAMATIC REPRESENTATION OF
LAYERS OF RMI:

11. ARCHITECTURE OF RMI:

12. JAVA RMI ENVIRONMENT:

13. 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.

14. Let we see how to create our own RMI objects.
1.
REMOTE INTERFACES:
When you create a remote object, you mask the
underlying implementation by passing around an
interface.
 When you create a remote interface, you must
follow these guidelines:
1. The remote interface must be public.
2. The remote interface must extend the
interface java.rmi.Remote

15. 

3. Each method in the remote interface must
declare
java.rmi.RemoteException
in
its throws clause, in addition to any applicationspecific exceptions.
4. 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.

16. 2.IMPLEMENTING THE REMOTE INTERFACE:
•
•
•
•
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.
Examples:

17. 3.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_name);
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.

18. 4.CREATE THE STUBS AND THE SKELETONS:
• 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:

19. IMPLEMENTATION MODEL OF JAVA RMI
USING STUBS AND SKELETON:

20. 5.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

21. PROGRAMMING A CLIENT:
•
•
•
1.
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.
2.
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.
3.
The local name of the remote object within the Object Registry.

22. Here is the example Client program:
/** * Client program for the "Hello, world!" example.
* @param argv The command line arguments which are ignored. */
public static void main (String[] argv)
{
try {
HelloInterface hello = (HelloInterface) Naming.lookup
("//ortles.ccs.neu.edu/Hello");
System.out.println (hello.say());
}
catch (Exception e)
{
System.out.println ("HelloClient exception: " + e);
}
}

23. •
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

24. 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)
{ try {
Naming.rebind ("Hello", new Hello ("Hello, world!"));
System.out.println ("Hello Server is ready.");
} catch (Exception e)
{
System.out.println ("Hello Server failed: " + e);
} }

25. PROGRAMMING A SERVER:
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.

26. 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
•
•
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

27. RUNNING A CLIENT:
•
The Client is run like any other java program.
•
The example Client is executed using:

java HelloClient

28. 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:-=
HelloInterface.java:

29. EXAMPLE:
import java.rmi.*;
/**
* Remote Interface for the "Hello, world!" example.
*/
public interface HelloInterface extends Remote
{
/**
* Remotely invocable method.
* @return the message of the remote object, such as "Hello,
world!".
* @exception RemoteException if the remote invocation fails.
*/
public String say() throws RemoteException;
}

30. Here is the file:=
Hello.java:
import java.rmi.*;
import java.rmi.server.*;
/**
* Remote Class for the "Hello, world!" example.*/
public class Hello extends UnicastRemoteObject implements
HelloInterface
{
private String message;
/**
* Construct a remote object
* @param msg the message of the remote object, such as "Hello,
world!".
* @exception RemoteException if the object handle cannot be
constructed.

31. public Hello (String msg) throws RemoteException {
message = msg;
}
/**
* Implementation of the remotely invocable method.
* @return the message of the remote object, such as "Hello, world!".
* @exception RemoteException if the remote invocation fails.
*/
public String say() throws RemoteException {
return message;
}
}

32. •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.

33. 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

34. ENHANCEMENT & CHANGES IN
PREVIOUS RELEASES:
Dynamic Generation of Stub Classes (since 5.0)
•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 be a java.lang.reflect.Proxy instance (whose class is
dynamically
generated)
with
a java.rmi.server.RemoteObjectInvocationHandler as its invocation

35. ENHANCEMENT & CHANGES IN
PREVIOUS RELEASES:
•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.

37. 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.

38. SECURITY:
•
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)
{}});

39. ENHANCEMENT IN SECURITY:
•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
(except
checkPermission)
are
implemented
by
the checkPermission method.
methods
calling

40. •
The type of permission being checked is specified by the
parameter
of
type
Permission
passed
to
the checkPermission method.
•
Example,
The
checkConnect
method
calls 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
•
•

42. Q & A?