The concurrent client problem
The introduction of states and transitions might suggest that it's pretty easy to design the protocol and that the agent described by this protocol will always follow the same tracks. However, there is a problem, as the following figure suggests.
Two clients concurrently sending
The transition graph in the middle explains that this agent will accept a message a and then b. You can see two other equal graphs above and below; these are the communication partners. Each one is compatible to the middle one, that is, the communication between one of them and the agent in the middle will work as expected. However, when two of them concurrently start to communicate, as shown here, the protocol of each communication act will be spoilt. Having received message a, the agent cannot accept another a.
But there is an easy way out of this problem: The agent presenting a transition graph is obliged to realize this graph regardless of any other communication acts that could be running in parallel. To achieve this, the agent somehow has to make sure that it does not mix the messages of different communication acts. This can be solved by introducing contexts.
What is a context?
Informally speaking, a context ensures that the sequence of interactions respects all state transition diagrams of the involved partners. Although it seems different, contexts are not global to all involved partners. This is described in the next figure.
There are no global contexts
Agent B expects two consecutive a messages. For example, it expects at first a name and then a password, both represented as Strings. Agent A provides these data. Here, one would say that we have one context for agent A and B, described by the respective transition graphs.
Take a look at agent C. And now imagine that agent B requests two integer values, probably standing for the annual salary of different persons. C delivers those values, but after each sending, the work of C is done. In that case, there is not a single common context. Obviously the context depends on the respective transition graph. If one views the transition graph as a type, an instance would be a set of possible interactions which are described by this type.
And this is a context.
A context is a instance of the state transition type.
The most important issue in this view is that each instance must not interfere with any other instance. That is, the context must contain certain data which are unique to this context. The actual flow of interactions declared by the transition graph contains the following information:
(Recall that the primary peer is the default communication partner. It is the one which is not specially marked to be sender or receiver in the state transition diagrams.)
This was the guideline for the creation of the AMETAS Context API. That means that a when a context is designed to be an instance of some class, it must contain these data as instance variables. If this is ensured, the agent