11.5.3 Call Choreography

A Call Choreography identifies a point in the Process where a global Choreography or a Global Choreography Task is used. The Call Choreography acts as a place holder for the inclusion of the Choreography element it is calling. This pre-defined called Choreography element becomes a part of the definition of the parent Choreography.

A Call Choreography object shares the same shape as the Choreography Task and Sub-Choreography, which is a rectangle that has rounded corners, two or more Participant Bands, and an Activity Name Band. However, the target of what the Choreography Activity calls will determine the details of its shape.

If the Call Choreography calls a Global Choreography Task, then the shape will be the same as a Choreography Task, but the boundary of the shape MUST have a thick line (see Figure 11.24).

If the Call Choreography calls a Choreography, then there are two options:

The details of the called Choreography can be hidden and the shape will be the same as a collapsed SubChoreography, but the boundary of the shape MUST have a thick line (see Figure 11.25).

The details of the called Choreography can be shown and the shape will be the same as an expanded SubChoreography, but the boundary of the shape MUST have a thick line (see Figure 11.26).

Figure 11.24 – A Call Choreography calling a Global Choreography Task

Figure 11.25 – A Call Choreography calling a Choreography (Collapsed)

Figure 11.26 – A Call Choreography calling a Choreography (expanded)

Figure 11.27– The Call Choreography class diagram

The Call Choreography element inherits the attributes and model associations of ChoreographyActivity (see Figure 11.27 and Table 11.1). Table 11.4 presents the additional model associations of the Call Choreography element.

Table 11.4 – Call Choreography Model Associations

11.5.4 Global Choreography Task

A GlobalChoreographyTask is a reusable, atomic Choreography Task definition that can be called from within any Choreography by a Call Choreography.

The GlobalChoreographyTask element inherits the attributes and model associations of Collaboration (see Table 9.1), through its relationship to Choreography. Table 11.5 presents the additional model associations of the

GlobalChoreographyTask element.

Table 11.5 – Global Choreography Task Model Associations

A GlobalChoreographyTask is a restricted type of Choreography, it is an “empty” Choreography. A GlobalChoreographyTask MUST NOT contain any Flow Elements.

Since a GlobalChoreographyTask does not have any Flow Elements, it does not require

MessageFlowAssocations, ParticipantAssocations, ConversationAssocations, or Artifacts. It is basically a set of Participants and Message Flows intended for reuse.

11.5.5 Looping Activities

Both Sub-Choreographies can have standard loops and multi-instances. Examples of Choreography Activities with the appropriate markers can be seen in Figure 11.12 and Figure 11.22.

11.5.6 The Sequencing of Activities

There are constraints on how Choreography Activities can be sequenced (through Sequence Flows) in a Choreography. These constraints are due to the limited visibility of the Participants, which only know of the progress of the Choreography by the Messages that occur. When a Participant sends or receives a Message, then that

Participant knows exactly how far the Choreography has progressed. This means that the ordering of Choreography Activities need to take into account when the Participants send or receive Messages so that they Participants are NOT REQUIRED to guess about when it is their turn to send a Message.

The basic rule of Choreography Activity sequencing is this:

The Initiator of a Choreography Activity MUST have been involved (as Initiator or Receiver) in the previous

Choreography Activity.

Of course, the first Choreography Activity in a Choreography does not have this constraint.

Figure 11.28 shows a sequence of two Choreography Activities that follow this constraint. “Participant B” is the Initiator of “Choreography Task 2” after being the Receiver in “Choreography Task 1.” While there is no requirement that “Participant B” sends the Message immediately, since there can be internal work that the Participant needs to do prior to the Message. But in this situation there is no ambiguity that “Participant B” will be the Initiator of the next Choreography Task. “Participant C” does not know exactly when the Message will arrive from “Participant B,” but “Participant C” knows that one will arrive and there are not any additional requirements on the Participant until the Message arrives.

The Initia tor of a

Chore ograp hy Task must be involved in the previous Activity

Figure 11.28 – A valid sequence of Choreography Activities

Naturally, the sequence of Choreography Activities shown in Figure 11.28, above can be expanded into a Collaboration diagram to show how the sequence can be enforced. Figure 11.29 shows the corresponding Collaboration. The diagram shows how the Activities within the individual Pools fit with the design of the

Choreography.

Figure 11.29 – The corresponding Collaboration for a valid Choreography sequence

When determining a valid sequence of Choreography Tasks, it is important to consider the type of Choreography Tasks that are being used. A single Choreography Task can be used for one or two Messages. Most of the time there will be one or two Messages for a Choreography Task. Figure 11.30 shows a sequence of Choreography Tasks, the first one being a two-way interaction, where the initiator sends a Message and gets a response from the other

Participant.

Figure 11.30 – A valid sequence of Choreography Activities with a two-way Activity

Figure 11.31 shows the corresponding Collaboration and how the two Choreography Tasks are reflected in the

Processes within the Pools. The Choreography Task that has two Messages is reflected by three Process Tasks. Usually in these cases, the initiating Participant will use a single Activity to handle both the sending and receiving of the Messages. A BPMN Service Task can be used for this purpose and these types of Tasks are often referred to as “request-response” Tasks for Choreography modelers.

Figure 11.31 – The corresponding Collaboration for a valid Choreography sequence with a two-way Activity

Figure 11.32 shows how a sequence of Choreography Activities can be designed that would be invalid in the sense that an Initiating Participant would not know when the appropriate time would be to send a Message. In this example, “Participant A” is scheduled to send a Message to “Participant C” after “Participant B” sends a Message to “Participant C.” However, “Participant A” will not know when the Message from “Participant B” has been sent. So, there is no way to enforce the sequence that is modeled in the Choreography.

The Initiator of a

C horeography Task m ust be involved in the previous Activity

Figure 11.32 – An invalid sequence of Choreography Activities