Pattern 4 (Exclusive Choice)

FLASH animation of Exclusive Choice pattern

Description

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.

Synonyms

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

Examples

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.

Motivation

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.

Overview

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

Context

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.

Implementation

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.

Issues

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

Solutions

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.