Èñòî÷íèê: http://perso.limsi.fr/jps/enseignement/examsma/2005/1.plateformes_2/SOHAIL/SOHAIL.htm

Table of Contents

1. Introduction

2. AALAADIN model

2.1. Agent

2.2. Group

2.3. Role

3. MADKIT as a multi-agent system

3.1. Agent micro-kernel

3.2. Agents

3.3. Agentification of services

3.4. Componential graphical architecture

4. Generic simulation tool based on MADKIT

5. Exception handling in multi-agent systems

6. Dynamic congestion avoidance using MADKIT

7. Applications

8. Conclusion

9. References

1. Introduction

In last few years, the multi-agent systems (MAS) are deploying in more and more complex environments. Multi-agent systems comprise agents that can be cooperative or self-interested. Cooperative agents coordinate among themselves towards achieving a common goal. An effective way to achieve coordination is via imposing a specific group organization. An organization comprises roles and their interrelations. A role clusters types of behavior into a meaningful unit that contributes towards group’s common goal. Role interrelations provide communication path among agents. Collaboration is a special type of coordinated activity in which participants work jointly with each other to achieve a shared goal. Therefore roles are considered in the context of achieving specific goals.

High degree on interaction: The degree of interaction in a team of agents can be reduced by imposing roles, specifying the resources that each agent can use, information that should be communicated between agents and goals that should be achieved by each agent towards organization’s collective objectives.

Environment dynamics: In a dynamic and unpredictably changing environment, roles provides the abstraction to the intensions that agent must adopt for the successful execution of tasks, specify the conditions that must hold for roles to apply in a context of action and capture dependencies among the intended behaviors in a shared context.

Distributivity: Roles in specific contexts of action provide abstract specifications of distributed behavioral patterns. Agents need to form groups with shared objectives, interact among themselves so as to have a coherent and integrated view of the whole task-environment and an integrated view of the mental states of their collaborators.

2. AALAADIN model

AALAADIN is not a specific agent methodology, but a meta-model for describing organizations of agents using the core concepts of group, agent and role. With AALAADIN one can describe multi agent systems with different forms of organizations such as market-like or hierarchical organizations and therefore it could be useful for designing MAS. An organization in AALAADIN is a framework for activity and interaction through the definition of groups, roles and their relationships. Figure 1 represents the diagram of this model.

ìîäåëü ÀÃÐ
FIG. 1 – Agent/Group/Role model

2.1 Agent

An agent is only specified as an active communicating entity which plays roles within groups. The model places no constraints on the internal architecture of the agents.

2.2 Group

Groups are defined as atomic sets of agent aggregation representing any usual multi-agent system. Each agent is part of one or more group. In AALAADIN groups can freely overlap each other.

2.3 Role

The role is abstract representation of an agent function, service or identification within a group. Each agent can handle multiple roles, and each role handled by an agent is local to a group.

Concluding the above, the AALAADIN model provides developers with the ability to define systems that can cope with task-environment dynamics in terms of agents, groups and roles. The actual properties of roles depend on the final MAS system design sophistication. However, for complex environments it requires substantial effort from the system designer and developer in order MAS to realize the full-range facilities provided by roles. This is mainly due to the fact that there is not a specific methodological and/or development framework for the specification and exploitation of roles during planning and execution of tasks.

We also see overlapping of groups as a trade-off between a flat world and a real world where a role of representative of the group is associated to one of its member to act as the proxy for the whole group for the external world.

3. MADKIT as a multi-agent system

Being able to take advantage of the diversity of approaches simultaneously is important to build complex systems while keeping heterogeneity manageable. Thus the interesting question is how to establish conceptual models and software toolkits to facilitate integration.

Motivated by the need to provide generic, highly customizable and scalable agent platform, MADKIT (multi-agent development kit) implemented on AALAADIN model is realized. The goal of building a foundation layer for various agent models was essential, as well as making the basic services provided completely extensible and replaceable.

MADKIT Architecture

The MADKIT platform is built around AALAADIN model. In addition to three core concepts, the platform adds three design principles:

MadKit itself is a set of packages of Java classes that implements the agent kernel, the various libraries of messages, probes and agents. It also includes a graphical development environment and standard agent models. But the platform is not an agent platform in the classical sense as any service besides those assured by micro-kernel is handled by agents.

