The AUML diagram for the status report protocol is shown below. This protocol is designed so that one agent (the Initiator) has a method by which it can ask another agent (the Respondent) about the status of some object. As with the request/response protocol in the previous section, a conversation must begin by the initiator sending a request message, which may be replied to by way of an inform message. However, in this case the respondent also has the option of refusing the request (by means of a refuse message). In addition to this, the message content is now important. Whereas in the previous example, any request message with any (or no) content would be capable of triggering the first transition, in this case it is necessary that the content of the message match status(?obj) . Here, ?obj is a variable. It may initially match against any string but its value is fixed thereafter (in a similar way to the agents' names in the previous example). The status(...) portion, however, is fixed, and can only match predicates of that type.
When represented by a FSM, the status report protocol is as shown below. As the conversation has not yet begun, any conversation following this protocol is initially in the Start state.
From this initial state, suppose the initial request message is sent by an agent named agent1 to another named agent2. The message has the content status(router1) .
In this example, agent1 is asking for an update on the status of a router (identified as "router1"). The intention of this interaction is to discover whether the router is currently functional or not. According to the protocol being followed, this message matches the transition from the Start state to the Requested state. As with the previous example, the variables ?initiator and ?respondent are bound to the names of the participating agents. On this occasion, however, the message content is also taken into account. The message content status(router1) is matched against the transition rule status(?obj) and the variable ?obj is bound to the value router1 in the same way as the variables relating to the conversation participants. Thus future transitions containing the variable ?obj must match the specific string router1 . The state of the conversation after this initial transition is shown below:
At this point, the Requested state has two possible outgoing transitions, one of which will be triggered in accordance with the next message to be exchanged. We now assume that agent2 sends a reply to agent1, which has an inform performative and content statusOf(router1,up) .
The participant names match the ?initiator and ?respondent variables as illustrated in the previous example. However, this transition makes use of the anonymous ? variable in the message content matching rule. Whereas ?obj must match the string it was previously bound to (i.e. "router1"), the anonymous variable may match any string (in this case, it is the string "up" that is matched) but does not cause any variable binding to occur. Having matched that transition, this message causes the conversation to enter the terminal Done state. The conversation has now ended.
Instead of the last message, however, suppose agent2 sent a refuse message with the content status(router1) . In this case, the conversation would have moved to the Refused state. Again, the names of the agents match the variables that acquired bound values earlier. However, the anonymous variable ? matches the message's content, since the anonymous variable can match any values. If this message had been sent instead, the conversation would have ended in the Refused state, as illustrated below.
