Agent Based Software

Development

Michael Luck, Ronald Ashri and Mark d’Inverno

Chapter 3: Agent Toolkits

Introduction Agent-based systems require significant infrastructure providing several layers of functionality, from message transportation to dynamic discovery mechanisms

Unrealistic to expect adopters of agent technologies to develop such infrastructure for each application at hand

Agent Toolkits are software for deploying an agent infrastructure and for aiding in the development of agent applications

Toolkits provide the basic building blocks to support an agent-based system allowing developers to focus on the domain-specific application challenges

Introduction

www.agentlink.org lists more than 100 toolkits

There is as yet no accepted overall generic architecture although overall patterns are beginning to emerge

Review some of the most influential toolkits from both academia and industry

Generic Toolkit Framework In order to compare

and contrast toolkits in a consistent manner we make use of a generic toolkit framework

The development of individual agents is separated from their interface to the environment.

Distinguish between high and low-level services

Distinguish between agent-building software and software to manage a functioning agent system

ZEUS - Background The Zeus agent toolkit has been under development since 1997 at BTexact.

According to the Zeus philosophy, there are five issues that represent the main infrastructural problems that need to be tackled by an agent toolkit Information Discovery – finding out about other

agents Communication – supporting message exchange Ontology – common language for describing

application domain Coordination – mechanisms for coordination

actions between agents Legacy software integration

ZEUS - Agents ZEUS Agents are

deliberative, goal-directed, versatile, truthful and temporally continuous

The generic agent architecture provides all the rudimentary tools to form the base of an agent functioning in a variety of domains

ZEUS – Multi-agent Systems

Low-level services All communication in ZEUS is based on message

exchange using the TCP/IP protocol and ASCII messages

High-level Services Zeus makes use of utility agents that provide

support to agents performing application tasks The Agent Name Server provides a white pages service

The Facilitator provides a yellow pages service

Agent Communication uses FIPA ACL

ZEUS – Supporting Software

ZEUS provides a graphical agent building environment Ontology Editor ZEUS Agent Editor

Management Services Society tool – visual information about

message exchange Report tool – progress of the main tasks and

execution state of each subtask Control tool – allows execution states to be

altered Statistic tool

RETSINA - Background RETSINA (Reusable Environment for Task Structured

Intelligent Network Agents) is a multi-agent systems toolkit developed over a period of years, since 1995, at the Intelligent Software Agents laboratory of Carnegie Mellon University’s Robotic Institute.

The design of RETSINA is based on two central assumptions about agent applications development Multi-agent systems infrastructure should support

complex social interactions between agents through the provision of services based on predefined conventions on how social interaction will take place. These predefined conventions refer, mainly, to the use of a common communication language, protocols and ontologies.

Agents in a multi-agent system engage in peer-to peer relationships. Any societal structures, such as hierarchies, should emerge through these peer-to peer interactions, and should not be imposed by a centralized approach.

RETSINA – Agents I An agent in RETSINA is understood, in abstract terms, as a

standalone survivable piece of code with communicative and intelligent behavior.

The agent-specific functionality is separated from operation within specific operating environments by placing agents in an AgentShell, which provides the necessary interfaces for interaction with the underlying operating system.

The reasoning and planning for agents is handled by the RETSINA Agent architecture

RETSINA – Agents II There are four types of RETSINA Agents

Interface Agents interact with users by receiving inputs and displaying results.

Task Agents carry out the main problem-solving activities by formulating plans and executing them by coordinating and exchanging information with other agents.

Information Agents interact with information sources such as databases or web pages. The task agents provide the queries, and the information agents are specialized in retrieving the required information by interfacing with databases, the web, and so on.

Middle Agents provide the infrastructural support for the discovery of services between agents.

RETSINA – Multi-agent systems Low-level services are handled by:

The RETSINA Communicator module, which enables agent-agent communication and abstracts beyond the underlying physical transmission layer and network type

Agent discovery is facilitated through the use of Simple Service Discovery Protocol, which is part of the Universal Plug-n-Play ad-hoc networking effort

High Level Services Agent Name Server that maps agent identifiers

to logical network addresses Middle Agents and a Language for Advertisement

and Request for Knowledge Sharing (LARKS)

RETSINA – Supporting Software The RETSINA Agent Foundation Classes are integrated

within the Microsoft VisualStudio development environment.

For debugging, RETSINA provides a graphical tool that enables developers to receive, compose and send KQML messages to agents in order to test their ability to respond to messages.

RETSINA provides three types of management: The Logger is a service that is able to record the main

state transitions between agents for inspection by developers.

This logging service can be connected to an ActivityVisualizer, which provides a graphical representation of the activity in a RETSINA application.

A Launcher service can coordinate the configuration and startup of infrastructural components and agents on diverse machines, platforms and operating systems from a single control point.

