Java Remote Method Invocation Program

Remote Method Invocation Sample Program

Remote interface:
1. The interface must be public.
2. The interface must extend the interface java.rmi.Remote.
3. Every method in the interface must declare that it throws java.rmi.RemoteException.
Other exceptions may also thrown.

HelloInterface.java

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;
}

Remote class:

1. It must implement a Remote interface.
2. It should extend the java.rmi.server.UnicastRemoteObject class.Objects of such a class exist in the address space of the server and can be invoked remotely. While there are other ways to define a Remote class, this is the simplest way to ensure that objects of a class can be used as remote objects. See the documentation of the java.rmi.server for more information.
3. It can have methods that are not in its Remote interface. These can only be invoked locally.

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. */
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;
}
}

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

The only problem one might encounter with this command is that rmic might not be able to find the files Hello.class and HelloInterface.class even though they are in the same directory where rmic is being executed. If this happens to you, then try setting the CLASSPATH environment variable to the current directory, as in the following command:

setenv CLASSPATH .

If your CLASSPATH variable already has some directories in it, then you might want to add the current directory to the others.

Remote class and its corresponding Remote interface. We call these Hello and HelloInterface, respectively. The Server requires the definition of both the Remote class and the Remote interface, but the Client only uses the Remote interface. Remote interface represents the type of an object handle, while the Remote class represents the type of an object. If a remote object is being used remotely, its type must be declared to be the type of the Remote interface, not the type of the Remote class.

Note: All remote objects must extend UnicastRemoteObject, which provides functionality that is needed to make objectsavailable for remote machines.

RMI Client program:

Client itself is just a Java program. It need not be part of a Remote or Serializable class, although it will use Remote and Serializable classes. A remote method invocation can return a remote object as its return value, but one must have a remote object in order to perform a remote method invocation. So to obtain a remote object one must already have one. Accordingly, there must be a separate mechanism for obtaining the first remote object. The Object Registry fulfills this requirement. It allows one to obtain a remote object using only the name of the remote object.

The name of a remote object includes the following information:

1. 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, this does not have to be included in the name.
3. The local name of the remote object within the Object Registry.

/** * 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 ("//RmiRegistryPath/Hello");
System.out.println (hello.say());
}
catch (Exception e)
{ System.out.println ("HelloClient exception: " + e);
}
}

The Naming.lookup method obtains an object handle from the Object Registry running on ortles.ccs.neu.edu and listening to the default port. Note that the result of Naming.lookup must be cast to the type of the Remote interface. The remote method invocation in the example Client is hello.say(). It returns a String which is then printed. A remote method invocation can return a String object because String is a Serializable class.

The code for the Client can be placed in any convenient class. In the example Client, it was placed in a class HelloClient that contains only the program above.

RMI Server:

Server itself is just a Java program. It need not be a Remote or Serializable class, although it will use them. The Server some responsibilities:

1. If class definitions for Serializable classes need to be downloaded from another machine,
then the security policy of your program must be modified. Java provides a security manager class called RMISecurityManager for this purpose. The RMISecurityManager defines a security policy that allows the downloading of Serializable classes from another machine. The "Hello, World!" example does not need such downloads, since the only Serializable class it uses String. As a result it isn't necessary to modify the security policy for the example program. If your program defines Serializable classes that need to be downloaded to another machine, then insert the System.setSecurityManager (new RMISecurityManager ()); as the first statement in the main program below. If this does not work for your program, then you should consult the Security section below.

2. At least one remote object must be registered with the Object Registry. The statement for this is: Naming.rebind (objectName, object); where object is the remote object being registered, and objectName is the String that names the remote object.

/** * 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);
} }

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

Running the client and server:

Start the rmiregistry
To start the registry, Windows users should do the following (assuming that your java\bin directory is in the current path):-
start rmiregistry

To start the registry, Unix users should do the following:-
rmiregistry &

Compile the server
Compile the server, and use the rmic tool to create stub files.

Start the server
From the directory in which the classes are located, type the following:-
java ServerProgram

Start the client
You can run the client locally, or from a different machine. In either case, you'll need to specify the hostname of the machine where you are running the server. If you're running it locally, use localhost as the hostname.
java ClientProgram