1 Scope
This document is part
of the FIPA specifications covering agent management for inter-operable agents.
This specification incorporates and further enhances the FIPA 98 Agent
Management Specification [FIPA00002]. The FIPA Agent Message Transport
Specification [FIPA00067] represent 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, each representing
a capability set (these can be combined in physical implementations of APs):
·
An Agent is the fundamental actor on an AP
which combines one or more service capabilities into a unified and integrated
execution model that may include access to external software, human users and
communications facilities. An agent may have certain resource brokering
capabilities for accessing software (see [FIPA00079]).
An agent must have at least one owner, for example, based on
organisational affiliation or human user ownership, and an agent may support
several notions of identity. An Agent Identifier (AID) 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
and it may have certain resource brokering capabilities for accessing software.
·
A Directory Facilitator (DF) is a
mandatory component of the AP. 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.
·
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.
·
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. APs 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 or agents who
dynamically register with an 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, called an Agent Identifier (AID). An AID comprises[1]:
· A name.
· Other parameters, such as transport addresses, name resolution service addresses, and so on.
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.
AIDs are primarily intended to be used to identify agents inside the envelope of a message, specifically within the :to and :from parameters (see [FIPA00067]). The definition of the AID object and its parameters is given in section 6.1.1, Agent Identifier Description.
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.
The :name parameter of an AID 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[2]
(HAP), separated by the '@' character.
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.
AgentA wishes to
send a message to AgentB, whose AID is:
(agent-identifier
:name AgentB@bar.com
:resolvers (sequence
(agent-identifier
:name ams@foo.com
:addresses (sequence iiop://foo.com/acc))))
and AgentA wishes to know additional
transport addresses that have been given for AgentB.
2.
Therefore, AgentA
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 AgentB
registered with it, then it returns a result message containing the AMS agent description of
AgentB; if not, then a failed message is returned.
4.
Upon receipt of
the result message, AgentA 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 AgentB.
5.
AgentA can now
send a message to AgentB by inserting the :addresses parameter into the AID of AgentB.
4 Agent Management Services
4.1 Directory Facilitator
4.1.1
Overview
A DF is a mandatory
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
: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, Directory Facilitator Agent Description:
·
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, Search Constraints such as the number of answers (:df-search-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.
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, deciding whether an agent can dynamically
register with the AP 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,
Agent Life Cycle)
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. Registration with the AMS, implies authorisation to access
the MTS of the AP in order to send or receive messages. The AMS will check the
validity of the passed agent description and, in particular, the local
uniqueness of the agent name in the AID.
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
:addresses (sequence hap_transport_address))
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, Agent Management System Agent Description (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.2.3
Management
Functions Supported by Agents
Mandatory agent
functions:
·
quit
This function is described in section 6.2.6, Terminate an Agent.
4.3 Message Transport Service
The Message Transport
Service (MTS) delivers messages between agents within an AP and to agents
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.
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 (see [FIPA00005]):
·
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 (see [FIPA00005]).
·
The agent
explicitly registered with the AP, assuming that the AP both supports dynamic
registration and is willing to register the new agent. Dynamic registration is
where an agent which has a HAP wishes to register on another AP as a local
agent.
Agent registration
involves registering an AID with the AMS. When an agent is either created or
dynamically 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 dynamically with an AP located at foo.com. The agent discovery-agent
was created on the AP (that is, discovery-agents
HAP) at bar.com and requests that the AMS registers it.
For example:
(request
: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.
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 following terms are used to describe the objects of the domain:
· Frame. This is the mandatory name of this entity, that must be used to represent each instance of this class.
· Ontology. This is the name of the ontology, whose domain of discourse includes the parameters described in the table.
· Parameter. This is the mandatory name of a parameter of this frame.
· Description. This is a natural language description of the semantics of each parameter.
· Presence. This indicates whether each parameter is mandatory or optional.
· Type. This is the type of the values of the parameter: Integer, Word, String, URL, Term, Set or Sequence.
· Reserved Values. This is a list of FIPA-defined constants that can assume values for this parameter.
6.1.1 Agent Identifier Description
This type of object represents the identification of the agent.
|
Frame Ontology |
agent-identifier FIPA-Agent-Management |
|
||
|
Parameter |
Description |
Presence |
Type |
Reserved Values |
|
name |
The symbolic name of the agent. |
Mandatory |
Word |
df@hap ams@hap |
|
addresses |
A sequence of ordered transport addresses where the agent can be contacted. The order implies a preference relation of the agent to receive messages over that address. |
Optional |
Sequence of URL |
|
|
resolvers |
A sequence of ordered AIDs where name resolution services for the agent can be contacted. The order in the sequence implies a preference in the list of resolvers. |
Optional |
Sequence of agent-identifier |
|
6.1.2 Directory Facilitator Agent Description
This type of object represents the description that can be registered with the DF yellow-page service.
|
Frame Ontology |
df-agent-description FIPA-Agent-Management |
|
||
|
Parameter |
Description |
Presence |
Type |
Reserved Values |
|
name |
The identifier of the agent. |
Optional |
agent-identifier |
|
|
services |
A list of services supported by this agent. |
Optional |
Set of service-description |
|
|
protocol |
A list of interaction protocols supported by the agent. |
Optional |
Set of String |
See [FIPA00025] |
|
ontology |
A list of ontologies known by the agent. |
Optional |
Set of String |
FIPA-Agent-Management |
|
language |
A list of content languages known by the agent. |
Optional |
Set of String |
FIPA-SL FIPA-SL0 FIPA-SL1 FIPA-SL2 |
6.1.3 Service Description
This type of object represents the description of each service registered with the DF.
|
Frame Ontology |
service-description FIPA-Agent-Management |
|
||
|
Parameter |
Description |
Presence |
Type |
Reserved Values |
|
name |
The name of the service. |
Optional |
String |
|
|
type |
The type of the service. |
Optional |
String |
fipa-df fipa-ams |
|
protocol |
A list of interaction protocols supported by the service. |
Optional |
Set of String |
|
|
ontology |
A list of ontologies supported by the service. |
Optional |
Set
of String |
FIPA-Agent-Management |
|
language |
A list of content languages supported by the service. |
Optional |
Set of String |
|
|
ownership |
The owner of the service |
Optional |
String |
|
|
properties |
A list of properties that discriminate the service. |
Optional |
Set of property |
|
6.1.4 Search Constraints
This type of object represents a set of constraints to limit the function of searching within a directory.
|
Frame Ontology |
search-constraints FIPA-Agent-Management |
|
||
|
Parameter |
Description |
Presence |
Type |
Reserved Values |
|
max-depth |
The maximum depth of propagation of the search to federated directories. This value should not be negative. |
Optional |
Integer |
|
|
max-results |
The maximum number of results to return for the search. This value should not be negative. |
Optional |
Integer |
|
6.1.5 Agent Management System Agent Description
This type of object represents the agent descriptions treated by an AMS agent.
|
Frame Ontology |
ams-agent-description FIPA-Agent-Management |
|
||
|
Parameter |
Description |
|||