FIPA Agent Management — Technical Committee 1
1 Scope
This document forms part of the FIPA 1997 standard. It specifies the minimum amount of technology deemed necessary for the management of agents in an open agent system. It provides a normative framework within which FIPA compliant agents can exist, operate and be managed. It is the intention that this document be consistent with both mobile and stationary agent requirements.
The document contains specifications of the FIPA:
- agent reference model
- agent platform
- agent management actions
- agent management content language and ontology
The document is primarily concerned with the interoperability between agents and the agent platform. The internal design of the agent and agent platform is outside the scope of this specification.
The document provides a series of examples to illustrate the agent management actions defined.
2 Normative reference(s)
Internet Inter-ORB Protocol (IIOP) : Common Object Request Broker Architecture (Version 2)
FIPA97– Part 2: Agent Communication Language.
FIPA97– Part 3: Agent/Software Integration.
3 Terms and definitions
For the purposes of this specification, the following terms and definitions apply:
Action
A basic construct which represents some activity which an agent may perform. A special class of actions is the communicative acts.
ARB Agent
An agent which provides the Agent Resource Broker (ARB) service. There must be at least one such an agent in each Agent Platform in order to allow the sharing of non-agent services.
Agent
An Agent is the fundamental actor in a domain. It combines one or more service capabilities into a unified and integrated execution model which can include access to external software, human users and communication facilities.
Agent Communication Language (ACL)
A language with precisely defined syntax, semantics and pragmatics that is the basis of communication between independently designed and developed software agents. ACL is the primary subject of this part of the FIPA specification.
Agent Communication Channel (ACC) Router
The Agent Communication Channel is an agent which uses information provided by the Agent Management System to route messages between agents within the platform and to agents resident on other platforms.
Agent Management System (AMS)
The Agent Management System is an agent which manages the creation, deletion, suspension, resumption, authentication and migration of agents on the agent platform and provides a “white pages” directory service for all agents resident on an agent platform. It stores the mapping between globally unique agent names (or GUID) and local transport addresses used by the platform.
Agent Platform (AP)
An Agent Platform provides an infrastructure in which agents can be deployed. An agent must be registered on a platform in order to interact with other agents on that platform or indeed other platforms. An AP consists of three capability sets ACC, AMS and Directory Facilitator.
Communicative Act (CA)
A special class of actions that correspond to the basic building blocks of dialogue between agents. A communicative act has a well-defined, declarative meaning independent of the content of any given act. CA's are modelled on speech act theory. Pragmatically, CA's are performed by an agent sending a message to another agent, using the message format described in this specification.
Content
That part of a communicative act which represents the domain dependent component of the communication. Note that "the content of a message" does not refer to "everything within the message, including the delimiters", as it does in some languages, but rather specifically to the domain specific component. In the ACL semantic model, a content expression may be composed from propositions, actions or Identifying Referring Expressions.
Conversation
An ongoing sequence of communicative acts exchanged between two (or more) agents relating to some ongoing topic of discourse. A conversation may (perhaps implicitly) accumulate context which is used to determine the meaning of later messages in the conversation.
Software System
A software entity which is not conformant to the FIPA Agent Management specification.
CORBA:
Common Object Request Broker Architecture, an established standard allowing object-oriented distributed systems to communicate through the remote invocation of object methods.
Directory Facilitator (DF)
The Directory facilitator is an agent which provides a “yellow pages” directory service for the agents. It store descriptions of the agents and the services they offer.
Feasibility Precondition (FP)
The conditions (i.e. one or more propositions) which need be true before an agent can (plan to) execute an action.
Illocutionary effect
See speech act theory.
Knowledge Querying and Manipulation Language (KQML)
A de facto (but widely used) specification of a language for inter-agent communication. In practice, several implementations and variations exist.
Message
An individual unit of communication between two or more agents. A message corresponds to a communicative act, in the sense that a message encodes the communicative act for reliable transmission between agents. Note that communicative acts can be recursively composed, so while the outermost act is directly encoded by the message, taken as a whole a given message may represent multiple individual communicative acts.
Message content
See content.
Message transport service
The message transport service is an abstract service provided by the agent management platform to which the agent is (currently) attached. The message transport service provides for the reliable and timely delivery of messages to their destination agents, and also provides a mapping from agent logical names to physical transport addresses.
Ontology
An ontology gives meanings to symbols and expressions within a given domain language. In order for a message from one agent to be properly understood by another, the agents must ascribe the same meaning to the constants used in the message. The ontology performs the function of mapping a given constant to some well-understood meaning. For a given domain, the ontology may be an explicit construct or implicitly encoded with the implementation of the agent.
Ontology sharing problem
The problem of ensuring that two agents who wish to converse do, in fact, share a common ontology for the domain of discourse. Minimally, agents should be able to discover whether or not they share a mutual understanding of the domain constants. Some research work is addressing the problem of dynamically updating agents' ontologies as the need arises. This specification makes no provision for dynamically sharing or updating ontologies.
Perlocutionary Effect
See speech act theory.
Proposition
A statement which can be either true or false. A closed proposition is one which contains no variables, other than those defined within the scope of a quantifier.
Protocol
A common pattern of conversations used to perform some generally useful task. The protocol is often used to facilitate a simplification of the computational machinery needed to support a given dialogue task between two agents. Throughout this document, we reserve protocol to refer to dialogue patterns between agents, and networking protocol to refer to underlying transport mechanisms such as TCP/IP.
Rational Effect (RE)
The rational effect of an action is a representation of the effect that an agent can expect to occur as a result of the action being performed. In particular, the rational effect of a communicative act is the perlocutionary effect an agent can expect the CA to have on a recipient agent.
Note that the recipient is not bound to ensure that the expected effect comes about; indeed it may be impossible for it to do so. Thus an agent may use its knowledge of the rational effect in order to plan an action, but it is not entitled to believe that the rational effect necessarily holds having performed the act.
Speech Act Theory
A theory of communications which is used as the basis for ACL. Speech act theory is derived from the linguistic analysis of human communication. It is based on the idea that with language the speaker not only makes statements, but also performs actions. A speech act can be put in a stylised form that begins "I hereby request …" or "I hereby declare …". In this form the verb is called the performative, since saying it makes it so. Verbs that cannot be put into this form are not speech acts, for example "I hereby solve this equation" does not actually solve the equation. [Austin 62, Searle 69].
In speech act theory, communicative acts are decomposed into locutionary, illocutionary and perlocutionary acts. Locutionary acts refers to the formulation of an utterance, illocutionary refers to a categorisation of the utterance from the speakers perspective (e.g. question, command, query, etc), and perlocutionary refers to the other intended effects on the hearer. In the case of the ACL, the perlocutionary effect refers to the updating of the agent's mental attitudes.
Local Agent Platform
The Local Agent Platform is the AP to which an agent is attached and which represents an ultimate destination for messages directed to that agent.
Software Service
An instantiation of a connection to a software system.
TCP/IP
A networking protocol used to establish connections and transmit data between hosts
Wrapper Agent
An agent which provides the FIPA-WRAPPER service to an agent domain.
4 Symbols (and abbreviated terms)
ACC: Agent Communication Channel
ACL: Agent Communication Language
AMS: Agent Management System
AP: Agent Platform
API: Application Programming Interface
ARB: Agent Resource Broker
CA: Communicative Act
CORBA: Common Object Request Broker Architecture
DB: Database
DCOM: Distributed COM
DF: Directory Facilitator
FIPA: Foundation for Intelligent Physical Agents
FP: Feasibility Precondition
GUID: Global Unique Identifier
HAP: Home Agent Platform
HTTP: Hypertext Transmission Protocol
IDL: Interface Definition Language
IIOP: Internet Inter-ORB Protocol
OMG: Object Management Group
ORB: Object Request Broker
RE: Rational Effect
RMI: Remote Method Invocation, an inter-process communication method embodied in Java
SL: Semantic Language
SMTP: Simple Mail Transfer Protocol
SQL: Structured Query Language
Sw: Software System
TCP / IP: Transmission Control Protocol / Internet Protocol
5 Overview
The agent management specification defines agent registration, agent message passing, agent lifecycles, and an agent platform (AP). An agent management ontology has been defined to facilitate interoperability between agent platforms using FIPA ACL.
The entities contained in the agent management specification are logical capability sets and do not imply any physical configuration.
It should be noted that the concept of an agent platform does not mean that all agents resident on an agent platform have to be co-located on the same host computer. FIPA envisages a variety of different agent platforms from single processes containing lightweight agent threads, to fully distributed agent platforms built around proprietary or open middleware standards.
In the FIPA vision, the implementation details of individual platforms and agents are the design choices of the individual agent system developers.
FIPA places minimal restrictions on whatever default intra-platform message routing protocol individual agent-developers wish to support. The minimum protocol a FIPA compliant agent platform will support is the Internet Inter-Orb Protocol (IIOP) from the Object Management Group (OMG). The use of IIOP does not preclude an AP from augmenting this inter-platform messaging protocol with other interoperability protocols, however IIOP must be supported for an AP to be FIPA compliant.
FIPA97 does not address how additional services such as security and transactions are implemented within an AP. Such issues will be addressed in FIPA98.
6 Reference Model
The agent reference model provides the normative framework within which FIPA Agents exist and operate. Combined with the Agent Life-cycle, it establishes the logical and temporal contexts for the creation, operation and retirement of Agents.
The Directory Facilitator (DF), Agent Management System (AMS) and Agent Communication Channel (ACC) are specific types of agents which support agent management. The AMS and ACC support inter-agent communication. The ACC supports interoperability both within and across different platforms. The Internal Platform Message Transport (IPMT) provides a message routing service for agents on a particular platform which must be reliable, orderly and adhere to the requirements specified in FIPA Part 2.
The ACC, AMS, IPMT and DF form what will be termed the Agent Platform (AP). These are mandatory, normative components of the model.
An Agent will also include a user interface in many cases, but this is not mandatory.
Figure 1 — Agent management reference model
6.1 Agent
An Agent is the fundamental actor on an agent platform which combines one or more service capabilities into a unified and integrated execution model which may include access to external software, human users and communications facilities.
An Agent also defines a unified security perimeter and is thus treated as a single entity in this respect. Note that this does not prohibit differentiated access control to individual Agent services on a secure basis. An Agent must have one or more owners, (for example, based on organisational affiliation or human user). An Agent may have various access control credentials and permissions. Agents may also possess security credentials and security permissions.
An Agent supports several notions of identity. A Globally Unique Identifier (GUID) also known as agent name over all FIPA domains which labels the agent so that it may be unambiguously distinguished in the agent universe. An agent may be registered at a number of addresses at which it can be contacted.
An Agent may have certain resource brokering capabilities for accessing software, (see FIPA 97 Part 3 Agent-Software Interaction).
6.2 Directory Facilitator (DF)
The DF provides “yellow pages” services to other agents. The DF is a mandatory, normative agent which is the trusted, benign custodian of an 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.
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 DF does not control the internal life-cycle of any Agent.
Agents may register their services with the DF or query the DF to find out what services are offered by which agents. At least one DF must be resident on each AP (the default DF). However an AP may support any number of DF’s.
DF’s can register with each other. Similarly, AMS, and ACC can register with a DF.
The membership of a DF directory defines an agent domain. A domain is a logical space which provides a context within which Agents may organise and locate each other. One AP can support multiple domains, one domain can span multiple AP´s.
The DF encompasses a search mechanism which searches first locally, then, if necessary, extends the searches to other DFs. The default search mechanism is assumed to be a depth first search. For specific purposes, the following optional constraints can be used, the number of answers :df-search-resp-req and the number of hops :df-search-depth.
6.2.1 Actions Supported by the DF
|
Action |
|
deregister |
|
modify |
|
register |
|
search |
6.2.2 Reserved Constants in Ontology for the DF
|
Constant |
Reserved name |
|
default-df |
df@<hostname>:<port>/<target> |
|
service-type |
fipa-df |
|
df-state |
active, suspended, retired |
6.3 Agent Management System (AMS)
An AMS is a mandatory component of the AP. It is an agent which exerts supervisory control over access to and use of the ACC. Only one AMS will exist in a single AP.
An AMS must register with at least the default DF of an AP with at least service fipa-ams.
The AMS is responsible for managing the activities of an AP. These responsibilities include creation of agents, deletion of agents, deciding whether an agent can dynamically register a the platform (for example, this could be based upon agent ownership) and overseeing the migration of agents to and from platforms. A life-cycle is associated with an agent on the AP.
The AMS maintains an index of all the agents which are currently resident on a platform. The index includes an agents GUID and their associated transport address for the AP.
6.3.1 Actions Supported by the AMS
|
actions |
|
authenticate |
|
register-agent |
|
deregister-agent |
|
modify-agent |
6.3.2 Reserved Constants in Ontology for the AMS
|
Constant |
Reserved name |
|
default-ams |
ams@<hostname>:<port>/<target> |
|
service-type |
fipa-ams |
|
ap-state |
initiated, active, suspended, waiting |
6.4 Agent Communication Channel (ACC)
All agents have access to at least one ACC. It provides the path for basic contact and interchange between an agent and other agents, including the DF, and AMS.
The ACC routes messages between agents within the platform and to agents resident on other platforms. The ACC is the default communication method that connects all agents within an AP and between AP’s. Only messages addressed to an agent can be sent to an ACC.
In order to be FIPA compliant an AP must minimally support IIOP. This is the minimum which needs to be specified in order to support the interoperability of agent platforms. However, if an agent dynamically registers with a platform, IIOP must be supported in order to guarantee the exchange of messages between that agent and the agents that already reside on the platform.
6.4.1 Actions Supported by the ACC
|
Actions |
|
Forward |
6.4.2 Reserved Constants in Ontology for the ACC
|
Constant |
Reserved name |
|
default-acc |
acc@<hostname>:<port>/<target> |
6.5 Software
Software is defined as all non-agent, executable collections of instructions accessible from a domain through an agent. Agents may access software to, for example:
2) acquire new communications protocols,
3) acquire new security protocols/algorithms,
4) acquire new negotiation protocols,
5) access tools which support migration, etc.
An Agent’s access to and use of software may be temporary or permanent. This Reference Model imposes no execution restrictions on the software. That is, the Agent may execute the software internally or remotely and at any time according to its own needs, (see FIPA 97 Part 3 Agent-Software Integration).
7 The Agent Platform (AP)
7.1 Overview
An AP provides the physical infrastructure in which agents can be deployed. An AP can support more than one domain.
The internal design of an AP is an issue for platform developers and is not a subject of standardisation within FIPA. AP’s and the agents which are native to those platforms, either by creation directly within or migration to the platform may use any proprietary method of intercommunication. For example, a platform could be implemented in Java and message-passing could be equivalent to function calls. FIPA is concerned only with how communication is carried out between agents who are native to the platform; and agents outside the platform, or agent who dynamically register with a platform. Agents are free to exchange messages directly by any means they can support.
7.2 Relationship between key entities within AP
Figure 2 is an illustration of the AP concept. This figure shows two agent platforms. On AP1 agents A and B are resident as well as the default AP agents (AMS, DFx). On the second AP (AP2), agents C, D and E are resident. Residency of an agent on the platform implies that the agent has been registered with the AMS.
The ACC provides for the routing of messages between agents on different platforms. Routing messages between AP’s requires agreement on a default interoperability protocol including transport protocol, encoding and addressing scheme. However, if an agent dynamically registers with a platform, then there is always a method available for exchanging messages between that agent and the agents that already reside on the platform. This method is via IIOP and the ACC.
Figure 2 — Agent Platform Reference Model Fragment
Returning to figure 2 on the second AP there are two DFs (DFy and DFz). As can be seen from the figure, DFs provide a logical view of agents which is independent of which particular platform an agent resides upon. Agents D and E have registered their services with DFz; agents B, C and D have registered their services with DFy; while agents A and B have registered their services with DFx. Thus in this example, agents B and D are registered with two DF’s.
7.3 The Home Agent Platform
The Home Agent Platform (HAP) is the platform on which an agent was created and is responsible for vouching for the agents identity in it’s dealings with other agents and agent platforms. This standard requires that every agent has an HAP which vouches for the agent to the rest of the agent community. To enforce this, FIPA requires that the GUID can be analysed to obtain the IIOP-URL of the HAP. FIPA requires that the HAP can authenticate the identity of the agent on that platform. To accomplish this the AMS of the HAP supports the following query:
( (request
:sender ams1-agent@iiop://fipa.org:50/acc
:receiver ams2-agent@iiop://agentland.com:90/acc
:content
(action ams2-agent@iiop://fipa.org:50/acc
(authenticate
(:ams-description
(:agent-name ag@iiop://agentland.com:90/acc)))
...)
))
The AMS on the agents HAP is responsible for recording an agents current valid address. For example this facility would be used when agents migrate from one platform to another. It is the agents responsibility to ensure that the address held by its HAP AMS is valid. An agent will have its name for its entire lifetime.
7.4 Agent Registration on an AP
There are only three ways in which an agent can come to be registered in the AMS:
1) The agent was created on the platform.
2) The agent migrated to the platform, for those platforms which support agent-mobility.
3) The agent explicitly registered with the platform, assuming the platform both supports dynamic registration and is willing to register the new agent. Dynamic registration is where an agent which has an HAP wishes to register on another AP as a local agent.
Agent registration involves registering the following two items of information with an AMS:
1) The globally unique agent identifier (GUID).
2) The local address of the agent.
When an agent is either created or dynamically registers with an agent platform, the agent is registered with the Agent Management System (AMS) using the register-agent action. In the following example an agent called Peter is registering dynamically with the FIPA agent platform (located at fipa.org) . The agent Peter was created on the platform (i.e. Peter’s HAP) at agentland.com. and requests that the AMS registers it.
(request
:sender peter@iiop://agentland.com:50/acc
:receiver ams@iiop://fipa.org:50/acc3
:ontology fipa-agent-management
:language SL0
:protocol fipa-request
:content
(action ams@iiop://fipa.org:50/acc
(register-agent
(:ams-description
(:agent-name peter@iiop://agentland.com:50/acc)
(:address iiop://agentland.com:50/acc)
….)))
It should be noted that the address which is supplied to the register-agent action is the address the agent would like messages directed to, in effect a forwarding address. This represents an agents local platform, which is the one to which it is attached and represents an ultimate destination for messages directed to that agent. In this example, the agent registers with fipa.org and sets it’s forwarding address to it’s HAP, so any messages which arrive at fipa.org for Peter will be forwarded to agentland.com[1]).
By default, the forward-agent parameter is set to the agent-name. If however, the agent chooses to change this parameter (using modify-agent action on the AMS), then messages will be re-directed to another agent.
7.5 The communication act
An agent has two options when it wishes to contact an agent on another platform:
1) It can request that the ACC on which it currently resides routes the message to the target agent and ACC.
2) It can contact the ACC of the target platform directly - i.e. cause a message to be sent directly to the target ACC. The target ACC is then responsible for routing the message to the agent on the target platform.
To contact another agent, the sender agent must be equipped with the agent name (i.e. GUID) of the receiver agent. In this case the message will be directed to the receiver agent’s HAP for delivery to the receiver agent. Alternatively, if the sender wishes to route the message directly to the agent, or to a platform on which the receiver agent has dynamically registered, then the sender can specify a communication address in addition to the agent-name in the receiver field of the message.
7.5.1 Agent Messaging and Addressing
FIPA requires that each platform provide an ACC which will route messages on an agent’s behalf where possible. To support this, FIPA requires that each ACC support at least IIOP (Internet Inter-Orb Operability Protocol) as a default method of communication. This does not mean that each agent must also support IIOP communication. The address an agent provides, for example on registration with the AMS, will determine how a message is routed to that agent. If the address given is the address of a platform (e.g. iiop://agentland.com:50/acc), then the message will be routed to that platform and it is then the responsibility of the ACC of that platform to route the message to the agent (in a platform-specific manner). On the other hand, if the agent is able to support direct communication then it is free to use a direct address when registering (e.g. iiop://agentland.com:50/peter).
All agents have a unique identifier also known as its GUID. An agent name is a concatenation of its HAP communication address and a unique name within that AP.
<name>@<hostname>:<port> / <target>[2])
1) where name is a unique expression for an agent within the HAP. For example, FipaAgent
2) where hostname is the IP address of the host on which an ACC is running or a Domain Name Service (DNS) entry which can be further resolved to an IP address
3) the port number of that host on which the ACC is listening; and
4) the target is the object key which is used to identify the receiver of the message which the ACC should dispatch the incoming message to. By default, the object key of IIOP messages exchanged between platforms will identify the ACC of that platform.
The payload of the IIOP message will contain an ACL (Agent Communication Language) message which will specify, among other things, the ultimate recipient of the message. Since an ACL message is encoded as a textual string, it can be the responsibility of the ACC to check that the incoming syntax of the ACL message is correct before forwarding the message to the receiver agent. The IIOP protocol supports message failures and re-direct.
The ACC may have a set of rules (implicitly or explicitly) which determine whether an incoming message should be routed to a recipient agent of it’s platform. For example:
1) If the Agent is not registered in the AMS, it then rejects the message.
2) If the Agent has expressly requested that access be restricted and the sender does not meet the criteria, it then rejects the message.
3) If the Agent has requested that access be authenticated, then the ACC must authenticate the sender’s ACC and the sender itself. It should be noted that since agents can migrate or dynamically register with AP, that the Agent may need to authenticate the sender itself.
Such behaviour is not mandated by FIPA.
Since each agent may register with a number of Agent Platforms, it may be associated with a number of addresses. A FIPA agent address consists of a URL, for example mailto:agent_server@fipa.org or iiop://agent.fipa.org:1755/acc, it simply defines a means of identifying where to send a message and under which protocol to send it. It is the responsibility of the receiver to handle the delivery of the message to the agent named as the receiver of the message. A FIPA message contains sender and receiver parameters. These contain the GUID of the agent the messages are to be directed to:
( :name <agent name> )
If only the GUID is provided this will be directed to the HAP identified by that name.
7.5.2 Message Routing
Routing a message to an agent involves requesting that the ACC performs the forward action[3]). In the following example, agent John is requesting that the ACC at agentland.com forwards a communicative act (message) to agent Peter (informing Peter of the weather forecast).
(request
:sender john@iiop://somewhere.com:50/acc
:receiver acc@iiop://agentland.com:50/acc
:ontology fipa-agent-management
:language SL0
:protocol fipa-request
:content
(action acc@iiop://agentland.com:50/acc
(forward
(inform
:sender john@iiop://somewhere.com:50/acc
:receiver peter@iiop://agentland.com:50/acc
:ontology weather-ontology
:language a-content-language
:content (weather-forecast ‘rain)
… ))))
When a message arrives at the AP, the ACC extracts the GUID and agent address from the receiver parameters of the message. There are two possibilities, it is either an in-coming message or an outgoing message.
7.5.2.1 Incoming messages
In all incoming messages the agent address identifies the AP on which the ACC operates. The ACC will check to see if the agent identified by the GUID is registered on the platform (with the AMS) and will attempt to forward the message to the address provided by the AMS. If the translated address is a local platform address then the platform will handle this in an implementation-dependent manner. The ACC will send an inform message to the originating ACC (as specified in the request protocol) containing the content string Done(<forward action>).
If the translated address is for another platform, then the ACC will substitute the new address in the receiver parameter of the message. The ACC will attempt to forward the message and it is now treated as an outgoing message.
If the agent is not registered on the platform then the ACC will return a refuse[4] message containing predicate (not-registered :name <agent name> :address <agent-address>)). In the following example, the AP at agentland.com refuses to forward the message because the recipient (identified by the receiver parameter of the message) is not registered at agentland.com.
For example
(refuse
:sender acc@iiop://agentland.com:50/acc
:receiver an_agent@iiop://fipa.org:50/acc
:ontology fipa-agent-management
:language SL0
:protocol fipa-request
:content
(refuse unavailable
(action acc@iiop://agentland.com:50/acc
(forward
(inform
:sender john@iiop://somewhere.com:50/acc
:receiver peter@iiop://agentland.com:50/acc
:ontology weather-ontology
:language a-content-language
:content (weather-forecast ‘rain)
… ))))… )
7.5.2.2 Outgoing Messages
In the outgoing message the <agent address> identifies another AP. The ACC will attempt to forward the message to this platform. If the address of the platform is not a valid address then the platform refuses to forward the message and the reason given is invalid-address.
If the address of the other platform is valid, then the platform will execute the communicative act <platform, request(other_platform, forward(…))> (this communicative action is the same type as shown in the example above). The other_platform will respond to this communicative act according to the fipa-request-protocol (typically an agree or refuse). If it is the latter, then a reason for refusing is also returned, for example, not-registered.
When the other platform attempts to actually forward the message, the agent can be unavailable (simply not answering), in which case the other platform will send a failure communicative act containing the reason unavailable.
Otherwise the other_platform informs the originating platform that the action has been performed
<other_platform, inform(platform,
Done(forward(:communicative-act <message>)))>
If agent Peter requested that ACC forward a message to agent jane@iiop://agentland.com:30/acc, but gave the address of Jane as phone://01/6046001. What happens if the ACC does not support phone communication? In such a case, the forward request is refused with the reason given as no-communication-means. Peter is free to analyse Jane’s address to obtain her HAP and can re-send the message this way.
7.5.2.3 Forwarding Messages to Another Agent
Agents may be physically disconnected from one AP rendering them uncontactable until they are re-connected to an AP. Mobile agents are likely to be uncontactable for short periods of time as they migrate between APs. Similarly, agents may be disconnected from an AP for prolonged periods of time if they are resident on devices such as laptop computers or mobile phones. In such situations, an agent can request that the AMS forward all messages to another delegated agent[5]) .
The delegated authority may have simple functionality such as the ability to buffer messages for later retrieval or more complex ability to act on behalf of the instructing agent.
It is envisaged that this action would be used by an agent prior to it physically being unplugged from an AP or in preparation for its migration to another AP. It is the responsibility of the agent to cancel the forward request once it has re-established itself on an AP.
The ability to delegate authority to another agent is restricted to the instructing agent only. In situations where an attempt is made by a third party agent to delegate responsibility of one agent to another the request action will be refused by the AMS.
The AMS supports the setting-up of an alternate recipient for an agent’s messages. Thus Peter could set the AMS / ACC to re-direct any messages sent to Peter to Jane. To do this requires modifying the :delegate-agent attribute of the agent entry in the AMS:
For example
(request
:sender peter@iiop://agentland.com:50/acc
:receiver ams@iiop://fipa.org:50/acc
:ontology fipa-agent-management
:language SL0
:protocol fipa-request
:content
(modify-agent
(:ams-description
(:agent-name peter@iiop://agentland.com:50/acc)
(:delegate-agent jane@iiop://agentland.com:50/acc
7.6 The Agent Platform Life-Cycle
The FIPA agents exist physically in an AP and utilises the facilities offered by the AP for realising agent functionalities. In this context, an agent, as a physical software process, has a physical life-cycle that has to be managed by the AP. For each agent, this physical life-cycle and the associated states can be different from the external logical life-cycle and states in the domain, which are managed by the DF. It should be noted that the implementation of a FIPA conformant agent platform can choose to support part of the states and transitions specified below.
The AP life-cycle of an FIPA agent is :
1) AP bounded: An agent is physically managed within an AP. The life-cycle of an agent is therefore always bounded to a specific AP
2) Application independent: The life-cycle model is independent from any application systems. It defines only the states and the transition of the agent service in its life cycle.
3) Instance oriented: The agent described in the life-cycle model is assumed an instance (an agent which has unique name and is executed independently).
4) Uniqueness: Different from the domain life-cycle, where an agent can have different states in different domains at the same time, each agent has only one AP life-cycle state at any time and within only one AP.
The agent AP life-cycle is represented by states (circles) and transitions as showed in the figure below.
Figure 3 — AP Life-Cycle
7.6.1 State Description
|
Initiated |
The agent is created or just arrived at a new AP. The AP can further initiate its parameters/environment before starting/restarting the agent. |