Pattern 6 (Multi-Choice)

FLASH animation of Multi-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 one or more of the outgoing branches based on a mechanism that selects one or more outgoing branches.

Synonyms

Conditional routing, selection, OR-split, multiple choice.

Examples

Depending on the nature of the emergency call, one or more of the despatch-police, despatch-fire-engine and despatch-ambulance tasks is immediately initiated.

Motivation

The Multi-Choice pattern provides the ability for the thread of execution to be diverged into several concurrent threads on a selective basis. The decision as to whether to pass the thread of execution to a specific branch is made at runtime. It can be based on a variety of factors including the outcome of a preceding task, the values of elements of specific data elements in the process, the results of evaluating an expression associated with the outgoing branch or some other form of programmatic selection mechanism. This pattern is essentially an analogue of the Exclusive Choice pattern (WCP4) in which multiple outgoing branches can be enabled.

Overview

The operation of the Multi-Choice pattern is illustrated in Figure 6. After task A has been triggered, the thread of control can be passed to one or both of the following branches depending on the evaluation of the conditions associated with each of them.

Figure 6: Multi-choice pattern

Context

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

Implementation

As with other branching and merging constructs, the Multi-Choice pattern can either be represented implicitly or explicitly. WebSphere MQ captures it implicitly via (non-disjoint) conditions on outgoing arcs from a process or block construct, COSA and iPlanet do much the same via overlapping conditions on outgoing arcs from tasks and outgoing routers respectively. Both COSA and iPlanet allow for relatively complex expressions to be specified for these outgoing branches and iPlanet also allows for procedural elements to form part of these conditions. The modelling and business process execution languages examined tend to favour the use of explicit constructs for representing the pattern: BPEL via conditional links within the <flow> construct, UML 2.0 ADs via the ForkNode with guards conditions on the outgoing arcs and EPCs via textual notations to the OR-split construct. BPMN and XPDL provides three alternative representations including the use of an implicit split with conditions on the arcs, an OR-split or a complex gateway.

Issues

Two issues have been identified with the use of this pattern. First, as with the Exclusive Choice, an issue that also arises with the use of this pattern is ensuring that at least one outgoing branch is selected from the various options available. If this is not the case, then there is the potential for the process to stall. Second, where an offering does not support the Multi-Choice construct directly, the question arises as to whether there are any indirect means of achieving the same behaviour.

Solutions

With respect to the first issue, the general solution to this issue is to enforce the use of a default outgoing arc from a Multi-Choice construct which is enabled if none of the conditions on the other outgoing arcs evaluate to true at runtime. For the second issue, a work-around that can be used to support the pattern in most offerings is based on the use of an AND-split immediately followed by an (binary) XOR-split in each subsequent branch. Another is the use of an XOR-split with an outgoing branch for each possible task combination, e.g. a Multi-Choice construct with outgoing branches to tasks A and B would be modelled using an XOR-split with three outgoing branches - one to task A, another to task B and a third to an AND-split which then triggered both tasks A and B. Further details on these transformations are presented by van der Aalst et al. [vdAtHKB03].

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. Note that the work-around based on XOR-splits and AND-splits is not considered to constitute support for this pattern as the decision process associated with evaluation of the Multi-Choice is divided across multiple split constructs.

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.