Pattern 4 (Exclusive Choice)

FLASH animation of Exclusive Choice pattern


The divergence of a branch into two or more branches such that when the incoming branch is enabled, the thread of control is immediately passed to precisely one of the outgoing branches based on a mechanism that can select one of the outgoing branches.


XOR-split, exclusive OR-split, conditional routing, switch, decision, case statement.


Depending on the volume of earth to be moved, either the dispatch-backhoe, despatch-bobcat or despatch-D9-excavator task is initiated to complete the job.

After the review election task is completed, either the declare results or the recount votes task is undertaken.


The Exclusive Choice pattern allows the thread of control to be directed to a specific (subsequent) task depending on the outcome of a preceding task, the values of elements of specific data elements in the process, the results of an expression evaluation or some other form of programmatic selection mechanism. The routing decision is made dynamically allowing it to be deferred to the latest possible moment at runtime.


The behaviour of the Exclusive Choice pattern is illustrated by the CP-net model in Figure 4. Depending on the results of the cond expression, the thread of control is either routed to task B or C.

Figure 4: Exclusive choice pattern


There is one context condition associated with this pattern: the mechanism that evaluates the Exclusive Choice is able to access any required data elements or other necessary resources when determining which of the outgoing branches the thread of control should be routed to.


Similar to the Parallel Split and Synchronization patterns, the Exclusive Choice pattern can either be represented explicitly via a specific construct or implicitly via disjoint conditions on the outgoing control-flow edges of an task. Staffware, SAP Workflow, XPDL, EPCs and BPMN provide explicit XOR-split constructs. In the case of Staffware, it is a binary construct whereas other offerings support multiple outgoing arcs. BPMN and XPDL provide for multiple outgoing edges as well as a default arc. Each edge (other than the default arc) has a condition associated with it and there is also the potential for defining the evaluation sequence but only one can evaluate to true at runtime. There is no provision for managing the situation where no default is specified and none of the branch conditions evaluates to true nor where more than one branch condition evaluates to true (simultaneously) and no evaluation sequence is specified. SAP Workflow provides three distinct means of implementing this pattern: (1) based on the evaluation of a Boolean expression one of two possible branches chosen, (2) one of multiple possible branches is chosen based on the value of a specific data element (each branch has a nominated set of values which allow it to be selected and each possible value is assigned to exactly one branch) and (3) based on the outcome of a preceding task, a specific branch is chosen (a unique branch associated with each possible outcome). UML 2.0 ADs also provide a dedicated split construct although it is left to the auspices of the designer to ensure that the conditions on outgoing edges are disjoint (e.g. the same construct can be used for OR-splits as well). Likewise EPCs support the pattern in a similar fashion. The other offerings examined - WebSphere MQ, FLOWer, COSA, iPlanet and BPEL - represent the pattern implicity, typically via conditions on the outgoing control-flow edges from a task which must be specified in such a way that they are disjoint.


One of the difficulties associated with this pattern is ensuring that precisely one outgoing arc is triggered when the Exclusive Choice is enabled.


The inclusion of default outgoing arcs on XOR-split constructs is an increasingly common means of ensuring that an outgoing arc is triggered (and hence the thread of control continues in the process instance) when the XOR-split is enabled and none of the conditions on outgoing branches evaluate to true. An associated issue is ensuring that no more than one branch is triggered. There are two possible approaches to dealing with this issue where more than one of the arc conditions will potentially evaluate to true. The first of these is to randomly select one of these arcs and allow it to proceed whilst ensuring that none of the other outgoing arcs are enabled. The second option, which is more practical in form, is to assign an evaluation sequence to the outgoing arcs which defines the order in which arc conditions will be evaluated. The means of determining which arc is triggered then becomes one of evaluating the arc conditions in sequential order until one evaluates to true. The arc is then triggered and the evaluation stops (i.e. no further arcs are triggered). In the event that none evaluate to true, then the default arc is triggered.

Evaluation Criteria

Full support for this pattern is demonstrated by any offering which provides a construct which satisfies the description when used in a context satisfying the context assumption.

Product Evaluation

To achieve a + rating (direct support) or a +/- rating (partial support) the product should satisfy the corresponding evaluation criterion of the pattern. Otherwise a - rating (no support) is assigned.





Staffware 10 + Supported through the condition construct modeling a binary decision. The decision is evaluated using a Boolean function and has only one or two outgoing arcs.
Websphere MQ 3.4 + Supported through the use of exclusive conditions on transitions.
FLOWer 3.51 + Supported through the plan type system decision (based on data) and the plan type user decision (based on a user selection on the wavefront). Moreover, it is possible to specify guards on the arcs in the static, dynamic and sequential subplans. When a guard evaluates to true the subsequent activity is enabled otherwise it is skipped (status "refused").
COSA 5.1 + Supported by multiple outgoing arcs from an activity. All of the arcs have disjoint transition conditions specified.
iPlanet 3.0 + Supported by using multiple outgoing routers from an activity with disjoint router enabling conditions.
SAP Workflow 4.6c + Directly supported through three constructs: (1) the condition step type, (2) the multiple condition step type, (3) a choice directly following an activity. The condition step type can only be used for binary conditions based on a single Boolean expression. The multiple condition step type can be used to select from more than two alternatives. There is default branch that is selected if none of the other branches can be taken. The choice directly following an activity is similar to the multiple condition step type but is not shown graphically in the workflow model. As for the parallel split and synchronization constructs, each split needs to correspond to a join, i.e. again only block structured models are supported.
FileNet 3.5 + Directly supported by a step with multiple outgoing routes (take route of the first true condition). Each of the routes must have a condition associated with it, all defined conditions must be exclusive. If several conditions are satisfied, the first specified in the lexical order is selected.
BPEL 1.1 + Supported by <switch> or links within the <flow> construct.
Websphere Integration Developer 6.0 + Supported by the <switch> activity or links within a <flow> activity.
Oracle BPEL 10.1.2 + Supported by the <switch> construct or links within a <flow> construct.
BPMN 1.0 + Supported by XOR-split gateway.
XPDL 2.0 + Supported by the XOR-split construct.
UML ADs 2.0 + Supported by the DecisionNode construct where the guard conditions on the outgoing edges are exclusive.
EPC (implemented by ARIS toolset 6.2) + Supported by the XOR-split connector. However, no language is given to describe the conditions for taking a branch.
jBPM 3.1.4 + jBPM implements exclusive choice through the Decision construct
OpenWFE 1.7.3 + OpenWFE implements exclusive choice through the <case> construct, within which a number of condition-action pairs are defined. The first condition to evaluate to true will trigger its pair-action.
Enhydra Shark 2 +

Enhydra Shark supports exclusive choice through
i) an activity/a routing activity node with a transition restriction <Split Type = "XOR"> specifying the transitions for the choice. The first transition with condition evaluating to true (or the first transition without any condition) is taken. (Shark, Wil)
ii) an activity/a routing activity node with a transition restriction <Split Type = "AND"> specifying the parallel transition leaving it. These transitions have mutually exclusive conditions defined on them and the one evaluating to true will continue the flow. (Wil)