1 FIPA Subscribe Interaction Protocol
The FIPA Subscribe Interaction Protocol (IP) allows an agent to request a receiving agent to perform an action on subscription and subsequently when the referenced object changes.
The representation of this IP is given in Figure 1 which is based on an extension of UML 1.x. [Odell2001]. This protocol is identified by the token fipa-subscribe as the value of the protocol parameter of the ACL message.
Figure 1: FIPA Subscribe Interaction Protocol
1.1 Explanation of the Protocol Flow
The Initiator begins the interaction with a subscribe message containing the reference of the objects in which they are interested. The Participant processes the subscribe message and makes a decision whether to accept or refuse the query request. If the Participant makes a refuse decision, then “refused” becomes true and the Participant communicates a refuse. Otherwise, ”agreed” becomes true.
If conditions indicate that an explicit agreement is required (that is, “notification necessary” is true), then the Participant communicates an agree. The agree may be optional depending on circumstances, for example, if the requested action is very quick and can happen before a time specified in the reply-by parameter.
In a successful response, the Participant replies with an inform-result communication with the content being a referring expression to the subscribed objects. The Participant continues to send inform-result messages as the objects denoted by the referring expression change. If at some point after the Participant agrees, it experiences a failure, then it communicates this with a failure message, which also terminates the interaction. Otherwise, the interaction may be terminated by the Initiator using the cancel meta-protocol as described in Section 1.2.
Any interaction using this interaction protocol is identified by a globally unique, non-null conversation-id parameter, assigned by the Initiator. The agents involved in the interaction must tag all of its ACL messages with this conversation identifier. This enables each agent to manage its communication strategies and activities, for example, it allows an agent to identify individual conversations and to reason across historical records of conversations. Additionally, because it may be important to preserve the sequence of the inform-result messages, it is important that the message transport used for this IP preserve the ordering of messages.
1.2 Exceptions to Interaction Protocol Flow
At any point in the IP, the receiver of a communication can inform the sender that it did not understand what was communicated. This is accomplished by returning a not-understood message. As such, Figure 1 does not depict a not-understood communication as it can occur at any point in the IP. The communication of a not-understood within an interaction protocol may terminate the entire IP and termination of the interaction may imply that any commitments made during the interaction are null and void.
At any point in the IP, the initiator of the IP may cancel the interaction protocol by initiating the meta-protocol shown in Figure 2. The conversation-id parameter of the cancel interaction is identical to the conversation-id parameter of the interaction that the Initiator intends to cancel. The semantics of cancel should roughly be interpreted as meaning that the initiator is no longer interested in continuing the interaction and that it should be terminated in a manner acceptable to both the Initiator and the Participant. The Participant either informs the Initiator that the interaction is done using an inform-done or indicates the failure of the cancellation using a failure.
Figure 2: FIPA Cancel Meta-Protocol
This IP is a pattern for a simple interaction type. Elaboration on this pattern will almost certainly be necessary in order to specify all cases that might occur in an actual agent interaction. Real world issues such as the effects of cancelling actions, asynchrony, abnormal or unexpected IP termination, nested IPs, and the like, are explicitly not addressed here.
2 References
[FIPA00037] FIPA
Communicative Act Library Specification. Foundation for Intelligent Physical
Agents, 2000.
http://www.fipa.org/specs/fipa00037/
[Odell2001] Odell, James, Van Dyke Parunak, H. and
Bauer, B., Representing Agent Interaction Protocols in UML. In: Agent-Oriented
Software Engineering, Ciancarini, P. and Wooldridge, M., Eds., Springer, pp.
121-140, Berlin, 2001.
http://www.fipa.org/docs/input/f-in-00077/
3 Informative Annex A — ChangeLog
3.1 2002/11/01 version G by TC X2S
Page 1, Figure 1: The not-understood communication was removed
Page 1, Figure 1: Reworked the protocol to insert an optional agree
Page 1, Figure 1: Deleted the explicit cancel from the protocol diagram because it has been moved to the meta-protocol section
Page 1, Figure 1: Added guards to the diagram to indicate that the protocol may be terminated by reaching the end of the conversation-length
Page 1, Figure 1: To conform to UML 2, the protocol name was placed in a boundary, x is removed from the diamonds (xor is now the default) and the template box was removed
Page 1, line 42: Reworked and expanded the section description of the IP
Page 1, line 54: Added a new section on Explanation of Protocol Flow
Page 1, line 54: Reworked and expanded the section on Exceptions of Protocol Flow to incorporate a meta-protocol for cancel
Page 1, line 54: Added a paragraph explaining the not-understood communication and its relationship with the IP