Pattern 6 (Multi-Choice)
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.
Conditional routing, selection, OR-split, multiple choice.
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.
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.
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
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.
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.
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.
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].
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.
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||-||Not supported. The condition construct can only model a binary decision.|
|Websphere MQ||3.4||+||Supported through the use of (non-exclusive) conditions on transitions.|
|FLOWer||3.51||+||Supported by guards on arcs in static, dynamic and sequential subplans.|
|COSA||5.1||+||Supported by multiple outgoing arcs from an activity. The arcs may have (possibly overlapping) transition conditions specified.|
|iPlanet||3.0||+||Supported by multiple outgoing routers from an activity, each with specific (and possibly overlapping) enabling conditions.|
|SAP Workflow||4.6c||-||Not supported. Although there are three constructs to model choices, it is not possible to select multiple exits for a choice (other than the fork). Hence a multi-choice requires a combination of fork and condition constructs.|
|FileNet||3.5||+||Directly supported by a step, which takes routes of all true conditions. Requires structure followed by a collector step.|
|BPEL||1.1||+||Supported by 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 links within a <flow> construct.|
|BPMN||1.0||+||Supported in three distinct ways: via an implicit split with conditions on the arcs, an OR-split or a complex gateway.|
|XPDL||2.0||+||Supported by the AND-split construct together with conditions on the outgoing transitions.|
|UML ADs||2.0||+||Supported by the ForkNode construct with guard conditions on the outgoing edges.|
|EPC (implemented by ARIS toolset 6.2)||+||Supported by the OR-split connector.|
|jBPM||3.1.4||-||jBPM does not directly support multi choice. The behavior can be implemented through a Node type Node, where the semantics of the pattern have to be coded in Java|
|OpenWFE||1.7.3||+/-||OpenWFE does not provide a direct support for this pattern. The behavior can be achieved by a collection of it-then clauses execution concurrently, where several of the in-conditions may evaluate to true|
|Enhydra Shark||2||+||Enhydra Shark supports this pattern through a parallel split on an activity/a routing activity (i.e. transition restriction <Split Type = "AND">) with conditions specified on the leaving transitions where several of the conditions may evaluate to true simultaneously [Wil]. XPDL also offers an OR split, however such a construct is not implemented in Enhydra Shark.|