img
. .
Next the client is started up. It calls the RMI function lookup() to ask the registry for any object
associated with the supplied string. The registry returns the reference to the server object f. This
object is returned as a remote object, meaning that the client basically has a "fake" local copy (a
stub) of that object which it can use normally. When the client calls one of the remotely callable
methods [e.g., frob()], the arguments are passed to the stub, which uses RMI to "package up"
the arguments (known as serializing an object) and send them across the wire to the actual object
in the server along with the method being invoked. That method runs in the server (6), doing
whatever it wants, and returns the result, which RMI serializes and ships back across the wire to
the client. We can now implement the same client/server program as before without bothering
with the details of working with raw sockets. This is a good thing.
Sending Remote References
It is also possible for the client to ship remote references to objects over to the server. In Figure
13-2 we expand upon the previous example by declaring a class in the client which subclasses
UnicastRemoteObject. In (5) we create an instance of that object and in (6) we cause RMI to
send a reference to it over the wire by passing it as an argument to frob(). Now the server has a
remote reference to an object in the client, and the client has one to an object in the server. The
server can call remote methods on this object and get arbitrary data from the client.
Figure 13-2. A More Complex RMI Call Sending a Remote Object Reference
Search WWH :
Custom Search
Previous Page
Multithreaded Programming with JAVA - Topic Index
Next Page
Multithreaded Programming with JAVA - Bookmarks
Home