Java has several advantages for distributed computing. Distributed computing can be summarized as "the network is the computer," meaning that objects can exist on remote machines, and that those object's methods can be invoked remotely over a network. If the network is the computer, then, Java is the platform. Why? Because of the java virtual machine, portable secure bytecodes, and developer friendly language semantics. Sun will support both homogeneous (100 % pure Java, RMI) and heterogeneous (multi-language environments, CORBA). Of course RMI can support other languages, and CORBA can be implemented in 100% pure Java. The two are not necessarily mutually exclusive. The offering of RMI and JavaIDL is not redundant. They deliver different distributed object functionality. RMI is recommended for distributed computing within a Java domain because of its simplicity and ease of use. CORBA is much more complex, as we shall see in the weeks to come.

RMI will continue to be supported into the future. An interface will be developed between it an CORBA. There will be an IIOP bridge between RMI and CORBA.

RMI is Java's language specific distributed objects model. It extends Java's object model beyond a single machine. Object serialization is used to convert objects to byte-streams for transport. Any java object can be passed over the network. It represents a progression of RPC (Remote procedure calls).

Key point: Single object model reduces complexity.

Java IDL

The standard Java mapping form the CORBA IDL spec. It will be part of core API starting with 1.2. The API includes a IDL-to-java mapping and compiler, a lightweight java ORB, and IIOP (Internet Inter-ORB Protocol), the de facto standard.

Key point: CORBA is designed to integrate objects among distinct languages.

Source: http://java.sun.com/features/1997/nov/rmi.html

Statement from SUN

http://java.sun.com/pr/1997/june/statement970626-01.html

Tutorial from:

http://java.sun.com/products/jdk/1.1/docs/guide/rmi/getstart.doc.html

Getting Started Using RMI

This chapter shows you the steps to follow to create a distributed version of the classic Hello World program using Java Remote Method Invocation (RMI).

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

To accomplish this, you will work through the following three lessons:

Write The HTML and Java Source Files

There are four source files for the Hello World server and applet:

The Java remote interface.
The Java remote object (server) which implements the remote interface.
The Java applet that remotely invokes the server's method.
The HTML code for the web page that references the applet.

Because the Java language requires a mapping between the fully qualified package name of a class file and the directory path to that class, before you begin writing Java code you need to 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 Hello World program developed in this chapter, the package name is examples.hello and the root directory is $HOME/jdk1.1/mysrc/examples/hello.

For example, to create the directory for your source files on Solaris, execute this command:

mkdir $HOME/jdk1.1/mysrc/examples/hello

Define a Remote Interface

Remote method invocations can fail in very different ways from local method invocations, due to network related communication problems and server problems. To indicate that it is a remote object, an object implements a remote interface, which has the following characteristics:

The remote interface must be public. Otherwise, a client will get an error when attempting to load a remote object that implements the remote interface.
The remote interface extends the interface java.rmi.Remote.
Each method must declare java.rmi.RemoteException in its throws clause, in addition to any application-specific exceptions.
A remote object passed as an argument or return value (either directly or embedded within a local object) must be declared as the remote interface, not the implementation class.

Here is the interface definition for Hello World. The interface contains just one method, sayHello, which returns a string to the caller: (Hello.java)

package examples.hello;
public interface Hello extends java.rmi.Remote {
	String sayHello() throws java.rmi.RemoteException;
}

Write an Implementation Class

To write a remote object, you write a class that implements one or more remote interfaces. The implementation class needs to:

Specify the remote interface(s) being implemented.
Define the constructor for the remote object.
Provide implementations for the methods that can be invoked remotely.
Create and install a security manager.
Create one or more instances of a remote object.
Register at least one of the remote objects with the RMI remote object registry, for bootstrapping purposes.

For example, here is the source for the HelloImpl.java file, which contains the code for the Hello World server. The code is followed by an explanation of each of the preceding six steps. (HelloImpl.java)

package examples.hello;

import java.rmi.*;
import java.rmi.server.UnicastRemoteObject;

