Fig. 1: An abstract context diagram of a generic agent
Abstract
There is an emerging consensus on the need to develop methodologies and tool-kits for building distributed multi-agent systems. This paper presents ZEUS, an advanced development tool-kit for constructing collaborative agent applications. ZEUS is a culmination of a careful synthesis of established agent technologies with the addition of some new ones, to provide an integrated environment for the rapid software engineering of collaborative agent applications. ZEUS defines a multi-agent system design methodology, supports the methodology with an environment for capturing user specification of agents, and automatically generates the executable source code of the user-defined agents. We also report on preliminary informal evaluation of ZEUS on three domains.
Keywords
Agent architectures, distributed multi-agent systems, constructing collaborative agent applications.
Introduction
This paper describes ZEUS, an advanced tool-kit for building distributed multi-agent applications. The tool-kit facilitates the construction of collaborative agent applications, arguably one of the more complex of agent types because they can have rich, deliberative internal models and operate in open and time-constrained environments (Nwana 1996).
The reasons for the development of ZEUS fall into two broad categories. Firstly, there is an emerging consensus amongst agent researchers of the need to develop methodologies and tool-kits for building distributed agent systems, moving away from point solutions to general architectures, frameworks and tool-kits (Ndumu & Nwana 1996). Secondly, a tool-kit like ZEUS facilitates the engineering of agent applications; it speeds up development time and encourages code reuse and standardisation of agent technology.
The ZEUS Philosophy and Specification
ZEUS arose out of a need to provide a generic, customisable, and scaleable industrial-strength collaborative agent building tool-kit. We required that the tool-kit encapsulate the following principles:
Firstly, it should clearly delineate between domain-level problem-solving abilities and agent-level functionality. The latter covers issues of communication, co-operation, co-ordination, task execution and monitoring, exception handling, etc. while the former allows for the acquisition of domain-specific knowledge. Thus, the tool-kit should provide agent developers with all the agent-level functionality; such that they need only provide the code implementing the domain-specific problem-solving abilities of the agents they define.
Secondly, the tool-kit should employ the direct manipulation metaphor whenever feasible. This HCI metaphor is epitomised by the visual programming paradigm and the "pick-and-choose" metaphor. That is, application developers should be able to select from varied menus, the functionality and modalities required of their agents.
Thirdly, the tool-kit should utilise "tandardised" technology wherever feasible as is exemplified by our employment of KQML (Finin & Labrou, 1997) as our agent communication language.
Fourthly, the tool-kit should support an open design to ensure it is easily extensible.
On the broad goals we set of ourselves for ZEUS, we required a tool-kit which provides a multi-agent systems developer an environment which supports the following:
In addition, we believed the tool-kit should support predefined agents such as name-server agents (white pages), facilitator agents (yellow pages) and a visualiser. A key goal of the visualiser was for analysis and debugging of distributed agent systems, as it is well known that this is a notoriously complex issue. Our visualiser is reported in Ndumu et al. (1997).
In summary, the specific goals for the ZEUS project included:>
A Generic Zeus Agent and The Zeus Agent Design Methodology
At the highest level of abstraction, a ZEUS agent is composed of three layers: a definition layer, an organisation layer and a coordination layer (Fig. 1).
At the definition layer, the agent is viewed in terms of its reasoning (and learning) abilities, its goals, resources, skills, beliefs, preferences, etc. At the organisation layer it is viewed in terms of its relationships with other agents, e.g. what agencies1 it belongs to, what roles it plays in these agencies, what other agents it is aware of, what abilities it knows those other agents possess, etc. At the coordination layer the agent is viewed as a social entity, i.e. in terms of the coordination and negotiation techniques it possesses. Regarding the other two layers, the communication layer handles the low-level details involved in inter-agent communication, while the application programmer’s interface (API) layer links the agent to the physical realisations of its resources and skills.
Fig. 2 depicts the architecture of a Zeus agent, which is not too dissimilar from others in the literature. The coordination layer of Fig. 1 is captured within the coordination engine of Fig. 2; the organisation layer roughly translates to the acquaintance model while the definition layer refers to the entire agent template. The key difference between ZEUS and other agent environments is how ZEUS supports the rapid engineering of agent systems with the internal complexity of Fig. 2.
The Mailbox handles communications between the agent and other external agents.
The Message Handler processes messages incoming from the mailbox, dispatching them to other modules of the agent.
The Coordination Engine and reasoning system takes decisions concerning the goals the agent should be pursuing, how they should be pursued, when to abandon them, etc., and coordinates the agent’s overall activities. It also has a database of pre-built coordination strategies like contract nets, auctions and master-slave.
The Acquaintance Model describes the agent’s beliefs about the capabilities of other agents in the society, and its relationships to them.
The Planner and Scheduler plans and schedules the tasks the agent is controlling, monitoring and managing based on decisions taken by the coordination engine and reasoning system, and the resources and tasks available to be controlled, monitored and/or managed by the agent.
The Resource Database contains logical descriptions of resources available to the agent. It also provides an interface between the database and external systems such that the database can query external systems about the availability of resources, etc.
The Task Database provides logical descriptions of tasks available for control, monitoring and/or management by the agent.
The Execution Monitor starts, stops and monitors external systems scheduled for execution or termination by the planner and scheduler. It also informs the Coordination Engine of successful and exceptional terminating conditions of the tasks it is monitoring.
We have provided in this section a description of ZEUS agents, and also provided a flavour of how a ZEUS agent is actually defined. The broad steps carried out in defining a ZEUS agent forms the core of our agent design methodology. Naturally, there are much other details which we omit here (for a more complete specification of the methodology see Ndumu et al. (1997)).
The ZEUS Tool-Kit
The ZEUS tool-kit essentially supports and instantiates the methodology outlined in the previous section. ZEUS consists of a host of (visual) editors which an agent developer uses to specify the information required to define a ZEUS agent. The current suite of editors include the following:
All the above editors essentially facilitate the identification and description of a set of agents, selecting agent functionality and inputting task and domain-related data. Hence, the output of the ZEUS tool-kit is then a logical description of a set of agents and a set of tasks to be carried out in a domain, together with executable code for each agent and stubs for executable code for each task. ZEUS therefore embodies a system of methods (i.e. methodology) plus environment.
In order to generate executables, in addition to the class of editors above, ZEUS also comes with the following predefined libraries:
An agent shell library which provides the agent template which dictates the agent structure shown in Fig. 2 including KQML communications, planning & scheduling algorithms, mailbox library, etc. Lastly, a set of standard supporting agents like agent name servers (ANS) (white pages), facilitators (yellow pages), and a visualiser.
Therefore, in order to generate the code for a specific application system, the code generator essentially inherits from the libraries and integrates the data from the various editors. ZEUS also provides a set of scripts for integrating the generated agents with the standard ones such as name-servers and visualisers into a coherent system. ZEUS allows for as many visualisers, name-servers and facilitators as is required by the user.
The entire ZEUS tool-kit has been implemented in the Java programming language and runs on Solaris, Unix and Windows NT platforms. Java was chosen for the following reasons. It is object-oriented, multi-threaded (each agent consists of several threads), portable across operating systems, web/HTML-friendly and it provides a rich set of APIs with its packages which are continuously being added to. ZEUS consists of about 60K lines of Java including the visualiser code.
Visualisation and Debugging in ZEUS
An area which the ZEUS tool-kit takes seriously, which we believe multi-agent system researchers have so far neglected is that of the analysis, visualisation and debugging of multi-agent systems. It is vital that a tool-kit of the like of ZEUS provides such facilities to the agent designer. Generally, visualising overall system behaviour in such systems with distributed control, data and process is a notoriously difficult task. Each agent in the system has only a local view of the organisation, and the burden is on the user to integrate into a coherent whole the large amounts of scope-limited information provided by individual agents. Further, because of the complexity of multi-agent interaction and behaviour, effective visualisation assumes more importance than in single-agent systems. It is necessary in order to reduce the information overload on users, and thus allow them to confirm, understand, control and/or analyse the behaviour of the system, and to debug the system.
The debugging problem in multi-agent systems cannot be over-stated, not least because even when individual agents in an organisation are "correct" the overall system behaviour might be less than desired.
In this section, we briefly describe ZEUS’ visualisation system. It system comprises a suite of tools, with each tool providing a view of the distributed multi-agent application being visualised. Each tool interrogates the agents in the application, collates the returned information and presents this information to a user in an appropriate manner. This in essence shifts the burden of inference from the user to the visualiser. Note that the visualiser is another agent which just requests local information from agents and tries to build a global view. Some agents may not reply because they are suspended or dead, and in such a scenario, the global view presented by the visualiser will be incomplete. The current tool-set includes:
We briefly illustrate ZEUS’ visualisation tools suite by returning to the scenario we described earlier. To reduce the textual descriptions of these tools to a minimum, we provide several screendumps of the visualiser tools on this scenario. For details on the visualiser suite of tools, see Ndumu et al. (1997).
Conclusions
A project of the complexity as building a generic and customisable tool-kit for constructing collaborative agents truly forces its developers to confront and synthesise many disparate bodies of work. We have found this very rewarding and we certainly encourage such research which synthesises existing work, but which also offers much scope for more meaningful "invention of new wheels". In carrying out this project, we have borrowed unashamedly from a wide and diverse literature including agent communication languages, distributed object technologies, co-ordination/cooperation/negotiation literature, rational agent theories, visual programming, planning & scheduling, visualisation, methodological issues, specification of ontologies, automatic code generation, HCI design, etc. In the same vein, we believe we have pushed the state-of-the-art in these broad areas:
We have also developed several applications with ZEUS.
There are several other advancements we have made in ZEUS but they are hidden in the details of various algorithms we have developed. Nevertheless, there are still many more research and development challenges yet to be addressed and some of these are covered in detail in Ndumu & Nwana (1997).
In conclusion, this paper has described briefly the rationale, philosophy, underlying methodology, design, implementation, evaluation and visualisation of an advanced tool-kit for constructing distributed agent applications. We hope it provides a valuable contribution to this new and exciting area of research.
© Зудикова Юлия Владимировна, ДонНТУ, 2010