Java Aglet Application Programming Interface (J-AAPI) White Paper - Draft 2
http://www.trl.ibm.co.jp/aglets
aglets@yamato.ibm.co.jp
IBM Tokyo Research
Laboratory
February 19, 1997
Aglets are Java objects that can move from one host on the Internet to another. That is, an aglet that executes on one host can suddenly halt execution, dispatch to a remote host, and resume execution there. When the aglet moves, it brings along its program code as well as its state (data). A build-in security mechanism makes it safe to host untrusted aglets.
The Java Aglet Application Programming Interface (J-AAPI) is a standard for interfacing aglets and their environment. J-AAPI defines the methods necessary
J-AAPI is simple, flexible, and stable. Internet agent developers can write platform independent aglets and expect them to run on any host that supports J-AAPI.
J-AAPI is intended for Internet agent programmers. It allows for the development of platform independent mobile agents written in the Java programming language.
A reference implementaton of J-AAPI is available in binary as well as source code form, along with html-based API documentation. The binary form of J-AAPI is available as the aglet package in Aglets Workbench.
Java and applets have revolutionized the Web, and executable content has become a common term in the Web glossary. Applets are essentially sets of program code that can be downloaded, instantiated, and executed in Web browsers. Recently, this concept has been matched by the introduction of the servlet. The servlet moves program code the in opposite way to the applet; that is, it allows the client program to upload additional program code to a server. The servlet's code is then instantiated and executed in the server.
The aglet represents the next leap forward in the evolution of executable content on the Internet, introducing program code that can be transported along with state information. Aglets are Java objects that can move from one host on the Internet to another. That is, an aglet that executes on one host can suddenly halt execution, dispatch to a remote host, and resume execution there. When the aglet moves, it brings along its program code as well as its data. Conceptually, the aglet is a mobile agent because it supports the ideas of autonomous execution and dynamic routing on its itinerary.
These are the interfaces and classes necessary for programming aglets:
The aglet object model defines a set of abstractions and the behavior needed to leverage mobile agent technology in Internet-like open wide-area networks. The key abstractions found in this model are aglet, context, proxy, message, itinerary, and identifier:
An aglet is a mobile Java object that visits aglet-enabled hosts in a computer network. It is autonomous, since it runs in its own thread of execution after arriving at a host, and reactive, because of its ability to respond to incoming messages.
A context is an aglet's workplace. It is a stationary object that provides a means for maintaining and managing running aglets in a uniform execution environment where the host system is secured against malicious aglets. One node in a computer network may host multiple contexts.
A proxy is a representative of an aglet. It serves as a shield for the aglet that protects the aglet from direct access to its public methods. The proxy also provides location transparency for the aglet. That is, it can hide the real location of the aglet.
A message is an object exchanged between aglets. It allows for synchronous as well as asynchronous message-passing between aglets. Message-passing can be used by aglets to collaborate and exchange information in a loosely coupled fashion.
A message manager allows for concurrency control of incoming messages.
An itinerary is an aglet's travel plan. It provides a convenient abstraction for non-trivial travel patterns and routing.
An identifier is bound to each aglet. This identifier is globally unique and immutable throughout the lifetime of the aglet.
Behavior supported in the aglet object model includes creation, cloning, dispatching, retraction, deactivation, activation, disposal of, and messaging:
The creation of an aglet takes place in a context. The new aglet is assigned an identifier, inserted in the context, and initialized. The aglet starts executing as soon as it has successfully been initialized.
The cloning of an aglet produces an almost identical copy of the original aglet in the same context. The only differences are the assigned identifier and that execution restarts in the new aglet. Notice that execution threads are not cloned.
Dispatching an aglet from one context to another will remove it from its current context and insert it into the destination context, where it will restart execution (execution threads will not migrate). We say that the aglet has been pushed to its new context.
The retraction of an aglet will pull (remove) it from its current context and insert it into the context from which the retraction was requested.
The deactivation of an aglet is the ability to temporarily remove it from its current context and store it in secondary storage. Activation of an aglet will restore it in a context.
The disposal of an aglet will halt its current execution and remove it from its current context.
Messaging between aglets involves sending, receiving, and handling messages synchronously as well as asynchronously.
A naming mechanism automatically assigns immutable identities to new aglets. These identities should be guaranteed to be globally unique.
A host needs to ensure that an aglet does not compromise its security. We classify aglets into two categories: trusted and untrusted. The aglet security manager checks whether the aglet is allowed to access the file system, network, and other aglets. The decision to trust an aglet is entirely up to the host.
A few usage scenarios are sketched below.
A client creates an aglet to gather information from several databases. The client provides the aglet with an itinerary and sends it off to the first database server. The itinerary controls the routing of the aglet and is able to handle exceptional conditions. For example, if a server is not responding, the aglet will go on to other servers first and then return to that server later.
A Web browser can dispatch an aglet to a Web site. The aglet can perform a local high-bandwidth search among the documents on that site or it can monitor specific documents for updates. When a document is updated the aglet can either send an email to its owner or return to its origin.
An aglet can be dispatched by a client to arrange a meeting. The agent will use an itinerary to visit other hosts (meeting participants) in order to negotiate an acceptable meeting schedule. At each host it will accommodate the host's calendar system. When negotiation has finished the aglet will notify all participants of the meeting time and place.
A client can dispatch an aglet that offers an item for sale. Other clients can dispatch aglets that are in search for specific items. When such aglets meet they may bargain. "Smart" aglets may make a good bargain and less clever aglets may make less good bargains.
In this example we let the aglet named DispatchingExample dispatch itself. The example is based on the same template as some of the previous examples in this chapter. DispatchingExample extends the Aglet class and overrides three methods: onDispatching, onArrival, and run. Again we use a Boolean field, _theRemote, to distinguish between the aglet before and after it has been dispatched. When this aglet is created and starts running (run()), it creates a URL for its destination. For simplicity, we let that destination be the current host. When the aglet has been dispatched all its threads will be killed. In other words, you should not expect the execution to return from a successful call to the dispatch method. When the aglet arrives at a new host, onArrival is called and the Boolean field is toggled. The aglet will now remain at this host until it is disposed.
package agletbook;
import aglet.*;
import java.net.URL;
public class DispatchingExample extends Aglet {
private boolean _theRemote = false;
public void onDispatching(URL url) {
System.out.println(who() + "\'onDispatching()\' is starting...");
pause();
System.out.println(who() + "\'onDispatching()\' is finishing.");
}
public void onArrival() {
_theRemote = true; //-- Yes, I am the remote aglet.
System.out.println(who() + "\'onArrival()\' is starting...");
pause();
System.out.println(who() + "\'onArrival()\' is finishing.");
}
public void run() {
if (!_theRemote) {
System.out.println(who() + "\'run()\' is starting...");
pause();
System.out.println(who() + "Dispatching \'" + PREFIX + "\'...");
try {
String host = getAgletContext().getHostingURL().toString();
URL destination = new URL((String)getAgletContext().getProperty("location", host));
System.out.println(who() + "Destination is \'" + destination.toString() + "\'");
dispatch(destination);
System.out.println(who() + "You should never see this on your console!");
} catch (Exception e) {
System.out.println(who() + "Failed to dispatch \'" + PREFIX + "\'.");
System.out.println(e.getMessage());
}
pause(); pause();
System.out.println(who() + "\'run()\' is finishing.");
} else {
System.out.println(who() + "\'run()\' is starting...");
pause();
System.out.println(who() + "\'run()\' is finishing.");
}
}
static private String PREFIX = "DispatchingExample";
private String who() {
return PREFIX + (_theRemote ? " (remote): " : " (original): ");
}
private static long SLEEP = 3000;
private void pause() {
try {
Thread.sleep(SLEEP);
} catch (InterruptedException ie) { }
}
}