Transcript Agent Based Software Development

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 agentbuilding 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, goaldirected, 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 agentagent 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 objectoriented 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 BeliefDesire-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 highlevel 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