General Java

Extremely large, complex software systems stretch the limits of modern design and implementation techniques. Agent-based computing is an approach to design and implementation that facilitates the design and development of sophisticated systems by viewing them as a society of independent communicating agents working together to meet the goals of the system. Java programming language's rich support for networking, security, and introspection make it well suited to implementing a distributed agent-based computing system.

This article explores the basics of agent-based computing and examines an open source Java toolkit for building distributed agent societies.

Often one of the most contentious parts of agent-based computing is agreeing on the definition of an "agent". In the human world the concept of an agent is familiar to most people. Travel agents make travel arrangements on behalf of their clients. Real estate agents manage real estate transactions as representatives of their clients. Human agents generally possess some specialized expertise and use it as a representative of some client. Software agents are similar in that they usually contain specialized behavior and represent some entity as they carry out their actions.

Most people agree that software agents exhibit some behaviors that distinguish them from other types of software. In general, software agents are:

• Autonomous: They're capable of carrying out actions on their own; that is, there isn't necessarily a predictable response for every stimulus, and the agent can take action without an external stimulus.
• Goal-directed: Like their human counterparts, they have skills they utilize to accomplish their objectives. Each agent in a society of agents has one or more goals and strategies to achieve them.
• Sociable: They can communicate and negotiate with other agents in pursuit of their goals, so in a society of cooperating agents, one may be able to draw on the resources of others to help accomplish its goals. It can also serve as a resource to others as long as that service is in line with the agent's goals.

Agent-based computing is different from object-oriented computing in several ways. While objects and agents both encapsulate their state, objects have methods that will be executed if invoked by some other object. The object can't decide to offer that service to some objects but not others or to offer it at some times but not others. An agent can decide whether carrying out a request is in line with its goals and choose whether to perform the operation. This is why messages between agents are usually called something like "requests" rather than "invocation."

Rather than try to make the case for some particular definition of agent-based computing, let's look at some ways it can be put to use.

There are several reasons agent-based computing is particularly suited to the design and implementation of very large systems. The agent concept parallels the way many real-world systems are put together. Businesses, for example, are comprised of departments that act autonomously but cooperatively in pursuit of their goals. A business might be modeled in an agent society with agents representing these departments. The messages between them correspond to communications between departments. Many physical systems are also composed of autonomous interacting parts. An accurate simulation of these systems can be most directly built using agents to represent the physical components. The messages between agents could represent the forces acting on those components.

Decomposition into agents also benefits the software development process. For the same reason that object decomposition reduces the dependencies between software components, agent decomposition decreases the dependencies even further. In an agent-based system, all agents communicate using a common language, and no agent can directly access any state or invoke any method of another agent. This decoupling of components and rigorous definition of the communication language enables the parallel development of agents, decreasing the chance that a defect in one component will damage another. This is particularly valuable when the components of a system are designed and developed by different organizations. Each organization can implement its business logic in its own way, dealing with the other components only in terms of the interagent messages.

Highly complex systems also lend themselves to agent-based solutions. Systems that are effectively modeled as agents can be built from components that are themselves simple but, when combined, exhibit complex behavior. The development of a complex agent society can be eased by the gradual increase in the sophistication of the individual agents. Some agents in the society can perform their tasks in a simplified manner, while others are fully functional. This allows a complex society to be built and a preliminary evaluation of the system's effectiveness made before all of the components are completed.

Because the agents in a society are autonomously pursuing their own goals, the exact behavior of the society can't always be predicted. This emergent behavior is at the heart of agent-based computing. By working together, software agents can make a system that's greater than the sum of its parts. This unpredictability also makes the task of designing and developing agents more difficult.

An agent needs a strategy to deal with all possible situations, including the failure of a neighboring agent or the unavailability of a resource. Handling failure is one of the most difficult parts of distributed systems programming. Agent-based computing doesn't eliminate this difficulty, but an agent-based approach can be a structure for handling errors. We'll see more about failure handling in the example below.

Software agents are often developed to represent legacy systems that contain essential business logic. Often called "wrappers", these agents make the functions and data of the legacy system available to the society of agents. This is a powerful mechanism for reuse and one of the reasons for the popularity of agent-based systems in organizations with legacy systems that must be modernized but can't be easily reimplemented.

An Example
As an example of agent-based design, let's look at how a small part of a business might be implemented in an agent society. Say a manager (agent) wants to promote an employee named Alice. In Figure 1, the ovals represent agents and the arrows represent interagent messages. Several things have to happen to get Alice her promotion, and several agents carry them out, each using its own goals, expertise, and relationships:

