Transcript Agent Based Software Development

Agent Based
Software Development
Michael Luck, Ronald Ashri and
Mark d’Inverno
FIPA


The Foundation for Intelligent Physical Agents
(FIPA) is a non-profit organization founded in 1996
to promote interoperability between heterogeneous
software agents and agent-based systems.
It is the major standards body in the area of agentbased computing, with standards in areas such as






Agent Communication Languages (ACLs)
Interaction Protocols (IPs)
content languages
agent management
message infrastructures
FIPA standards cover many of the main areas of
agent development





To date, there are nearly 20 implementations of the current
generation of specifications, many open source, with significant user
communities.
In late 2000, FIPA adopted a new process for development of its
standards (draft, experimental and final standard levels of
development)
The consortium recently voted to approve the first full set of
specifications to the final standards status after extensive comment
periods.
New standard level documents were ratified in November 2002,
finalizing and formalizing the experimental level specifications that
proceeded them.
It is expected that implementations will begin to adopt the new
standards as part of their new development cycle.
FIPA Abstract Architecture


The FIPA Abstract
Architecture Specification
gives an overall
description of the FIPA
standard set.
It defines core notions
such as agents, services
for agents and elements
necessary to enable
agents to handle multiple
message transport
systems, agent languages
and other components.
Mappings to the Abstract
Architecture


The network
architecture enables
the reification of FIPA
agent concepts into
target technology
environments
(concrete realizations).
The abstract
architecture definitions
act as reference points
for defining mappings
between the different
realizations
Abstract Architecture
Specification



The abstract architecture specification is useful for
orientation but not essential for development of
specific implementations
Most implementations derive from agent
management, agent communication and other
concrete specifications (below the abstract layer)
There are two reifications of the architecture:



The Java Agent Services API: designed to validate the
Abstract Architecture
The FIPA2003 Standard Specification set
These concrete specifications generally implement
and specialize the abstract architecture
FIPA Agent Management

The FIPA Agent Management Specification defines





type of runtime environment that FIPA agents inhabit
services expected to be available to them
management actions that can be carried out by or for them
It introduces the notion of an agent platform as the
key building block of such an environment.
FIPA agent platforms include the following
mandatory components:




an agent runtime environment
a Directory Facilitator
an Agent Management System
message transport systems


Each component is specified in detail in terms
of functionality and interfaces (for the agent
runtime in terms of a lifecycle) and is widely
implemented in a range of FIPA agent
platform implementations
Note that management of platform resources
is currently not usually handled by the AMS
in most platform implementations but by
external user accessible interfaces
FIPA Agent Platform Reference
Model
Agent runtime environment


Agent runtime environment defines the notion of
agenthood used in FIPA and a lifecycle for such
systems.
A platform can implement its runtime environment
in almost any way



inside a single Java virtual machine
using a distributed object system to manage separate
processes on many remote machines
etc
Directory Facilitator



A Directory Facilitator (DF) acts as a yellow
pages service for the agents on the platform
It enables them to advertise and discover
service offerings
Provisions are made for the federation of DFs
between different agent platforms
Agent Management System



An Agent Management System (AMS) acts as
a white pages service
Agents registered on the platform can locate
one another
It is the main authority on the platform
controlling service and resource use
(enforcing the agent lifecycle)
Message Transport Systems

Message Transport Systems provide
communication services for on and off
platform agent message exchange
Agent Message Transport Service

Message transport specifies encodings, interfaces
and subsystems for message exchange




Message Transport Service specifies the overall message
transport architecture
Message Transport Protocol for IIOP, and Message
Transport Protocol for HTTP define low level details
required for on-the-wire transfer of messages between
interfaces on different agent platforms
Message Transport Envelope Specifications define how
metadata required for message forwarding over individual
Message Transport Protocols (MTPs) is encoded. In
principle, they are reusable across different MTPs
Several ACL message representation specifications that
define the precise syntax to be used when sending
messages. (implemented by a number of platforms)
Agent Communication Channel


These components fit together to enable message
transport between agents in two different ways
FIPA also allows agents to interact in an arbitrary
direct way but this does not require standards



FIPA defines external transport interfaces of agent
platforms (via agent communication channel - ACC) in
terms of overall transport architecture, MTPs and message
envelopes
the resulting external interfaces can then be accessed by
either ACCs (method 1) or agents (method 2) directly from
other platforms or on the same platform
the internal interface of an agent to its platform's
messaging services is not defined, to provide flexibility for
toolkit developers.
FIPA-defined transport
mechanisms
Agent Communication Standards

