Java Reference
In-Depth Information
Advanced RMI
There are several advanced features of RMI that are beyond the scope of this
topic, but that are important to know about. I'm only going to describe these fea-
tures briefly here; you should consult
Java Enterprise in a Nutshell
for details.
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 bur-
den, especially when the server implementation changes. Fortunately, RMI pro-
vides 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 a RMI client).
Third, since you've installed a security manager, you must explicitly specify a secu-
rity 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.
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 activatable 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 argu-
ments) that the activation service uses to activate your object when it is requested
by a client.
Once you have implemented your activatable 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