The reduced size of micro-kernel, combined with the principle of modular services managed by agents enable a range of multiple and scalable platforms.

MadKit arhitecture diagram
FIG. 2 – MadKit arhitecture diagram

3.1 Agent micro-kernel

MADKIT micro-kernel is a small and optimized agent kernel. The kernel itself is wrapped in a special agent KernelAgent which permits control and monitoring of the kernel within the agent model. Kernel only handles the following tasks:

Control of local groups and roles: The micro-kernel is responsible for maintaining correct information about group members and roles handled. It also checks if requests made on groups and roles structures are correct.

Agent life-cycle management: The kernel is responsible for the creation and destruction of agents and maintaining tables and references of agent instances. It assigns a global unique identifier AgentAddress (kernel address plus identification of agent on local kernel) to each agent upon its creation.

Local message passing: The kernel manages routing and distribution of messages between local agents. The basic mechanism relies on a copy-on-write implementation to avoid unnecessary operations.

Kernel hooks

The kernel itself is fully extensible through kernel hooks, which allows extension of the core behavior of the platform. Any agent can request KernelAgent to subscribe to the kernel hooks.

Monitor hooks: An inform message is send to all subscribed agent upon invocation of kernel operation, with argument of this operation as contents of the message. Any number of agents can subscribe for this type of hook.

Interceptor hooks: It prevents the execution of the implemented kernel operation and can only be attained by one agent. It is particularly useful to write distributed messaging agents, group synchronizers, security control in groups, etc. by changing the behavior of a basic operation.

3.2 Agents

Group and roles actions and requests are defined at action level. The agent developer is completely free to define the agent behavior, but the organizational view will be always present.

Control and life-cycle: The main agent class in MADKIT defines primitives related to message passing, plus group and role management, but does not implement a specific execution policy. A subclass adds support for concurrent, thread-based execution, which is the natural model for coarse-grained collaborative or cognitive agent. Additional subclasses implements synchronous execution through an external scheduler, focused on reactive or hybrid architectures: many fine-grained agents.

Communication: It is achieved through asynchronous message passing, with primitives to directly send a message to another agent represented by its AgentAddress, or the higher-level version that send or broadcast to one or all agents having a given role in a specific group.

Message passing

Messages in the MADKIT platform are defined by inheritance from a generic Message class. Thus specific messages can be defined for intra-group communication, and allows a group to have its specific communication attributes. Messages receivers and senders are identified with their AgentAddress. MadKit do not define interaction mechanism, which can be defined on an ad-hoc basis, or built in a specific agent model library.

3.3 Agentification of services

MADKIT uses agents to achieve things like distributed message passing, migration control, dynamic security, and other aspect of system management. These different services are represented in the platform as roles in some specific groups, defined in an abstract organizational structure. This allows a very high level of customization, as these service agents can be replaced without hurdle.

Communication and distribution

As messaging, as well as groups and roles management uses the AgentAddress identifier, and as this identifier is unique across distant kernels, MADKIT agents can be transparently distributed without changing anything in the agent code. Groups can spawn across different kernels, and agents usually do not notice it. Distribution in the agent platform relies on two roles in the system group:

The communicator agent is used by the micro-kernel to route non-local messages to other communicator agents, on distant platforms, which therefore injects the now local messages in their kernel.

The group synchronizer agents allows groups and roles to be distributed among kernels by sending groups and roles changes to other synchronizers, which in turn enter these information in their local kernel. Note that these group synchronizers use themselves their own distributed group to ease distributed group management.

Communication agents
FIG. 3 – Communication agents

3.4 Componential graphical architecture

MADKIT graphic model is based on independent graphic components, using the Java Beans specification in the standard version. Each agent is solely responsible for its own graphical interface, in every aspects (rendering, event processing, actions...) An agent interface can be a simple label, a complex construction based on multiple widgets, or a legacy bean software module. A “graphic shell” launches the kernel and setup the interfaces for the various agents and manage them in a global GUI (for instance: each agent has its own window, or is mapped in a global worksheet, or is combined with another agent interface,...). As the graphic shell is a classic software module, it can be wrapped in an agent for maximum flexibility, allowing control of other agent interfaces by a regular MADKIT agent that can be part of any interaction scenario.