Need to define is the precise meaning (or
semantics) of the bits being transported




FIPA-ACL Message Structure Specification defines the
framework for FIPA-ACL messages, the components that
must be present and how they must be interpreted.
A library of communicative acts or performatives defines
formal and informal meanings (semantics) for a set of
different communicative acts specified by FIPA.
FIPA Protocols define a number of different interaction
sequences (message sequences) for standard situations
that may occur in agent systems, eg. a request sequence,
Contract Nets, auctions, etc.
Content Language defines (FIPA-SL) for use in FIPA
Messages (also used in all agent management interactions
and for formally defining the FIPA-ACL semantics)
Generic communication stack
Level
Description
Example
Conversation
(Interaction
Protocol)
A sequence of communicative acts
related to a particular topic
Sequence of messages
about buying and
eating an apple
Communicative Communication (Expression of
Act
Agent Attitude) about a piece of
content
Requesting somebody
to perform action of …
Content
Expression
Description of states of world over
objects
Expressing the action
of eating an apple
Ontology
Description of objects in domain
Meaning of ``apple'’
and ``eat''
Syntax
Representation of Content
HTML, JPG, SQL
Protocol
Data exchange protocol (ISO layer7) HTTP, GIIOP, SMTP
Transport
Physical transport and low level
transport protocols (ISO layers 1-6)
Optical Fiber, TCP-IP,
etc

Together, these specifications can be used to
construct interactions between agents



Protocols are often used first, indicating which ACL
messages (performatives) are needed
The ACL message structure, syntaxes and definitions are
then used to construct messages, and FIPA-SL is used to
express the message content
Note that FIPA remains neutral on the ontology
language to be used for expressing domain
knowledge associated with a communication

Increasingly, though, FIPA platform implementations seem
likely to support DAML-OIL or OWL as the ontology
representations of choice
Agent message example



