Making a server into an activatable object

Activation stubs are yet another example of a classic computer-programming maxim: Got a problem? Add a layer of indirection.

17.6.1 Code Changes Necessary for Activation

This all seems pretty reasonable; activation consists of a daemon that launches servers, along with stubs that know how to communicate with the daemon. The question then becomes: how do you incorporate activation into your application? The answer is that you have to do two things: modify the servers to become activatable objects and modify the launch code.

17.6.1.1 Making a server into an activatable object

All of our servers so far have used UnicastRemoteObject in order to be tied to the RMI runtime. This has happened in one of two ways. Either the server has extended UnicastRemoteObject , or the launch code has used one of the static export methods defined on UnicastRemoteObject to create a stub for the server. In order to use a server with the activation framework, we need to change this. Instead of using UnicastRemoteObject , we need to extend the Activatable class which is defined in the java.rmi.activation package or use one of the static export methods defined on the Activatable class to create a stub for the server. That is, Activatable is used in a way that is exactly parallel to UnicastRemoteObject . However, while Activatable is used in a way thats exactly parallel to UnicastRemoteObject , the methods that Activatable defines can take more, and more types of, arguments. Here, for example, are the constructors and export methods from Activatable : protected ActivatableActivationID id, int port protected ActivatableActivationID id, int port, RMIClientSocketFactory csf, RMIServerSocketFactory ssf protected ActivatableString location, MarshalledObject data, boolean restart, int port protected ActivatableString locat ion, MarshalledObject data, boolean restart, int port, RMIClientSocketFactory csf, RMIServerSocketFactory ssf public static Remote exportObjectRemote obj, ActivationID id, int port public static Remote exportObjectRemote obj, ActivationID id, int port, RMIClientSocketFactory csf, RMIServerSocketFactory ssf public static ActivationID exportObjectRemote obj, String location, MarshalledObject data, boolean restart, int port public static ActivationID exportObjectRemote obj, String lo cation, MarshalledObject data, boolean restart, int port, RMIClientSocketFactory csf, RMIServerSocketFactory ssf For now, well continue ignoring the socket factories, a policy we first adopted in Chapt er 8 . Socket factories will be thoroughly covered in Chapt er 18 . There are two new classes here: ActivationID and MarshalledObject . ActivationID is a globally unique identifier that contains the information the activation daemon needs to uniquely identify a particular server. In particular, it contains both an ObjectID for the server that will be activated we discussed the ObjectID class in Chapt er 16 and a reference to the activation daemon. For the most part, instances of ActivationID are created by the Activation Framework and passed into the Activation Framework without being altered by your code. MarshalledObject is a wrapper class; an instance of MarshalledObject has only one purpose: encapsulating a serialized instance of another class. Instances of MarshalledObject are created by passing in an instance of a serializable class as an argument to the constructor. Once created, an instance of MarshalledObject has only one useful method, get , which is used to retrieve the instance stored in the instance of MarshalledObject . The point of using MarshalledObject is that it defines a way for launch code to pass data to servers that will be launched at a later time. When instances of MarshalledObject are used to help create activatable servers, the following sequence occurs: 1. Instances of MarshalledObject are created by your launch code, which passes in a serializable object to MarshalledObject s constructor. This object is serialized using RMIs customized version of the serialization mechanism. [ 3] The instance of MarshalledObject stores the output of serialization as a sequence of bytes. [ 3] See Chapt er 10 for more details on this. 2. The instances of MarshalledObject are passed into the Activation Framework. MarshalledObject is, itself, a serializable class. 3. The instances of MarshalledObject are stored by the Activation Framework. Eventually, when the servers are actually launched, copies of the instances of MarshalledObject are passed to the constructor of an activatable server. The activatable server is responsible for calling get on the instance of MarshalledObject if appropriate, thereby getting deserialized copies of the original serialized object. This process is shown in Figur e 17- 3 . Figure 17-3. Launching an individual server Consider, for example, the constructor from the activatable version of Account_Impl : public class Account_Impl extends Activatable implements Account { private Money _balance; public Account_ImplActivationID id, MarshalledObject data throws RemoteException { superid, 0; try { _balance = Money data.get ; } catch Exception e { Both ClassNotFoundException and IOException can be thrown. } } This calls the superclass constructor and then immediately attempts to initialize itself from the MarshalledObject by getting an instance of Money and setting it as the account balance. The activatable constructor takes two arguments: an instance of ActivationID and an instance of MarshalledObject . This constructor must be present in order for the Activation Framework to work. That is, when the Activation Framework tries to launch a server, it looks for a two- argument constructor with precisely this signature and throws an exception if the constructor is not present. Our constructor calls a similar superclass constructor that takes two arguments: an instance of ActivationId and a port. The port argument serves the same role as it does with UnicastRemoteObject : a value of 0 means that the associated server socket will listen on whatever port the RMI runtime finds convenient. Our code simply passes along the instance of ActivationID and lets RMI choose the port. This is by far the most common way of writing an activatable server. Unless you have a good reason to do otherwise, extending Activatable and using a port with a value of 0 is convenient. The only problem arises when you need to pass a nonserializable argument to your server for initialization. However, that problem arises in any system that delays launching a server™you must find a way to store the initialization parameters until the server is launched. The second most common way uses the second constructor, which adds socket factories. Well discuss reasons to use this second constructor in Chapt er 18 . Apart from the constructor, our server code is exactly the same as it was before.

17.6.1.2 Modifying our launch code