---
title: "11.1 General"
chapter: "11 Choreography"
source: "OMG BPMN 2.0.2 — formal/2013-12-09"
pages: "315-316"
---
> 11 Choreography · páginas 315-316 · [índice](../README.md)
## 11.1 General
**NOTE:** The content of this clause is REQUIRED for **BPMN Choreography Modeling Conformance** or for **BPMN Complete Conformance**. However, this clause is NOT REQUIRED for **BPMN Process Modeling Conformance**, **BPMN Process Execution Conformance**, or **BPMN BPEL Process Execution Conformance**. For more information about **BPMN** conformance types, see page 1. A **Choreography** is a type of process, but differs in purpose and behavior from a standard **BPMN Process**. A standard **Process**, or an *Orchestration* **Process** (see page 143), is more familiar to most process modelers and defines the flow of **Activities** of a specific PartnerEntity or organization. In contrast, **Choreography** formalizes the way business *Participants* coordinate their interactions. The focus is not on orchestrations of the work performed *within* these *Participants*, but rather on the exchange of information (**Messages**) *between* these *Participants*. Another way to look at Choreography is to view it as a type of business contract between two or more organizations. This entails **Message** (document) exchanges in an orderly fashion: e.g., first a retailer sends a purchase order request to a supplier; next the supplier either confirms or rejects intention to investigate the order; then supplier proceeds to investigate stock for line-items and seeks outside suppliers if necessary; accordingly the supplier sends a confirmation or rejection back; during this period the retailer can send requests to vary the order, etc. **Message** exchanges between partners go beyond simple request-response interactions into multi-cast, contingent requests, competing receives, streaming, and other service interaction patterns (REF for SIP). Moreover, they cluster around distinct scenarios such as: creation of sales orders; assignment of carriers of shipments involving different sales orders; managing the “red tape” of crossing customs and quarantine; processing payment and investigating exceptions. A **Choreography** is a definition of expected behavior, basically a procedural business contract, between interacting *Participants* (see page 111 for more information on *Participants*). It brings **Message** exchanges and their logical relation as **Conversations** into view. This allows partners to plan their **Business Processes** for inter-operation without introducing conflicts. An example of a conflict could arise if a retailer was allowed to send a variation on a purchase order immediately after sending the initial request. The **Message** exchange sequences in **Choreography** models need to be reflected in the orchestration **Processes** of participants. A **Choreography** model makes it possible to derive the **Process** interfaces of each partner’s **Process** (REF: Decker & Weske, 2007). To leverage the familiarity of flow charting types of **Process** models, **BPMN Choreographies** also have “activities” that are ordered by **Sequence Flows**. These “activities” consist of one or more *interactions* between *Participants*. These *interactions* are often described as being *message exchange patterns* (MEPs). A MEP is the atomic unit (“**Activity**”) of a **Choreography**. Some MEPs involve a single **Message** (e.g., a “Customer” requests an “Order” from a “Supplier”). Other MEPs will involve two **Messages** in a request and response format (e.g., a “Supplier” request a “Credit Rating” from a “Financial Institution,” who then returns the “Credit Rating” to the “Supplier”). There can be even more complex MEPs that involve error **Messages**, for example. A single MEP can be defined as a **BPMN Choreography Task** (see page 323). Thus, a **Choreography** defines the order in which **Choreography Tasks** occur. **Sub-Choreographies** allow the composition/decomposition of
**Choreographies** are designed in **BPMN** to allow stand-alone, scalable models of these *Participant interactions*. However, since **BPMN** provides other **Business Process** modeling views, **Choreographies** are designed to fit within **BPMN Collaboration** diagrams to display the relationship between the **Choreography** and *Orchestration* **Processes** thus expanding **BPMN 1.2** capabilities (see page 107 for more information on **Collaborations**, and page 361 for **Choreographies** within **Collaborations**). Figure 11.1 displays the metamodel of the key **BPMN** elements that contribute to **Choreography** modeling. The sub clauses of this clause will describe the characteristics of these elements and how they are used in a **Choreography**.
*Figure 11.1 – The Choreography metamodel* (p. 316)
The **Choreography** element inherits the attributes and model associations of **Collaboration** (see Table 9.1) and of FlowElementContainer (see Table 8.45), but does not have any additional attributes or model associations. **NOTE:** The **Collaboration** attribute choreographyRef is not applicable to **Choreography**.