ACRE is designed so that agents will use pre-designed interaction protocols for their communication. A protocol is the description of the messages that agents are allowed to send and in what order. Whenever two agents decide to make use of a protocol, the messages they send are considered to be part of a conversation. Each conversation should follow the rules set out by a defined protocol.

Protocols are defined as states and transitions. Each transition contains some rules that a message must match against so as to be a legal message. The state of a conversation will change every time a legal message is sent by one agent to another. Visually, each state is shown as a circle with a name in it. Transitions are shown as arrows with the message rules attached. This can be seen below.

Every protocol has one start state associated with it. This is the state a conversation is in at the very beginning, before any message have been sent. Visually, a start state is shown by an arrow pointing to it that doesn’t come from another state. An end state shows that the conversation has come to an end and that no more messages should be sent. This is shown by a double-line circle around the state. A protocol can have any number of end states.

The method by which a conversation follows a protocol is illustrated in the following examples.

Example 1: A Simple Request/Response Protocol

Below is an Agent UML representation of a simple Request/Response protocol. This is designed to allow one agent (the initiator) to ask for information from another (the respondent) on a one-off basis. The initial message is required to use the request performative, with the response using inform.

This protocol would be represented in ACRE by the diagram below. This protocol consists of three states:Start at the beginning of the conversation when no messages have yet been sent, Requested after the initial request message has been sent by the Initiator agent, and End after the Respondent has replied with the required information. The Start state is highlighted in red as this is the initial state of any conversation that is to follow the Request/Response protocol.

A conversation moves between states by using transitions: these describe details about the message that should be sent to advance the conversation. In this protocol, each of the transitions are labelled with these message details. Note that the performative is set: request for the first message and inform for the response.

The participants in the protocol, however, are indicated by variables that are matched against the names of the agents. In this example, both the ?initiator and ?respondent variables are used to refer to the names of the agents participating in the conversation. This means that the agent that sends the initial message (at which point its name is bound to the ?initiator variable) must be the recipient of the response that follows.

Given this protocol, suppose a request message is sent by an agent named agent1 to an agent namedagent2. This message matches the first transition and the conversation moves to the Requested state, as shown below. Note that the transition from Requested to End is now shown differently. Because agent1 sent the first message, further uses of the ?initiator variable must also refer to agent1. This ensures that agents maintain the same role throughout the conversation.

The text in the middle of the Requested state shows the current variable bindings associated with the conversation: each of the variables that has been matched against some previous value is bound to that value.

Next, suppose agent2 replies with an inform message. This matches the next transition as the message has the same performative and is sent by agent2 to agent1, as required by the transition.

In this protocol, the End state is a terminal state (i.e. once the conversation reaches that state there are no more transitions that could be triggered by further messages). The conversation has now come to an end.

Example 2: Content and Anonymous Variables: Status Protocol

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). Thestatus(…) 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 contentstatus(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.

Example 3: Rebinding Variables: Process Documents Protocol

This example introduces the concept of a mutable variable. In the previous examples, once a variable had been bound to a value, it would maintain that value for the duration of the conversation. However, it is sometimes desirable for a variable to take on a new value at particular stages in the conversation.

Below is an AUML specification of a protocol that is designed to allow one agent to ask another to process some documents. Initially, one agent (called the initiator) contacts the other (the respondent) to tell it that it is ready to process documents. The respondent replies to request that the initiator process a particular document identified by an identifier. At this point, the initiator has the option of processing the document as requested or refusing to process it. Refusal will end the conversation, whereas informing the respondent that the document has been processed causes the conversation to enter a loop, and the respondent can now request that another document be processed.

The above AUML diagram is represented as an ACRE protocol below. Note in this case that in the transition from the Waiting state to the Requested state, the ??docid variable is shown with two ?? signs. This indicates that the variable is being used in a mutable context, meaning that it in this transition it is always free to take on a new value. Thus it doesn’t matter what processing has previously occurred: the respondent can always request that a new document be processed.

This is in contrast to the same variable’s usage in the transition back from Requested to Waiting. Here, it is shown with only a single ?, meaning that it must match the value that was previously bound to it. This can be illustrated by showing the consequences of exchanging some messages.

The first message sent is a simple inform message from the initiator agent (named processor) to the respondent (named manager). This causes the conversation to enter the Waiting state. As before, the variables representing the names of the participating agents are bound to the actual names.

Next, the manager sends a request message with the content process(doc123), bringing the conversation to the Requested state. This value is bound to the ?docid variable, so the transitions out of the Requestedstate have that value applied to it.

The processor agent can only advance the conversation by either declaring that doc124 has been processed (bringing the conversation back to the Waiting state), or by refusing to process doc123. Referring to any other document will not progress the conversation, as the transition would not match.

The processor agent replies with an inform message to indicate that doc123 has been successfully processed (the content is processed(doc123)). This matches the transition back to the Waiting state. It is here that the importance of having variables in mutable context becomes apparent. Had the variable in the transition from Waiting to Requested been written as ?docid (as in the previous examples), then only a request to process document doc123 would advance the conversation. However, that document has already been processed, so the manager wishes to have another document processed instead. The mutable context now means that a request message to process(doc1024) will still match the transition, with the ?docidvariable taking on a new value until it is redefined again. This takes the conversation back to the Requestedstate.

At this point, the processor agent may again process the requested document to continue the loop, allowing the manager to ask for a new document to be processed. Eventually, the processor may exit the conversation by refusing to process the last document that was requested. This would cause the conversation to enter theEnd state, whereby the conversation terminates having reached a terminal state.