Passing Remote and Serializable objects

A Remote object is an instance of any class that extends Remote (line 3). This is the kind of object we have been working with in the last two examples. If it is desirable to pass a Remote object reference as an argument or a return value, the actual object stays on the server, and the recipient receives an object reference to a "stub" or "proxy" object. Using the stub object, the recipient can manipulate the server object by invoking remote methods. This mechanism could be described as passing the object "by reference".

An object can also be passed "by value". This means that a "copy" of the object is transported across the wire and re-materialized in the recipient's JVM. This feature is active for an instance of any class that implements Serializable (line 32). Once the delivery is complete, the recipient is no longer bound to the server, it has its own local copy of the transported object.

The distinction between these two scenarios is significant. In the first case, the recipient is sharing the server object with all other clients, and is forever coupled to the original server object. In the second case, the client receives its own personal snapshot of the server object, and from that point forward, the original and the copy are free to diverge. Both approaches are valid, but they are not equivalent. This example attempts to demonstrate a pothole that can result from misunderstanding the distinction.

The class PassObjectMaster (lines 53, 60, and 104) is capable of returning a reference object (lines 3, 10, and 106) and a value object (lines 32 and 107). Initially, both objects are equivalent (lines 108-109 and 125-126). The same additions are made to each (lines 111-112), and they are equivalent at lines 114-115 and 128-129. Then both objects are retrieved from the original custodian again and output one last time (lines 118-119 and 131-132). Something is not right with the value object!

When the reference object was being changed (line 111), the changes were happening to the original object on the server. Re-retrieving the object reference of the original object never affects "who" we were interacting with.

When the value object was being changed (line 112), the changes were happening to the local copy of the original object. Re-retrieving the object reference of the original object is guaranteed to affect "who" we were interacting with - it always produces a new copy of the unchanged original.

Let's go back and step through the entire example. PassObjectRef (line 3) is the "IDL" for the remote object that is going to be passed. PassObjectRefImpl (line 10) is its remote object class. PassObjectMaster (line 53) is the "IDL" for the class that creates reference and value objects and returns them when instructed. PassObjectMasterImpl (line 60) is its remote object class.

The two "contained" objects are created at lines 65-66 and 92-93. The "container" object is created at lines 86 and 94. The client initializes its container object reference at line 104, and its two contained object references at lines 106-107. After manipulating both contained objects, the client re-assigns its contained object references at lines 116-117. This has no effect on the contained object that is passed "by reference", but it un-does all the effort that had just been invested in the contained object that is passed "by value".

In summary, passing the object reference of a Remote object must not be taken lightly in sophisticated contexts.


RMI and CORBA

Java's RMI is not a substitute for CORBA. Both technologies have their place and use. RMI provides advanced functionality for Java programmers and stylized access to remote CORBA objects. Java's IDL/ORB provides full CORBA interoperability. New projects can use Java RMI whether or not they need IIOP. Existing projects that are already using CORBA, can use Java's ORB. Java programmers can access CORBA-based objects through IIOP, the OMG's CORBA-based protocol.

The features of Java RMI were designed to work with its native transport protocol, JRMP. Sun expects that only certain features of RMI will be able to work with IIOP initially. In order to support IIOP as it is today, Sun will define a restricted subset of features of Java RMI that will work with IIOP. Developers writing their applications to this restricted subset will be able to use IIOP as their transport protocol.