Finally, a graphical tool is available for managing Agent Name Servers, allowing direct inspection of the information currently registered with an ANS, and the configuration of the ANS itself

IMPACT - Background IMPACT (Interactive Maryland Platform for Agents

Acting Together) is a joint research project between the University of Maryland in the USA, Bar Ilan University in Israel, the University of Koblenz-Landau in Germany, the University of Vienna in Austria, and the University of Milan in Italy.

The view of what constitutes appropriate infrastructure support and software agent development is illustrated through ten desiderata that the IMPACT project aims to meet: It should always be possible to agentize non-agent

programs. The methods in which data is stored should be versatile

in recognition of the current diversity in data storage mechanisms.

The theory of agents should be independent from the specific actions any agent may perform. Such actions are a parameter of the agent.

The decision-making mechanisms of each agent should be clearly articulated in order to enable modification at any point of an agent’s life.

It should be possible to reason about beliefs, uncertainty and time.

Security mechanisms are critical to protect the infrastructure from malicious agents, and to protect agents from other agents assuming false identities.

There should be some method of providing guarantees as to the performance of agents.

A theory of agents needs to be accompanied by an efficient implementation and should be such as to allow for an efficient implementation.

Infrastructure reliability is paramount. Testing a theory through practical applications

is essential.

IMPACT - Agents Agents in IMPACT are

divided into two parts: the software code,

which consists of data types and functions that can manipulate those data types; and

the wrapper, which provides the actual intelligent agent functionality.

IMPACT places particular importance on the need to specify exactly what an agent can and cannot do through action constraints and integrity constraints

IMPACT – Multi-Agent systems Agents in IMPACT operate in a dedicated platform called an agent roost, which provides network connectivity and manages the agents operating within it

High-level services come in the form of: Yellow Pages services that are supported by:

The Type service, which allows developers to define relationships between types (e.g. japanese_car can be defined as a sub-type of car)

The Thesaurus service, which allows the matchmaking algorithm to discover information such as car and automobile are synonyms

IMPACT – Supporting Software

The IMPACT toolkit provides an agent development environment, called AgentDE, that allows developers to define every aspect of the agent that forms part of the agent wrapper.

The AgentDE can maintain a library of actions, agent programs, service descriptions, and other definitions used during development so that they can be quickly recalled and reused.

JADE/LEAP – Background JADE is an open source project distributed by TILab (Telecom Italia Labs) that has been under development since 1999 at TILab

The JADE (Java Agent Development Environment) toolkit provides a FIPA compliant agent platform and a package to develop Java agents.

LEAP is a lightweight implementation of the core functionalities of the JADE FIPA platform, and can be used in conjunction with the JADE libraries for agent development.

JADE - Agents The JADE toolkit facilitates the development of agents

that can participate in FIPA compliant multi-agent systems.

It does not define any specific agent architectures but provides a basic set of functionalities essential for an autonomous agent architecture Autonomy is interpreted as an implementation of agents as

active objects (that is, with their own thread of operation). The requirement for sociality leads to enabling agents to hold

multiple conversations on a peer-to-peer basis through an asynchronous messaging protocol.

JADE – Multi-agent systems Low-level Services - A JADE Platform is made up of a

number of Containers that operate on individual machines.

A Platform can be thought of as defining a common application domain, and agents within this platform have access to the same infrastructural services.

Each Container can have a number of agents within it. Containers handle communication between agents and

access to Platform services. Communication between platforms is based on FIPA-defined

Message Transport Protocol (MTP) over which ACL messages can be sent.

The high level services offered by JADE follow the FIPA specifications Each JADE platform has access to an Agent Management

System, which manages the platform and supervises access to it as well as providing White Pages services.

Yellow Pages services are offered by Directory Facilitators and several can exist within a FIPA platform. JADE provides implementations of the SL-0 content language and Agent Management Ontology that is used by the AMS and DF services to communicate.

JACK - Background JACK is an agent development environment produced by the

Agent Oriented Software Group - first released in 1998 and currently at version 5.0

There are two principles underpinning the development of JACK. Agent-oriented development can be thought of as an extension

of object-oriented development. As a result, JACK operates on top of the Java programming language, acting as an extension that provides agent-related concepts.

Agents in JACK are intelligent agents in that they are based on the Belief-Desire-Intention architecture.

The JACK development environment can be divided into three main components. The JACK Agent Language is a superset of the Java language,

and introduces new semantic and syntactic features, new base classes, interfaces, and methods to deal with agent-oriented concepts.

The JACK Compiler compiles the JACK Agent Language down to pure Java, so that the resulting agents can operate on any Java platform.

Finally, the JACK Agent Kernel is the runtime program within which JACK agents operate, and provides the underlying agent functionality that is defined within the JACK Agent Language.

JACK - Agents Although JACK can, in principle, support a wide

