RMI procedures are defined using an existing Java mechanism:
interfaces. An interface is similar
to an abstract class, but a class can implement more than one
interface. RMI remote interfaces must be
subclassed from java.rmi.Remote
,[53] and both the client and server must be in the same Java
package. All parameters and return values must be either primitives
(int
, double
, etc.), or
implement Serializable
(as do most of the standard
types like String
). Or, as we’ll see in
Section 22.6, they can also be
Remote
.
Figure 22-1 shows the relationships between the important classes involved in an RMI implementation. The developer need only write the interface and two classes, the client application and the server object implementation. The RMI stub or proxy and the RMI skeleton or adapter are generated for you by the rmic program (see Section 22.4), while the RMI Registry and other RMI classes at the bottom of the figure are provided as part of RMI itself.
Example 22-1 is a simple
RemoteDate
getter interface, which lets us find
out the
date and time on a remote machine.
Example 22-1. RemoteDate.java
package darwinsys.distdate; import java.rmi.*; import java.util.Date; /** A statement of what the client & server must agree upon. */ public interface RemoteDate extends java.rmi.Remote { /** The method used to get the current date on the remote */ public Date getRemoteDate( ) throws java.rmi.RemoteException; /** The name used in the RMI registry service. */ public final static String LOOKUPNAME = "RemoteDate"; }
It’s necessary for this file to list all the methods that will be callable from the server by the client. The lookup name is an arbitrary name that is registered by the server and looked up by the client to establish communications between the two processes. While most authors just hardcode this string in both programs, I find this error-prone, so I usually include the lookup name in the interface.
“So interfaces can contain variables?” you say. No
variables indeed, but interfaces may
contain non-variable (final
) fields, as here.
Putting the lookup name here ensures that both server and client
really agree, and that is what this interface is all about, after
all. I’ve seen other developers waste a considerable amount of
time tracking down spelling mistakes in the lookup names of various
remote services, so I prefer doing it this
way.
[53] You might not have known that interfaces can
extendother interfaces, just
as classes extend classes. It’s worth knowing this, however.
Indeed, there are a few examples of this in the standard API:
LayoutManager2
extends
LayoutManager
, and both are interfaces.
18.219.81.43