Agents: Not just for Bond anymore

Learn what agents are and how to create them using IBM's Aglet Workbench

Did you ever wonder what that famous Agent 007 does when he's not saving the free world from the villainous plots of quirky supercriminals or dodging the gyrations of well-endowed silhouettes? Does he browse the Web? Shop for bargains? Book airline tickets to visit his sister in Cleveland? Monitor alt.kgb.announce for newly hatched Soviet schemes to subvert democracy?

He may not do those things, but a different sort of agent promises to! Acting as our own little electronic Jerry Maguires, digital agents will obediently notify us when needles of interesting information are found in the information haystack. These agents will monitor our stock quotes, surf our favorite Web sites, and filter the daily deluge of incoming e-mail and news messages. They will even act as our personal shoppers, stockbrokers, and attorneys, transacting commerce in our stead. Agents will do our dirty work, permitting us to disconnect the neural shunts that shackle us to our workstations, freeing us to commune in the majestic serenity of nature.

No doubt the JavaWorld faithful are familiar with the concept of technology hype and how difficult it can be to distill a usable essence from the waterfall of snake oil spewing from the mouths of Silicon Valley profiteers. Like Java, digital agent technology is receiving considerable attention in the popular press, with many of the column inches devoted to philosophical "golly gee whiz" musings like the above.

Placing the hype aside, this article will attempt to explain the concepts behind digital agents and how they compare to other distributed computing models. Practical applications of the technology will be identified, as will some of the tools available for implementing agent-based systems. Finally, using IBM's excellent Aglets Workbench, we will create two agent-driven applications, a distributed search engine and a virtual supercomputer.

An introduction to different types of agents

In a broad sense, the precepts of agent technology exist in many of the applications we use today and take for granted. For example, your e-mail client is a type of agent. At your request, it goes about its business of collecting your unread e-mail from your mail server. Contemporary e-mail clients will even presort your incoming messages into specified folders based on criteria you define. In this manner, the software becomes an extension of the user, performing tasks on the user's behalf. Indeed, the computer itself can be considered an agent, as its primary task is to increase productivity through automation.

Most often you hear about intelligent agents, such as the e-mail client that exhibits some sort of artificial smarts to determine the importance of a particular piece of e-mail -- possibly by scanning the message text for tell-tale indicators of urgency ranging from "deadline" or "won the lotto" to "introductory offer" or "marketing." However, agents need not be intelligent. For example, an ActiveX control that indiscriminately deletes files from your disk and then reboots your machine for you can hardly be considered intelligent. Nonetheless, it could be characterized as an agent of sorts.

Perhaps the most interesting agents are mobile agents, which can themselves be intelligent or unintelligent. This narrower class of agents is the focus of this article. Unlike their static brethren, which are content to execute in the cozy confines of a single machine or address space, mobile agents have wheels. They migrate about the network, executing tasks at each waystation, potentially interacting with other agents that cross their paths.

Mobile vs. static agents

To contrast static and mobile agents, consider a mobile and static version agent-based of e-mail delivery.

The dominant store-and-forward model in use today, in which a POP client communicates with an SMTP server, can be considered an application of static agents. The POP client, either at user request or on a preset timer, connects to a designated SMTP server and collects mail. The SMTP server receives and routes incoming mail, storing it into appropriate mailboxes for later retrieval. Both players in the transaction stay on their respective machines, using the network only for the transfer of message content.

A mobile agent design of the same transaction might define a mail carrier agent that travels about the network autonomously, handing messages to mail handler agents at each stop. These mail handler agents might themselves go mobile or spawn mobile children to distribute particular pieces of mail to other mailstops, perhaps to synchronize multiple mailboxes or to forward urgent messages to a paging service. In this model, the players in the transaction migrate between machines, bringing with them not just the message content but also their instructions on what to do when they arrive at each new destination.

Mobile agents are defined in formal terms by computer scientists as objects that have behavior, state, and location. A subset of behaviors of every agent is inherited from the model, notably those behaviors that define the means by which agents move from place to place. Mobile agent models almost always define a method of interagent messaging as well. Finally, a mobile agent model is not complete without defining a set of events that are of interest to the agent during its lifetime. For example, the event of arriving at a new location is a momentous one in the life of an agent and generally entails the invocation of one or more of its behaviors. The set of events varies a bit from model to model, but the following is a list of the most common ones:

  • Creation -- Analogous to the constructor of an object. A handler for this event should initialize state and prepare the agent for further instructions.

  • Disposal -- Analogous to the destructor of an object. A handler for this event should free whatever resources the agent is using and prepare the agent for burial.

  • Dispatch -- Signals the agent to prepare for departure to a new location. This event can be generated explicitly by the agent itself upon requesting to migrate, or it can be triggered by another agent that has asked this agent to move.

  • Arrival -- Signals the agent that it has successfully arrived at its new location and that it should commence performing its duties.

  • Communication -- Notifies the agent to handle messages incoming from other agents and is the primary means of interagent correspondence.

