Tutorials : An Introduction to Remote Method Activation (ROA) :

Persistent And non-Persistent References To Remote Objects

In the case of activable objects, the problem is radically different, because a client can receive a reference to an activable object even if that object is not currently running. This reference is a persistent because its life cycle is independent from the life cycle of the referenced object. As a consequence, you can register an activable object to the RMI registry even if it wasn't instantiated.

Note: An activable object is not running when it hasn't been "built", its JVM was closed, it was collected by the Garbage Collector, etc.

An important difference between activatable remote objects and simple remote objects is that you can make a remote reference to an activable remote object even if the activable remote object is not running. You may ask: "How can I call the remote methods of a remote object if it is not running?What should I do in this case ?"

First of all, it's important to know that the client is acting in the same exact way as it would in the case of a RMI application based on simple remote objects. The client receives a stub object that can be used for calling remote methods. The bulk of the work is done by the activation system that listens for any remote method call and resolves the call to the client's benefit. An activable remote object becomes active when the client makes its first remote method call (this is known as "lazy" activation). In other words, when the activation system intercepts the first remote method call, it checks to see if the activable remote object is active. If it is not, then the activation system activates it. During the activation process, the activation system ensures that the activable remote object has a JVM and it uses the activable remote object information (provided in the moment of registration in the activation system) to activate the object.

After the activable remote object is successfully activated, the process is the same as that of a simple RMI application. This happens until the activable remote object is deactivated. If the activable remote object is not running, the RMI application supports other remote methods calls—only after it's been reactivated by the activation system. This demonstrates the power of persistent references—their usefulness extends beyond the life of the referenced activable remote objects.

How Does an Activable Remote Object Work?

This chain of events is called "activation protocol." Figure 1 is a graphical representation of this chain of events:

There are seven steps involved in activation protocol (note: the following explanation presumes that the client already contains the stub object and that the activable remote object is not active):

1. The client uses its stub to call a remote method. The stub checks for an active (or, "live") reference to the corresponding remote object. If it gets a null (meaning, there is no such reference), it will contact the activator. The activator, which performs two tasks: first, it is a database that maps the activation identifiers to the information needed for activation.; second, it manages the JVM's currently running (it also has the power to create JVMs for activation groups). Step 1 ends when the stub passes the activation identifier to the activator for the desired activable remote object.
2. The activator uses the activation identifier it has received from the stub to access the activation descriptor associated with the activable remote object. The activation descriptor was created when the activable remote object was registered to the activation system and it contains information about it's parent activable remote object.
3. The activator determines whether the activable remote object belongs to any existing activation group. To do this, the activator uses the activation descriptor which in turn uses the group descriptor. Groups descriptors contain information necessary to create/recreate a group as well as information about system properties and options used to run the JVM. If the activator determines that the activable remote object belongs to an existing activation group, it will pass the activation request to that group.
4. If the activable remote object does not belong to an existing activation group, the group descriptor will create new group especially for this object. The activator will also provide a JVM for the new group.
5. The activation request is now passed to the new group, whichuses the activation descriptor associated to this activable remote object to load the corresponding class and to create an instance of it using a special constructor, theactivation/reactivation constructor. One of the activation/reactivation constructor arguments is the activation descriptor.
6. After the activation procedure is ends, the activation group returns a reference to the active remote object to the activator.
7. The last word belongs to the activator which registers the reference received from the activation group, associates to this reference the corresponding activation identifier, and returns this reference to the stub. Now the stub finally has a "live" reference with which is can call the remote methods for that activable remote object.

How to Add Java Applets to Your Site

New on the Java Boutique:

New Review:

Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling API boasts simplicity, ease-of-integration, a well-rounded feature set, and it's free!

New Applet:

Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA sequences into three useful formats.

Elsewhere on internet.com:

WebDeveloper Java
Lots of Java information on webdeveloper.com

WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.

ScriptSearch Java
Hundreds of free Java code files to download.

jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.