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