Note that as soon as a remote reference is exported from the client, the client starts up an RMI
thread of its own to handle remote calls on any exported object. Thus when the server calls the
remote method fgetS() on c at (7), that remote call will run in the client's new RMI thread, not
the main thread which made the initial call to frob().
The basic idea is that an object can (a) implement Remote, in which case passing it as an
argument will cause RMI to ship a remote object reference to the server. An object can (b)
implement the Serializable interface instead (or subclass Remote-Stub), in which case
passing it as an argument will cause RMI to ship a complete copy of that object to the server.
(Strings are serializable.) Finally, (c) an object can do neither, in which case passing it as an
argument is not legal and the compiler will complain.
In the code for this program (Code Example 13-1), we see the declaration of the interface for the
ServerImpl object (ServerOp), where the remote method frob() is declared. Next we see
the ServerImpl object itself,[1] where the actual method frob() is defined. The ClientOp
interface and ClientImpl class look very similar.
[1]
The use of the postfixes "Op" for the interface and "Impl" for the object are a general RMI naming
convention that we use for convenience and uniformity. You may choose any names you like, but
we recommend sticking with the convention.
Example 13-1 Simple RMI Server and Client
//
ServerRMI/Server.java
/*
A simple RMI server program. It sets up a registry name for the
client program to connect to. It creates an unknown number of
threads
FOR you, exiting them when it feels like it.
*/
import java.rmi.*;
import java.rmi.server.*;
Search WWH :
