Remote Method Invocation

This week we're going back for another pass at Remote Method Invocation (RMI). We will not attempt to make a full-fledged, tutorial-style attempt at describing it, but we'll touch on the basics. Hopefully, this column will give you a good idea of what goes into it, what you can get out it, and what's involved.

We've already given our short speech about why we don't necessarily like RMI, now you'll see why. Let's pick apart how Sun describes the use of its RMI scheme.

There are four principal components: The first is an interface that describes your remotely invocable methods. Interfaces, to recap in brief, are descriptions to which classes conform. They're written in Java. We've looked at them before--they're there to provide and confirm a sort of framework upon which other classes can depend. If a class "implements" an interface called "cloneable" (for instance), you can be assured that it's been written to contain (at least) the methods and other resources described in the interface. We could (for instance) also rely on being able to "clone" it. What that actually entails is unimportant. Bottom line, methods, variables, and the like are described in an interface, and if a class implements it, it's guaranteed to have them or it wouldn't compile.

The second compile is an "Implementation Class," which, you can guess, is the actual class that delivers what you've described in the interface you've written. The third is an applet or application that actually uses the remote method(s), and fourth, there's a "Remote Object Registry," maintained by a "Remote Object Server."

The first step is relatively easy. Creating an interface is simple: One simply writes a .java file starting with something along the lines of:

public interface MyInterface extends java.rmi.Remote

The interface inherits some basic properties of "Remoteness" by extending an interface already provided for us in the API. Within it are defined all the methods that one wants to make available for remote use. Each method must throw, according to the standard, a new kind of exception called java.rmi.RemoteException. This is only natural, one might suppose. Because there are a whole new class of potential problems that arise when attempting to run methods remotely, there's a whole new exception to represent them all.

The second step is more complicated. Creating a class that actually implements this interface involves not only the actual writing of those methods, but the authoring of a constructor for the class, which must instantiate a separate Security Manager (we've talked about Security Managers in a previous issue). It must also actually instantiate an object of itself and "bind" it to the "Remote Registry" by invoking the following method:

Naming.rebind("//MyHost/MyObjectName",MyObject);

where "MyHost" is the computer that will be allowing the remote invocation of its methods, and "MyObject" is the name of the object on which these methods will actually be invoked.

In the third step, when writing the Java code that will actually want to use this hypothetical remotely invokable method, you must import the java.rmi.* package, and then in your applet use the Naming class mentioned previously once again:

MyInterfaceType theRemoteObject = (MyInterfaceType)
Naming.lookup("//MyHost/MyObjectName");

Perhaps you've recognized the string in quotes above. It's actually the latter portion of a URL--without the section up to the colon describing protocol (e.g., "http:"). That would actually make sense as well because the protocol used by RMI is fixed. Notice also that the object returned by the Naming.lookup call is treated with the name of the implementation you've defined, and not the class that implements it.

In order for all this to work, there actually needs to be a server program running on whatever machine is making remote methods available. That means there's another program provided with the JDK called rmiregistry, which is run in the background on your UNIX or Windows host.

For all of these pieces to fit together properly, there needs to be a little more "glue" (to employ a favorite programmer's metaphor). In this case, something called a stub and something called a skeleton need to be created and stored in the same place that the rest of your applet or application's class files are stored. Without going into too much detail, these play various roles by transparently and compatibly allowing the applet to seamlessly refer to networked objects. They're created with another supplied program called rmic.

If you were wondering whether or not Object Serialization is somehow involved in all of this, you're correct. The two are tied together as some of the features in object serialization are employed in making this happen.

More generally, if you're feeling confused and betrayed by the complexity of all this, don't worry, it's worse than we let on. There are still a few more vagaries and caveats, but we won't bore you with them at this time. Making remotely invokable methods can be a relatively involved and often unrewarding process.

Next week, we'll look at more new developments in Java. In the meantime, read the documentation.

Past installments of Java Jolt