1. The manager requests a promotion for Alice from the personnel department agent.
2. The personnel agent requests a raise for Alice from the payroll department agent. The payroll agent may then have to take several actions to update tax information or recalculate deductions. The payroll agent might be a wrapper for a legacy human resources system.
3. The personnel agent also requests a new office for Alice from the facilities agent. The facilities agent may also need to take several actions to satisfy the request. This agent might order new furniture or schedule painting.

Notice that each agent has its own expertise (algorithm) for satisfying requests. The manager agent doesn't need to know how to talk to the payroll or facilities agents - he or she only needs to communicate with the personnel agent. In fact, the manager agent may not even know that the payroll and facilities agents exist. The scalability and robustness of an agent-based system comes from this information and behavior hiding.

As I mentioned, software agents also need to be able to handle failure. In the example in Figure 1, it's assumed that all requests are satisfied. This is a bad assumption. When agents make requests of one another, they need feedback on the success or failure of the request so they can decide whether to take further action. The communications shown in Figure 1 are really bidirectional communications as shown in Figure 2.

What happens if a request can't be satisfied? The ability of agents to negotiate becomes important. In this example, if the facilities agent has no more available offices, the personnel agent needs to be notified that the request can't be fulfilled. This report can be a simple success/failure message, but if the agents share a richer vocabulary, the negotiation can be much more efficient. Instead of just saying "No," the facilities agent could say, "There are no offices available until January 1." With this information the personnel agent can make a better decision about how to handle the failure. Notice that the facilities agent contains all the logic for determining available offices. This calculation is invisible to the personnel agent, who only knows that the request wasn't satisfied and any other information the facilities agent chooses to share.

At this point, the personnel agent needs to use its expertise to solve the problem. A simple-minded agent could tell the manager agent that Alice can't be promoted, but that's not a good solution. A better agent might make another request from the facilities agent for a different resource - a tall cubicle, for example - or request an office as of January 1. Figure 3 depicts this negotiation. The order of the messages is top to bottom.

Once the negotiations are complete the personnel agent can report to the manager agent that the promotion was successful using a vocabulary known by the manager agent. Then the manager agent can decide whether to take further action or accept the results given by the personnel agent.

Java Agents
Next let's look in some detail at a Java toolkit for building agent-based systems. The Cognitive Agent Architecture (Cougaar) provides mechanisms for building distributed agent systems in Java.

The Cognitive Agent Architecture grew out of a program by the U.S. Defense Advanced Research Projects Agency (DARPA) called the Advanced Logistics Project (ALP). While originally focused on logistics, Cougaar is a general-purpose agent architecture. The software is available under an open source license at www.cougaar.org. Cougaar provides a 100% Java framework for building and distributing societies of agents. It also includes a framework for building the agents themselves and some semantics for the interagent messages.

Cougaar agents communicate with one another by sending directives, which most commonly take the form of tasks; that is, a request for another agent to do something. Of course because they're autonomous, the agent that receives the task may be unwilling or unable to complete it and can report its disposition back to the sending agent. The agent that sent the task can also decide to take back or "rescind" the task. A task can only be rescinded if the receiving agent hasn't already completed the task or can undo what it did.

Cougaar agents are composed of business logic classes called plugins, and their behavior is determined by the plug-in components, which can respond to and generate directives. Each agent contains a blackboard that's shared by the plug-ins in that agent. plug-ins can publish objects to the blackboard and subscribe to changes in it. plug-ins can't communicate with other plug-ins except through the agent's blackboard, which isn't accessible by any other agents or processes. This enforces the modularity of both the plug-ins and the agents. The behavior of most plug-ins is determined completely by what objects in the blackboard they subscribe to and publish.

The reason it's called the Cognitive Agent Architecture is because it was designed to develop agents that model the human problem-solving process. Humans carry out several processes when trying to solve a problem. These include:

• Decompose the problem: Break the problem down into simpler sub problems and solve those. We saw an example in the personnel agent that knew that to do a promotion, a raise and a new office were needed.
• Delegate the problem: Assign the problem to someone or something and let them handle it. The manager agent delegated the details of Alice's promotion to the personnel agent.
• Consolidate multiple problems: Sometimes it makes sense to collect several problems and solve them simultaneously. If the facilities agent had several office moves, it might be possible to group the before hiring a moving company.
• Monitor progress: Observe the effects of the solution to the problem and reevaluate the solution if necessary.
• Gather data: Collect information needed to solve the problem.
• Report: Provide information to others about the solution to the problem.
• Act: Take action to directly carry out the solution.
  Cougaar agents can have plug-ins that carry out these processes:
