Understanding Remote Object Activation
While it sounds simple, starting remote servers prior to their usage may not always be a practical proposition. For instance, it is highly inefficient to have hundreds of resource-intensive remote objects running in memory all the time—especially if they are used only on an occasional basis. What's worse, they may even turn out to be a logistical nightmare if your enterprise's distributed computing environment demands hundreds or thousands of remote objects. As we can see quite clearly, the old approach of prestarting an RMI server becomes unmanageable rather quickly in a real-life scenario.

Luckily for us, however, with the advent of Java 2, the headaches associated with developing fairly large-scale distributed systems using RMI have now been greatly alleviated. Specifically, with the help of the new Remote Object Activation (ROA) feature, you no longer have to worry about starting up remote objects prior to their invocation.

By extending java.rmi.activation.Activatable and making use of the new RMI activation daemon rmid, RMI developers can now register information about remote object implementations that should be instantiated only when necessary, rather than running all the time. The ROA mechanism accomplishes this by what is known as lazy activation. Lazy activation implies that the passive remote object is activated by rmid, by loading its constituent classes into a JVM only on the receipt of the client's first remote method invocation, and not until then. rmid—which runs on the same host as the activatable object and the RMI name server, rmiregistry—also needs to be configured with information that will allow it to locate and load the classes used by the remote object. This task is usually delegated to a separate setup or bootstrap program, after first starting up rmid and rmiregistry. Activatable objects can optionally be associated with a persistent state. This can be provided to the remote object during activation to reestablish its state information. The good news is, choosing to make your remote objects is strictly a server-side decision; RMI clients don't care whether the remote objects are activatable or not.

Developing an Activatable Remote Object ROA can be a fairly complex topic for the novice RMI developer. If you are not familiar with Java remote objects, it may be useful for you to read my earlier article on distributed Java and RMI. ¹ Assuming you are familiar with the basics of RMI, let us take a closer look at activatable remote objects. The best way to understand ROA is to see it in action via a concrete example. As with any RMI object, the activatable object in our example implements a remote interface. Here, CountInterface (shown in Listing 1), contains a single remote method getCount() and basically allows a client to obtain a count of the number of times the remote object has been accessed.

The class for our activatable server object is shown in Listing 2. CountServer not only maintains a running count of the number of accesses by RMI clients, but is also activatable—i.e., its instantiation is deferred until the first remote method invocation. Further, it also makes use of MarshalledObject to regain its state—even if it is restarted after a server shutdown.

Now, let us dissect the activatable remote server a little and see how it differs from a conventional RMI server. Consider the line:

public class CountServer extends Activatable

 implements CountInterface

Observe the constructor for CountServer:

public CountServer(
  ActivationID id, MarshalledObject data)
	throws RemoteException,
     ClassNotFoundException, IOException {
...
}

The MarshalledObject parameter here can also optionally contain any serialized object. In this example, we use it to supply the name of the file containing some previously persisted state information. The great thing about using the MarshalledObject is that now, your remote objects can preserve state even between successive restarts. Observe that the constructor also checks whether the file passed via MarshalledObject exists, indicating the presence of a previously persisted state. If it does exist, the method restoreState() is invoked, causing the activatable object to initialize itself from the persisted data.

Because our remote object implements CountInterface, it defines getCount(), which increments a counter specifying the number of times the object was accessed. For each client invocation, this method updates and saves the count data to the file that was passed as the MarshalledObject, before returning the count to the client.

You may also have noticed that unlike a conventional RMI server, an activatable remote object does not contain a main() method. There is no need for one, as the server is now instantiated by rmid, instead of being manually started from the command line.

Setup Program
Before activatable objects can be instantiated, the rmid and rmiregistry services must be properly initialized with information regarding these objects. First, we need to initialize rmid with some URL-based information that will allow it to locate and load the remote object's constituent classes before instantiating them. Second, we have to register a remote reference (an instance of the generated stub class) for the activatable class within the rmiregistry, and associate it with an URL-based identifier. A setup program that is executed for each activatable object usually performs this configuration work. Listing 3 demonstrates the setup program for our activatable remote object.

Because our activatable object serializes its state information to a file, we have to explicitly grant this level of access, bypassing the default security sandbox. For testing, you can give carte blanche access to the setup program by disabling the security mechanism with the following policy file:

grant {
	permission java.security.AllPermission;
};

props.put("java.security.policy","/policy");

The activation system provides great flexibility when activating remote objects through the use of activation groups. Each activation group is associated with its own JVM. Thus, it is possible to run groups of activatable objects within different JVMs by associating them with a distinct ActivationGroupID:

ActivationGroupDesc.CommandEnvironment ace =
  null;

ActivationGroupID agi=
	    ActivationGroup.getSystem().registerGroup(
                             new
ActivationGroupDesc(props, ace));

MarshalledObject data=
  new MarshalledObject(
  new File("/Count.ser"));

All the information required to activate a remote object is stored within an instance of the activation descriptor ActivationDesc. This activation descriptor is then interrogated by rmid to obtain the necessary information during object activation. The line:

      ActivationDesc desc = new ActivationDesc(
      agi, "cup.chap6.activation.CountServer",
      location, data);

     
counter =
      (CountInterface)Activatable.register(desc);

	Naming.rebind("/CountServer", counter);

Demonstrating Remote Object Activation
Each time a client makes a remote method invocation, the activatable remote object updates its counter and stores the state in the form of serialized data to the file specified by the MarshalledObject. Now that you have the requisite example programs ready, you can compile them and generate the RMI stub and skeleton files as usual:

javac -d . *.java
rmic -d . com.jr.active.CountServer

start rmid
start rmiregistry

start java -Djava.security.policy=\policy
     -Djava.rmi.server.codebase=file:\examples        com.jr.active.BootStrap

The RMI applet can then be started as:

start appletviewer counter.html

Figure 1. Output of repeated execution of CounterApplet.

Now let us observe an interesting phenomenon. Without closing the appletviewer window, shut down rmiregistry and rmid. After that, restart both of them, and run the setup program as before. You should observe that the applet can resume where it left off—i.e., the RMI stub reference holds well even if the server goes down. Also, the activation system automatic- ally restarts the remote server, while reading in the previous state from the serialized file passed via MarshalledObject.

Design Considerations
Remote object activation is an extremely powerful feature and should empower us to build much more flexible distributed systems. Although activatable and non-activatable remote objects can coexist in the same environment, they introduce a new level of complexity to the remote object lifecycle management issues. For instance, activatable remote objects can be deactivated via the method Activatable.unexportObject(). If the target remote object happens to be the last one present within its activation group, then one of the consequences of this deactivation call would result in the shutting down of the JVM! This could in turn lead to RMI clients that access non-activatable remote objects left with dangling stub references.

Conclusion
Using the Activatable class and the activation daemon rmid, you can design remote object implementation that can be executed on-demand, rather than running all the time. This feature allows us to design highly scalable distributed systems while making efficient use of system resources. rmid provides a default JVM from which other JVM instances may be automatically spawned. We have also seen how the MarshalledObject can be used for passing initialization data through the activation descriptor, without having to hard-code these values within the remote object itself.

Reference
1. Seshadri, G., "Distributed Java Computing Using RMI," Java Report,
Vol. 2, No. 10, Oct. 1997, pp. 39-46.