Getting Started Using RMI

This tutorial shows you the steps to follow to create a distributed version of the classic Hello World program using Java Remote Method Invocation (RMI). While you work through this example, you will probably come up with a number of related questions. You may find the answer in the RMI FAQ, or you may wish to look in the email archives of the rmi-users alias. If you'd like to subscribe to the rmi-users email alias, click here.

The distributed Hello World example uses an applet to make a remote method call to the server, from which the applet was downloaded, to retrieve the message "Hello World!". When the applet runs, "Hello World!" is displayed on the client browser.

This tutorial is organized as follows:

  1. The steps to write the Java source and HTML files
  2. The steps to compile and deploy class files and HTML files
  3. The steps to start the RMI registry, server, and applet
The files needed for this tutorial are: Note:  For the remainder of this tutorial, the terms "remote object implementation", "object implementation," and "implementation" may be used interchangeably to refer to  the class, examples.hello.HelloImpl, which implements a remote interface.

For all of the source code used in this tutorial, you may choose from the following formats:

Write the Java Source and HTML files

Because the Java language requires a mapping between the fully-qualified package name of a class and the directory path to that class, before you begin writing any Java code you should decide on package and directory names. This mapping allows the Java compiler to know the directory in which to find the class files mentioned in a Java program. For the programs in this tutorial, the package name is examples.hello and the source directory is $HOME/mysrc/examples/hello.

To create the directory for your source files on Solaris, execute the command: 

mkdir -p $HOME/mysrc/examples/hello
On Windows platforms, you would go to the directory of your choice, and type:

mkdir mysrc
mkdir mysrc\examples
mkdir mysrc\examples\hello

There are three tasks to complete in this section:
 

  1. Define the functions of the remote class as a Java interface
  2. Write the implementation and server classes
  3. Write a client program that uses the remote service
 
Define the functions of the remote class as a Java interface
In Java, a remote object is an instance of a class that implements a remote interface. Your remote interface will declare each of the methods that you would like to call remotely.  Remote interfaces have the following characteristics: Because remote method invocations can fail in very different ways from local method invocations (due to network related communication problems and server problems) remote methods will report communication failures by throwing a java.rmi.RemoteException.  If you want more information on failure and recovery in distributed systems, you may wish to read A Note on Distributed Computing.

Write the implementation and server classes

At a minimum, a remote object implementation class must:

A "server" class in this context, is the class which has a main method that creates an instance of the remote object implementation, and binds that instance to a name in the rmiregistry. The class that contains this main method could be the implementation class itself, or another class entirely.

In this example, the main method is part of examples.hello.HelloImpl. The server program needs to:

An explanation of each of the preceding six steps follows the source for HelloImpl.java: 
package examples.hello;

import java.rmi.Naming;
import java.rmi.RemoteException;
import java.rmi.RMISecurityManager;
import java.rmi.server.UnicastRemoteObject;

public class HelloImpl extends UnicastRemoteObject
    implements Hello {

    public HelloImpl() throws RemoteException {
        super();
    }

    public String sayHello() {
        return  "Hello World!";
    }
    public static void main(String args[]) {

        // Create and install a security manager
        if (System.getSecurityManager() == null) {
            System.setSecurityManager(new RMISecurityManager());
        }
        try {
            HelloImpl obj = new HelloImpl();
            // Bind this object instance to the name "HelloServer"
            Naming.rebind("//myhost/HelloServer", obj);
            System.out.println("HelloServer bound in registry");
        } catch (Exception e) {
             System.out.println("HelloImpl err: " + e.getMessage());
             e.printStackTrace();
        }
    }
}

Implement a remote interface
In the Java language, when a class declares that it implements an interface, a contract is formed between the class and the compiler. By entering into this contract, the class is promising that it will provide method bodies, or definitions, for each of the method signatures declared in the interface that it is implementing. Interface methods are implicitly public and abstract, so if the implementation class doesn't fufill it's contract, it becomes by definition an abstract class, and the compiler will point out this fact if the class was not declared abstract.

The implementation class in this example is examples.hello.HelloImpl.  The implementation class declares which remote interface(s) it is implementing.  Here is the HelloImpl class declaration: 

public class HelloImpl extends UnicastRemoteObject
     implements Hello
As a convenience, the implementation class can extend a remote class, which in this example is java.rmi.server.UnicastRemoteObject.  By extending UnicastRemoteObject the HelloImpl class can be used to create a remote object that: If you want a remote object that can be activated (created) when a client requests it, rather than running all the time, after you finish this tutorial, you can take a look at the Remote Object Activation tutorial. Also, you can learn about how to use your own communication protocol, rather than the TCP sockets that RMI uses by default, in the tutorial on Creating a Custom RMI socket factory.
 

