Using Java RMI

An Overview of RMI Applications

RMI applications are often comprised of two separate programs: a server and a client. A typical server application creates a bunch of remote objects, makes references to those remote objects accessible, and waits for clients to invoke methods on these remote objects. A typical client application gets a remote reference to one or more remote objects in the server and then invokes methods on them. RMI provides the mechanism by which the server and the client communicate and pass information back and forth. Such an application is sometimes referred to as a distributed object application.

Distributed object applications need to:

Locate remote objects

Applications can use one of two mechanisms to obtain references to remote objects. An application can register its remote objects with RMI's simple naming facility, the rmiregistry. Or the application can pass and return remote object references as part of its normal operation.

Communicate with remote objects

Details of communication between remote objects are handled by RMI; to the programmer, remote communication looks like a standard Java method invocation.

Load class bytecodes for objects that are passed around

Because RMI allows a caller to pass pure Java objects to remote objects, RMI provides the necessary mechanisms for loading an object's code as well as transmitting its data.

The illustration below depicts an RMI distributed application that uses the registry to obtain references to remote objects. The server calls the registry to associate a name with a remote object. The client looks up the remote object by its name in the server's registry and then invokes a method on it. The illustration also shows that the RMI system uses an existing web server to load Java class bytecodes, from server to client and from client to server, for objects when needed.

RMI system uses a web server to load Java class bytecodes, from server to client and from client to server.

Advantages of Dynamic Code Loading

One of the central and unique features of RMI is its ability to download the bytecodes (or simply, code) of an object's class if the class is not defined in the receiver's virtual machine. The types and behavior of an object, before only available in a single virtual machine, can be transmitted to another, possibly remote, virtual machine. RMI passes objects by their true type, so the behavior of those objects is not changed when they are sent to another virtual machine. This allows new types to be introduced into a remote virtual machine, thus extending the behavior of an application dynamically. The compute engine example in this chapter utilizes RMI's capability to introduce new behavior to a distributed program.

Remote Interfaces, Objects, and Methods

A distributed application built using Java RMI, like any other Java application, is made up of interfaces and classes. The interfaces define methods, while the classes implement the methods defined in the interfaces and, perhaps, define additional methods as well. In a distributed application, some of the implementations are assumed to reside in different virtual machines. Objects that have methods that can be called across virtual machines are remote objects.

An object becomes remote by implementing a remote interface, which has these characteristics:

• A remote interface extends the interface java.rmi.Remote.
• Each method of the interface declares java.rmi.RemoteException in its throws clause, in addition to any application-specific exceptions.

RMI treats a remote object differently than a non-remote object when the object is passed from one virtual machine to another. Rather than making a copy of the implementation object in the receiving virtual machine, RMI passes a remote stub for a remote object. The stub acts as the local representative or proxy for the remote object and basically, to the caller, is the remote reference. The caller invokes a method on the local stub which is responsible for carrying out the method call on the remote object.

A stub for a remote object implements the same set of remote interfaces that the remote object implements. This allows a stub to be cast to any of the interfaces that the remote object implements. However, this also means that only those methods defined in a remote interface are available to be called in the receiving virtual machine.

Creating Distributed Applications using RMI

When you use RMI to develop a distributed application, you follow these general steps:

1. Design and implement the components of your distributed application.
2. Compile sources and generate stubs.
3. Make classes network accessible.
4. Start the application.

Design and implement the components of your distributed application.

First, decide on your application architecture and determine which components are local objects and which ones should be remotely accessible. This step includes:

• Defining the remote interfaces. A remote interface specifies the methods that can be invoked remotely by a client. Clients program to remote interfaces, not to the implementation classes of those interfaces. Part of the design of such interfaces is the determination of any local objects that will be used as parameters and return values for these methods; if any of these interfaces or classes do not yet exist you need to define them as well.
• Implementing the remote objects. Remote objects must implement one or a number of remote interfaces. The remote object class may include implementations of other interfaces (either local or remote) and other methods (which are only available locally). If any local classes are to be used as parameters or return values to any of these methods, they must be implemented as well.
• Implementing the clients. Clients that use remote objects can be implemented at any time after the remote interfaces are defined, including after the remote objects have been deployed.

Compile sources and generate stubs.

This is a two-step process. In the first step, you use the javac compiler to compile the Java source files, which contain the implementation of the remote interfaces and implementations, the server classes, and the client classes. In the second part of this step, you use the rmic compiler to create stubs for the remote objects. RMI uses a remote object's stub class as a proxy in clients so that clients can communicate with a particular remote object.

Make classes network accessible.

In this step, you make everything--the Java class files associated with the remote interfaces, stubs, and other classes that need to be downloaded to clients--accessible via a web server.

Start the application.

Starting the application includes running the RMI remote object registry, the server, and the client.

The remainder of this chapter shows you how to follow these steps to create a compute engine.

Building a Generic Compute Engine

This trail focuses on a simple yet powerful distributed application called a compute engine. The compute engine is a remote object in the server that takes tasks from clients, runs them, and returns any results. The tasks are run on the machine where the server is running. This sort of distributed application could allow a number of client machines to make use of a particularly powerful machine, or one that had specialized hardware.

The novel aspect of the compute engine is that the tasks it runs do not need to be defined when the compute engine is written. New kinds of tasks can be created at any time and then given to the compute engine to be run. All that is required of a task is that its class implements a particular interface. Such a task can be submitted to the compute engine and run, even if the class that defines that task was written long after the compute engine was written and started. The code needed to accomplish the task can be downloaded by the RMI system to the compute engine, and then the engine runs the task, using the resources on the machine on which the compute engine is running.

The ability to perform arbitrary tasks is enabled by the dynamic nature of the Java platform, which is extended to the network by RMI. RMI dynamically loads the task code into the compute engine's Java virtual machine and runs the task without prior knowledge of the class that implements the task. An application like this which has the ability to download code dynamically is often called a behavior-based application. Such applications usually require full agent-enabled infrastructures. With RMI, such applications are part of the basic mechanisms for distributed computing in Java.

Using Java RMI