.

Spotlight: OO Systems

Jim Waldo
Remote procedure calls and
Sun Microsystems
jim.waldo@sun.com Java Remote Method
Invocation

REMOTE PROCEDURE CALL SYSTEMS have been around systems. The machines’ instruction sets might differ. Indeed,
since Andrew Birrell and Greg Nelson first proposed them in data representations might differ from one machine to another.
1984.1 During the intervening 15 years, numerous evolution- This heterogeneity is the central problem that systems such
ary improvements have occurred in the basic RPC system, as Corba were designed to solve. As their solution, these systems
leading to improved systems—such as NCS2—that offer pro- introduced proxies on each machine that could process infor-
grammers more functionality or greater simplicity. The Com- mation passing from one member of the distributed system to
mon Object Request Broker Architecture from the Object another. The processing converted the information from the for-
Management Group3 and Microsoft’s Distributed Common mat known by one member into a format known by the other.
Object Model4 are this evolutionary process’s latest out- The proxy on the client (calling) side became known as a stub,
growths. while the proxy on the server (receiving) side became known
With the introduction of Java Developer’s Kit release 1.1, as the skeleton. Stubs are compiled into the calling code and con-
a third alternative for creating distributed applications has vert any call into some machine-neutral data representation (a
emerged. The Java Remote Method Invocation system has process called marshaling) that gets transmitted to the receiving-
many of the same features of other RPC systems, letting an machine skeleton. This skeleton will translate the transmitted
object running in one Java virtual machine make a method call information into the appropriate data types for that machine (a
on an object running in another, perhaps on a different phys- process known as unmarshaling), will identify the code that
ical machine. needs to be called with that information, and will make the call.
On the surface, the RMI system is just another RPC mech- Skeletons also marshal any return values, transmitting them
anism, much like Corba and DCOM. But on closer look, RMI back to the stub that made the call, which will unmarshal those
represents a very different evolutionary progression, one that values and return them to the calling code.
results in a system that differs not just in detail but in the very Stub and skeleton production happens automatically, based
set of assumptions made about the distributed systems in on language and machine-neutral interface-definition language
which it operates. These differences lead to differences in the descriptions of the calls that can be made. An IDL definition
programming model, capabilities, and way the mechanisms describes the procedures or methods that can be called over the
interact with the code that implements and built the distrib- network and the information that passes to and from those pro-
uted systems. cedures or methods. From such a description, the programmer
can invoke an IDL compiler that will produce stub and skele-
RPC system assumptions ton source code for marshaling, transmitting, and unmarshal-
ing this data. This code can then be compiled for the target
To understand the differences between RMI and more stan- machine and linked into the appropriate application code.
dard RPC mechanisms such as Corba and DCOM, let’s exam- Having a machine-neutral IDL also lets such systems deal with
ine the different systems’ underlying assumptions concerning heterogeneous languages. Different IDL compilers can trans-
their operating environment. These assumptions structure the late the remote interfaces defined through the IDL into stubs
thinking of the system’s designers and the resulting system’s and skeletons for different implementation languages. Because
functionality. the exchanged data’s on-the-wire format is the same no matter
Corba and DCOM (and earlier systems in the RPC evolu- what language is used, stubs generated by one compiler can send
tionary line) were built on assumptions of heterogeneity. These procedure or method calls (along with parameters) to a skeleton
mechanisms assume that the distributed system contains generated by a compiler for a different target language.
machines that might be different, running different operating This approach has considerably simplified the building of

July–September 1998 5
.

