Agent Based Software Development

1
Agent Based Software Development

• Michael Luck, Ronald Ashri and Mark dInverno
• Chapter 3 Agent Toolkits

2
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

3
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

4
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

5
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

6
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

7
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

8
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

9
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 Universitys
  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.

10
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

11
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.

12
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)

13
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

14
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 agents life.

15

• 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.

16
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

17
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

18
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.

19
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.

20
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.

21
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.

22
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.

23
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.

24
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

25
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.

26
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.

27
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.

28
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

29
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

30
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

31
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

32
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

33
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

34
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