variety of agent architectures, the default architecture is the BDI architecture

Agents schedule actions, including concurrent actions, using the TaskManager.

Beliefs represent the knowledge that an agent possesses about the world.

Plans are sequences of actions that agents execute on recording an event.

Events within the agent architecture are divided into: external events (such as messages from other agents); internal events initiated by the agent itself; and motivations (which are described as goals that the

agent wants to achieve). Capabilities provide a means for structuring a set of

reasoning elements into a coherent cluster that can be plugged into agents.

JACK – Multi-agent systems

Networking capabilities in JACK are based on UDP over IP, with a thin layer of management on top of that to provide reliable peer-to-peer communication.

Agent communication between agents is handled by the JACK Kernel, which handles the routing of messages and the interface with lower-level networking infrastructure

A rudimentary Agent Name Server is provided

FIPA ACL is supported

JACK – Supporting Software JACK provides a comprehensive, graphical agent

development environment A high level design tool allows a multi-agent

system application to be designed by defining the agents and relationships between them, in a notation similar to UML.

A plan editor allows plans to be specified as decision diagrams.

A plan tracing tool and an agent interaction tool allow developers to visualize the monitoring of an application.

An application can be monitored through an Agent Tracing Controller, which allows a developer to choose which agents to trace and provides a visual representation of the agents stepping through their plans.

Living Markets

The living markets toolkit is developed by Whitestein Technologies (who acquired Living Systems AG)

The living markets toolkit consists of: A base agent server, which handles the

application domain independent issues relating to agent development

Specific solutions for specific markets (ranging from transportation to intra enterprise production and deal flow optimization) are built on top of the agent server.

Living Markets - Agents Agents in living markets are understood as

proactive, goal directed entities able to perform actions and perceive the environment. They have specific domain expertise and may adopt roles.

Application agents are domain specific agents and represent the main core functionality of the system.

Integration agents are dedicated to integrating the rest of the system with existing systems outside of the living markets environment.

Interface agents handle interaction with people for the system as a whole.

System Agents are the agents that handle the management of the living markets system itself, performing tasks such as performance monitoring and load balancing.

Living Markets – Multi-agent systems Agents operate within the living agents run-time system (LARS), which provides the required communication channels

The living markets system offers a number of high-level services through a dedicated toolkit, divided in four tiers Search for partners, products or services Matching of service providers to service

requests Dynamic pricing mechanisms, negotiation Clearing and settlement of deals

Living Markets – Supporting Software Agent development is supported by an integrated

graphical agent development environment, the living markets Development Suite Allows application developers to visually design

agent scenarios, which are representations of the main agents in the system, and the communication flows between them

Management in a living markets system is divided between day to day management of entire systems and more detailed management of agents and servers General management capabilities are provided

through a living markets Management Console, which provides a web-based interface to allow day to day administration of the application.

Individual agents can be managed through a Control Center which allows access to the LARS server

Discussion - Agents

Of the six toolkits compared, three offer variations of the BDI architecture for agents (ZEUS, RETSINA, JACK), JADE and living markets are relatively neutral, and IMPACT represents a significantly different stance There is as yet little agreement or means of

measuring the suitability of one approach versus another

Developers are left to make their own choice based on a variety of factors from ease of use and personal preference to application requirements

Discussion – Multi-Agent systems Low-level services

Of the systems reviewed only ZEUS and JACK make use of just TCP and UDP for communication

IMPACT, living markets and JADE make use of RMI which is costly

Each approach has its relative benefits but the current trend is certainly towards more lightweight approaches, with Web Service technologies beginning to play an important role – although not yet integrated with most agent toolkits

There are clear management benefits to having agents operate within dedicated platforms (JADE, living markets) since they can easily offer monitoring and management tools

Stand-alone architectures, however, offer more flexibility

Discussion – Multi-Agent systems

High-Level Services Matchmaking

Predominantly via Yellow Page services Communication based on FIPA ACL (except

IMPACT) Ontology support to varying degrees

Truly open agent systems are yet to be achieved – no agent developed for one system would easily communicate with an agent developed for another system without considerable modification

Supporting Software There is a clear distinction between commercial software and research lab efforts, with commercial software offering extensive and integrated development environments while research software is more rudimentary

Each development environment adopts a relatively ad-hoc approach to development and there is no support for a design methodology

All toolkits stress the importance of management and monitoring software, for which there are varying degrees of support

Summary There are now numerous examples of agent toolkits

that have been used to create a number of applications

As yet there is little consensus as to which approach is most suited, although broad patterns are emerging, especially on issues such as matchmaking and communication languages

Increasingly, existing middleware technologies are being adopted, allowing toolkits to focus on the purely agent-related issues

Future challenges include: Truly open systems Sophisticated security mechanisms Tackling scalability issues Appropriate design methodologies