Remote Method Invocation and Object Serialization - Java: The Good Parts - page 156

binary formats with which the system needed to interact, this was really the only reasonable
approach. But it does mean that calling any parameter object in the remote procedure would
result in another remote call (back to the remote object that was referenced by the passed-in
object reference).
This means that if we tried our example in a CORBA system, either the List being passed
back from the getRoster() method would have to be changed to a supported primitive data
type (like an array) or what would be passed to our client would be a proxy to a remote object
implementation of a list. Passing a proxy would keep the programming model the same (if we
ignore the additional failure semantics introduced by RemoteException ), but it would mean
that any traversal of the list would involve a remote method call to get each Player object,
with the subsequent performance implications. Further, what would be returned from such a
list traversal would have to be a proxy for a remote implementation of a Player object, so any
call to that object (for example, to get the player ID) would also be a remote call.
This is not a criticism of the CORBA style of RPC call. Given the language-independent
nature of the CORBA system, this is the sort of thing that is required. Further, the whole
goal of the CORBA system was to allow easy access to remote objects, not passing copies of
language-level objects. CORBA does what it set out to do very well. But what it set out to do
means that the kind of programming allowed by RMI is simply not possible.
A system much closer to RMI was the Module-3 Network Objects [ 34 ] system. Network Ob-
jects started as a language-based RPC system. Because it assumed that both the caller and the
called were written in Modula-3, it could assume that the two ends of the RPC shared a single
type system. This by itself is a powerful assumption, in that it allows the system to determine
when two classes are the same or somehow related.
The Network Objects system also allowed objects to be passed by value as well as by refer-
ence. Like the CORBA system, Network Objects would allow a proxy for a remote object to
be passed to some other address space. When a method on that object was called, the proxy
would send the method request, along with the parameters, to the remote object, and receive
and hand back any results of the call. But you could also pass an object from one address
space to another, resulting in a copy of that object being recreated in the second address space.
When that happened, any call to the object would not cause a remote call to be made, but
would be processed locally. Like any other form of call by value, changes made in the copy of
the object in the new address space would not be propagated to the original object.
The hard problem in a RPC system that allows passing objects by value is what to do when
the object that is passed (either as a parameter or as a return value) is a subtype of the type that
the method declares. If we go back to our getRoster() method of the StatRecorder class,