Multiple participants each manage stateful resources via operations.
How can agreement across multiple participants be achieved so that all participants see the same outcome?
- The communication channels used by loosely coupled, distributed systems usually do not provide transactional semantics at the transport level. Instead, participants can send and receive message, often reliably.
- Many distributed interactions require coordination, such that all participants should perform a specific action, or none of them. The classical example is making a travel reservation. You don't want a hotel reservation if you cannot get a flight ticket or vice versa.
- Participants may be able to respond to requests but may not want to take on the task of coordination.
- Participants may be independent service providers that do not directly interact with each other.
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:
- The Coordinator initiates the conversation by asking each participant to perform an action or to provide available resources. It waits for responses, determines whether an agreement is possible, and shares the outcome with all participants.
- The Participants respond to the action with the outcome or their availability and subsequently react to the joint outcome, either by confirming a Tentative Operation or performing a Compensating Action.
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:
- XA transactions require positive feedback from all participants. If one or more participants cannot confirm the action, all participants are instructed to cancel their Tentative Operations.
- The Coordinator may conduct multiple iterations to achieve agreement. For example, a meeting coordinator may first ask each participant for open meeting slots. If none can be found, the Coordinator may chose the most agreeable option(s) and ask unavailable participants to please enable them.
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
