1 Scope
This document is part of the FIPA specifications and deals with message transportation between inter-operating agents. This document also forms part of the FIPA Agent Management specification and contains specifications for agent message transport, including:
· A reference model for an agent Message Transport Service.
· Definitions for the expression of message transport information to an agent Message Transport Service.
· Definitions of Agent Message Transport Protocols for transportation of messages between agents.
· Specifications of syntactic representations of ACL.
2 Normative References
· ”FIPA Agent Management” [FIPA00023].
· ”FIPA Agent Communication Language” [FIPA00061].
· ”FIPA Communicative Acts” [FIPA00037].
· ”FIPA Content Languages” [FIPA00007].
· ”FIPA SL Content Language” [FIPA00008].
· Internet Inter-ORB Protocol (IIOP): Common Object Request Broker Architecture Version 2.2.
3 Agent Message Transport Reference Model
3.1 Message Transport Model
The FIPA Message Transport Model (MTM) comprises three levels (see Figure 1):
1. The Message Transport Protocol (MTP) is used to carry out the physical transfer of messages between two ACCs.
2. The Message Transport Service is a service provided by the AP to which an agent is attached. The MTS supports the transportation of FIPA ACL messages between agents on any given AP and between agents on different APs. The MTS is provided by the ACC.
3. The ACL represents the content of the messages carried by both the MTS and MTP.
Figure 1: Overview of the Message Transport Model
3.2 Message Structure
In its abstract form, a message is made up of two parts: a message envelope expressing transport information and the message body comprising the ACL message of the agent communication.
For the purposes of message interpretation by an agent:
· ACL semantics are defined only over the ACL message delivered in the message body of a FIPA message (see [FIPA00023]).
· All information in the message envelope is supporting information only. How and if this information is used to by an agent for any kind of additional inference is undefined by FIPA.
4 Message Transport Service
The Message Transport Service (MTS) provides a mechanism for the transfer of FIPA ACL messages between agents. The agents involved may be local to a single AP or on different APs. On any given AP, the MTS is provided by an ACC.[BB1]
4.1 Expressing Message Transport Information
Information relating to the delivery and transportation of messages can be specified in the message envelope of a message.
4.1.1 Abstract Message Envelope Syntax
The syntax described here is an abstract representation. Any MTP may use a different internal representation, but must express the same terms, represent the same semantics and perform the corresponding actions. See Section 0, Normative Annex A: Concrete Message Envelope Syntax for the lexical and syntactical representation of a message envelope for the FIPA baseline MTP.
The following are general statements about the form of a message envelope:
· A message envelope comprises a collection of slots.
· A slot is a name/value pair.
· A message envelope contains at least the mandatory to, from, dateandacl-representation slots.
· A message envelope can contain optional slots.
Each ACC handling a message may add new information to the message envelope, but it may never overwrite existing information. ACCs can add new slots to a message envelope which override existing slots that have the same slot name; the mechanism for disambiguating message envelope entries in this case is specified by each concrete message envelope syntax.
4.1.2 Message Envelope Slot Semantics
4.1.2.1 Agent Message Transport Objects
The following terms are used to identify the ontology of the agent message transport objects:
· Frame. This is the name of this entity.
· Ontology. This is the name of the ontology, whose domain of discourse includes the slots described in the table.
· Slot. This identifies each component within the frame.
· Description. This is a natural language description of the semantics of each slot.
· Presence. This indicates whether each slot is mandatory or optional.
· Type. This indicates the type of each slot: Integer, String, Word, URL, Set, Sequence, Term or other object description.
· Reserved Values. This is a list of FIPA-defined constants associated with each slot.
4.1.2.2 Message Envelope Description
|
Frame Ontology |
envelope fipa-agent-management |
|
||
|
Slot |
Description |
Presence |
Type |
Reserved Values |
|
to |
This contains the names of the primary recipients of the message. |
Mandatory |
Sequence of agent-identifier |
|
|
from |
This is the name of the agent who actually sent the message. |
Mandatory |
agent-identifier |
|
|
comments |
This is a comment in the message envelope. |
Optional |
String |
|
|
acl-representation |
This is the name of the syntax representation of the message body. |
Mandatory |
String |
See Section 7 |
|
content-length |
This contains the length of the message body. |
Optional |
String |
|
|
content-encoding |
This contains the language encoding of the message body |
Optional[1] |
String |
US-ASCII, ISO-8859-{1..9}, UTF-8, Shift_JIS, EUC-JP, ISO-2022-JP, ISO-2022-JP-2 |
|
date |
This contains the creation date and time of the message envelope – added by the sending agent. |
Mandatory |
Date |
|
|
encrypted |
This contains information indicating how the message body has been encrypted. |
Optional |
Sequence of String[2] |
|
|
intended-receiver |
This is the name of the agent to whom this instance of a message is to be delivered. |
Optional |
Sequence of agent-identifier |
|
|
received |
This is a stamp representing the receipt of a message by an ACC. |
Optional |
received-object |
|
|
transport-behaviour |
This contains the transport requirements of the message. |
Optional |
(Undefined) |
|
4.1.2.3 Received Object Description
|
Frame Ontology |
received-object fipa-agent-management |
|
||
|
Slot |
Description |
Presence |
Type |
Reserved Values |
|
by |
The URL of the receiving ACC. |
Mandatory |
URL |
|
|
from |
The URL of the sending ACC. |
Optional |
URL |
|
|
date |
The time and date when a message was received. |
Mandatory |
DateTime |
|
|
id |
The unique identifier of a message. |
Optional |
String |
|
|
via |
The type of MTP the message was delivered over. |
Optional |
String |
See Section 7 |
4.1.3 Updating Message Envelope Slot Information
An ACC may never overwrite information in a message envelope. To update a value in one of the envelope slots, the ACC must add a new copy of the message envelope slot (containing the new value) to the envelope.
Since this mechanism permits multiple occurrences of the same slots in a message envelope (with different values), each concrete message envelope syntax must provide a general mechanism for identifying which copy of the slot (and hence which value) is current. For example, The concrete envelope syntax given in Section 0, Normative Annex A: Concrete Message Envelope Syntax, specifies that the first occurrence of a slot overrides any subsequent occurrence.
4.1.4 Additional Message Envelope Slots
Any concrete syntax definition for the message envelope must include a clear mechanism for adding and distinguishing new and user defined slots added to the message envelope. For example, the concrete envelope syntax given in Section 0, Normative Annex A: Concrete Message Envelope Syntax, specifies that all new and user defined slots must be prefixed by “X-“.
4.2 Agent Identifiers and Transport Addresses
Agent Identifiers (AIDs) and transport addresses are defined in [FIPA00023].
4.3 Message Transport Functions of the ACC
The ACC is an entity providing a service directly to the agents on an AP. The ACC may access information provided by the other AP services (such as the AMS and DF) to carry out its message transport tasks.
4.3.1 Interfaces to the Message Transport Service
4.3.1.1 Standard MTP Interfaces to the MTS
The standard MTP interfaces of an ACC are used to provide message transport interoperability between FIPA-compliant APs. To be FIPA-compliant an ACC must have at least one such interface which supports a FIPA agent MTP as specified in Section 6, Message Transport Protocols.Furthermore, as a minimum, the ACC must support the FIPA baseline MTP for its AP description, additionally other standard MTP interfaces may also be provided. Refer to Section 4.5.2, Minimal Transport Requirements for FIPA Interoperability for information on the required standard MTP interfaces for each MTP transport profile.
When messages are received over a message interface advertised as implementing one of the FIPA standard MTPs, these messages must be handled as specified in Section 4.3.2, Agent Communication Channel Message Handling Behaviour.
4.3.1.2 Proprietary MTP Interfaces to the MTS
FIPA does not specify how agents communicate using proprietary interfaces with the MTS.
4.3.2 Agent Communication Channel Message Handling Behaviour
To provide the MTS, an ACC must transfer the messages it receives in accordance with the transport instructions contained in the message envelope. An ACC is only required to read the message envelope; it is not required to parse the message body.
Section 4.1.2, Message Envelope Slot Semantics specifies the expected behaviour of an ACC receiving each message envelope instruction in a message. In performing message transfer tasks, the ACC may be required to obtain information from the AMS or DF on its own AP.
Some implementations of ACCs may provide some form of buffering capability to help agents manage their messages.
4.3.2.1 Interpretation of Message Envelope Instructions
ACC message forwarding behaviour is determined by the instructions for message delivery expressed in the message envelope. Table 1 gives an overview of the ACC’s basic interpretation of each slot.
|
Slot |
Description |
|
to |
If no intended-receiver parameter is present the information in this slot is used to generate intended-receiver field for the messages the ACC subsequently forwards. |
|
from |
If required, the ACC returns error and confirmation messages to the agent specified in this slot. |
|
comments |
None. |
|
acl-representation |
None, this information is intended for the final recipient of the message. |
|
content-length |
The ACC may use this information to improve parsing efficiency. |
|
content-encoding |
None, this information is intended for the final recipient of the message. |
|
date |
None, this information is intended for the final recipient of the message. |
|
encrypted |
None, this information is intended for the final recipient of the message. |
|
intended-receiver |
An ACC uses this parameter to determine where this instance of a message should be sent. If this parameter is not provided, then the first ACC to receive the message should generate an intended-receiver parameter using the to parameter. |
|
received |
A new received slot is added to the envelope by each ACC that the message passes through. Each ACC handling a message must add a completed received slot. |
|
transport-behaviour |
If this parameter is present, the handling ACC must deliver the message according to the transport requirements specified in this parameter. If these requirements cannot be met (or understood) then the ACC raises an error (See Section 4.3.3, Error and Confirmation Messages). |
Table 1: ACC interpretation of message envelope instructions
4.3.2.2 Forwarding Messages
The recipients of a message are specified in the to slot of a message envelope and take the form of AIDs. Depending upon the presence of intended-receiver slots the ACC forwards the message in one of the following ways:
· If an ACC receives a message envelope without an intended-receiver, then it generates a new intended-receiver slot from the to slot (possibly containing multiple AIDs). It may also generate multiple copies of the message with different intended-receiver slots if multiple receivers are specified. The intended-receiver slots form a delivery path showing the route that a message has taken.
· If an ACC receives a message envelope with an intended-receiverslot,this is used for delivery of this instance of the message (the toslot is ignored).
· If an ACC receives a message envelope with more than one intended-receiver slot, the most recent is used. Identifying which is the most recent is done using the conventions set for the concrete envelope syntax in use.
Before forwarding the message, the ACC adds a completed received slot to the message envelope. Once an ACC has forwarded a message it no longer needs to keep any record of that message’s existence.
4.3.2.2.1 Handling a Single Receiver
In delivering a message to a single receiver specified in the to or intended-Receiver slot of a message envelope, the ACC forwards the message to one of the addresses in the addresses slot of the AID (see Section 4.3.2.2.2 for how to handle multiple transport addresses). If this address leads to another ACC, then it is the task of the receiving ACC to deliver the message to the receiving agent (if the agent is resident on the local platform) or to forward it on to another ACC (if the agent is not locally resident).
4.3.2.2.2 Handling Multiple Transport Addresses for a Single Receiver
The AID given in the to or intended-receiver slot (in the case of both slots being present, the information in the intended-receiver slot is used) of an agent message envelope may contain multiple transport addresses for a single receiving agent. The ACC uses the following method to try to deliver the message:
· Try to deliver the message to the first transport address in the addresses slot; the first is chosen to reflect the fact that the transport address list in an AID is ordered by preference.
· If this fails (because the agent or AP was not available, because the ACC does not support the appropriate message transport protocol, etc.), the ACC creates a new intended-receiver slot containing the AID with the failed transport address removed. The ACC then attempts to send the message to the next transport address in AID in the intended receiver list (now the first in the newly created intended-receiver slot).
· If delivery is still unsuccessful when all transport addresses have been tried (or the AID contained no transport addresses), the ACC may try to resolve the AID using the resolvers named in the resolvers slot of the AID. Again, the resolvers should, where possible, be tried in order of their appearance.
· As a last resort the ACC may try to deliver the message to the HAP of the agent (as specified in the hap slot of the AID).
Finally, if all previous message delivery attempts have failed, then an appropriate error message for the final failure is passed back to the sending agent (see Section 4.3.3, Error and Confirmation Messages).
4.3.2.2.3 Handling Multiple Receivers
An ACC uses the following rules in delivering messages to multiple intended receivers[3]:
· If an ACC receives a message envelope with no intended-receiver slot and a to slot containing more than one AID, it may or may not split these up to form separate messages[4] (each containing a subset of the agents named in the to slot in the intended-receiver slot).
· If an ACC receives a message envelope with an intended-receiver slot containing more than one AID, it may or may not split these up to form separate messages.
The resulting messages are handled as in the single receiver case (see Section 4.3.2.2.1).
4.3.2.3 Delivering Messages
Once a message has arrived at ACC that can directly deliver it to the agent or agents named in the intended-receiver slot of the message envelope, this ACC should pass the message directly to the agent(s) concerned. FIPA does not specify how final message delivery is carried out - the message may be passed to the agent(s) using any of the ACC’s interfaces (proprietary or standard MTPs). An ACC should deliver the whole message, including the message envelope, to the receiving agent, however particular AP implementations may provide middleware layers to free agents of the task of processing this information.
4.3.2.4 Using a resolver
In certain circumstances, if an AID for a receiver contains no transport addresses then the ACC may try to resolve the AID by contacting one of the entities listed in the resolvers slot of the AID. The interface used by the ACC to do this is not specified by FIPA, it may be proprietary (if the resolver is the local platform AMS for example), ACL (if the ACC can also act as an agent and communicate using ACL) or specific to some third party resolving service.
4.3.3 Error and Confirmation Messages
Error and confirmation messages sent to a sending agent by the MTS are sent in the form of ACL messages over the MTS. These MTS information messages are sent on behalf of the AMS agent responsible (the sender slot of the message must be set the local AMS’s AID) for the AP the ACC is running on. How the message is generated (whether by the AMS or by the ACC on behalf of the AMS) is not specified by FIPA.
If an error message needs to be returned, the message generated must follow the exception model defined in Section 7.3 of [Agent Management] such that:
· The communicative act is a failure,
· The predicate symbol is internal-error,
· The argument is a string describing the error that occurred (the form and content of which is not defined here).
4.4 Using the Message Transport Service
4.4.1 Sending Messages
An agent has three options when sending a message to another agent resident on a remote AP (see Figure 2):
1. Agent A sends the message to its local AP ACC using a proprietary or standard interface. The ACC then takes care of sending the message to the correct remote ACC using an MTP. The remote ACC that will eventually deliver the message.
2. Agent A sends the message directly to the ACC on the remote AP on which Agent B resides. This remote ACC then delivers the message to B. To use this method, Agent A must support access to one of the remote ACC’s MTP interfaces.
3. Agent A sends the message directly to Agent B, by using a direct communication mechanism. The message transfer, addressing, buffering of messages and any error messages must be handled by the sending and receiving agents. This communication mode is not covered by FIPA.