11.7.2 Event-Based Gateway

11.7.3 Inclusive Gateway

Inclusive Gateways are used for modeling points of synchronization of a number of branches, not all of which are active, after which one or more alternative branches are chosen within a Choreography flow. For example, one of more branches MAY be activated upstream, in parallel, depending on the nature of goods in an order (e.g., large orders, fragile goods orders, orders belonging to pre-existing shipment contracts), and these are subsequently merged. The point of merge results in one or more risk mitigating outcomes (e.g., special insurance protection needed, special packaging needed, and different container categories needed). Inclusive Gateways are also used within an Orchestration Process see page 291.

Like Exclusive Gateways, Inclusive Gateways are used in a Choreography, but they are constrained by the lack of a central mechanism to store the data that will be used in the Condition expressions of the Gateway’s outgoing Sequence Flows. Choreographies MAY contain natural language descriptions of the Gateway’s Conditions to document the one more alternative paths of the Choreography (e.g., “special insurance protection needed,” “special packaging needed,” and different “container category needed”), but such Choreographies would be underspecified and would not be enforceable. To create an enforceable Choreography, the Gateway Conditions MUST be formal Condition Expressions. In general the following rules apply for the Expressions.

Like the enforceability of the Exclusive Gateway, the Inclusive Gateway in a Choreography requires that the data in the Expressions of the outgoing Sequence Flows of the Gateway be available to the initiators of the

Choreography Activities of outgoing Sequence Flows. This means that the initiators of these Choreography Activities should also be senders or receivers of Messages in Choreography Activities immediately preceding the Gateway. The major difference, however, is that the synchronizing behavior of the Inclusive Gateway can only be enforced through one participant. Hence, the rules for enforceability are as follows:

The data used for Gateway Conditions MUST have been in a Message that was sent prior to (upstream from) the

Gateway.

More specifically, all Participants that are directly affected by the Gateway MUST have either sent or received the Message(s) that contained the data used in the Conditions.

Furthermore, all these Participants MUST have the same understanding of the data. That is, the actual values of the data cannot selectively change after a Participant has seen a Message. Changes to data during the course of the Choreography MUST be visible to all the Participants affected by the

Gateway.

Merge: In order to enforce the synchronizing merge of the Gateway, the sender of the Choreography Activity after the Gateway MUST participate in the Gateway immediately preceding the Gateway. This ensures that the merge can be enforced. (This relies on the assumption of logical atomicity of a Choreography Activity, otherwise the rule would require that all receivers are the same so that the Gateway is enforced in the receiver’s Process only).

Split: In order to enforce the split side of the Gateway, the initiators of all Choreography Activities immediately following the Gateway MUST be the same as the common sender or receiver of Choreography Activities preceding the Gateway. The sender(s) of all the Choreography Activities after the Gateway

MUST be involved in all the Choreography Activities that immediately precede the Gateway.

Figure 11.40 shows an example of a Choreography with an Inclusive Gateway. The Gateway is enforced in the corresponding Business Processes of the Participants involved. For the merge behavior to be enforced, the initiator of Choreography Activities immediately following the Gateway participates in the Choreography Activities immediately preceding the Gateway.

M1

Participant A

Choreography

Task 1

Participant B

Participant D

Choreography

Task 1

M2

Participant B

Figure 11.40 – An example of a Choreography Inclusive Gateway configuration

Figure 11.41 – The corresponding Collaboration view of the above Choreography Inclusive Gateway configuration

Figure 11.42, a variation of Figure 11.40 above, shows an example of a Choreography illustrating the enforcement of the split behavior of the Inclusive Gateway. For the split behavior to be enforced, the initiators of Choreography Activities immediately following the Gateway and the receiver of Choreography Activities immediately preceding the Gateway are the same Participant (i.e., A).

Figure 11.42 – An example of a Choreography Inclusive Gateway configuration

Figure 11.44 – Another example of a Choreography Inclusive Gateway configuration

Figure 11.45 – The corresponding Collaboration view of the above Choreography Inclusive Gateway configuration