Define the constructor for the remote object
The constructor for a remote class provides the same functionality as the constructor for a non-remote class: it initializes the variables of each newly created instance of the class, and returns an instance of the class to the program which called the constructor.

In addition, your remote object instance will need to be "exported".  Exporting a remote object makes it available to accept incoming remote method requests by listening for incoming calls to the remote object on an anonymous port. When you extend java.rmi.server.UnicastRemoteObject or java.rmi.activation.Activatable, your class will be automatically exported upon creation.

If you choose to extend a remote object from any class other than UnicastRemoteObject or Activatable, you will need to explicitly export the remote object by calling either the UnicastRemoteObject.exportObject method or the  Activatable.exportObject method from your class's constructor (or another initialization method, as appropriate).

Because the object export could potentially throw a java.rmi.RemoteException, you must define a constructor that throws a RemoteException, even if the constructor does nothing else. If you forget the constructor, javac will produce the following error message:

HelloImpl.java:13: Exception java.rmi.RemoteException must be caught, or it must be declared in the throws clause of this method.
        super();
             ^
1 error
To review: The implementation class for a remote object needs to: Here is the constructor for the examples.hello.HelloImpl class:
public HelloImpl() throws RemoteException {
        super();
}
Note the following: Although the call to  the superclass's no-argument constructor, super(), occurs by default (even if omitted), it is included in this example to make clear the fact that the Java VM constructs the superclass before the class.

Provide an implementation for each remote method
The implementation class for a remote object contains the code that implements each of the remote methods specified in the remote interface.  For example, here is the implementation for the sayHello method, which returns the string "Hello World!" to the caller: 

public String sayHello() throws RemoteException {
        return  "Hello World!";
}
Arguments to, or return values from, remote methods can be of any Java type, including objects, as long as those objects implement the interface java.io.Serializable. Most of the core Java classes in java.lang and java.util implement the Serializable interface.  In RMI: A class can define methods not specified in the remote interface, but those methods can only be invoked within the virtual machine running the service and cannot be invoked remotely.

Create and install a security manager
The main method of the server first needs to create and install a security manager: either the RMISecurityManager or one that you have defined yourself. For example:

if (System.getSecurityManager() == null) {
    System.setSecurityManager(new RMISecurityManager());
}
A security manager needs to be running so that it can guarantee that the classes that get loaded do not perform operations that they are not allowed to perform. If no security manager is specified no class loading, by RMI clients or servers, is allowed, aside from what can be found in the local CLASSPATH.

Create one or more instances of a remote object
The main method of the server needs to create one or more instances of the remote object implementation which provides the service. For example: 

HelloImpl obj = new HelloImpl();
The constructor exports the remote object, which means that once created, the remote object is ready to accept incoming calls.

Register the remote object
For a caller (client, peer, or applet) to be able to invoke a method on a remote object, that caller must first obtain a reference to the remote object.

For bootstrapping, the RMI system provides a remote object registry that allows you to bind a URL-formatted name of the form "//host/objectname" to the remote object, where objectname is a simple string name.

The RMI registry is a simple server-side name server that allows remote clients to get a reference to a remote object. It is typically used only to locate the first remote object an RMI client needs to talk to. Then that first object in turn, would provide application-specific support for finding other objects.

For example, the reference can be obtained as a parameter to, or a return value from, another remote method call. For a discussion on how this works, please take a look at Applying the Factory Pattern to RMI.

Once a remote object is registered on the server, callers can look up the object by name, obtain a remote object reference, and then remotely invoke methods on the object.

For example, the following code binds the name "HelloServer" to a reference for the remote object: 

Naming.rebind("//myhost/HelloServer", obj);
Note the following about the arguments to the rebind method call: For security reasons, an application can bind or unbind only to a registry running on the same host. This prevents a client from removing or overwriting any of the entries in a server's remote registry. A lookup, however, can be done from any host.
Write a client program that uses the remote service

The applet part of the distributed Hello World example remotely invokes the sayHello method in order to get the string "Hello World!", which is displayed when the applet runs. Here is the code for the applet:


    package examples.hello;

    import java.applet.Applet;
    import java.awt.Graphics;
    import java.rmi.Naming;
    import java.rmi.RemoteException;

    public class HelloApplet extends Applet {

        String message = "blank";
     
        // "obj" is the identifier that we'll use to refer
        // to the remote object that implements the "Hello"
        // interface
        Hello obj = null;

        public void init() {
            try {
                obj = (Hello)Naming.lookup("//" +
                             getCodeBase().getHost() + "/HelloServer");
                message = obj.sayHello();
            } catch (Exception e) {
                System.out.println("HelloApplet exception: " +
                                        e.getMessage());
                e.printStackTrace();
            }
        }

        public void paint(Graphics g) {
            g.drawString(message, 25, 50);
        }
    }

  1. First, the applet gets a reference to the remote object implementation (advertised as "HelloServer") from the server host's rmiregistry.  Like the Naming.rebind method, the Naming.lookup method takes a URL-formatted java.lang.String. In this example, the applet constructs the URL string by using the getCodeBase method in conjunction with the getHost method. Naming.lookup takes care of the following tasks:

    2.    
  2. The applet invokes the remote sayHello method on the server's remote object

    3.  
  3. The applet invokes the paint method, causing the string "Hello World!" to be displayed in the drawing area of the applet.
