Enterprise Integration Patterns
Conversation Patterns
Conversation Patterns
Coordinated AgreementConversation Patterns » Ensuring Consistency

Multiple participants each manage stateful resources via operations.

How can agreement across multiple participants be achieved so that all participants see the same outcome?

A separate coordinator collects responses from each participant, determines an agreeable outcome, if possible, and shares it with all participants.

The Coordinated Agreement conversation involves the following participants:

Conversations using Coordinated Agreement are somewhat pessimistic because they optimize the "unhappy path" by explicitly verifying the correctness of the outcome with each participant. Valuing certainty assures an agreeable outcome (as long as one is possible) but creates complexity in the conversation with 3 message exchanges per participant. This approach is useful if errors are common or it is difficult to find agreement.

Coordinated Agreement generally assumes that the Coordinator knows all participants and therefore knows how many responses to expect. If the number and identity of participants is unknown, a Scatter-Gather can be used, which involves a Publish-Subscribe Channel to reach all participants. As the number of expected responses is unknown, the Coordinator must use Aggregator strategies to derive a result from a variable number of responses.

The Coordinator may initiate the conversation directly ro do so on behalf of an Initiator.

The Coordinator can pursue a number of different strategies depending on the business problem:

Error States

Missing Participant Responses

If the Coordinator knows the number and identity of all participants it can determine whether all responses were received. If a response is missing, it can employ Request-Response with Retry to elicit a response. If the response is not received the Coordinator should apply a business policy to determine the desired outcome. For example, in a business setting it may be acceptable to ignore a participant's availability for a meeting if the person never replied to the request for available times.

Example: Scheduling a Meeting

In case of a meeting the "resource" being allocated by the participants is time. A coordinator requests availability from each participant. Participants may already block the time at this point or mark it as "tentative"" as a Tentative Operation. Once the coordinator has that information, he or she picks a suitable time based on one of the strategies mentioned above, for example, a majority decision. She then informs the participants, who book the time, e.g. by confirming the Tentative Operation.

If no agreement can be reached the meeting may be canceled and participants can release any allocated time, either by explicit cancellation (Compensating Action) or by letting the Tentative Operation cancel out.

Many meeting systems use a tri-state system for time slot allocation: free, tentative, and busy to support Tentative Operations without pessimistic resource allocation.

Example: Finding a Place to Eat

Example: XA Transaction

Related patterns: Aggregator, Scatter-Gather, Compensating Action, Publish-Subscribe Channel, Request-Response with Retry, Tentative Operation

Creative Commons Attribution License

You can reuse the following elements under the Creative Commons Attribution license: pattern icon, pattern name, problem and solution statements (in bold), and the sketch. Other portions are protected by copyright.