Page #488 (Chapter 36. Remote Method Invocations)

[Page 1244 ( continued )]

36.2. RMI Basics

RMI is the Java Distributed Object Model for facilitating communications among distributed objects. RMI is a higher-level API built on top of sockets. Socket-level programming allows you to pass data through sockets among computers. RMI enables you not only to pass data among objects on different systems, but also to invoke methods in a remote object. Remote objects can be manipulated as if they were residing on the local host. The transmission of data among different machines is handled by the JVM transparently .

In many ways, RMI is an evolution of the client/server architecture. A client is a component that issues requests for services, and a server is a component that delivers the requested services. Like the client/server architecture, RMI maintains the notion of clients and servers, but the RMI approach is more flexible than the client/server paradigm.

• An RMI component can act as both a client and a server, depending on the scenario in question.

• An RMI system can pass functionality from a server to a client, and vice versa. A client/server system typically only passes data back and forth between server and client.

36.2.1. How Does RMI Work?

All the objects you have used before this chapter are called local objects . Local objects are accessible only within the local host. Objects that are accessible from a remote host are called remote objects . For an object to be invoked remotely, it must be defined in a Java interface accessible to both the server and the client. Furthermore, the interface must extend the java.rmi.Remote interface. Like the java.io.Serializable interface, java.rmi.Remote is a marker interface that contains no constants or methods. It is only used to identify remote objects.

The key components of the RMI architecture are listed below (see Figure 36.1):

• Server object interface: A subinterface of java.rmi.Remote that defines the methods for the server object.

• Server implementation: A class that implements the remote object interface.

• Server object: An instance of the server implementation.

• RMI registry: A utility that registers remote objects and provides naming services for locating objects.

• Client program: A program that invokes the methods in the remote server object.

• Server stub: An object that resides on the client host and serves as a surrogate for the remote server object.

• Server skeleton: An object that resides on the server host, and communicates with the stub and the actual server object.

---

[Page 1245]

Figure 36.1. Java RMI uses a registry to provide naming services for remote objects, and uses the stub and the skeleton to facilitate communications between client and server.

RMI works as follows :

1. A server object is registered with the RMI registry.

2. A client looks through the RMI registry for the remote object.

3. Once the remote object is located, its stub is returned in the client.

4. The remote object can be used in the same way as a local object. Communication between the client and the server is handled through the stub and the skeleton .

The implementation of the RMI architecture is complex, but the good news is that RMI provides a mechanism that liberates you from writing the tedious code for handling parameter passing and invoking remote methods. The basic idea is to use two helper classes known as the stub and the skeleton for handling communications between client and server.

The stub and the skeleton are automatically generated in JDK 1.5. The stub resides on the client machine. It contains all the reference information the client needs to know about the server object. When a client invokes a method on a server object, it actually invokes a method that is encapsulated in the stub. The stub is responsible for sending parameters to the server, and for receiving the result from the server and returning it to the client.

The skeleton communicates with the stub on the server side. The skeleton receives parameters from the client, passes them to the server for execution, and returns the result to the stub.

Note

JDK 1.5 has simplified RMI development and deployment. Please use JDK 1.5 for this chapter.

36.2.2. Passing Parameters

When a client invokes a remote method with parameters, passing the parameters is handled by the stub and the skeleton. Obviously, invoking methods in a remote object on a server is very different from invoking methods in a local object on a client, since the remote object is in a different address space on a separate machine. Let us consider three types of parameters:

• Primitive data types , such as char , int , double , or boolean , are passed- by-value like a local call.

• Local object types , such as java.lang.String , are also passed-by-value, but this is completely different from passing an object parameter in a local call. In a local call, an object parameter's reference is passed, which corresponds to the memory address of the object. In a remote call, there is no way to pass the object reference because the address on one machine is meaningless to a different JVM. Any object can be used as a parameter in a remote call as long as it is serializable. The stub serializes the object parameter and sends it in a stream across the network. The skeleton deserializes the stream into an object.

  ---

  [Page 1246]

• Remote object types are passed differently from local objects. When a client invokes a remote method with a parameter of a remote object type, the stub of the remote object is passed. The server receives the stub and manipulates the parameter through it. Passing remote objects is discussed in §36.6, "RMI Callbacks."

36.2.3. RMI Registry

How does a client locate the remote object? The RMI registry provides the registry services for the server to register the object and for the client to locate the object.

You can use several overloaded static getRegistry() methods in the LocateRegistry class to return a reference to a Registry , as shown in Figure 36.2. Once a Registry is obtained, you can bind an object with a unique name in the registry using the bind or rebind method or locate an object using the lookup method, as shown in Figure 36.3.

Figure 36.2. The LocateRegistry class provides the methods for obtaining a registry on a host.

Figure 36.3. The Registry class provides the methods for binding and obtaining references to remote objects in a remote object registry.