Representing a query for (query-ref
any known object
:sender (agent-identifier
matching the object
:name i)
variable ?x
:receiver (agent-identifier
?x is just defined as
:name j)
meeting the criteria for
:ontology car
the predicate is-car,which
must be defined in the car :language FIPA-SL
:content
ontology
“((any ?x (is-car ?x)))”
The query-ref
performative indicates
)
that the agent is asking
about information related
to a particular reference
(in this case represented
by variable ?x.
Applications

FIPA Nomadic Application Support Specification
supports deployment of FIPA compliant systems in
limited connectivity environments.



Includes provisions for management of communication
channels, management of directory entries and negotiation
of message transport characteristics.
The FIPA Device Ontology Specification defines a
standard nomenclature for specifying device
characteristics used in mobile environments.
Quality of Service Ontology Specification defines a
standard nomenclature for specifying quality of
service characteristics used in mobile environments.
Java Agent Services (JAS)





Concrete instantiation of the abstract architecture in
the form of a Java API
Led by several FIPA member organizations,
including Fujitsu Laboratories of America, Sun and
IBM
The resulting Java Agent Services project followed
the Sun Microsystems Java Community Process
(JCP) to register the API in the “javax.agent’”
namespace.
Reference implementation has been produced.
More information at http://www.java-agent.org.
Other FIPA Specifications

FIPA Ontology Service Specification


FIPA Application Specifications are not yet standards


useful model of functionality and interfaces providing
ontological information
Personal Travel Assistant, Audio-Visual Entertainment and
Broadcasting, Network Management and Provisioning and
Personal Assistant provide motivating scenarios
FIPA Agent Management Support for Mobility


Useful starting point for developers of mobile agents
However FIPA is no longer active in area of mobile agents
Other FIPA Specifications

FIPA Domains and Policies Specification





High level description of notions such as domain, policy
A range of use cases and descriptions of architectural
elements needed for implementation
Still incomplete but already provides a useful introduction
to the issues involved
All these are generally not in active use, but are
useful for developers working on specific problems
in these areas
Available from FIPA website http://www.fipa.org
KQML





Developed as part of the DARPA Knowledge Sharing
Effort in the early 1990's
Language specifications provide syntax and
semantics for exchanging information and
knowledge
Designed to enable construction of large scale
knowledge bases via more flexible data exchange
Rapidly adopted by agent researchers to structure
message exchanges between systems
As with FIPA-ACL, it is based on Speech Act Theory
and notion of performatives (around 35 compared to
FIPA's 20)
Example KQML messages
(ask-one
:content (PRICE IBM
?price)
:receiver stock-server
:language LPROLOG
:ontology NYSE-TICKS)
Asking for a single stock price
quote for a particular company
(subscribe
:content
(stream-all
:content
(PRICE IBM
?price)))
Requesting future updates on all
price changes for the same stock
item - note the embedded
message inside another message.
KQML vs FIPA ACL

Several flavors of KQML emerged


Main differentiating factor is a recent trend towards
the greater adoption of FIPA-ACL, which now



has a greater number of available toolkits and active users
is more uniform in use (there are few dialects)
Differences in the semantics



Eg. Stanford's KQML+KIF ACL
Problem if implemented agents were to actively use the
modal logic levels of the languages (relating to belief,
desire, intention, uncertainty, etc.) for reasoning.
Some toolkits are based primarily on KQML
 Eg. Stanford's JatLite
KQML resources at http://www.cs.umbc.edu/kqml
Mobile Agent Standards


Mobile agents can freeze execution (code, state and
data) at a runtime location (virtual or physical
machine) and be transported via a network to
another location to continue operation
The development of standards is challenging:


The range of systems is wide, from specially coded selfexecuting TCP-IP packets in active networks to mobile
CORBA (OMG's Common Object Request Broker
Architecture) objects as in Voyager more complex Aglets
Level of interoperability is different from message
exchanges; agents arriving at a location must be able to
 execute (code compatibility)
 access local resources (file handles, threads, etc.)
 be securely sandboxed for agent and platform security
Available mobile standards



Standardization is thus concerned more with code
level, and issues are more closely related to
distributed object technologies such as CORBA than
FIPA standards
But both levels together would be required to
develop what might be regarded as a complete
mobile agent system
The main standards efforts in the mobile agents
area to date have been:


OMG MASIF (Mobile Agent System Interoperability Facility)
Specification
FIPA Agent Management Support for Mobility Specification



Both of these groups are now unfortunately
relatively inactive and have not produced complete
standards documents. However, results include
reference models for mobility that may be useful as
a basis for future standards.
To date still rely heavily on all participants using the
same mobile agent toolkit, creating single vendor
environments that cannot strictly be described as
standards based.
In the future, however, one of these toolkits may
become sufficiently established to create a de facto
standard in the area.
OMG MASIF


Originally a submission by organizations including
General Magic, IBM, Crystaliz and GMD Fokus
Resulting specification was completed in 1998:




Agent Management enables remotely creating agents,
starting and stopping them, and other lifecyle functions
Agent Tracking addresses location of agents in a mobile
agent environment, including remote queries to directories
of agents on different platforms
Agent Transport enables receiving and fetching agent class
files between platforms and making them available for
agent management functions and execution
The first two elements are considered easy to
implement, but the last is more complex
MASIF terminology

MASIF defines a reference terminology for mobile
agent systems containing definitions for notions of
agents, mobility, state and, in particular, several
notions of locality.



A place is a context in which an agent can execute, so a
place is an execution environment.
An agency is an agent system. An agency can have
several places. An agent system represents a platform that
can create, interpret, execute, and transfer agents.
A region is a group of agencies that belong to a single
authority.
MASIF standards


The technical specifications are defined in terms of
standard CORBA services (naming, lifecycle,
externalization and security services) available in
many CORBA ORB implementations.
The standards are captured in two Interface
Definition Language (IDL) interface definitions:


MAFAgentSystem and MAFFinder must be implemented by
mobile agent platforms in order to be considered compliant
with the MASIF standard
They allow the specified remote operations implied by the
standard to be carried out transparently, whatever the
software platform the remote platform is actually using.
FIPA Agent Mobility Standard


FIPA Agent Management Support for Mobility
Specification was part of FIPA'98 but not developed
after 1999
Sought to determine minimum provisions necessary to
allow agents to take advantage of mobility:




definition of terms related to mobility (stationary agents, mobile
agents, migration and so forth)
management actions to be supported by a FIPA platform to
provide mobile agent functionality
ontology specification for elements of agent profile that
described agent data, code and other associated information in
a standard framework
a mobility lifecycle and different mobility protocols describing
different modes of agent transfer between systems.
FIPA mobile agent lifecycle