Sponsored Link •
Aglets versus applets
The Java aglet extends the model of network-mobile code made famous by Java applets. Like an applet, the class files for an aglet can migrate across a network. But unlike applets, when an aglet migrates it also carries its state. An applet is code that can move across a network from a server to a client. An aglet is a running Java program (code and state) that can move from one host to another on a network. In addition, because an aglet carries its state wherever it goes, it can travel sequentially to many destinations on a network, including eventually returning back to its original host.
A Java aglet is similar to an applet in that it runs as a thread (or multiple threads) inside the context of a host Java application. To run applets, a Web browser fires off a Java application to host any applets it may encounter as the user browses from page to page. That application installs a security manager to enforce restrictions on the activities of any untrusted applets. To download an applet's class files, the application creates class loaders that know how to request class files from an HTTP server.
Likewise, an aglet requires a host Java application, an "aglet host," to be running on a computer before it can visit that computer. When aglets travel across a network, they migrate from one aglet host to another. Each aglet host installs a security manager to enforce restrictions on the activities of untrusted aglets. Hosts upload aglets through class loaders that know how to retrieve the class files and state of an aglet from a remote aglet host.
The aglet lifestyle
An aglet can experience many events in its life. It can be:
Created: a brand new aglet is born -- its state is
initialized, its main thread starts executing
Cloned: a twin aglet is born -- the current state of the original is duplicated in the clone
Dispatched: an aglet travels to a new host -- the state goes with it
Retracted: an aglet, previously dispatched, is brought back from a remote host -- its state comes back with it
Deactivated: an aglet is put to sleep -- its state is stored on a disk somewhere
Activated: a deactivated aglet is brought back to life -- its state is restored from disk
Disposed of: an aglet dies -- its state is lost forever
Note that every activity besides creation and disposal involve either duplication, transmission across a network, or persistent storage of the aglet's state. Each of these activities uses the same process to get the state out of an aglet: serialization.
Serializing the state...
Aglet hosts use object serialization, available in JDK 1.1 or with the RMI (remote method invocation) add-on to JDK 1.0.2, to export the state of an aglet object to a stream of bytes. Through this process, the aglet object and the tree of serializable objects reachable from it, are written to a stream. An object is serializable if it implements either the
Serializable or the
interface. In a reverse process, the state of the aglet can be
reconstructed from the stream of bytes. Serialization allows an image
of the heap (the heap's state) to be exported to a byte stream (such as
a file) and then reconstructed from that byte stream.
...but not all of the state
The state of the execution stacks and program counters of the threads owned by the aglet are not serialized. Object serialization touches only data on the heap, not the stacks or the program counters. Thus when an aglet is dispatched, cloned, or deactivated, any relevant state sitting on any stack of a running aglet, as well as the current program counter for any thread, is lost.
In theory, a software agent should be able to migrate with all its state: heap, execution stack, and registers. Some will likely consider the inability of aglets to do this as a flaw in the aglet's implementation of mobile-agent theory. This feature of aglets arises out of the architecture of the JVM, which doesn't allow a program to directly access and manipulate execution stacks. This is part of the JVM's built-in security model. Unless there is a change to the JVM, aglets and any other mobile Java-based agent will be unable to carry the state of their execution stacks with them as they migrate.
Before it is serialized, an aglet must place on the heap everything it will need to know to be resurrected properly as a newly activated aglet, a freshly dispatched aglet, or a clone. It can't leave any of this information on the stack, because the stacks won't be reproduced in the aglet's new life. As a result, the aglet host informs an aglet that it is about to be serialized so that the aglet can prepare itself. When the aglet is informed of an impending serialization, it must place onto the heap any information it will need to continue its execution properly when it is resurrected.
>From a practical standpoint, the inability of an aglet to migrate with its execution stacks is not an unreasonable limitation. It simply forces you to think a certain way when you write aglets. You can look at an aglet as a finite state machine with the heap as the sole repository of the machine's state. If at any point in an aglet's life you can know what state it is in by looking at its heap, then it can be serialized at any time. If not, then you must have a way to record sufficient information on the heap just prior to serialization such that you can continue properly when the aglet is resurrected.
Also, even though the inability to serialize execution stacks necessitates giving aglets a warning prior to serialization, such warnings probably are a good idea anyway. It is difficult to think of a case in which an aglet wouldn't want to know it was about to be serialized and why. It may need to finish some incomplete process before allowing the serialization, or it may want to refuse the action that requires the serialization. For example, if an agent is told it is about to be serialized and dispatched to an aglet host in Silicon Valley, it may refuse and decide instead to dispatch itself to a host on an island in the South Pacific.