Question

Suppose I have a remote class that has a method with a POJO parameter:

class MyRemote implements Remote {

    void service(Param param) throws RemoteException;

}

The client retrieves a stub and does:

// DerivedParam is defined by the client
// and is derived from Param
DerivedParam dparam = getDerivedParam();
myService.service(dparam);

It fails, because the server has no clue about the DerivedParam class (and interfaces that it possibly implements).

The question: is it somehow possible to pass those classes from client to server to make such an invocation possible?

Answer 1

I am no an expert on the subject, but I did pulled this trick some time ago. The magic is in the use of code mobility by means of setting the java.rmi.server.codebase property.

You make this property point to a URL or space-separated list of URLs where your shared classes may reside. This could be, for instance, an FTP server or an HTTP server where a jar file with common classes reside.

Once set up, the codebase annotation will be included in all objects marshalled by server and client, and when either party cannot find a class, they look it up in the URLs provided in the code base and would dynamically load it.

Please read Dynamic Code Downloading with Java RMI.

Let’s say you provide to your client only interfaces, and the implementations will be located in a given code base. Then the client requests the server to send a given object, the client expects to receive an object that implements a given interface, but the actual implementation is unknown to the client, when it deserializes the sent object is when it has to go to the code base and download the corresponding implementing class for the actual object being passed.

This will make the client very thin, and you will very easily update your classes in the code base without having to resort to updating every single client.

Let’s say you have a RMI server with the following interface

public interface MiddleEarth {
     public List<Creature> getAllCreatures();
}

The client will only have the interfaces for MiddleEarth and Creature, but none of the implementations in the class path.

Where the implementations of Creature are serializable objects of type Elf, Man, Dwarf and Hobbit. And these implementations are located in your code base, but not in your client’s class path.

When you ask your RMI server to send you the list of all creatures in Middle Earth, it will send objects that implement Creature, that is, any of the classes listed above.

When the client receives the serialized objects it has to look for the class files in order to deserialized them, but these are not located in the local class path. Every object in this stream comes tagged with the given code base that can be used to look for missing classes. Therefore, the client resort to the code base to look for these classes. There it will find the actual creature classes being used.

The code base works in both directions, so it means that if you send your server a Creature (i.e. an Ent) it will look for it in the code base as well.

This means that when both, client and server need to publish new types of creatures all they have to do is to update the creaturesImpl.jar in the code base, and nothing in the server or client applications themselves.