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

Object Serialization
In order to send parameters to a remote implementation of a method and receive the results
of a call to such a method, we need to be able to send the parameters and the return values
over the network. For primitive data types this is straightforward, [ 31 ] only requiring that the
sending JVM and the receiving JVM interpret the bits that represent the primitives in the same
way. For objects, the case is somewhat more complex. The data in the object may be, at base,
made out of primitive object types. But the object is more than just the data held by the object
and the order in which that data is presented. An object includes an interface and the methods
that allow one to use the interface to manipulate the underlying data. Objects can also contain
references other objects. Getting all of this in some representation that can be sent over the
wire, and reconstructing that representation when it gets to the other side, is the job of object
serialization. [ 32 ]
At the most abstract level, the object serialization system simply converts a Java object into a
linear string of bits that can be sent over the wire (an operation known, confusingly, as serial-
ization), and converts a well-formed stream of bits into a Java object (an operation known as
deserialization). More accurately, object serialization will convert a graph of objects, rooted
in some particular object, into such a stream and convert a stream into a copy of an equivalent
graph of objects. This means that if an object being serialized refers to some other object, that
referred-to object will also be serialized, and a copy of the object will be reconstructed when
the object that refers to it is reconstructed. Object serialization will also annotate the stream
of bits with the information needed to determine the class of the objects that are to be recon-
structed, so that the code for the class can be associated with the data.
To see how this works, let's go back and take a look at our remotely accessible server, the
StatRecorderImpl . This class implements the two methods of the StatRecorder interface,
which itself is declared as a Remote , which allows the methods in that interface to be called
from another address space. One of these, getRoster() , takes a String that identifies a team
and returns a List<Player> , that is, something that is a list of Player objects. What the im-
plementation in StatRecorderImpl actually hands back is in fact a LinkedList of objects,
each of which implements the Player interface. In fact, these objects are themselves Play-
erImpl objects. This is what you would expect in an object-oriented language. There are no
simple List objects (since List is an interface) just as there are no Player objects (also an
interface). The method tells us that what we will get back from the call to getRoster() is
something that is at least a List and that the contents of the List will be at least of type Play-
er .