2

Why not just RMI?

Each Java architect reviewing the JSR-121 APIs invariably wonders why the Link class should even exist in the specification. After all, Java provides a mechanism for communication between isolated applications or application components in the form of it's Remote Method Invocation APIs. What possible justification could there be for inventing a new wheel? The answer to this comes in two parts.

Isolates are peculiar in the sense that while their specification dictates perfect isolation from their peers, frequently the very first thing a new isolate must do is communicate with one or more peer isolates. This creates a naming problem: how to utter the name of a peer isolate in order to communicate a simple message like “Hey! I'm ready to work!” or “Ouch! Just took an exception I can't handle, having to terminate!” There is an object oriented catch-22 with isolates: they require state passed on by their creation process to be able to function and, furthermore, establishing arbitrary communication with other isolates has to be possible to keep the problem space they can cover as large as possible. Moreover, whatever solution is defined must, by original agreement of the isolate designers, address the needs of small editions of Java as well as large ones.

But serialization is not provided by the current J2ME CLDC specification, let alone RMI, and using RMI pushes heavy responsibilities onto the developer, possibly causing there to be as many naming/registration schemes as implementations using isolates, a situation surely less desirable than introduction of the Link class. Also, Link has been carefully designed to be a primitive transport layer for other communication mechanisms, including RMI. So Link can be thought of as essential plumbing for isolate communication across all possible implementations of JSR-121.

But the other part of the technical justification for Link is that this mechanism provides capabilities that simply cannot be expressed with the current Java editions. For example a frequently named use case for an isolate is as a service fork for an open socket. But Java does not provide for communicating an open socket to another autonomous Java application component.[1][2] But an even more powerful capability offered by Link is the ability to communicate Isolate and Link references to other isolates. In addition, arbitrarily complex collections of messages can be easily composed as a single composite message for sending to another isolate as an atomic operation. Finally, Link's rendezvous semantics provide a very simple mechanism for isolate synchronization.

So although at face value a reviewer of JSR-121 might ask “why not just RMI?” a deeper look makes it clear why the API designers took the course they did to define the simplest possible inter-isolate communication mechanism that can also be available to all the Java editions.

[1] If Java provided access to Unix Domain Sockets and support encompassed a rich set of this RPC mechanism's capabilities, it would be natural to expect support for passing open I/O objects. However step one in this process would be an alternative name like “Local Sockets” to avoid the nontechnical baggage that would come with any name including “Unix”, despite the fact that Microsoft Windows has support for implementing this mechanism and maintaining “local socket” semantics.

[2]The System.inheritedChannel() method provides a means of accessing a java.nio Channel interface to an open device defined for a Java program by external means starting with J2SE 5.0, but this mechanism isn't available to the other Java editions and only pertains to a single channel instance.