Mobile Agents on the Internet - Aglets SDK (III) (EN)

This is the third and final article in the series. See the 1st and 2nd parts.

One of the most promising fields for mobile agents is the design of complex dynamic systems from simple behaviors. In this article, the last in the series, we will learn about the Java API of the Aglets SDK and program a couple of Aglets that are surprising for how so little can do so much. We will end the series with a brief commentary on the impact that mobile agents can have on e-commerce.

In the previous article, we presented the architecture of the ASDK, looking at its main elements and their purpose.

There are many more things that could be said about this architecture, but at this level, it is much more important to learn the basics of Aglet programming.

We will tackle the problem from two fronts. First, we will present the ASDK API in broad strokes, but with a clear practical focus. Second, we will look at two simple aglets that exhibit complex dynamics: we will analyze them from top to bottom, completing the set with a practical example.

Aglets

Aglets are mobile Java objects that move in a network of computers enabled with host applications that manage them. For us, an Aglet will be any object that directly or indirectly extends (through another derived class) the com.ibm.aglet.Aglet class:

import com.ibm.aglet.*

public class ExplorerAglet extends Aglet {...}

The Aglet class provides all the necessary methods to control the agent’s life cycle, as well as the activities it will perform throughout it. Figure C shows the different groups into which we can classify the methods of the Aglet class.

The Aglet’s life cycle and its ability to respond to events that occur in it are controlled by the Operations on the Aglet and Event Response and Propagation method groups.

The first group, Operations on Aglets, contains methods declared as final (meaning we don’t have to implement them), such as dispatch(URL destination), which sends the Aglet to the host indicated in the URL, or dispose(), which destroys it.

The second group, Event Response and Propagation, contains methods that handle events that happen to the Aglet. After the dispatch() method is invoked, but before sending the Aglet, the runtime environment invokes the onDispatching() method, which allows the agent to prepare for the trip or refuse by throwing an exception. When the Aglet arrives at the new AgletContext, the runtime environment of the receiving system will invoke its onArrival() method, thus informing it of its arrival at the destination. All these methods will be the ones we must override to customize the behavior of our agent.

The event propagation part of the second group contains methods to include observers of specific events. For example, addCloneListener(CloneListener listener) adds an observer to the list of observers for the “clone the aglet” event.

The group of methods dedicated to messaging allows, among other things, handling the messages that reach the Aglet. Specifically, the handleMessage(Message message) method is in charge of interpreting these messages and performing the predefined tasks for each one:

public boolean handleMessage(Message message) {

  if(message.kind.equals("Hello")) {
    ... // Respond to “Hello”
    return true;    // The message was handled
  } else return false; // Unknown message

}

Obviously, this, along with the event response methods, will be one of the key methods for defining the Aglet’s behavior.

Finally, we have two groups, one that provides information about the Aglet or allows it to be set (with methods like getAgletID() or getAgletInfo()), and another that allows the agent to interact with the context. We find, for example, methods to subscribe to specific context messages, get images from remote URLs, etc.

But the most significant of this last group, and the one that will allow us to explore the environment, is the getAgletContext() method. Once the context is obtained, we can, as we will see next, interact with the rest of the Aglets.

The AgletContext

If we want our agents to perform interesting tasks, we must start by getting to know the environment in which they will move, and in our case, the environment is none other than the context or AgletContext. Since the Aglet initially only has access (outside of itself) to the context, knowing this object well will be critical for us to be able to give the Aglet autonomy in the environment that hosts it.

Although we mentioned it earlier, we will now delve a little deeper into the AgletContext API. Figure D shows us globally the different possibilities offered by the AgletContext.

When an Aglet invokes its getAgletContext() method, it obtains an object that implements the AgletContext interface, being able from that moment to invoke any of its methods. The agent can ask the context, for example, to create a new Aglet with the createAglet() method.

As Figure D shows, we can consider that the Aglet is initially isolated within the context. But the latter, through its methods (like getAgletProxies()), allows the agent to access the list of the rest of the “inhabitants”:

Enumeration e = getAgletContext().getAgletProxies();

The context provides two types of mechanisms for the flow of information between and for its inhabitants. The first is subscription-based messaging, and its principle is the same as that currently used by automatic e-mail lists (or most event management models): if the agent subscribes to the messaging service (AgletEjemplo.subscribeMessage(String name)), it will receive messages of the chosen type. The second is similar, but instead of the information coming to it, the Aglet itself will go for it (if it knows where it is, of course); in the AgletContext, it will have public properties that it can get and set (Context.getProperty(), Context.setProperty()).

AgletProxies

Aglets do not interact directly with each other, as it is potentially dangerous. Using introspection techniques, an agent could analyze another from top to bottom and start playing with its public interface. To avoid problems, the Aglets architecture introduces AgletProxy objects, “representatives” of other Aglets.

Each agent in the context has its associated AgletProxy; there can even be local representatives of Aglets located in remote contexts. These representatives present a uniform view of the agent to the rest of the Aglets, thus hiding its public interface and providing a standard for interaction between agents. We get an AgletProxy, for example, when we ask the context to create a new agent:

AgletProxy proxy = context.createAglet(...);

Figure E shows the three groups into which we can classify the methods of the AgletProxy class. Methods like clone(), dispatch(), dispose(), and deactivate() are used to control the Aglet (if it allows it, of course).

An agent can send another agent to a certain destination through its representative:

proxy.dispatch(new URL(..));

Another group of methods allows sending messages to the represented agent. An agent can send a synchronous message (sends the message and waits for the response) to another agent:

Message msg = new Message(“Hola!”);
Object result = proxy.sendMessage(msg));

Or it can also send an asynchronous message:

FutureReply  resp = proxy.sendAsyncMessage(msg);

... // continue without waiting for the response

Object result = resp.getReply();

Of course, if what we want is information about the agent, or the agent object itself if it lets us, we can do it with the methods of the last group of methods:

AgletIdentifier aid = proxy.getIdentifier();

Conclusions

With this description of the different elements, we should have a more elaborate idea of how AMAs work, and how IBM Japan has implemented them in Java. If this has been achieved, let’s be satisfied.

In the previous article, we talked about AMAs in general; in this one, we have fully entered into a completely functional AMA architecture that is beginning to be used in innovative projects. In the next article, we are going to give life to some simple agents, but we will try to have them have some interesting social behavior; we will also launch an explorer to investigate some AgletContexts that work permanently in different parts of the globe. We will see what it finds.