Chapter 13. RMI
·
Remote Method Invocation
In which we examine RMI and see what it provides in terms of a distributed object programming
model. We look at how threading interacts with it and how it uses threads.
RMI is not a thread topic per se, but it does often play a significant role in threaded programs
because of its use by threaded programs. The prototypical MT program is a client/server system
where the server is threaded to provide greater throughput. In our previous examples, we
implemented client/server programs using simple byte streams to communicate across raw sockets.
This was good because it was simple and fast, but it was bad because encoding any level of
complexity (integers, symbols, objects, etc.) into the byte stream required complicated, ad hoc
byte stream formats for those more complex objects.
RMI provides us a simple method of encoding and transmitting arbitrarily complex objects,
making it a natural replacement for our raw socket code. Thus we expect a great deal of threaded
code to use RMI and therefore include a section on it.
Remote Method Invocation
The basic idea of remote objects is very simple. A server program creates an object and makes a
reference to that object remotely available. Client programs find that reference and use it remotely
to perform work. The client code treats that reference as if it were a normal, local object, calling
methods on it and getting results back. For the most part, the client is unaware that there is
anything special about the object. The underlying RMI system takes care of packaging up method
invocations and arguments, transmitting them across the wire and returning results. This is a good
thing.
In Figure 13-1 we see a typical, simple RMI application. The rmiregistry is started first. (The
registry is a "poor man's" name server. It can be started directly from the command line or it can
be started by the server when that first starts up. We'll use the command line method.) Next the
server program is started. At (1) the server program instantiates a new ServerImpl object (this
is just a regular class that implements java.rmi.Remote; we'll subclass
UnicastRemoteObject). At (2) it calls the RMI bind() method, which first finds the registry
(by default it looks on port 1099 on the current host), then tells the registry to associate the string
supplied ("frobber") with the object (f). Now the main thread is done, exporting that object.
We'll let it exit, although you could keep it around if you wanted. The server startup code has done
its work and is done. Behind the scenes, RMI has started up a new thread of its own [while
executing the bind() call] which will now handle all requests for the object f. (Lots of details
here; we'll discuss them in a bit.)
Figure 13-1. A Simple RMI Call Sending and Receiving a String
Search WWH :
