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

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

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

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)))” ) Agent message example

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

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

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

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

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

Agent Based Software Development