لطفا منتظر باشید ...
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.
