Скачиваний:
25
Добавлен:
28.01.2021
Размер:
7.15 Mб
Скачать

11 Choreography

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.

Business Process Model and Notation (BPMN), v2.0.2

315

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

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.

316

Business Process Model and Notation (BPMN), v2.0.2

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.

 

The bands display the names of the

 

Participants (Roles/Entities)

Message

Additional Participants can be added on

additional bands (for Sub-Processes)

I want to see

I feel sick

 

I need my

the Doctor

 

medicine

 

 

Patient

Patient

Patient

Patient

Doctor

Handle

Handle

Handle

Request

Symptoms

Prescription

Medicine

Dr. Office

Dr. Office

Dr. Office

Dr. Office

Go see the Doctor

Pickup your medicine, then leave

The Message is shaded, so it is not the initiating Message

Here is your medicine

The unshaded Participant is the initiator of the Activity

Figure 11.2 – An example of a Choreography

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

Business Process Model and Notation (BPMN), v2.0.2

317

number of Messages of the same type being sent. For example, a Messages can be sent from the Retailer to the Supplier, indicated the actual elements for sending/receiving inside the multi-instances

number of Retailer Order and Delivery Variations by respective multi-instances constructs (for brevity, construct have been omitted).

Shipper

Receive

Send

Message

Message

Consignee

Receive

Send

Receive

Send

Message

Message

Message

Message

 

 

 

 

 

Shipment

 

Proposed

Delivery

Proposed

 

Confirma-

 

 

Plan

 

 

 

 

 

Plan

Plan & Cost

 

tion

 

 

Variation

 

Plan & Cost

 

 

 

 

Variation

Variation

 

Received

 

 

 

 

Variation

 

 

 

 

 

 

 

 

 

 

 

 

 

Send

Receive

 

 

 

 

 

 

 

 

Message

Message

 

 

 

 

 

Supplier

Send

Receive

Receive

 

 

Send

Receive

Receive

Send

Message

Message

Message

 

 

Message

Message

Message

Message

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Send

Receive

 

 

 

 

 

 

 

 

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

 

Retailer

Receive

Send

Send

Receive

Send

Send

Receive

Send

Receive

Message

Message

Message

Message

Message

Message

Message

Message

Message

 

 

 

 

 

 

 

 

 

Figure 11.3 – A Collaboration diagram logistics example

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.

318

Business Process Model and Notation (BPMN), v2.0.2