4. Generic simulation tool based on MADKIT

Agent interaction and activation structures can play important roles in multi-agent systems (MAS). Habitually, the main preoccupation of simulation designers is to compute agents’ behaviors rather than explore different ways of computing the MAS simulation dynamic. So this matter, the scheduling problem, does not have almost any methodological support whereas paradoxically this is a mandatory stage when computing a MAS simulation. In a classical way, a simulation consists in trying out models given in the form of mathematical relations between variables representing real physical objects. On the contrary MAS simulation proposes to directly represent the individuals, their behaviors and their interactions. The enumeration of all the works based on MAS simulations could be very tiresome. However the majority have as an aim to simulate a specific MAS model: a ant colony, soccer robots, or to offer a more or less generic platform related to a particular applicability: ecology (Cormas, Echo), robotic (MissionLab), ethology (LiveWorld), multi-agent coordination (Mass).

The development of simulation platforms is usually made around the following concepts:

Being given the variety of MAS applications, this approach, which one can describe as “theoretical model directed”, is justified and models can require thorough analysis. Almost all platforms are more or less esoteric in their engineering. This means that most of the time it is difficult, and at least not possible as an external project user, to modify the simulator’s basic operations. Especially the scheduling method employed. So if the considered model is complex, it is surely more reassuring to develop from scratch in order to be aware of all the simulation development stages and then be able to understand all the meanings of the output results.

Any MAS simulator can itself be expressed as a MAS and then, by nature, this system defines a subjacent organizational structure. An explicit use of this structure must provide a solution to the problems raised, as well on a description level as on computation of scheduling mechanisms. This approach can easily be exhibited using the AALAADIN organizational meta-model. Based on three core concepts -agent/group/role- this model allows simple and powerful description of organizational structures and interactions independently of the agents’ internal architecture. Thus its use will enable us to simply define the MAS dynamic by dividing up the global synchronization problem into several sub problems defined as terms of various groups and roles emerging from the whole simulation’s model structure. This method enables us to compute very different activation structures that can coexist inside only one single simulation.

Simulator as a particular MAS

Based on the above, a Scheduler Agent and its tool Activator [4] based on the MadKit platform is presented here. This architecture transposes the MadKit’s design principles to simulation and implements a micro-kernel dedicated to simulation called synchronous engine. So, a MadKit micro-kernel special agent, the Scheduler agent, offer services related to the design of heterogeneous scheduling methods. Its role consists in handling execution policies on which no constraint is supposed. Thus this agent is associated with a generic tool object called Activator. In its simplest form, an Activator is simply a mean for the Scheduler to identify a particular agent set given a group and a role. For example, the Scheduler can create an Activator on the role agent within the group simulation, or displayer within Graphical interface. The idea is to specialize subclasses of Activator in order to define a particular scheduling procedure that could then be applied punctually, by the scheduler, on various groups of agents. The advantage lies in the fact that the same Scheduler agent can create as many activators as necessary. Its task is simply summarized in organizing the activation of its activators in order to define the whole simulation process.

An organizational simulator
FIG. 4 – An organizational simulator

The principal advantage of dividing the global scheduling lies in the possibility of modifying, or replacing, an activator without having to touch the whole structure : the simulation management problems (the Scheduler’s work) is uncoupled from the agent synchronization problem (The Activator’s work). An activator is the place where the modeler has to deal with the problems of agents ordering and action granularity. So, one can notice that a Scheduler is not responsible for the quality of a particular activator. Additionally, a Scheduler agent can, as a regular one, be scheduled by an agent hierarchically higher. Another advantage is that this mechanism is not related to the internal architecture of agents. Thus an agent (a particular Java class) can be substituted by another one (another class) without having to change the scheduler or its activators. By the way, an agent can enter a simulation process just by playing the right role in the right group as an Activator overlooks this particular couple. So you can compile an agent during a simulation and then put it within the simulation without having to stop it.

5. Exception handling in multi-agent systems

Exception handling capabilities are a must-have to enable the realization of reliable large scale agent systems. To be adapted to multi-agent systems (MASs), an exception handling system (EHS) has to correctly deal with two main issues:

Agents are not native concepts of the language chosen to implement the MAS. They are higher level entities that use specific communication and execution mechanisms in order to conform with the agent paradigm. The management of exceptions at the agent level therefore requires a specific EHS that is integrated and adapted to these mechanisms: exceptions should be propagated from provider agents to their client agents through messages; agents should immediately react to messages signaling exceptions by searching for handlers associated with the activities that are affected by theses failures.

MadKit is a generic MAS coded in Java that does not prescribe any specific execution model and, as a consequence, does not provide any specific EHS. The activities of agents are coded as methods and the exceptions raised during their execution are classically treated by the handlers associated with blocks of code of these methods. When an exception cannot be treated by these handlers, it is propagated to the top level of the call-stack of the thread in which the agent executes. The thread is then destroyed by the Java virtual machine. From the MAS point of view, this corresponds to the accidental death of the agent. The lack of an appropriate agent level EHS implies that no exception can be propagated to other agents or more simply to the MAS itself, as exceptions are not supposed to be propagated outside the execution thread.

SaGE: an exception handling system based on MADKIT platform

MadKit, is a generic MAS that does not prescribe any predefined, fixed execution model: it only provides a framework of versatile communication and management mechanisms for agents. Thus, an execution model [5] is designed for MadKit agents because of the need of cooperative concurrency between agents.

Intra-agent concurrency is also mandatory in the system in order to preserve the responsiveness of agents to critical events such as exception signaling.

Handler search process in SaGE
FIG. 5 – Handler search process in SaGE

For this Sage model, the kernel of the MadKit platform is not modified but chooses to specialize classes from its core implementation (AbstractAgent, Agent, ACLMessage) along with the standard Java Exception class. In MadKit, agents are referenced by their logical AgentAddress adresses. These addresses are used to route ACLMessage messages to the recipient agents through the middleware. The class ACLMessage has been specialized in order to encapsulate data which is specific to our execution model:

The standard Java Exception class is also extended in order to:

When a message is received, it is handled by the handleSaGEMessage method that calls more specific methods depending on the category of the message (request, exception, etc.). Roles agents, implemented as a specialized class of SaGEAgent agents by the RoleAgent class, handle the broadcasting of the requests they receive with the generic broadcastService method.

The model presented here does not rely on the use of entities external to agents but fully integrates exception handling mechanisms to the execution model of the agents. It allows in-context, pertinent handlers to be defined that can directly be associated with the services provided by an agent, as part of its behavior. The execution model supports cooperative concurrency and manages the propagation of exceptions between cooperating agents. Moreover, individual exceptions propagated from agents that contribute to a collective activity can be concerted into more pertinent exceptions regarding the management of those global activities. Handlers and exception resolution functions can be associated with different kind of execution model entities (services, agents, roles) in order to support exception handling in different contexts (from the local behavior of agents to the collective activities in roles, through one-to-one collaborations between agents).

6. Dynamic congestion avoidance using MADKIT

Congestion management is always a major concern in networks. Queues fill during periods of congestion, and “last resort” congestion management is achieved through packet dropping. It is therefore necessary to control the amount of packets in the buffers by the use of buffer management techniques that choose when and what packets to drop. Different techniques have emerged to control congestion, and the most popular are those based on preventive mechanisms that rely on notification messages to try to avoid congestion. The schemes rely on cooperation between the network nodes and the end hosts to respond to these notifications to avoid reaching congestion state. This results in having network entities interacting together to achieve the common goal of congestion management, a method used to develop “intelligence” inside the network that is closely related to “multi-agent” terminology.

Integent agents in MAS
FIG. 6 – Integent agents in MAS

MAS-based agents are used in a wide range of applications, such as distributed vehicle monitoring, computer integrated manufacturing, natural language parsing, transportation planning, and in particular telecommunications management. Agents in MAS (figure 6) are stationary entities in the network, providing the necessary intelligence, and are able to perform specific predefined tasks autonomously (on behalf of a user or an application). The basic attributes of this type of agent are their ability to act asynchronously, to communicate, to cooperate with other agents, and to be dynamically configurable:

Asynchronous Operation: An agent may execute its task(s) totally decoupled from its user or other agents. This means that agents may be triggered by the occurrence of a certain event, or by the time of day. An agent placed within the network may operate totally asynchronous to the user, performing its task by talking to various system resources and potentially to other agents.

Agent Communication: During their operation, agents may communicate with various system resources and users. From an agent’s point of view, resources may be local or remote.

Agent Cooperation: This attribute indicates that the agent system allows for cooperation between agent entities. This cooperation may necessitate the exchange of knowledge information, and represents the prerequisite for multi-agent systems.

A DWRED (Dynamic Weighted Random Early Detection) simulator [6] using MadKit is proposed. It considers three classes of traffic: Gold (high priority), Silver (medium priority) and Bronze (low priority). The routers implements the agents executing DWRED buffer management. The entire routing and forwarding mechanisms of a router has been implemented by adding Java classes to MadKit to simulate a router behavior, because of generic agents architecture in MadKit.

DWRED simulator shows that cooperative congestion avoidance between routers could significantly improve service. Due to Multi-Agents Systems, the dynamics of the mechanism can be easily implemented and deployed, and communications between agents assure cooperation in the entire network to detect and fight any incipient congestion.

7. Applications

MadKit has been used in various research teams for nearly two year in projects covering a wide range of applications, from simulation of hybrid architectures for control of submarine robots to evaluation of social networks or study of multi-agent control in a production line. For instance, Wex, developed by Euriware S.A., is a complex MADKIT application for knowledge-management applications. It federates information from different data sources (databases, support tools, web search engines, current page browsed by the user and parsed...) and present unified views of these highly heterogeneous knowledge sources. Users can maintain shared ontologies on their domain. Agents have been implemented to encapsulate the various mechanisms to retrieve and transform information. The abstract organizational structure has been defined, and the various agents can plugged in to adapt the platform to the client specific needs.

8. Conclusion

In this paper, MadKit (multi-agent development kit), a generic multi-agent platform is presented. This toolkit is based on a organizational model. It uses concepts of groups and roles for agents to manage different agent models and multi-agent systems at the same time, while keeping a global structure. The architecture of MadKit is discussed which is based on a minimalist agent kernel decoupled from specific agency models. Basic services like distributed message passing, migration or monitoring are provided by platform agents for maximal flexibility. The componential interface model allows variations in platform appearance and classes of usage. MadKit can also be used on mobile devices such as Palm Pilot by using only the set of classes that are allowed under Java Micro Edition (J2ME). Some extensions to the platform related to specific features and use of MadKit for creating complex solutions are also discussed briefly. In short, MadKit lacks some of the features such as proper execution mechanism, however, it provides solid base for constructing complex MASs and for extension of the basic functions to provide a customized solution because of its generic architecture.

9. References

[1] The MADKIT project development guide. www.madkit.org

[2] Olivier Gutknecht, Jacques Ferber. The MADKIT Agent Platform Architecture. Agents Workshop on Infrastructure for Multi-Agent Systems, 2000.

[3] Ioannis Partsakoulakis and George Vouros. Importance and Properties of Roles in MAS Organization: A review of methodologies and system. Department of Information and Communication Systems Engineering University of the Aegean, Samos, Hellas, June 2002.

[4] Fabien Michel, Jacques Ferber and Olivier Gutknecht. Generic Simulation Tools Based on MAS Organization. LIRMM Laboratoire d’Informatique, Robotique et Micro-?electronique de Montpellier, 2001.

[5] Frederic Souchon, Christophe Dony, Christelle Urtad, Sylvain Vauttier. Improving Exception Handling in Multi-Agent Systems. LGI2P - Ecole des Mines d’Ales - Parc scientifique G. Besse, Nimes and LIRMM Montpellier, 2004.

[6] Nicolas Rouhana and Eric Horlait. Dynamic Congestion Avoidance using Multi-Agents Systems. Faculty of Engineering, University Saint Joseph, Beirut, Lebanon and LIP6, University Pierre et Marie Curie, Paris, France, 2001.

[7] Alexander Serenko and Brian Detlor. Agent toolkits: A general overview of the market and an assessment of instructor satisfaction with utilizing toolkits in the classroom. Michael G. DeGroote School of Business McMaster University Hamilton, Ontario, July 2002.