public class HelloImpl
	extends UnicastRemoteObject
	implements Hello
{
	private String name;

	public HelloImpl(String s) throws RemoteException {
		super();
		name = s;
	}

	public String sayHello() throws RemoteException {
		return  "Hello World!";
	}

	public static void main(String args[])
	{
		// Create and install a security manager
		System.setSecurityManager(new RMISecurityManager());

		try {
			HelloImpl obj = new HelloImpl("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

The implementation class for the Hello World example is HelloImpl. An implementation class specifies the remote interface(s) it is implementing. Optionally, it can indicate the remote server that it is extending, which in this example is java.rmi.server.UnicastRemoteObject. Here is the HelloImpl class declaration:

public class HelloImpl
	implements Hello
	extends java.rmi.server.UnicastRemoteObject

Extending UnicastRemoteObject indicates that the HelloImpl class is used to create a single (nonreplicated) remote object that uses RMI's default sockets- based transport for communication. If you choose to extend a remote object from a nonremote class, you need to explicitly export the remote object by calling the method UnicastRemoteObject.exportObject.

Define the Constructor for the Remote Object

The constructor for a remote class is no different than the constructor for a nonremote class: it initializes the variables of each newly created instance of the class.

Here is the constructor for the HelloImpl class, which initializes the private string variable name with the name of the remote object:

private String name;
public HelloImpl(String s) throws java.rmi.RemoteException {
	super();
	name = s;
}

Note the following:

The super method call invokes the no-arg constructor of java.rmi.server.UnicastRemoteObject, which "exports" the remote object by listening for incoming calls to the remote object on an anonymous port.
The constructor must throw java.rmi.RemoteException, because RMI's attempt to export a remote object during construction might fail if communication resources are not available.

Although the call to the super no-arg constructor occurs by default if omitted, it is included in this example to make clear the fact that Java 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.

Local objects are passed by copy, and only the nonstatic and nontransient fields are copied by default.
Remote objects are passed by reference. A reference to a remote object is actually a reference to a stub, which is a client-side proxy for the remote object. Stubs are described fully in Generate Stubs and Skeletons.

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 service first needs to create and install a security manager: either the RMISecurityManager or one that you have defined yourself. For example:

System.setSecurityManager(new RMISecurityManager());

A security manager needs to be running so that it can guarantee that the classes loaded do not perform "sensitive" operations. If no security manager is specified, no class loading for RMI classes, local or otherwise, is allowed.

Create One or More Instances of a Remote Object

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

HelloImpl obj = new HelloImpl("HelloServer");

The constructor exports the remote object, which means that once created, the remote object is ready to begin listening for incoming calls.

Register a 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. Most of the time, the reference will be obtained as a parameter to, or a return value from, another remote method call.

For bootstrapping, the RMI system also provides a URL-based registry that allows you to bind a URL of the form //host/objectname to the remote object, where objectname is a simple string name. 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 URL of the remote object named HelloServer to a reference for the remote object:

Naming.rebind("//myhost/HelloServer", obj);

Note the following about the arguments to the call:

The host defaults to the current host if omitted from the URL, and no protocol needs to be specified in the URL.
The RMI runtime substitutes a reference to the remote object's stub for the actual remote object reference specified by the obj argument. Remote implementation objects like instances of HelloImpl never leave the virtual machine where they are created, so when a client performs a lookup in a server's remote object registry, a reference to the stub is returned.
Optionally, a port number can be supplied in the URL: for example //myhost:1234/HelloServer. The port defaults to 1099. It is necessary to specify the port number only if a server creates a registry on a port other than the default 1099.

For security reasons, an application can bind or unbind only in the 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 an Applet that Uses the Remote Service

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

package examples.hello;

import java.awt.*;
import java.rmi.*;

public class HelloApplet extends java.applet.Applet {
	String message = "";
	public void init() {
		try {
			Hello 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);
	}
}

The applet first gets a reference to the "HelloServer" from the server's registry, constructing the URL by using the getCodeBase method in conjunction with the getHost method.
The applet remotely invokes the sayHello method of the HelloServer remote object and stores the return value from the call (the string "Hello World!") in a variable named message.
The applet invokes the paint method to draw the applet on the display, causing the string "Hello World!" to be displayed.

The constructed URL must include the host. Otherwise, the applet's lookup 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 host.

Write the Web Page that Contains the Applet

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="../.."
	code="examples.hello.HelloApplet"
	width=500 height=120>
</applet>
</HTML>

Note the following:

There needs to be an HTTP server running on the machine from which you want to download classes. The applet's codebase attribute indicates the URL, as shown here:

codebase="../.."

The codebase in this example specifies a directory two levels above the directory from which the web page was itself loaded. Using this kind of relative path is usually a good idea.

The applet's code attribute specifies the fully package-qualified name of the applet, in this example examples.hello.HelloApplet:

code="examples.hello.HelloApplet"

Compile and Deploy Class Files and HTML Files

The source code for the Hello World example is now complete and the $HOME/jdk1.1/mysrc/hello directory has four files:

Hello.java, which contains the source code for the Hello remote interface.
HelloImpl.java, which is the source code for the HelloImpl remote object implementation, the server for the Hello World applet.
HelloApplet.java, which is the source code for the applet.
index.html, which is the web page that references the Hello World applet.

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 skeleton, 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. In this chapter, this is $HOME/public_html/codebase.

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

Compile the Java Source Files

Make sure that the deployment directory $HOME/public_html/codebase and the development directory $HOME/jdk1.1/mysrc/examples/hello are each visible via the local CLASSPATH on the development machine.

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

javac -d $HOME/public_html/codebase
	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/codebase. The command then writes to that directory the files Hello.class, HelloImpl.class, and HelloApplet.class. These are the remote interface, the server, and the applet respectively.

Generate Stubs and Skeletons

To create stub and skeleton files, run the rmic compiler on the names of compiled class files that contain remote object implementations. rmic takes one or more class names as input and produces as output class files of the form myImpl_Skel.class and myImpl_Stub.class.

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

rmic -d $HOME/public_html/codebase examples.hello.HelloImpl

The -d option indicates the root directory in which to place the compiled stub and skeleton files. So the preceding command creates the following files in the directory $HOME/public_html/codebase/examples/hello:

HelloImpl_Stub.class
HelloImpl_Skel.class

Note that the generated stub 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 index.html file must be moved from the development directory to the codebase directory. For example:

mv $HOME/jdk1.1/mysrc/examples/hello/index.html
	$HOME/public_html/codebase/examples/hello

Set Paths for Runtime

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

Start the Remote Object Registry, Server, and Applet

Start the RMI Bootstrap Registry

The RMI registry is a simple server-side bootstrap 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. That object in turn will provide application specific support for finding other objects.

To start the registry on the server, execute the rmiregistry command. This command produces no output and is typically run in the background. For example, on Windows 95 or Windows NT:

start rmiregistry

(Use javaw if start is not available.)

And on Solaris:

rmiregistry &

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

start rmiregistry 2001

If the registry is running on a port other than the default, you need to specify the port number in 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, here is the call required to bind the URL of the HelloServer to the remote object reference:

Naming.rebind("//myhost:2001/HelloServer", obj);

Similarly, the URL stored on the web page needs to specify the nondefault port number, or else the applet's attempt to look up the server in the registry will fail:

<PARAM name="url" value="//myhost:2001/HelloServer">

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 class 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 references to the remote objects created by the server can include the URL from which the stub class can be dynamically downloaded to the client.

The following command shows how to start the HelloImpl server, specifying this property:

java -Djava.rmi.server.codebase=http://myhost/~myusrname/codebase/
	examples.hello.HelloImpl &

The trailing / in the codebase URL must be specified.

A stub class is dynamically loaded into a client's virtual machine only when the class is not already available locally.

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/codebase/examples/hello/index.html &

After running the appletviewer, you will see output similar to the following on your display:

Home