21.10 Advanced RMI

There are several advanced features of RMI that are beyond the scope of this book but are important to know about. I'm only going to describe these features briefly here; you should consult Java Enterprise in a Nutshell for details.

21.10.1 Remote Class Loading

Ideally, a client of a remote object should need only direct access to the remote interface; it should not need to know anything about the implementation of that interface. In the examples we've seen in this chapter, however, the client requires access to the implementation stub class as well. (And in practice, you've probably run the client and the server on the same machine with the same class path, so they shared all classes.)

Having to distribute implementation stubs with RMI client programs can be a burden, especially when the server implementation changes. Fortunately, RMI provides a mechanism that allows a client to remotely load the stub classes it needs from a network server. Unfortunately, making this work takes a fair bit of effort. First, you must have a web server running and make the stub classes available for download from that server. Second, you must install a security manager in all your clients to protect against malicious code in the downloaded stub classes (and remember that an RMI server that uses other remote objects is itself an RMI client). Third, since you've installed a security manager, you must explicitly specify a security policy that allows your RMI clients to make the network connections they need to communicate with remote objects. See Java Enterprise in a Nutshell for all the details.

21.10.2 Activation

In the RMI examples of this chapter, the process that implements a remote object must be running all the time, waiting for connections from clients. As of Java 1.2, the RMI activation service enables you to define remote objects that don't run all the time, but that are instantiated and activated only when needed. Activation also enables persistent remote references that can remain valid even across server crashes.

In order to implement an activateable remote object, you extend the java.rmi.activation.Activatable class, rather than the UnicastRemoteObject class that we've used in this chapter. When you subclass Activatable, you must define an initialization constructor that specifies a location from which the class can be loaded. You must also define an activation constructor (with different arguments) that the activation service uses to activate your object when it is requested by a client.

Once you have implemented your activateable remote object, you can instantiate an initial instance of it and register it with the activation service, or you can create an ActivationDesc object that tells the activation service how to instantiate it when it is needed. In either case, the activation service itself must be running. You run this service with the rmid command that ships with the Java SDK in Java 1.2 and later. Conveniently, rmid can also perform the function of the rmiregistry.

All the details described here are server-side details: the client can't tell the difference between an activateable remote object and a regular remote object. This section has outlined only the process of creating activateable objects; see Java Enterprise in a Nutshell for more information.

21.10.3 CORBA Interoperability with RMI/IIOP

One of the weaknesses of traditional RMI remote objects is that they work only when Java is used for both the client and the server. (This is also a strength, in that it keeps the remote method infrastructure simple and easy to use.) A new technology called RMI/IIOP allows you to use RMI remote objects with the IIOP network protocol. IIOP is the Internet Inter-ORB Protocol: the protocol used by the CORBA distributed object standard. RMI/IIOP is implemented in the javax.rmi package, and is a standard part of Java 1.3 and later.

RMI remote objects can't automatically use the IIOP protocol: you must implement them specially by subclassing the javax.rmi.PortableRemoteObject class and following a number of other steps. Although there is extra work involved, using RMI/IIOP can be of great value if you are working in a heterogeneous environment and want to connect Java remote objects with legacy remote objects implemented using the CORBA standard. See Java Enterprise in a Nutshell for an overview, and see http://java.sun.com/products/rmi-iiop/ and the RMI/IIOP documentation in the Java SDK for complete details.