WOLAITA SODO UNIVERSITY

SCHOOL OF INFORMATICS

DEPARTMENT OF INFORMATION TECHNOLOGY

Assignment of ADVANCED JAVA

TITLE :-RMI

Name: Tizazu selemon

Program: Weekend in MSc IT
ID: PGW/48803/13

SUB TO:- Professor Dr.Natarajan Sivanandam,

Remote Method Invocation (RMI)
•The Remote Method Invocation (RMI) model represents a distributed object application.

RMI allows an object inside a JVM (a client) to invoke a method on an object running on a remote JVM
(a server) and have the results returned to the client. Therefore, RMI implies a client and a server.

•The server application typically creates an object and makes it accessible remotely.

o Therefore, the object is referred to as a remote object.

o The server registers the object that is available to clients.
o One of the ways this can be accomplished is through a naming facility provided as part of the
JDK, which is called the rmiregistry.
o The server uses the registry to bind an arbitrary name to a remote object.

• A client application receives a reference to the object on the server and then invokes methods on it.

o The client looks up the name in the registry and obtains a reference to an object that is able to
interface with the remote object.
o The reference is referred to as a remote object reference.
o Most importantly, a method invocation on a remote object has the same syntax as a method
invocation on a local object.

RMI Architecture
• The interface that the client and server objects use to interact with each other is provided through
stubs/skeleton, remote reference, and transport layers.

o Stubs and skeletons are Java objects that act as proxies to the client and server, respectively.
o All the network-related code is placed in the stub and skeleton, so that the client and server
will not have to deal with the network and sockets in their code.
o The remote reference layer handles the creation of and management of remote objects.
o The transport layer is the protocol that sends remote object requests across the network.

• A simple diagram showing the above relationships is shown below.

The Remote Interface
• The server's job is to accept requests from a client, perform some service, and then send the results
back to the client.

o The server must specify an interface that defines the methods available to clients as a service.
This remote interface defines the client view of the remote object.

• The remote interface is always written to extend the java.rmi.Remote interface.

o Remote is a "marker" interface that identifies interfaces whose methods may be invoked from a
non-local virtual machine.

CalendarTask.java

package examples.rmi;
import java.rmi.Remote;
import java.rmi.RemoteException;
import java.util.Calendar;
public interface CalendarTask extends Remote {
Calendar getDate() throws RemoteException;
}

• In the example above, getDate() is a remote method of the remote interface CalendarTask.

o All methods defined in the remote interface are required to state that they throw a
RemoteException.
o A RemoteException represents communication-related exceptions that may occur during the
execution of a remote method call.

The Remote Object

• An implementation of the CalendarTaskinterface is shown below.

o The implementation is referred to as the remote object.

o The implementation class extends UnicastRemoteObject to link into the RMI system. This is not
a requirement. A class that does not extend UnicastRemoteObject may use its exportObject()
method to be linked into RMI.
o When a class extends UnicastRemoteObject, it must provide a constructor declaring that it may
throw a RemoteExceptionobject. When this constructor calls super(), it activates code in
UnicastRemoteObject, which performs the RMI linking and remote object initialization.

CalendarImpl.java

package examples.rmi;
import java.rmi.RemoteException;
import java.rmi.server.UnicastRemoteObject;
 import java.util.Calendar;
public class CalendarImpl extends UnicastRemoteObject
implements CalendarTask {
private int counter = 1;
public CalendarImpl() throws RemoteException {}
public Calendar getDate() throws RemoteException{
System.out.print("Method called on server:");
System.out.println("counter = " + counter++);
return Calendar.getInstance();
}
}

Writing the Server

• The server creates the remote object, registers it under some arbitrary name, then waits for remote
requests.

o The java.rmi.registry.LocateRegistry class allows the RMI registry service (provided as part of
the JVM) to be started within the code by calling its createRegistry method. This could have
also been achieved by typing the following at a command prompt:rmiregistry
o The default port for RMI is 1099.
o The java.rmi.registry.Registry class provides two methods for binding objects to the registry.
o Naming.bind("ArbitraryName", remoteObj); throws an Exception if an object is already
bound under the "ArbitrayName.”
o Naming.rebind ("ArbitraryName", remoteObj); binds the object under the
"ArbitraryName" if it does not exist or overwrites the object that is bound.

• The example on the following page acts as a server that creates a CalendarImpl object and makes it
available to clients by binding it under a name of "TheCalendar. "

CalendarServer.java

package examples.rmi;
import java.rmi.Naming;
import java.rmi.registry.LocateRegistry;

