Java Reference
In-Depth Information
How It Works
Here's how it works:
1.
RMIInterface
defines the methods the server will expose to the client without actually specifying
the code to be executed, just as a normal interface would. However, unlike normal interfaces, note
that RMI interfaces need to extend the remote interface in order to be used as an RMI service. In
addition, each method you define in the interface needs to throw a
RemoteException
exception.
2.
Concerning
RMIServer
, most of the code should be self‐explanatory, especially the implemen-
tation of the two provided methods. Two important aspects should be noted: first, the class
should implement the interface you've defined earlier. Second, you are extending another class—
UnicastRemoteObject
—which is a built-in class that allows you to automatically export a so‐
called “stub” for
RMIServer
. A stub is basically a bare‐bones version of the
RMIServer
class that
includes functionality for parameter conversion. Since the server and client code of an RMI pro-
gram can run on different machines with different architectures, they might not agree on the data
representation of different parameters. Consider, for example, 32‐ and 64‐bit machines using dif-
ferent sizes to represent number types. A stub handles the conversion of passed method arguments
and deconversion of returned results automatically. There are two ways to generate stubs: manu-
ally, using the
rmic
program included in the Java JDK (this would create an
RMIServer_Stub.
class
file), or automatically, like you've done here by extending
UnicastRemoteObject
.
3.
Next, take a look at the
main
method of
RMIServer
. First, this method uses the
LocateRegistry
built‐in class to create an RMI registry running on port
1099
. An RMI registry keeps track of the
services provided by an RMI server by binding objects providing methods over RMI to specific
names. Again, it is possible to start this registry from the operating system (using the
rmiregistry
program included in the Java JDK), but you're taking the programmatic route here. Next, the
main
class instantiates an
RMIServer
object and binds it to the name
RMIServer
on the local machine,
localhost
.
4.
The client (
RMIClient
) uses the
LocateRegistry
class to retrieve the registry running on
localhost
, and then an interface object is created by looking up the bound object to the name
RMIServer
in the registry. Finally, everything is set for methods to be executed on this object, just
as you would with a normal object. The difference, however, is that the method arguments will
now be sent over the network.
Apart from Java RMI, a large number of additional RPC‐based standards and protocols have been
defined throughout the past years, not all of them being specific to Java, of course. For example, the
Common Object Request Broker Architecture (CORBA) is a standard that was defined by the OMG
(Object Management Group) and enables communication between systems. The reason I mention it
is because it is the only OMG standard that's been incorporated in Java SE as a built‐in library, with
classes being located in the
org.omg.CORBA
package. Conceptually speaking, CORBA enables the
same functionality as Java RMI, with the difference that CORBA allows communication between
very diverse systems (i.e., not only between Java programs) running on different architectures, dif-
ferent operating systems, and written using different programming languages. However, CORBA
has been subject to quite a bit of criticism—some of it relating to technical aspects, some of it to
design choices—and the complexity of the standard means that it is not very widely adapted. As
Search WWH ::
Custom Search