A real-world model

For purposes of illustration, consider for a moment a mail carrier agent whose reason for living is to deliver our packages and late credit card payment notices. This mail carrier has a few behaviors, a couple of which are "Get mail from post office" and "Insert mail into mailbox." Another useful behavior might be "Elude attacking hound." Our trusty federal employee also has state -- specifically the contents of the mailbag. Finally, the mail carrier has location: either at the post office, in transit between mail drops, or at one of the stops along their route. As the mail carrier makes rounds, their location changes as the mail carrier migrates from point to point along their daily itinerary. State also changes as each bundle of parcels is safely deposited into the mailbox and outgoing mail is placed into that U.S. Postal Service regulation canvas bag.

Let's trace a single mail carrier's voyage on a typical morning mail delivery, and outline agent concepts at work in the process of the mail carrier earning a living.

As each new day dawns, the post office (which could be considered a static agent) spawns an army of postal carriers, assigning them each a pile of mail to deliver. At this point, the Creation event has occurred in the life of one of these newly spawned postal carrier agents, name of Marvin. In response to this event, Marvin the mail carrier executes a series of behaviors that marks the top of the morning. First, he gulps down a few cups of coffee and then packs his assigned pile of mail into his mailbag. After packing his bags, Marvin plans an optimal route (that is, after consulting a map and the tactics of a few traveling salespeople) and begins his daily deliveries. In Java, Marvin's Creation event handler might look as follows:

public void onCreation(MailPile pile) {
    while (sleepy()) {
    mailbag = new MailBag(pile);
    route = new Route(mailbag);

The next interesting event in Marvin's day occurs when he arrives at the first house along his route. At this point, Marvin searches his mailbag for mail addressed to the resident and inserts it into the resident's mailbox. He then takes a break (remember, this is a federal employee) and continues on to his next destination. An interesting exception to the usual behavior occurs when Marvin completes his route and arrives back at the post office. He performs his end-of-day routine, such as clocking out.

public void onArrival() {
    if (getCurrentAddress().equals("Post Office")) {
    } else {

Consider another type of agent in this world, the bane of mail carriers everywhere: the watchdog. Spike the watchdog is generally a static agent, obediently waiting for intruders to tread on his master's property, at which point he will not hesitate to thrash them severely. To model this behavior, we will use message-passing between our Marvin the mailman agent and Spike the watchdog agent.

public void onAgentArriving(Agent newArrival) {
    if (!newArrival().equals(getOwner())) {
        newArrival.sendMessage(new Message("Woof"));

To maintain the integrity of his pantlegs, Marvin must somehow respond to messages of this variety. A typical message handler for this message might read as follows:

public void handleMessage(Message message) {
    if (message.kind().equals("Woof")) {

Marvin's daily travels consist of the following steps, illustrated in the diagram Mail carrier lifecycle:

  1. Post Office spawns an army of mail carriers.
  2. Mail carrier migrates to first destination in itinerary.
  3. Mail carrier interacts with agents at first stop, delivers his mail, and continues to the next stop.
  4. Mail carrier returns to the Post Office.

Now that we have demonstrated the concepts behind mobile agents, we will compare them to other paradigms of distributed computing and determine which classes of applications lend themselves to agent implementations.

Agents vs. distributed objects vs. messaging-oriented middleware

Distributed Systems Architectures

By now, most Java programmers are familiar with distributed objects and how they can be used to partition a system across several machines, as shown in the diagram Distributed objects architecture. Java RMI (remote method invocation) and several implementations of the CORBA specification are available to Java programmers. Using distributed objects, the Java programmer can invoke methods on objects residing on other machines as easily as invoking methods on local objects.

In addition to distributed objects, other distributed computing models can be used to segment systems over a network. Messaging-oriented middleware (MOM), yet another buzzword, acts similarly to traditional RPC (remote procedure call) systems, but with a twist. MOM, whose architecture is described in the diagram Messaging-oriented middleware architecture consists of messages that are brokered by one or more "post offices," which then forward these messages to interested parties. This model is advantageous in that it can support systems of temporarily disconnected clients (such as notebook computers or machines with low-reliability network connections).

Distributed Systems Architectures

Mobile agents differ from both of these distribution mechanisms: With mobile agents, executable content is moved across the wire. In this regard, a mobile agent can be considered a distributed object that moves. Indeed, the Object Management Group's Mobile Agent Facility is in the process of determining how agents fit into the world of CORBA. It is hoped that OMG's work, as well as that of other standards bodies, will result in a set of common concepts, communication mechanisms, and protocols for agent-based applications. More information about these efforts can be found in the Resources section.

Agent applications

Deciding which distributed computing paradigm to use depends on the application you are attempting to build. Each has advantages over the others for a given problem domain. This section outlines some parameters that you can use to determine whether a particular application lends itself to an agent-based implementation. This list of parameters is by no means exhaustive (or authoritative), but it can provide the basis for an architecture discussion.

1 2 3 Page 1
Page 1 of 3