public class CalendarServer {

public static void main(String args[]) {

System.out.println("Starting server...");
// Start RMI registry service and bind
// object to the registry
try {
LocateRegistry.createRegistry(1099);
 Naming.rebind("TheCalendar",
new CalendarImpl());
} catch (Exception e) {
e.printStackTrace();
System.exit(1);
}
System.out.println("Server ready");
}
}

• If both the client and the server are running Java SE 5 or higher, no additional work isneeded on the
server side.

o Simply compile the CalendarTask, CalendarImpl, and CalendarServer, and the server can then
be started.
o The reason for this is the introduction in Java SE 5 of dynamic generation of stub classes. Java
SE 5 adds support for the dynamic generation of stub classes at runtime, eliminating the need
to use the RMI stub compiler, rmic, to pre-generate stub classes for remote objects. Note that
rmic must still be used to pre-generate stub classes for remote objects that need to support
clients running on earlier versions.

The RMI Compiler

• If RMI is being used with a version of Java prior to Java SE 5, a stub must be generated on the server-
side and made available to the client.

o The RMI compiler (rmic) is a tool used to create any necessary stubs and/or skeletons to
support the remote object. Skelton(s) have been optional since Java SE 1.2.
o The rmic compiler is passed to the compiled version of the remote object and generates a stub
class from it as shown below.
rmic - keep - d %CLASSES% examples. rmi. CalendarImpl
o The "-keep" is optional and is being used so that, in addition to the generated .class files, the
.java files will be retained so that they can be viewed if desired.
o The result of running the rmic command above is a file named CalendarImpl_Stub.class.
o Since the "-keep" option was used, there is also a file named CalendarImpl_Stub.java.
o The CalendarImpl_Stub class generated is a client-side component and as such, must exist on
the client's classpath in order for client code to successfully communicate with the server.
o If the stub class is not available locally to the client, it must be loaded dynamically over the
network.
o Keep in mind that this is only necessary if a version of Java prior to Java SE 5 is being used.
Writing the Client
• An RMI client is a program that accesses the services provided by a remote object.

o The java.rmi.registry.LocateRegistry class allows the RMI registry service to be located by a

client by its getRegistry method. The java.rmi.registry.Registry class provides a lookup method
that takes the "ArbitraryName" the remote object was bound to by the server.

• Once the client obtains a reference to a remote object, it invokes methods as if the object were local.

CalendarClient.java

package examples.rmi;
import java.rmi.registry.*;
import java.util.Calendar;
public class CalendarClient {
public static void main(String args[]) {
Calendar c = null;
CalendarTask remoteObj;
String host = "localhost";
if(args.length == 1)
host = args[0];
try {
Registry r =
LocateRegistry.getRegistry(host, 1099);
Object o = r.lookup("TheCalendar");
remoteObj = (CalendarTask) o;
c = remoteObj.getDate();
} catch (Exception e) {
e.printStackTrace();
}
System.out.printf("%tc", c);
}
}
Remote Method Arguments and Return Values
• The arguments to a remote method must be Serializable.

o They must be primitive types or objects that implement the Serializable interface.
o The same restriction applies to return values. The RMI stub/skeleton layer decides how to send
arguments and return values over the network.
o If the object is Serializable but not Remote: the object is serialized and streamed in byte format;
and the receiver de-serializes the bytes into a copy of the original object.
o If the object is a Remote object: a remote reference for the object is marshaled and sent to the
remote process; and this reference is received and converted into a stub for the original object.
o If the argument or return value is not serializable, a java.rmi.MarshalException is thrown.

• The key difference between remote and non-remote objects is that Remote objects are sent by
reference, while non-remote objects (and primitive types) are sent by copy.

Dynamic Loading of Stub Classes

• If the client stub class is not available in the local CLASSPATH, it must be loaded dynamically over the
network.

o This is a typical scenario when the client and server are not running on the same machine.
o We will illustrate downloading of stub classes via a web server.

• When the RMI run-time system marshals a remote object stub, it encodes a URL in the byte stream to
tell the process on the other end of the stream where to look for the class file for the marshaled object.

o This URL is obtained from a system property called java.rmi.server.codebase. We will set this
property on the command line to point to a directory within the web server’s document base.
o Note that in order for a Java runtime system to be able to load classes remotely, it has to have a
security manager installed that will allow the remote load. There is one provided by the
java.rmi.RMISecurityManager class.
o The final issue is that the default Java security policy does not allow all the networking
operations required to load a class from a remote host. An RMI client that needs to load classes
remotely must have a policy file granting the necessary permissions. The name of the policy file
can be specified on the command line by setting the java.security.policy property.