The constructed URL-string that is passed as a prameter to the Naming.lookup method must include the server's hostname. Otherwise, the applet's lookup attempt will default to the client, and the AppletSecurityManager will throw an exception since the applet cannot access the local system, but is instead limited to communicating only with the applet's host.

Here is the HTML code for the web page that references the Hello World applet:


<HTML>
<title>Hello World</title>
<center> <h1>Hello World</h1> </center>

The message from the HelloServer is:
<p>
<applet codebase="myclasses/"
        code="examples.hello.HelloApplet"
        width=500 height=120>
</applet>
</HTML>

Note the following:

Compile and Deploy Class Files and HTML Files

The source code for the Hello World example is now complete and the $HOME/mysrc/examples/hello directory has four files: In this section, you compile the .java source files to create .class files. You then run the rmic compiler to create stubs and skeletons. A stub is a client-side proxy for a remote object which forwards RMI calls to the server-side dispatcher, which in turn forwards the call to the actual remote object implementation.

When you use the javac and rmic compilers, you must specify where the resulting class files should reside. For applets, all files should be in the applet's codebase directory. For our example, this directory is $HOME/public_html/myclasses.

Some Web servers allow accessing a user's public_html directory via an HTTP URL constructed as "http://host/~username/". If your Web server does not support this convention, you may use a file URL of the form "file://home/username/public_html".

There are four tasks to complete in this section:

  1. Compile the Java source files
  2. Use rmic to generate stubs and sleletons
  3. Move the HTML file to the deployment directory
  4. Set paths for runtime

    Compile the Java source files

    Make sure that the deployment directory $HOME/public_html/myclasses and the development directory $HOME/mysrc/examples/hello are each accessible through the local CLASSPATH on the development machine, before attempting to compile.

    To compile the Java source files, run the javac command as follows: 

    javac -d $HOME/public_html/myclasses
        Hello.java HelloImpl.java HelloApplet.java
    This command creates the directory examples/hello (if it does not already exist) in the directory $HOME/public_html/myclasses. The command then writes to that directory the files Hello.class, HelloImpl.class, and HelloApplet.class. These are the remote interface, the implementation, and the applet respectively.  For an explanation of javac options, you can refer to the Solaris javac manual page or the  Win32 javac manual page.

    Use rmic to generate skeletons and/or stubs

    To create stub and skeleton files, run the rmic compiler on the fully-qualified package names of compiled class files that contain remote object implementations, like my.package.MyImpl. The rmic command takes one or more class names as an argument and produces class files of the form MyImpl_Skel.class and MyImpl_Stub.class.

    By default, in JDK 1.2, rmic runs with the -vcompat flag on, which produces stubs and skeletons that support access to:
     

      1. Unicast (not Activatable) remote objects from 1.1 clients and
      2. All types of remote objects from 1.2 clients

        3.  
    If you will only ever need suport for 1.2 clients, rmic can be run with the -v1.2 option. For an explanation of rmic options, you can refer to the Solaris rmic  manual page or the  Win32 rmic manual page.

    For example, to create the stub and skeleton for the HelloImpl remote object implementation, run rmic like this: 

    rmic -d $HOME/public_html/myclasses examples.hello.HelloImpl
    The -d option indicates the root directory in which to place the compiled stub and skeleton class files. So the preceding command creates the following files in the directory $HOME/public_html/myclasses/examples/hello:
      The generated stub class implements exactly the same set of remote interfaces as the remote object itself. This means that a client can use the Java language's built-in operators for casting and type checking. It also means that Java remote objects support true object-oriented polymorphism.

    Move the HTML file to the deployment directory

    To make the web page that references the applet visible to clients, the hello.html file must be moved from the development directory to the applet's codebase directory. For example:
      
    mv $HOME/mysrc/examples/hello/hello.html $HOME/public_html/

    Set paths for runtime

    Make sure that the $HOME/public_html/codebase directory is available through the server's local CLASSPATH when you run the HelloImpl server. 

Start the RMI registry, server, and applet

There are three tasks to complete in this section:
  1. Start the RMI registry
  2. Start the server
  3. Run the applet

Start the RMI registry

The RMI registry is a simple server-side name server that allows remote clients to get a reference to a remote object. It is typically used only to locate the first remote object an application needs to talk to. Then that object in turn would provide application-specific support for finding other objects.

