1 Scope
This document is part of the FIPA specifications covering agent management for inter-operable agents. This specification incorporates and further enhances [FIPA00002] and [FIPA00067] represents a companion specification.
This document contains specifications for agent management including agent management services, agent management ontology and agent platform message transport. This document is primarily concerned with defining open standard interfaces for accessing agent management services. The internal design and implementation of intelligent agents and agent management infrastructure is not mandated by FIPA and is outside the scope of this specification.
The document provides a series of examples to illustrate the agent management functions defined.
2 Agent Management Reference Model
Agent management provides the normative framework within which FIPA agents exist and operate. It establishes the logical reference model for the creation, registration, location, communication, migration and retirement of agents.
The entities contained in the reference model (see Figure 1) are logical capability sets (that is, services) and do not imply any physical configuration. Additionally, the implementation details of individual APs and agents are the design choices of the individual agent system developers.
Figure 1: Agent Management Reference Model
The agent management reference model consists of the following logical components[1], each representing a capability set (these can be combined in physical implementations of APs):
· An agent is a computational process that implements the autonomous, communicating functionality of an application. Agents communicate using an Agent Communication Language. An Agent is the fundamental actor on an AP which combines one or more service capabilities, as published in a service description, into a unified and integrated execution model. An agent must have at least one owner, for example, based on organisational affiliation or human user ownership, and an agent must support at least one notion of identity. This notion of identity is the Agent Identifier (AID) that labels an agent so that it may be distinguished unambiguously within the Agent Universe. An agent may be registered at a number of transport addresses at which it can be contacted.
· A Directory Facilitator (DF) is an optional component of the AP, but if it is present, it must be implemented as a DF service (see Section 4.1). The DF provides yellow pages services to other agents. Agents may register their services with the DF or query the DF to find out what services are offered by other agents. Multiple DFs may exist within an AP and may be federated. The DF is a reification of the Agent Directory Service in [FIPA00001].
· An Agent Management System (AMS) is a mandatory component of the AP. The AMS exerts supervisory control over access to and use of the AP. Only one AMS will exist in a single AP. The AMS maintains a directory of AIDs which contain transport addresses (amongst other things) for agents registered with the AP. The AMS offers white pages services to other agents. Each agent must register with an AMS in order to get a valid AID. The AMS is a reification of the Agent Directory Service in [FIPA00001].
· An Message Transport Service (MTS) is the default communication method between agents on different APs (see [FIPA00067]).
· An Agent Platform (AP) provides the physical infrastructure in which agents can be deployed. The AP consists of the machine(s), operating system, agent support software, FIPA agent management components (DF, AMS and MTS) and agents.
The internal design of an AP is an issue for agent system developers and is not a subject of standardisation within FIPA. AP’s and the agents which are native to those APs, either by creation directly within or migration to the AP, may use any proprietary method of inter-communication.
It should be noted that the concept of an AP does not mean that all agents resident on an AP have to be co-located on the same host computer. FIPA envisages a variety of different APs from single processes containing lightweight agent threads, to fully distributed APs built around proprietary or open middleware standards.
FIPA is concerned only with how communication is carried out between agents who are native to the AP and agents outside the AP. Agents are free to exchange messages directly by any means that they can support.
· Software describes all non-agent, executable collections of instructions accessible through an agent. Agents may access software, for example, to add new services, acquire new communications protocols, acquire new security protocols/algorithms, acquire new negotiation protocols, access tools which support migration, etc.
3 Agent Naming
The FIPA agent naming reference model identifies an agent through an extensible collection of parameter-value pairs[2], called an Agent Identifier (AID). The extensible nature of an AID allows it to be augmented to accommodate other requirements, such as social names, nick names, roles, etc. which can then be attached to services within the AP. An AID comprises[3] (see Section 6.1.1):
· The name parameter, which is a globally unique identifier that can be used as a unique referring expression of the agent. One of the simplest mechanisms is to construct it from the actual name of the agent and its home agent platform address[4] (HAP), separated by the @ character. This is a reification of the notion of an Agent Name from [FIPA00001].
· The addresses parameter, which is a list of transport addresses where a message can be delivered (see Section 3.1). This is a reification of the notion of a Locator from [FIPA00001].
· The resolvers parameter, which is a list of name resolution service addresses (see Section 3.2).
The parameter values of an AID can be edited or modified by an agent, for example, to update the sequence of name resolution servers or transport addresses in an AID. However, the mandatory parameters can only be changed by the agent to whom the AID belongs. AIDs are primarily intended to be used to identify agents inside the envelope of a transport message, specifically within the to and from parameters (see [FIPA00067]).
Two AIDs are considered to be equivalent if their name parameters are the same.
3.1 Transport Addresses
A transport address is a physical address at which an agent can be contacted and is usually specific to a Message Transport Protocol. A given agent may support many methods of communication and can put multiple transport address values in the addresses parameter of an AID.
The EBNF syntax of a transport addresses is the same as for a URL given in [RFC2396]. [FIPA00067] describes the semantics of message delivery with regard to transport addresses.
3.2 Name Resolution
Name resolution is a service that is provided by the AMS through the search function. The resolvers parameter of the AID contains a sequence of AIDs at which the AID of the agent can ultimately be resolved into a transport address or set of transport address.
An example name resolution pattern might be:
1. agent-a wishes to send a message to agent-b, whose AID is:
(agent-identifier
:name agent-b@bar.com
:resolvers (sequence
(agent-identifier
:name ams@foo.com
:addresses (sequence iiop://foo.com/acc))))
and agent-a wishes to know additional transport addresses that have been given for agent-b.
2. Therefore, agent-a can send a search request to the first agent specified in the resolvers parameter which is typically an AMS. In this example, the AMS at foo.com.
3. If the AMS at foo.com has agent-b registered with it, then it returns a result message containing the AMS agent description of agent-b; if not, then a failed message is returned.
4. Upon receipt of the result message, agent-a can extract the agent-identifier parameter of the ams-agent-description and then extract the addresses parameter of this to determine the transport address(es) of agent-b.
5. agent-a can now send a message to agent-b by inserting the addresses parameter into the AID of agent-b.
4 Agent Management Services
4.1 Directory Facilitator
4.1.1 Overview
A DF is a component of an AP that provides a yellow pages directory service to agents; . It is the trusted, benign custodian of the agent directory. It is trusted in the sense that it must strive to maintain an accurate, complete and timely list of agents. It is benign in the sense that it must provide the most current information about agents in its directory on a non-discriminatory basis to all authorised agents. At least one DF must be resident on each AP (the default DF). However, an AP may support any number of DFs and DFs may register with each other to form federations.
Every agent that wishes to publicise its services to other agents, should find an appropriate DF and request the registration of its agent description. There is no intended future commitment or obligation on the part of the registering agent implied in the act of registering. For example, an agent can refuse a request for a service which is advertised through a DF. Additionally, the DF cannot guarantee the validity or accuracy of the information that has been registered with it, neither can it control the life cycle of any agent. An object description must be supplied containing values for all of the mandatory parameters of the description. It may also supply optional and private parameters, containing non-FIPA standardised information that an agent developer might want included in the directory. The deregistration function has the consequence that there is no longer a commitment on behalf of the DF to broker information relating to that agent. At any time, and for any reason, the agent may request the DF to modify its agent description.
An agent may search in order to request information from a DF. The DF does not guarantee the validity of the information provided in response to a search request, since the DF does not place any restrictions on the information that can be registered with it. However, the DF may restrict access to information in its directory and will verify all access permissions for agents which attempt to inform it of agent state changes.
The default DF on an AP has a reserved AID of:
(agent-identifier
:name df@hap_name[5]
:addresses (sequence hap_transport_address))
4.1.2 Management Functions Supported by the Directory Facilitator
In order to access the directory of agent descriptions managed by the DF, each DF must be able to perform the following functions, when defined on the domain of objects of type df-agent-description in compliance with the semantics described in Section 6.1.2:
· register
· deregister
· modify
· search
4.1.3 Federated Directory Facilitators
The DF encompasses a search mechanism that searches first locally and then extends the search to other DFs, if allowed. The default search mechanism is assumed to be a depth-first search across DFs. For specific purposes, optional constraints can be used as described in Section 6.1.4 such as the number of answers (max-results). The federation of DFs for extending searches can be achieved by DFs registering with each other with fipa-df as the value of the type parameter in the service-description.
When a DF receives a search action, it may determine whether it needs to propagate this search to other DFs that are registered with it[6]. It should only forward searches where the value of the max-depth parameter is greater than 1 and where it has not received a prior search with the same search-id parameter. If it does forward the search action, then it must use the following rules:
1. It must not change the value of the search-id parameter when it propagates the search and the value of all search-id parameters should be globally unique.
2. Before propagation, it should decrement the value of the max-depth parameter by 1.
4.2 Agent Management System
4.2.1 Overview
An AMS is a mandatory component of the AP and only one AMS will exist in a single AP. The AMS is responsible for managing the operation of an AP, such as the creation of agents, the deletion of agents and overseeing the migration of agents to and from the AP (if agent mobility is supported by the AP). Since different APs have different capabilities, the AMS can be queried to obtain a description of its AP. A life cycle is associated with each agent on the AP (see Section 5.1) which is maintained by the AMS.
The AMS represents the managing authority of an AP and if the AP spans multiple machines, then the AMS represents the authority across all machines. An AMS can request that an agent performs a specific management function, such as quit (that is, terminate all execution on its AP) and has the authority to forcibly enforce the function if such a request is ignored.
The AMS maintains an index of all the agents that are currently resident on an AP, which includes the AID of agents. Residency of an agent on the AP implies that the agent has been registered with the AMS. Each agent, in order to comply with the FIPA reference model, must register with the AMS of its HAP.
Agent descriptions can be later modified at any time and for any reason. Modification is restricted by authorisation of the AMS. The life of an agent with an AP terminates with its deregistration from the AMS. After deregistration, the AID of that agent can be removed by the directory and can be made available to other agents who should request it.
Agent description can be searched with the AMS and access to the directory of ams-agent-descriptions is further controlled by the AMS; no default policy is specified by this specification. The AMS is also the custodian of the AP description that can be retrieved by requesting the action get-description.
The AMS on an AP has a reserved AID of:
(agent-identifier
:name ams@hap_name[7]
:addresses (sequence hap_transport_address))
The name parameter of the AMS (ams@hap_name) is considered to be the Service Root of the AP (see [FIPA00001]).
4.2.2 Management Functions Supported by the Agent Management System
An AMS must be able to perform the following functions, in compliance with the semantics described in Section 6.1.5 (the first four functions are defined within the scope of the AMS, only on the domain of objects of type ams-agent-description and the last on the domain of objects of type ap-description):
· register
· deregister
· modify
· search
· get-description
In addition to the management functions exchanged between the AMS and agents on the AP, the AMS can instruct the underlying AP to perform the following operations:
· Suspend agent,
· Terminate agent,
· Create agent,
· Resume agent execution,
· Invoke agent,
· Execute agent, and,
· Resource management.
4.3 Message Transport Service
The Message Transport Service (MTS) delivers messages between agents within an AP and to agents that are resident on other APs. All FIPA agents have access to at least one MTS and only messages addressed to an agent can be sent to the MTS. See [FIPA00067] for more information on the MTS.
5 Agent Platform
5.1 Agent Life Cycle
FIPA agents exist physically on an AP and utilise the facilities offered by the AP for realising their functionalities. In this context, an agent, as a physical software process, has a physical life cycle that has to be managed by the AP. This section describes a possible life cycle that can be used to describe the states which it is believed are necessary and the responsibilities of the AMS in these states.
The life cycle of a FIPA agent is (see Figure 2):
· AP Bounded
An agent is physically managed within an AP and the life cycle of a static agent is therefore always bounded to a specific AP.
· Application Independent
The life cycle model is independent from any application system and it defines only the states and the transitions of the agent service in its life cycle.
· Instance-Oriented
The agent described in the life cycle model is assumed to be an instance (that is, an agent which has unique name and is executed independently).
· Unique
Each agent has only one AP life cycle state at any time and within only one AP.
Figure 2: Agent Life Cycle
The followings are the responsibility that an AMS, on behalf of the AP, has with regard to message delivery in each state of the life cycle of an agent:
· Active
The MTS delivers messages to the agent as normal.
· Initiated/Waiting/Suspended
The MTS either buffers messages until the agent returns to the active state or forwards messages to a new location (if a forward is set for the agent).
· Transit
The MTS either buffers messages until the agent becomes active (that is, the move function failed on the original AP or the agent was successfully started on the destination AP) or forwards messages to a new location (if a forward is set for the agent). Notice that only mobile agents can enter the Transit state. This ensures that a stationary agent executes all of its instructions on the node where it was invoked.
· Unknown
The MTS either buffers messages or rejects them, depending upon the policy of the MTS and the transport requirements of the message.
The state transitions of agents can be described as:
· Create
The creation or installation of a new agent.
· Invoke
The invocation of a new agent.
· Destroy
The forceful termination of an agent. This can only be initiated by the AMS and cannot be ignored by the agent.
· Quit
The graceful termination of an agent. This can be ignored by the agent.
· Suspend
Puts an agent in a suspended state. This can be initiated by the agent or the AMS.
· Resume
Brings the agent from a suspended state. This can only be initiated by the AMS.
· Wait
Puts an agent in a waiting state. This can only be initiated by an agent.
· Wake Up
Brings the agent from a waiting state. This can only be initiated by the AMS.
The following two transitions are only used by mobile agents:
· Move
Puts the agent in a transitory state. This can only be initiated by the agent.
· Execute
Brings the agent from a transitory state. This can only be initiated by the AMS.
5.2 Agent Registration
There are three ways in which an agent can be registered with an AMS:
· The agent was created on the AP.
· The agent migrated to the AP, for those APs which support agent mobility.
· The agent explicitly registered with the AP.
Agent registration involves registering an AID with the AMS. When an agent is either created or registers with an AP, the agent is registered with the AMS, for example by using the register function. In the following example, an agent called discovery-agent is registering with an AP located at foo.com. The agent discovery-agent was created on the AP (that is, discovery-agent’s HAP) at bar.com and requests that the AMS registers it.
For example:
:sender
(agent-identifier
:name discovery-agent@bar.com
:addresses (sequence iiop://bar.com/acc))
:receiver (set
(agent-identifier
:name ams@foo.com
:addresses (sequence iiop://foo.com/acc)))
:ontology fipa-agent-management
:language fipa-sl0
:protocol fipa-request
:content
"((action
(agent-identifier
:name ams@foo.com
:addresses (sequence iiop://foo.com/acc))
(register
(:ams-description
:name
(agent-identifier
:name discovery-agent@bar.com
:addresses (sequence iiop://bar.com/acc))
...)))")
It should be noted that the addresses parameter of the AID represents the transport address(es) that the agent would like any messages directed to (see [FIPA00067] for information on how the MTS deals with this). In the above example, the agent discovery-agent registers itself with the foo.com AP but by virtue of specifying a different transport address in the addresses parameter of its AID, messages that arrive at foo.com will be forwarded to bar.com.
5.2.1 Registration Lease Times
To enable the DF to manage a maintainable number of registrations over a long period of time, the DF may implement lease times using the lease-time parameter of a df-agent-description. A lease time is either a duration of time, such as 3 hours, or an absolute time, such as 08:00 26-Jul-2002, at which point a registration made by an agent can be removed from the DF registration database.
When an agent wishes to register with a DF, it can specify a lease time which is how long it would like the registration to be kept. If this lease time is okay for the DF, then it will accept the registration as usual and the value of the lease-time parameter in the content of the inform reply will be the same. Consequently, when the lease time expires, the registration will be silently removed by the DF. On the other hand, if the lease time is not acceptable to the DF, then the DF can include a new lease time as the value of the lease-time parameter in the content of the inform reply. This is the case when an agent does not specify a lease time in its registration.
If the DF does not support lease times, it will notify to the requesting agent that its registration is valid for an unlimited time by removing this parameter in the content of the inform reply, in fact the default lease-time is defined to be unlimited.
For example, and agent may register the following df-agent-description:
(request
...
:content
"((action
(agent-identifier
:name df@foo.com
:addresses (sequence iiop://foo.com/acc))
(register
(df-agent-description
:name
(agent-identifier
:name dummy@foo.com
:addresses (sequence iiop://foo.com/acc))
:protocols fipa-request
:ontologies (set fipa-agent-management)
:languages (set fipa-sl0)
:lease-time +00000000T600000000T
...")
Then if the DF agrees to this lease time, it will reply with and inform which contains the same value for the lease-time parameter:
(inform
...
:content
"((done
(action
(agent-identifier
:name df@foo.com
:addresses (sequence iiop://foo.com/acc))
(register
(df-agent-description
:name
(agent-identifier
:name dummy@foo.com
:addresses (sequence iiop://foo.com/acc))
:protocols (set fipa-request application-protocol)
:ontologies (set meeting-scheduler)
:languages (set fipa-sl0 kif)
:lease-time +00000000T600000000T
...")
If an agent wishes to renew a lease time, then it can use the modify action to specify a new value for the lease-time parameter. The verification of this lease time goes through the same procedure mentioned in the last paragraph: if it is okay, then the value of the lease-time parameter in the content of the inform reply will be the same, if it is not okay, the value of the lease-time parameter in the content of the inform reply will be a new value which is acceptable to the DF.
6 Agent Management Ontology
6.1 Object Descriptions
This section describes a set of frames that represent the classes of objects in the domain of discourse within the framework of the fipa-agent-management ontology. The closure of symbols of this ontology can be obtained from [FIPA00067] that specifies additional set of frames of this ontology.
This ontology does not specify any specific positional order to encode the parameters of the objects. Therefore, it is required to encode objects in SL by specifying both the parameter name and the parameter value (see Section 3.6 of [FIPA00008]).