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 Requested state 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 ?docid variable taking on a new value until it is redefined again. This takes the conversation back to the Requested state.
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 the End state, whereby the conversation terminates having reached a terminal state.