Pattern 16 (Deferred Choice)

FLASH animation of Deferred Choice pattern

Description

A point in a process where one of several branches is chosen based on interaction with the operating environment. Prior to the decision, all branches represent possible future courses of execution. The decision is made by initiating the first task in one of the branches i.e. there is no explicit choice but rather a race between different branches. After the decision is made, execution alternatives in branches other than the one selected are withdrawn.

Synonyms

External choice, implicit choice, deferred XOR-split.

Examples

At the commencement of the Resolve complaint process, there is a choice between the Initial customer contact task and the Escalate to manager task. The Initial customer contact is initiated when it is started by a customer services team member. The Escalate to manager task commences 48 hours after the process instance commences. Once one of these tasks is initiated, the other is withdrawn.

Once a customer requests an airbag shipment, it is either picked up by the postman or a courier driver depending on who can visit the customer site first.

Motivation

The Deferred Choice pattern provides the ability to defer the moment of choice in a process, i.e. the moment as to which one of several possible courses of action should be chosen is delayed to the last possible time and is based on factors external to the process instance (e.g. incoming messages, environment data, resource availability, timeouts etc.). Up until the point at which the decision is made, any of the alternatives presented represent viable courses of future action.

Overview

The operation of this pattern is illustrated in Figure 22. The moment of choice is signified by place p1. Either task B or C represent valid courses of action by only one of them can be chosen.

Figure 22: Deferred choice pattern

Context

There is one context condition associated with this pattern: only one instance of the Deferred Choice can operate at any time (i.e. place p1 is assumed to be safe).

Implementation

This is a complex pattern and it is interesting to see that only those offerings that can claim some sort of token-based underpinning are able to successfully support it. COSA is based on a Petri net foundation and can implement the pattern in much the same way as it is presented in Figure 22. BPEL provides support for it via the <pick> construct, BPMN through the event-based gateway construct, XPDL using the XOREVENT-split construct and UML 2.0 ADs using a ForkNode followed by a set of AcceptSignal actions, one preceding each action in the choice. In the case of the latter three offerings, the actual choice is made based on message-based event interactions. FLOWer does not directly provide a notion of state but it provides several ways of supporting this pattern through the use of user and systems decisions on plan types and also by using arc guards that evaluate to NIL in conjunction with data elements to make the decision as to which branch is selected. FileNet provides partial support for the pattern as it only allows for withdrawal of timer-based branches not of all branches other than the one selected for execution.

Issues

None identified.

Solutions

N/A.

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. If there are any restrictions on which branches can be selected or withdrawn, then the offering is rated as having partial support.

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.

Product/Language

Version

Score

Motivation
Staffware 10 - Not supported. No state support in the process model. Although there is a workaround based on a parallel split and withdraw actions, it is not safe.
Websphere MQ 3.4 - Not supported. There is no means of selecting that one out of a set of possible activities by executed (and the other activities be withdrawn).
FLOWer 3.51 + Although there is no explicit notion of state, there are different ways of realizing this pattern: (1) The plan type user decision (based on user selection on the wavefront) can make the implicit choice in some cases. (2) The plan type system decision can make the implicit choice in other cases. Note that a system decision blocks until at least one of its conditions is true. As a consequence, race conditions based on time or external triggers are possible. In the latter case, triggering is handled through data-dependencies rather than explicit control-flow dependencies. (3) Yet another way to use a specific type of deferred choice is by using guards on arcs in a plan model (i.e., inside a static, dynamic or sequential plan) that evaluate to NIL. In this case processing stops until the guard evaluates to true or false. A guard evaluates to NIL if e.g. it contains an undefined variable. Moreover, using the operator "HasValue" this can be exploited. This way a deferred choice may be implemented via data. Note that data can be set from outside the process (e.g., based on a trigger).
COSA 5.1 + Supported by multiple outgoing arcs from a place.
iPlanet 3.0 - Not supported. No concept of state.
SAP Workflow 4.6c - Not supported. It can only be realized by starting multiple branches in parallel using the fork construct and then commencing each branch with a "wait for event" step. Once the first event completes and the subsequent activity completes, the other branches can be cancelled by setting the required number of complete branches to 1 in the join node of the fork. However, when using this approach it is still possible that multiple activities run in parallel. Clearly, this is not sufficient support for this pattern.
FileNet 3.5 +/- Partially supported. It is possible to withdraw a timer, but not possible to withdraw an activity.
BPEL 1.1 + Supported by the <pick> construct.
Websphere Integration Developer 6.0 + Supported by the <pick> activity.
Oracle BPEL 10.1.2 + Supported by the <pick> construct.
BPMN 1.0 + Supported via an event-based exclusive gateway followed by either intermediate events using message-based triggers or receive tasks.
XPDL 2.0 + Supported by the XOREVENT-split construct.
UML ADs 2.0 + Supported through a ForkNode and a set of AcceptSignal actions, one preceding each action in the choice.
EPC (implemented by ARIS toolset 6.2) - Not supported. The split and join connectors are executed when they become enabled. Therefore, an XOR-split makes an immediate decision and this choice cannot be deferred.
jBPM 3.1.4 + jBPM support this pattern by allowing more than one transition to leave a Task Node. At run-time one of these alternative transitions needs to be selected by the user.
OpenWFE 1.7.3 - OpenWFE does not support this pattern.
Enhydra Shark 2 - Enhydra Shark does not support this pattern. There only are two split types: XOR and AND. The default choice is XOR.