Note:  Before you start the rmiregistry, you must make sure that the shell or window in which you will run the registry, either has no CLASSPATH set or has a CLASSPATH that does not include the path to any classes that you want downloaded to your client, including the stubs for your remote object implementation classes.

If you start the rmiregistry, and it can find your stub classes in its CLASSPATH, it will ignore the server's java.rmi.server.codebase property, and as a result, your client(s) will not be able to download the stub code for your remote object.

To start the registry on the server, execute the rmiregistry command. This command produces no output and is typically run in the background. For more on the rmiregistry, you can refer to the Solaris rmiregistry  manual page or the  Win32 rmiregistry manual page.
In order to run this code on your system, you'll need to change the location of the policy file to be the location of the directory on your system, where you've installed the example source code.

For example, on Solaris:

rmiregistry -J-Djava.security.policy=$HOME/mysrc/policy &
Note: In this example, for simplicity,  we will use a policy file that gives global permission to anyone from anywhere. Do not use this policy file in a production environment. For more information on how to properly open up permissions using a java.security.policy file, please refer to to the following documents:
    http://java.sun.com/products/jdk/1.2/docs/guide/security/PolicyFiles.html
    http://java.sun.com/products/jdk/1.2/docs/guide/security/permissions.html

For example, on Windows 95 or Windows NT: 

start rmiregistry -J-Djava.security.policy=C:\yourdirectory\mysrc\policy
(Use javaw if start is not available.)

The registry by default runs on port 1099. To start the registry on a different port, specify the port number from the command-line. For example, to start the registry on port 2001 on a Windows NT system: 

start rmiregistry -J-Djava.security.policy=C:\yourdirectory\mysrc\policy 2001
If the registry is running on a port other than the default, you need to specify the port number in the name handed to the URL-based methods of the java.rmi.Naming class when making calls to the registry. For example, if the registry is running on port 2001 in the Hello World example, the call required to bind the URL of the HelloServer to the remote object reference would be: 
Naming.rebind("//myhost:2001/HelloServer", obj);
You must stop and restart the registry any time you modify a remote interface or use modified/additional remote interfaces in a remote object implementation. Otherwise, the type of the object reference bound in the registry will not match the modified class.
 
 

Start the server

When starting the server, the java.rmi.server.codebase property must be specified, so that the stub class can be dynamically downloaded to the registry and then to the client. Run the server, setting the codebase property to be the location of the implementation stubs.  Since the codebase property can only reference a single directory, make sure that any other classes that may need to be downloaded, have also bee installed in the directory referenced by java.rmi.server.codebase.

For explanations of each of the java.rmi.server properties, click here. To see all the available java.rmi.activation properties, click here. For an explanation of java options, you can refer to the Solaris java  manual page or the  Win32 java manual page.  If you have problems running the example code, please take a look at the RMI Networking FAQ.

Note: A stub class is dynamically downloaded to a client's virtual machine only when the class is not already available locally and the java.rmi.server.codebase property has been set properly, to where the class files live, on the server.

There are three things that need to go on the same command line: the "java" command, followed by the property name=value pair (no spaces from the "-D" all the way though the last "/") and then the fully-qualified package name of the server program. There should be a space just after the word "java" and just before the word "examples" (which is very hard to see when you view this as text, in a browser, or on paper).  The following command shows how to start the HelloImpl server, specifying the java.rmi.server.codebase property: 

java -Djava.rmi.server.codebase=http://myhost/~myusrname/myclasses/
        examples.hello.HelloImpl
The codebase property will be resolved to a URL, so it must have the form of "http://aHost/somesource/" or "file:/myDirectory/location/" or, due to the requirements of some operating systems, "file:///myDirectory/location/" (three slashes after the "file:").
 
Please note that each of these sample URL strings has a trailing "/". The trailing slash is a requirement for the URL set by the java.rmi.server.codebase property, so the implementation can resolve (find) your class definition(s) properly.
 
If you forget the trailing slash on the property, or if the class files can't be located at the source (they aren't really being made available for download) or if you misspell the property name, you'll get thrown a java.lang.ClassNotFoundException. This exception will be thrown when you try to bind your remote object to the rmiregistry, or when the first client attempts to access that object's stub. If the latter case occurs, you have another problem as well because the rmiregistry was finding the stubs in its CLASSPATH.

The output should look like this:

HelloServer bound in registry
 

Run the applet

Once the registry and server are running, the applet can be run. An applet is run by loading its web page into a browser or appletviewer, as shown here: 
appletviewer http://myhost/~myusrname/hello.html &
After running the appletviewer, you will see output similar to the following on your display:


Copyright © 1996, 1997, 1998 Sun Microsystems, Inc. All rights reserved.