Java Reference
In-Depth Information
nearly the same as for making a local method call. The only real differences are
the steps needed to obtain the remote reference to begin with and dealing with
the additional exceptions that can occur for remote method calls. An RMI client
application first obtains references (we explain just how below) to the remote
objects and then invokes remote methods. The RMI subsystem handles all the
communications between client and server in a way that is nearly transparent to
the developer.
Much more detail about the design and operation of RMI can be found in the
online API documentation. What we describe here is the basic use of RMI needed
to implement the distributed client/server design of Chapters 16 and 17. We also
demonstrate the downloadable bytecodes feature.
18.3.2 Stubs and skeletons
As already mentioned, calling objects cannot access the program counter in the
remote JVM. So how does RMI work its magic to present the illusion that a
remote method call is just like a local call? The answer is through the use of a
tried and true mechanism (from RPC technology) known as stubs and skeletons.
When a client makes a remote call, it is actually making a local call to a
stub
.
The stub then handles the communication to the remote object. Part of this com-
munication is to package up and send the method parameters to the remote side,
a process called
marshalling
.Onthe server side there is a
skeleton
that reads the
incoming parameters (
unmarshals
them) and then dispatches the incoming call
to the actual server-side implementation of the remote object. For the return, the
reverse happens - the skeleton marshals the results and sends them to the stub,
which unmarshals the return value or exception and returns the value to the caller.
Fortunately, we don't have to write the stub and skeleton. Java provides a tool
(the
rmic
compiler) to create them from the remote object class file(s).
Without going into detail that, while interesting, is not important to the casual
RMI programmer, Figure 18.1 illustrates how the various players interact in
a remote method call. The Java 2 SDK introduced a new stub protocol that
eliminated the need for skeletons on the server side as long as both client and
server use Java 2, which is now quite likely, at least for applications instead of
applets. Instead, generic code is used to carry out the duties previously performed
by skeletons in JDK1.1. Nevertheless, it is still useful to think of stubs and
skeletons as the components handling the RMI communications between the
calling and called objects.
18.3.3 Creating remote objects
We mentioned above that an RMI server must make its objects that have remotely-
callable methods into
remote
objects. Just how does an object become a remote
Search WWH ::
Custom Search