Java Reference
In-Depth Information
Another abstract class required for writing RMI programs is
java.rmi.RemoteServer
. The
RemoteServer
class is the common super class for server implementations and provides the
framework to support a wide range of remote reference semantics. Specifically, the functions
needed to create and export remote objects (i.e., to make them remotely available) are pro-
vided abstractly by
RemoteServer
and concretely by its subclasses.
RemoteServer
has two
important subclasses:
java.rmi.server.UnicastRemoteObject
and
java.rmi.Activatable
.
Exporting remote objects is the responsibility of
Activatable
or
UnicastRemoteObject
. An
Activatable
object executes when requested and can turn itself off when necessary, whereas
UnicastRemoteObject
runs only when the server is up and running. An active object is one that
has been instantiated and exported to a JVM. A passive object is one that has not been instan-
tiated. Activation is the process of transforming a passive object into an active one. Lazy
activation is the process of deferring activation until its first use. The
Activatable
interface
provides RMI with the option of delaying access to persistent objects until needed. It is unde-
sirable to permit an RMI server to use extensive system resources by loading a lot of remote
objects that are infrequently used or not needed. Ideally, distributed systems should have
access to thousands of persistent objects over very long, even indefinite, periods of time.
An RMI server that makes use of
UnicastRemoteObject
requires that remote objects be
instantiated prior to a remote client invoking one of the remote methods. But in the case
where we have many remote objects and the cost of instantiating all of them is prohibitive, an
Activatable
RMI server is an excellent alternative. With the
Activatable
interface used in con-
junction with
rmid
, the RMI daemon, the server will instantiate the remote object when it is
needed.
Luckily, we do not need to worry about this facet of resource management when imple-
menting our RMI server, since we have only one remote object,
BookDatabaseImpl
, that acts as
our RMI server and gateway to the database. We do not demonstrate an
Activatable
imple-
mentation in this topic. Instead, we extend the
UnicastRemoteObject
class.
What Is an RMI Factory?
An RMI factory is just what the name would imply: an RMI version of the software design
pattern aptly named the Factory pattern. As explained in Chapter 5 (which discussed data
locking), we make use of an RMI factory to have a proper identifier mechanism for lock own-
ership. By ensuring that each RMI client has its own version of the
DvdDatabase
class, we
avoid the issue of thread reuse, which is common in RMI and cannot be controlled explicitly
through a JVM or RMI property. Since we cannot be sure how threads are being used and we
are not allowed to use cookies or tokens to identify the requester, we exploit the Factory pat-
tern to produce discrete instances of the
DvdDatabase
. The sequence-like diagram in Figure 6-9
depicts the typical actions and actors in a Factory pattern.
