Remote Method Invocations

The Remote Method Invocation mechanism lets you do something that sounds simple. If you have access to an object on a different machine, you can call methods of the remote object. Of course, the method parameters must somehow be shipped to the other machine, the server must be informed to execute the method, and the return value must be shipped back. RMI handles these details.

For example, the client seeking product information can query a Warehouse object on the server. It calls a remote method, find, which has one parameter: a Customer object. The find method returns an object to the client: the Product object (see Figure 5-3).

Figure 5-3. Invoking a remote method on a server object

In RMI terminology, the object whose method makes the remote call is called the client object. The remote object is called the server object. It is important to remember that the client/server terminology applies only to a single method call. The computer running the Java code that calls the remote method is the client for that call, and the computer hosting the object that processes the call is the server for that call. It is entirely possible that the roles are reversed somewhere down the road. The server of a previous call can itself become the client when it invokes a remote method on an object residing on another computer.

Stubs and Parameter Marshalling

When client code wants to invoke a remote method on a remote object, it actually calls an ordinary method on a proxy object called a stub. The stub resides on the client machine, not on the server. The stub packages the parameters used in the remote method into a block of bytes. This packaging uses a device-independent encoding for each parameter. For example, in the RMI protocol, numbers are always sent in big-endian byte ordering, and objects are encoded with the serialization mechanism that is described in Volume 1, Chapter 12. The process of encoding the parameters is called parameter marshalling. The purpose of parameter marshalling is to convert the parameters into a format suitable for transport from one virtual machine to another.

To sum up, the stub method on the client builds an information block that consists of

• An identifier of the remote object to be used;

• A description of the method to be called; and

• The marshalled parameters.

The stub then sends this information to the server. On the server side, a receiver object performs the following actions for every remote method call:

• It unmarshals the parameters.

• It locates the object to be called.

• It calls the desired method.

• It captures and marshals the return value or exception of the call.

• It sends a package consisting of the marshalled return data back to the stub on the client.

The client stub unmarshals the return value or exception from the server. This value becomes the return value of the stub call. Or, if the remote method threw an exception, the stub rethrows it in the process space of the caller. Figure 5-4 shows the information flow of a remote method invocation.

Figure 5-4. Parameter marshalling

This process is obviously complex, but the good news is that it is completely automatic and, to a large extent, transparent for the programmer. Moreover, the designers of the remote Java object tried hard to give remote objects the same "look and feel" as local objects.

The syntax for a remote method call is the same as for a local call. If centralWarehouse references a stub object for a central warehouse object on a remote machine and getQuantity is the method you want to invoke on it, then a typical call looks like this:

 int q = centralWarehouse.getQuantity("SuperSucker 100 Vacuum Cleaner"); 

The client code always uses object variables whose type is an interface to access remote objects. For example, associated to this call would be an interface:

 interface Warehouse {    int getQuantity(String description)       throws RemoteException;    Product getProduct(Customer cust)       throws RemoteException;    . . . } 

An object declaration for a variable that will implement the interface is

 Warehouse centralWarehouse = . . .; 

Of course, interfaces are abstract entities that only spell out what methods can be called along with their signatures. Variables whose type is an interface must always be bound to an actual object of some type. When remote methods are called, the object variable refers to a stub object. The client program does not actually know the type of those objects. The stub classes and the associated objects are created automatically.

Although the designers did a good job of hiding many details of remote method invocation from the programmer, a number of techniques and caveats still must be mastered.

NOTE

Remote objects are garbage-collected automatically, just as local objects are. However, the current distributed collector uses reference counting and cannot detect cycles of objects that refer to each other but have no external reference into the cycle. Cycles must be explicitly broken by the programmer before the remote objects can be reclaimed.

Dynamic Class Loading

When you pass a remote object to another program, either as a parameter or return value of a remote method, then that program must have the class file for that object. For example, consider a method with return type Product. Of course, the client program needs the class file Product.class to compile. But now suppose the server constructs and returns a Book object, and Book is a subtype of Product. The client may have never seen the Book class, and it may have no idea where to find the class file Book.class. Therefore, a class loader that will load required classes from the server is required. The process is similar to the class loading process of applets that run in a browser.

Whenever a program loads new code from another network location, there is a security issue. For that reason, you need to use a security manager in RMI client applications. This is a safety mechanism that protects the program from viruses in stub code. For specialized applications, programmers can substitute their own class loaders and security managers, but those provided by the RMI system suffice for normal usage. (See Chapter 9 for more information on class loaders and security managers.)