Multi-Tier Communication Abstractions for Distributed Multi-Agent Systems Michael Thome (
[email protected]) BBN Technologies, 10 Moulton St, Cambridge, MA, 02138
Abstract— Most Multi-Agent System (MAS) architectures use a single communication model for sharing of data, propagation of tasking, and negotiation for services. We describe the Cougaar distributed multi-tiered MAS infrastructure which uses different communication techniques at each tier to gain large-scale parallelization, scalability and asynchronous operation without sacrificing the ability to support efficient, tightly coupled businesslogic components. We illustrate the architecture with results gathered from a set of small to medium-sized Cougaar applications.
1. INTRODUCTION Cougaar is a Java-based architecture for the construction of large-scale distributed agent-based applications. It is an Open Source product of a multi-year DARPA research project exploring large-scale, scalable, heterogeneous, distributed and survivable Multi-Agent Systems. Current work is focused on supporting high-quality robustness, security and scalability mechanisms in the infrastructure in the context of a large military logistics system. The Cougaar infrastructure was designed to address a specific primary goal: To build a distributed application substrate infrastructure capable of unlimited scalability, subject only to the inherent limits of the application itself. As a derived goal, Cougaar was to support an arbitrarily large number of physical machines but must also be fully functional on a single one. This goal suggests a number of subsidiary design points: • Peer-to-Peer (P2P) communication is preferred. • A scalable application will be deployed over a large hardware base. • Any infrastructure “choke points” need to be replicated. • Single points of failure (SPOFs) are not allowed. • Reliable communications cannot be assumed. • Synchronous operations must be avoided, especially over the network. • All operations that can operate in parallel should operate in parallel, at least by design.
In order to achieve these design points, we have built a hybrid infrastructure that combines many of the attributes of a traditional Multi-Agent System with additional capabilities from Parallel and Distributed Computing and Web Services technologies. The result is an infrastructure that supports highperformance data sharing for tightly coupled business logic, distributed communications for loosely coupled large-grain agents, and highly parallel processing on both the large and small scales. In this paper, we will describe the Cougaar Agent architecture, pointing out the similarities with and differences from traditional MASs. We will also analyze several small-to-medium sized Cougaar applications in terms of the tiers of agent-like communications.
2. COUGAAR Cougaar Architecture Cougaar supports three primary types of Agent-related interaction models (See Table 1): • Plugins are tightly coupled, non-distributed distillations of application business logic, task decomposition actors and small-scale collaboration. • Agents are loosely coupled, distributed application entities with a distinct, addressable identity that communicate directly with other Agents. • Communities are abstract, attribute-based sets of Agents formed as task- or application-groups. Communities communicate by nominating a member Agent as a spokesman. Cougaar also has a number of intermediate abstractions that allow aggregation of Plugins into Agents, support largerscale applications and provide for system management (including optimization). • Logic Providers (LPs) are application domain translators, interfacing applications to each other and to the messaging system at the blackboard level. • Services and Components are the infrastructure glue and logic that holds the system together, acting at all sub-agent levels.
Society Community Node Node (Node Agent) Concrete Components Agent Services Plugin Logic Provider Table 1- Cougaar Architecture Components Abstract
Cougaar Architecture Details Plugin— A Plugin is typically a small to medium-sized codification of application business logic. Plugin code is usually used in more than one Agent in an application with instances performing similar functions in each location differing only by host agent and data flow. Within an Agent, Plugins communicate with each other and other components only via the host Agent’s Blackboard. Plugin state is generally maintained on the Blackboard. Nearly all application programming of Cougaar is done at the Plugin level. Plugins are logically independent entities – since they only communicate directly and asynchronously with the Blackboard, they may run in parallel. Plugins do not, however, have an independent, externally visible identity. That is, Plugins are never addressable at any level – they only interact with other entities by data exchange in the context of the Agent within which they exist. Agent—Cougaar Agents are essentially a collection of Plugins, a Blackboard, a Messaging system, and a set of other support services. Each agent has a unique, addressable network identity and may bind a name to that identity with a high-level naming service. An Agent’s application behavior is derived entirely from the set of Plugins from which it is composed. Indeed, early versions of Cougaar used the term “Cluster” rather than “Agent” to draw attention to this feature. Cougaar application developers generally do not program at the Agent level, but rather choose the set off-the-shelf and custom Plugins to instantiate in each Agent. Blackboard—Each Agent has at its core a membershiptransactional Blackboard with predicate-based publishsubscribe semantics. Logically, the Blackboard is an arbitrary collection of objects – each Plugin may publish
The Blackboard is also the center of Cougaar persistence and mobility support – anything stored on the Blackboard will be retained in snapshots and will move when the agent moves. In general, other components are expected to operate without state, store their state on the Blackboard, or be prepared to reconstruct any state if lost due to Blackboard restore or move. There is also support for distributed (interagent) Blackboard reconciliation on rehydration when the application objects support it. High-performance, general-purpose distributed blackboards are difficult to implement. It is legitimate to view Cougaar as just such an implementation of a distributed data space inhabited by Plugins. In this model, what we are calling “Agents” are merely the blackboard partitions and the specific configurations of the Plugin micro-agents.
LP
Infrastructure
LP LP
Application
objects to the Blackboard to make them visible to the other Agent-local Plugins. Each Plugin may have any number of Subscriptions to a predicate-defined slice of the published objects of the Blackboard. Each Subscription is kept up-todate by the Blackboard infrastructure so that, as the contents of the blackboard change, all affected Subscriptions are changed as well. Whenever a Subscription changes, the owning Plugin is notified so that it can react as appropriate to its logic. Subscription changes and publishes are shallowly transaction controlled, so that Plugins see only consistent sets of changes. A Cougaar Blackboard is not a Database – transactional safety is limited to object membership in the Blackboard.
LP LP
• Nodes are single-VM machine abstractions, managing a set of agents that may share some services and benefit from low communications cost within the Node. • Societies are abstract entities comprised of all the Agents that can address each other directly. “Society” is nearly isomorphic to the “Application”, except that a Society usually includes gateways to external (non-Cougaar) systems.
Agent
Plugin LP
Plugin
Plugin
Blackboard
Plugin
Plugin
Messaging LP
Plugin
Figure 1 - Cougaar Agent Detail Logic Provider—A Logic Provider (LP) is a very small bit of code that observes Blackboard activity and translates between application language domains, including messaging. Since there are usually many different application languages in use and even present on an Agent’s Blackboard at any given time, LPs provide the mechanism to join them together so that Plugins can focus on domain logic. A critical example of this abstraction is that Plugins know nothing about Messaging – typically, Cougaar data ontologies only refer to messages implicitly. Instead, a set of
LPs will translate Blackboard objects that imply messaging into actual calls to the Messaging system and vice versa. Logic Providers only have a sub-transaction view of the Blackboard and are only ever invoked as an effect of a Blackboard (or Messaging) event.
Communities are supported in Cougaar by a naming-like service that maintains group membership and attributes for each community in its domain. Messaging supports a Community group-multicast function as well as a concept of “spokesman” for a group for external clients.
Messaging—A Cougaar Agent communicates with other Agents via directed, asynchronous, and unidirectional messaging. Other messaging semantics are supported at both the application level (e.g. Query-Response) and by the messaging system itself (e.g. Broadcast, group multicast, etc). Although a single, simple interface in presented to Messaging clients, the API allows for the attachment of hints (e.g. differentiated service tags) to messages in order to assist the Messaging system to perform optimally. The Messaging service is itself very modular and has a number of low-level transports and filters, including RMI, compression, encryption, and SMTP.
Society—A Cougaar Society is defined as the abstract set of all Agents that can address each other. “Society” is approximately equivalent to “Application,” though an application will usually include non-Agent members like databases and other non-Cougaar external systems (like users). Although Societies are not addressable as entities, it is often a useful term.
Node—Cougaar Agents are rather heavyweight when compared to most MAS Agents. The Cougaar Agent architecture was specifically designed to function well (in some cases, best!) if each Agent were to run on its own host machine or at least in parallel with other Agents on the same machine. A Cougaar Node is an in-Cougaar abstraction of a host. A Node may contain any number of client Agents, in effect providing life support and some shared services. Messaging is an example of a service that is provided at the Node level in order to reduce the overhead associated with network connections when there may be dozens of application agents on a single host (see Figure 2). Another important Node-level Service is a highly manageable Thread Pool service, allowing code to assume unlimited parallelism without the overhead of heavyweight Threads.
Agent
RMI
Agent Agent Agent
Messaging
Components and Services—All concrete Cougaar components (including Plugins and Agents) are implemented using a Component Model based loosely on the Java BeanContext API [6]. This model allows for straightforward customization, extension and pruning of Cougaar infrastructure components at configuration time rather than compile time. All Components are arranged in a strict Containment hierarchy that guarantees strict encapsulation (see [8]).
Node
Agent
SSL SMTP …
Figure 2 - Node Detail Typical Communication Patterns Cougaar applications tend to use similar communication patterns. While it is impossible to describe all of the variations, what follows is a typical set. Plugin-Plugin—The most common Plugin-Plugin pattern recapitulates asynchronous messaging: A task or query is published to the Blackboard and some time later one or more responses are observed. The most commonly used varieties of this pattern are Task Allocation and Task Decomposition.
Nodes are also themselves genuine Cougaar Agents. This allows the implementation of Agent management applications using the same infrastructure at the same time as the “primary” application. Implemented examples of this include crash-detection and restart management, load balancing and security auditing tools.
The generalization of de-facto directed 1-1 messaging to 1-N messaging is supported via a “Relay” facility that supports an arbitrary number of responses from any interested responders and issuer-defined selection or aggregation of the results. This facility is commonly used when the responder is both likely to be remote and is not addressable via a simple name lookup – for example a “message” to an Agent with a Community-defined role.
Community—Communities are abstract groups of Agents and other Communities that are related by task, by function, or by management structure. Examples of Communities are the typical nested Organization-Chart structures, “trusted security enclave,” “agents running on hosts I manage”.
The Blackboard is the most straightforward way to access the Cougaar persistence capability. Many Plugins find it more convenient to store their own state directly on the Blackboard in order to avoid having to reconstruct it themselves after rehydration.
Task Decomposition & Delegation
Agent-Agent—Agents communicate as a side effect of their Plugins’ business logic, as translated into “message space” by their Logic Providers. Typical Cougaar applications have a vertical inter-agent messaging component which maps to some sort of task decomposition structure and a horizontal component where messaging is between peers either tasking each other for services or negotiating/collaborating on solutions.
Agent Agent
Agent Agent
Agent
Agents
Tasks
Messages
36
30,000
767
52
35,000
1,126
133 137,000 3,016 Table 2 - Message Metrics for Sample Societies
Agent
Agent
several years by many people to solve the logistics-planning problem, so it can be taken as a representative application in its domain and not a contrived example. The following table shows the configurations used for these experiments and the overall communications resources used.
Agent
Peer/Attribute-based Collaboration
Figure 3 - Agent-Agent Communications A recent addition to the Cougaar suite is a Service Discovery add-on that allows web-services like discovery, request and tasking based on the attributes of the services desired. When coupled with a hierarchical notion of “locality of service,” this leads to a flexible way to find other Agents as appropriate to tasking without a-priori knowledge, as well as allowing fallback and rediscovery when the larger system is not reliable. This facility is critical when deploying large societies because the overhead of statically managing agents representing hundreds (or thousands or more) of organizations quickly becomes untenable.
3. CASE STUDY For the last six years, we have been developing applications using the Cougaar MAS. This work represents scores of man-years of work developing, integrating, and testing distributed Multi Agent Systems. In this section, we examine one of those applications and see how the multi-level approach applies. This application performs logistics planning for a set of military units for a particular contingency. This application can be scaled to solve incrementally larger problems by adding more agents to represent more military units and more detailed planning capability. It was developed over
The Agents column of Table 2 shows the size of the MAS in terms of the number of Agents representing military units present in the system. The Tasks column shows the approximate total number of Tasks generated by the planning system and gives an indication of the size of the problem space. The Message column is the total number of messages sent between agents in creating the plan. Agents 133 Plugins 2,396 Blackboard events 1,798,060 Inter-Agent Messages 156,460 Aggregate Messages 3,016 Table 3 - Sub-agent Activity for 133 Agents Table 3 shows further detail of the largest case. The Plugin count is the sum of the Plugin instances contributing to the solution across the whole 133 Agent Society. Blackboard events are approximately the number of Plugin-Plugin interactions, including LP contributions. The Inter-Agent Messages figure is the total number of unique messages sent between Agents. An “Aggregate Message” is a collection of inter-agent messages sent between the same sourcedestination pair representing a rollup of one or more whole transactions for purposes of network and application efficiency. It is clear from these figures that the magnitude of the interactions within agents is actually fairly similar to the level of complexity between the agents of this application. Plugin Relationship Analysis It is difficult to illustrate the relationships between such large numbers of Plugins, even in these small societies. Given the simple interaction models commonly used at the Plugin level, it is simple to derive diagrams like the following as in Figure 4. Here, chain A-G performs multistage task decomposition delegating E-G to another Agent, chain H-J does task aggregation, and chain K does simple (local) task allocation.
C A
B
G F
D E
H I K
J
Agent
Figure 4 - Typical intra-Agent Plugin Relationships Agent Relationship Analysis The following figures show relationship graphs for the three Societies described in Table 2.
Figure 6 - Relationships Among 52 Agents In Figure 6, clusters of related agents are starting to become apparent. While, the agent in the center is still related to all other agents, subgroups are starting to become apparent in the upper left and lower right corners.
Figure 5 - Relationships Among 36 Agents Figure 5 shows that this agent society has one agent that exchanges messages with all of the other agents. It turns out that this agent is responsible for a global initialization stage – later versions of this society have replaced this global process with a scalable, hierarchical one for significantly better performance and scalability.
Figure 7 - Relationships Among 133 Agents By the time the MAS reaches 133 agents (Figure 7), a number of Agent Communities are readily apparent. This becomes clearer if those relationships that are lightly used (total link traffic