distributed applications. However, it has limitations. The lan- ing, from stubs representing remote objects to real objects that
guage-neutral nature of these systems limits the kinds of data can pass from one part of a distributed system to another.
that can travel between processes to the basic data types that The ability to download code plays its most prominent role
can be represented in all the target languages, to references to in connection with the ability to pass full objects into and out
remote objects, and to structures made up of basic data types of an RMI call. Because of RMI’s single-language assumption,
and references to remote objects. Although the complexity of the system allows almost any Java object to pass as a parame-
network data representations are hidden from the program- ter or return value in a remote call. Remote objects pass by ref-
mer, the programmer must face the complexity of mapping erence, in effect, by passing a copy of the object’s stub code.
from the IDL to the implementation-language data types. Nonremote objects are passed by value, creating a copy of the
Finally, the life-cycle management of data sent, either as a para- object in the destination..
meter or a return, requires complex conventions or explicit The objects that pass are real objects, not just the data that
reference counting, both of which are subject to programmer makes up an object’s state. This distinction becomes impor-
error that can cause memory leaks or referential integrity loss. tant if a subtype of a declared type passes from one member of
Perhaps this approach’s greatest limitation, however, is the the distributed computation to another. Passing a subtype
static nature of the information that can pass over the network. object could result in receiving an unknown object. Because a
Systems built this way depend on the stub and skeleton match- subtype can change the behavior of known methods in an
ing, allowing the receiving process to interpret the sent infor- object, simply treating the object as an instance of a known
mation. This in turn requires that the receiving process know type might change the results of making a method call on that
exactly what the sending process places on the wire. In object- object.
oriented terms, no polymorphism is al- To avoid such a change, RMI uses a
lowed—the transmitted object’s type (or variant of the Java Object Serialization
its reference type) cannot be a subtype package to marshal and reconstruct
of the type expected by the skeleton. If a RMI’s Java-centric objects. This package will annotate any
process passes an instance or a reference object with enough information to iden-
to such a subtype, the system converts it
design lets the system tify the object’s exact type and its imple-
to a reference of the exact type that the capitalize on the Java mentation code. When an object of a
skeleton expects. environment’s dynamic previously unknown type is received as
nature, letting code the result of an RMI call, the system
RMI system fetches the code for that object, verifies
load any time during it, and dynamically loads it into the
assumptions execution. receiving process.
The Java RMI system is built on an Distributed computations therefore
entirely different set of assumptions. can use all the standard object-oriented
Heterogeneity is not the major problem. Indeed, it is not a design patterns that rely on polymorphism, because the object’s
problem at all, because RMI assumes that the client and the behavior moves when the object moves. The receiving process
server are both Java classes running in a Java virtual machine, must simply define the set of methods that will be called on an
which makes the network a homogeneous collection of (vir- object that passes to it; how the object implements those meth-
tual) machines. ods can vary in ways that the receiving process need not know.
The RMI system takes homogeneity one step further and Although we generally discuss passing objects in conjunction
assumes that all objects constituting the distributed system are with nonremote objects that pass by value, it also affects the
written in Java. RMI’s designers made this single-language way the RMI system can pass references to remote objects.
assumption to simplify the overall system, placing RMI in the These references are themselves stub objects, generated by the
evolutionary line of language-centric systems such as Oberon RMI compiler. However, unlike standard RPC IDL compil-
and the Modula-3 Network Object system. With this single- ers, these stubs are generated on the implementation class of
implementation language assumption, the RMI system does the object to which the stub refers. Rather than reflecting only
not need a language-neutral IDL. RMI simply uses the Java the declared remote interface, these stub objects support all
interface construction to declare remotely accessible inter- the remote methods that the remote object’s implementation
faces. A remote interface in RMI is one that extends the marker supports.
interface java.rmi.Remote. Stubs for remote objects therefore also load at runtime when
Finally, RMI’s Java-centric design lets the system capitalize needed, and the stub will reflect the exact (remote) type of the
on the Java environment’s dynamic nature, letting code load object for which the stub is a proxy. This changes the basic
any time during execution. Rather than requiring, as do tradi- notion of ownership and responsibility in the distributed appli-
tional RPC systems, that all code needed for communication cation. In systems such as Corba, the stub code is the respon-
between processes be available at some time prior to that com- sibility of the calling client and can be linked ahead of time
munication, RMI makes aggressive use of dynamic code load- into that client. In the RMI system, the stub for a remote object

6 IEEE Concurrency
 .

originates with the object and can be different for any two objects with
the same apparent type. The system locates and loads these stubs at run-
time, when the system determines what the exact stub type is.
Such an association makes the stub an extension of the remote object in
the client’s address space, rather than something that is built into the client
as a way of contacting the remote object. This approach allows program-
mers using the system to build a variety of “smart” proxies. Such smart
proxies can cache certain values in the stub, avoiding the need to make
remote calls in certain cases. Indeed, because the stub loads dynamically
depending on the particulars of the remote-object implementation, stubs
for objects that have the same apparent class might be very different,
because the full implementation class of those objects might be very
different.
This points out what is perhaps the most fundamental difference
between most existing RPC systems and Java RMI. In most existing sys-
tems, the result of writing an IDL interface is a static wire protocol, which
defines the way the stub of one member of the distributed computation will
interact with the skeleton that belongs to another part of the distributed
computation. In the RMI system, the interaction point has moved into
the address space of the client of a remote object and is defined in terms
of a Java interface. That interface’s implementation comes from the remote
object itself, is dynamically loaded when needed, and can vary in remote
objects that appear, from the client’s point of view, to be of the same type
(because the client only knows that remote objects are of at least some
type).

REFERENCES
1. A.D. Birrell and B.J. Nelson, “Implementing Remote Procedure Calls,” ACM
Trans. Computer Systems, Vol. 2, No. 1, Jan. 1984, pp. 39–59.
2. T.H. Dineen et al., “The Network Computing Architecture and System: An
Environment for Developing Distributed Applications,” Proc. Summer Usenix
Conf., Usenix Assoc., Berkeley, Calif., 1987, pp. 385–398.
3. Common Object Request Broker: Architecture and Specification, Revision 2.1, Object
Management Group, Framingham, Mass., 1997.
4. The Component Object Model Specification, Microsoft, Redmond, Wash.;
http://www.microsoft.com/oledev/olecom/title.htm.

Jim Waldo is a senior staff engineer with Sun Microsystems, where he is the lead
architect for Jini, a distributed programming infrastructure for Java. He is also an
adjunct faculty member of Harvard University’s Department of Computer Sci-
ence, where he teaches distributed computing. He currently works in the area of
Java-centric distributed computing. He received his PhD in philosophy from the
University of Massachusetts at Amherst and also holds MA degrees in linguistics
and philosophy. He edited The Evolution of C++: Language Design in the Marketplace
of Ideas and writes the “Java Advisor” column for Unix Review. He is a member of
the IEEE and the ACM. Contact him at Sun Microsystems, 2 Elizabeth Dr., Clems-
ford, MA 01824-4195; jim.waldo@sun.com.

July–September 1998