Passing by Value Versus Passing by Reference

result = in.readBoolean ; } catch java.io.IOException e { throw new java.rmi.UnmarshalExceptionerror unmarshalling return, e; } finally { ref.donecall; } return result; While this may seem a bit more complex than the code we wrote for the socket-based printer server and the fact that were showing only part of the code indicates that stubs are actually quite a bit more complicated than the ClientNetworkWrapper class might have led us to expect, the fact remains: the stub implements the Printer interface, and the implementation of each method in the Printer interface simply pushes data onto a stream, and then reads data from a stream. Strictly speaking, skeletons arent really necessary. They can be replaced by a more generic framework that uses Javas reflection API to invoke methods on the server side. Well cover this in more detail in Chapt er 8 . In this book, however, our code uses skeletons.

4.1.2 Passing by Value Versus Passing by Reference

In the first section of this chapter, we stated that RMI automatically generates most of the marshalling and demarshalling code required to build a distributed application. Its easy to see how RMI could automatically do this for primitive argument types. After all, an int is simply four consecutive bytes. Automatically marshalling and demarshalling objects, on the other hand, is a more difficult task. And, in order to do so correctly, RMI requires us to distinguish between two main types of objects: those that implement the Remote marker interface and those that implement the Serializable marker interface. A marker interface doesnt define any methods; it simply provides information available by reflection about other code. In this case, RMI checks to see whether a given object implements either Remote or Serializable and behaves differently in either case. Remote objects are servers. That is, they have a fixed location and run in a specific JVM on a particular computer somewhere in the network; they are the objects that receive remote method invocations. In RMI, remote objects are passed by reference. That way, if two instances of some remote object type exist, they are logically distinct. For example, in the current application, each Printer is a remote object, and any two instances of Printer are not equal. Serializable objects, on the other hand, are objects whose location is not important to their notion of identity. That is, while they do have a location, the location is not particularly relevant to their state. Instead, serializable objects encapsulate data and are mobile™they can be passed from one JVM to another. Hence, serializable objects are very much like the primitive datatypes, such as float and int , which are also always passed by value. Serialization Serialization is a general purpose mechanism for taking an object and encoding it as a stream of bytes. The underlying design rationale is fairly simple. The Java Language Specification defines encodings for primitive types such as integer or float. If an objects instance variables are all primitive types, then by adopting a few conventions such as, The first thing encoded will be the a string containing the name of the class, we can automatically define a way to encode an object. We call such objects easily serialized objects. If an objects instance variables point to either primitive types or to easily serialized objects, then it is easy to see how to automatically generate an encoding for this object as well. The general idea is this: if a class definition has references only to primitive types or to classes that are themselves serializable, then the class is, itself, serializable. We call such classes obviously serializable. If a class isnt obviously serializable, and it needs to be passed by value anyway, then the programmer needs to write code that defines how to serialize the class. For example, if the generic framework cant figure out how to marshall and demarshall the object, the programmer needs to provide code that does so. And thats all that serialization is: a flexible implementation of the code that automatically encodes serializable objects so they can be passed by value over the wire. Ill cover the exact details of the serialization algorithm and their consequences for the design of an RMI application in much greater detail in Chapt er 10 .For now, three simple rules will suffice: • Classes that are intended to be serialized must declare that they implement the Serializable marker interface. This declaration can either be direct or inherited e.g., our implementation of PrinterException implements Serializable because Exception is defined to implement Serializable . • Any nonserializable superclass of a serializable class must have a zero-argument constructor. They can have other constructors, but the zero-argument constructor is the one that the serialization mechanism will use if it creates a copy of the object. • Any class that is declared to be serialized must either be obviously serializable or must contain code that allows the serialization mechanism to proceed anyway. The most common way of accomplishing this second task is to declare some variables to be transient and then implement a pair of private methods, readObject and writeObject , which the serialization mechanism will call instead of using the automatic encoding for the object. Note that if an argument is a remote object e.g., a server, the skeleton doesnt send a serialized copy of the server. Instead, it creates a stub that serves as a reference to that object and sends a serialized copy of the stub over the wire. What about arguments that are neither serializable nor remote? Well, if its a primitive datatype, it is passed by value as well. But if its an object and is neither serializable nor remote, an exception is thrown.

4.2 The Architecture Diagram Revisited