Agent Based Software Development

1
Agent Based Software Development

• Michael Luck, Ronald Ashri and Mark dInverno

2
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
  agent-based 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

3

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

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

5
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

6
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

7
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

8

• 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

9
FIPA Agent Platform Reference Model
10
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

11
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

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

13
Message Transport Systems

• Message Transport Systems provide communication
  services for on and off platform agent message
  exchange

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

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

16
FIPA-defined transport mechanisms
17
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)

18
Generic communication stack
19

• 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

20
Agent message example

• Representing a query for any known object
  matching the object variable ?x
• ?x is just defined as meeting the criteria for
  the predicate is-car,which must be defined in the
  car ontology
• The query-ref performative indicates that the
  agent is asking about information related to a
  particular reference (in this case represented by
  variable ?x.

• (query-ref
• sender (agent-identifier name i)
• receiver (agent-identifier name j)
• ontology car
• language FIPA-SL
• content
• ((any ?x (is-car ?x)))
• )

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

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

23
Other FIPA Specifications

• FIPA Ontology Service Specification
• useful model of functionality and interfaces
  providing ontological information
• FIPA Application Specifications are not yet
  standards
• 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

24
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

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

26
Example KQML messages
27
KQML vs FIPA ACL

• Several flavors of KQML emerged
• Eg. Stanford's KQMLKIF ACL
• 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
• 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

28
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 self-executing 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

29
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

30

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

31
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

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

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

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

35
FIPA mobile agent lifecycle