---
title: "11.2 Basic Choreography Concepts"
chapter: "11 Choreography"
source: "OMG BPMN 2.0.2 — formal/2013-12-09"
pages: "317-319"
---
> 11 Choreography · páginas 317-319 · [índice](../README.md)
## 11.2 Basic Choreography Concepts
A key to understanding **Choreographies** and how they are used in **BPMN** is their relationship to **Pools** (see page 111 for more information on **Pools**). **Choreographies** exist outside of or in between **Pools**. A **Process**, within a **Pool**, represents the work of a specific PartnerEntity (e.g., “FedEx”), often substituted by a PartnerRole (e.g., “Shipper”) when a PartnerEntity is not identified and can be decided later. The PartnerEntity/PartnerRole is called a *Participant* in **BPMN**. **Pools** are the graphical representation of *Participants*. A **Choreography**, on the other hand, is a different kind of process. A **Choreography** defines the sequence of *interactions* between *Participants*. Thus, a **Choreography** does not exist in a single **Pool**, it is not the purview of a single *Participant*. Each step in the **Choreography** involves two or more *Participants* (these steps are called **Choreography Activities**, see below). This means that the **Choreography**, in **BPMN** terms, is defined outside of any particular **Pool**. The key question that needs to be continually asked during the development of a **Choreography** is “what information do the *Participants* in the **Choreography** have?” Basically, each *Participant* can only understand the status of the **Choreography** through observable behavior of the other *Participants*; which are the **Messages** that have been sent and received. If there are only two *Participants* in the **Choreography**, then it is very simple; both *Participants* will be aware of who is responsible for sending the next **Message**. However, if there are more than two *Participants*, then the modeler needs to be careful to sequence the **Choreography Activities** in such a way that the *Participants* know when they are responsible for initiating the *interactions*. Figure 11.2 presents a sample **Choreography**. The details of **Choreography** behavior and elements will be described in the sub clause below.
*Figure 11.2 – An example of a Choreography* (p. 317)
To illustrate the correspondence between **Collaboration** and **Choreography**, consider an example from logistics. Figure 11.3 shows a **Collaboration** where the **Pools** are expanded to reveal orchestration details per participant (for *Shipper, Retailer* etc.). **Message Flows** connect the elements in the different **Pools** related to different participants, indicating **Message** exchanges. For example, a *Planned Order Variations* **Message** is sent by the *Supplier* to the *Retailer*; the corresponding send and receive have been modeled using regular **BPMN** messaging **Activities**. Also, a number of **Messages** of the same type being sent. For example, a number of *Retailer Order and Delivery Variations* **Messages** can be sent from the *Retailer* to the *Supplier*, indicated by respective *multi-instances* constructs (for brevity, the actual elements for sending/receiving inside the *multi-instances* construct have been omitted).
per Receive Send neig Receive Send Receive Send hip Message Message Message Message Message Message
Variation Plan & Cost Variation Variation Received
lie Send Receive Receive Send Receive Receive Send upp Message Message Message Message Message Message Message
Planned Order & Deliver Updated PO PO & Confirma- PO & Finalized Order Delivery Checkpoint & Delivery Delivery tion of Delivery Schedule Variations Variations Request Schedule Modifications Schedule Schedule
ile Receive Send Send Receive Send Send Receive Send Receive ta Message Message Message Message Message Message Message Message Message
*Figure 11.3 – A Collaboration diagram logistics example* (p. 318)
The scenario modeled in Figure 11.3 entails shipment planning for the next supply replenishment variations: the *Supplier* confirms all previously accepted variations for delivery with the *Retailer*; the *Retailer* sends back a number of further possible variations; the *Supplier* requests to the *Shipper* and *Consignee* possible changes in delivery; accordingly, the *Retailer* interacts with the *Consignee* and *Supplier* for final confirmations. A problem with model interconnections for complex **Choreographies** is that they are vulnerable to errors. Interconnections might not be sequenced correctly, since the logic of **Message** exchanges is considered from each partner at a time. This in turn leads to deadlocks. For example, consider the PartnerRole of *Retailer* in Figure 11.3 and assume that, by error, the order of *Confirmation Delivery Schedule* and *Retailer Confirmation received* (far right) were swapped. This would result in a deadlock since both *Retailer* and *Consignee* would wait for the other to send a **Message**. Deadlocks in general, however, are not that obvious and might be difficult to recognize in a **Collaboration**. Figure 11.4 shows the **Choreography** corresponding to the **Collaboration** of Figure 11.3.
Supplier Supplier Consignee Consignee Supplier Supplier Finalized PO Accept PO and Retailer Confirmation of Update PO and Delivery Delivery Confirmation Delivery PO and Delivery and Delivery Retailer Retailer Retailer Retailer Retailer Retailer
*Figure 11.4 – The corresponding Choreography diagram logistics example* (p. 319)