• Expander plug-ins:Take large tasks and break them into workflows of subtasks.
• Allocator plug-ins: Assign tasks to other agents or real-world assets.
• Aggregator plug-ins: Group tasks to be carried out together.
• Assessor plug-ins: Monitor external data sources, like sensors or data bases, to make sure that earlier decisions are still valid.
• Data plug-ins: Retrieve data from databases, Web sites, or other sources, for use in decision making.
• User interface plug-ins: Report the agent's progress to a human user.
• Execution plug-ins: Carry out actions that change the world outside the agent society, like updating databases, or commanding actuators.

Figure 4 shows how the personnel agent in this example might be implemented using Cougaar plug-ins. Plug-ins are represented as trapezoids. An expander plug-in receives the "Give Alice a promotion" directive from the manager agent. It decomposes that task into two subtasks: "Give Alice a raise" and "Give Alice a big office." An allocator plug-in delegates the raise subtask to the payroll agent, and another delegates the office move subtask to the facilities agent. This separation of responsibility within the agent makes it easier to upgrade or modify the agent's behavior. Just replace a plug-in with one that implements the new behavior.

Cougaar uses several different Java technologies in its implementation and library of generic reusable plug-ins. It uses an RMI mechanism for interagent communication when agents are distributed across a network. Java introspection is used extensively to facilitate the communication between agents and plug-ins. Many wrapper agents use JDBC to access legacy databases and provide that data to the agent society. Cougaar also includes examples of wrapper agents for Web-based data that access HTML and XML data via HTTP.

If you're like me, things make more sense when you see some code. Let's look at some of the details of the Cougaar software. The basic building block of a Cougaar agent is the plug-in. In its simplest form a plug-in needs only to initialize itself and respond to changes in the set of objects of interest. There are two abstract methods in the plug-in's base class for these operations.

protected abstract void setupSubscriptions()

As its name implies, this method is implemented by the plug-in developer to perform initialization functions, including subscribing to the objects of interest. It's called just once when the plug-in is loaded. Plug-in developers define subscriptions by defining a small object with one method (a unary predicate) that returns true if the object should be included in the subscription. See Listing 1 for an example of creating a subscription.

protected abstract void execute()

The Cougaar agent executive calls this plug-in method when one of the plug-ins' subscriptions changes. Events that signal a subscription change include:

• New objects of interest being published
• A change in an object of interest
• The removal of objects of interest

The objects of interest might be published by another plug-in or transmitted from another agent as part of a directive. This is how a Cougaar agent's behavior is defined - through the subscriptions and publications of its plug-ins. The Cougaar infrastructure is also responsible for handling the transaction associated with the execute method. It ensures that no plug-in can modify the subscription objects during the execute method of another plug-in. Listing 1 is a simple example of a Cougaar plug-in.

Agents are social software, so they need to know about other agents. Other agents appear as objects in the local blackboard, so they can be accessed through a subscription like any other object. Tasks delegated from other agents appear in the blackboard, so they can also be elements of a plug-in's subscription. Common plug-in actions include taking incoming tasks and decomposing them into subtasks, collecting tasks to be handled as a group, or assigning tasks to other agents for further handling.

Applications of Agent Computing
Agent-based computing is applied in many domains. It maps well into the realm of autonomous robotics. A fleet of autonomous mobile robots has requirements similar to an agent-based system. The robots are individually goal-driven but need to communicate with one another. They behave autonomously, but cooperatively.

Agent-based computing has also been used to model network security. Work is underway to represent networks and computers as agents and simulate attacks by hacker agents. In this case, the agents are not all cooperative, but they all have goals and behave autonomously.

A marketplace is well represented as an agent society. In this case, agents can represent buyers and sellers. Some examples of this type of agent are in use already in some Internet auction sites. The real power of agent technology will come when suppliers' and customers' negotiation agents are tied into other back office agents and can adapt in real time to changes in the business environment.

Distributed agent computing is a great match for the Java environment. As the technologies mature, agent-based computing will be an important design method for large, complex systems.

Resources for Java agent computing

1. www.cougaar.org: Web site for the Cognitive Agent Architecture discussed in this article. In addition to the core Cougaar software, the site has documentation and examples.
2. java.stanford.edu: Web site for the Java Agent Template, Lite. JATLite was developed by the Center for Design Research at Stanford University and is available under the GNU Public License. It provides the connection and communications facilities necessary to enable messaging between agents but says nothing about the internal structure of the agent or the semantics of the messages. JATLite uses FTP or SMTP (e-mail) for interagent communication and has facilities for other message transport mechanisms to be implemented.
3. www.aglets.org: IBM recently released their Aglet Java mobile agent software under an Open Source license. An aglet is a mobile agent in that it can move from one host computer to another as it executes. In addition to the tools on the Open Source site, a free aglet software development kit is available from IBM.
4. mole.informatik.uni-stuttgart.de: A group at the University of Stuttgart has another Java mobile agent system called Mole. The software can be downloaded from their site. It's free for noncommercial use.