The Choreography Model provides a global perspective over the interactions that can occur between a collection of participants in an architecture in order to achieve a common goal. It captures the interactions in which the participants engage to achieve this goal and the dependencies between these interactions.

The choreography model uses the participants, scenarios, and message types defined earlier and defines the business process as a series of message exchanges between these participants. It defines the dynamic "behavioural type" of the architecture. It provides the 'type' definition that encompasses and aggregates the various paths expressed within the individual scenarios. As such, it will only be considered valid, and therefore meeting the overall business requirements, when it can successfully be verified against the previously defined scenarios. Where a scenario has been defined to express an invalid path through the business process, validation of this scenario against the choreography should correctly highlight the invalid interaction(s), to demonstrate that the choreography model does not inadvertently support invalid paths.

The choreography expresses the progression of a collaboration. Initially, the collaboration is established between participants, then work is performed within it and finally it completes either normally or abnormally. The choreography flow can model sequences, parallel activities, and choices (branching). It shows the interactions between participants as a series of message exchanges.

The following choreography shows the global behavior for the purchasing example expressed using the pi4soa choreography modeling tool.

Once the choreography has been defined, it can be validated against the scenarios using scenario validation. The following shows the simulation of an invalid scenario (BuyConfirmed cannot follow  CreditCheckInvalid) against this choreography, to demonstrate how the simulation can be used to highlight inconsistencies.

In these situations, either the scenario is incorrect and not consistent with the overall choreography that has been defined to satisfy the other business requirements, or the choreography has not correctly catered for the scenario. In either case, the architect may need to consult the business analyst and user to resolve the issue.

TODO: Consider how policies should be defined in the choreography – and/or in the service contracts/design – and then enforced at runtime (via the monitor?)

Details

Defines the dynamic behaviour associated with the collaboration between the participants.

Repo: Store the choreography model. Establish dependency against the collaboration model (which indirectly has dependencies on scenarios/message examples/schema).

Input: Set of scenarios.

Output: Choreography model. Architectural documentation.