Java Reference
In-Depth Information
Subtypes in RPC Systems
Object serialization looks a lot like the marshalling and unmarshalling of objects that you will
find in any remote procedure call system. What makes object serialization somewhat unique
and what makes RMI very different from previous RPC systems is that the serial stream in-
cludes the information needed to identify and, when properly configured, find the code that
goes along with the serialized object. This is not a big win when object serialization is used
to write an object to persistent store and read that object back sometime later. But when com-
bined with the Java Virtual Machine, this ability makes RMI unlike any other RPC system.
To see this difference, consider the issue of how to pass arguments and return values in an RPC
system. The idea of such systems is that the arguments can be passed to the remote procedure,
and the return values can be returned to the calling procedure. But in an object-oriented sys-
tem, one of the basic patterns in method calls is to pass or return subtypes of the declared type
into a method, and to utilize the particular implementation of some method in that subtype to
perform the overall method, passing back something that is at least the type of the declared
return type but perhaps something more. Making this work in an RPC system can be, in the
least, somewhat challenging. But since RMI is designed to be used between JVMs, the system
can use object serialization to get just this kind of behavior.
Consider a fairly standard form of RPC system such as the one that implements the Object
Management Group's Common Object Request Broker Architecture (OMG CORBA) RPC
mechanism. CORBA was meant to be a language-independent RPC system, so interfaces are
defined in a special Interface Definition Language (IDL) that was originally based on a declar-
ative subset of C++. The idea was that these interfaces could be used to generate stubs (that
would marshal the input parameters, make a call to the remote procedure, and unmarshall the
return value of the call) and the skeletons (that would unmarshall the input parameters, call the
local procedure implementation, and return the results to the caller) in the target languages of
the caller and procedure called. But since the system was programming-language-independ-
ent, all that could be passed were primitive types that could be mapped to all of the target
languages, references to remote objects, and structures made up of those primitive types and
references.
Thus, the only real objects that could be passed in CORBA were really references to remote
objects. Although you could pass a reference to a remote object that was a subtype of the de-
clared object type, when that object was unmarshalled (either as a parameter or a return value)
the object created would be of exactly the declared type in the interface definition. In other
words, the CORBA system would truncate the actual type of a (remote) object to the declared
type of the interface. Given the language-independent nature of CORBA, and the variety of
