Pattern 40 (Interleaved Routing)

FLASH animation of Interleaved Routing pattern

Description

Each member of a set of tasks must be executed once. They can be executed in any order but no two tasks can be executed at the same time (i.e. no two tasks can be active for the same process instance at the same time). Once all of the tasks have completed, the next task in the process can be initiated.

Examples

The check-oil, test-feeder, examine-main-unit and review-warranty tasks all need to be undertaken as part of the machine-service process. Only one of them can be undertaken at a time, however they can be executed in any order.

Motivation

The Interleaved Routing pattern relaxes the partial ordering constraint that exists with the Interleaved Parallel Routing pattern and allows a sequence of tasks to be executed in any order.

Overview

Figure 58 illustrates the operation of this pattern. After A is completed, tasks B, C, D and E can be completed in any order. The mutex place ensures that only one of them can be executed at any time. After all of them have been completed, task F can be undertaken.

Figure 58: Interleaved routing pattern

Context

There is one consideration associated with the use of this pattern: tasks must be initiated and completed on a sequential basis, in particular it is not possible to suspend one task during its execution to work on another.

Implementation

In order to effectively implement this pattern, an offering must have an integrated notion of state that is available during execution of the control-flow perspective. COSA has this from its Petri-Net foundation and is able to directly support the pattern. Other offerings lack this capability and hence are not able to directly support this pattern. BPEL (although not Oracle BPEL) can achieve similar effects using serializable scopes within the context of a <pick> construct. FLOWer has a distinct foundation to that inherent in other workflow products in which all tasks in a case are always allocated to the same resource for completion hence interleaving of task execution is guaranteed, however it is also possible for a resource to suspend a task during execution to work on another hence the context conditions for this pattern are not fully satisfied. BPMN and XPDL indirectly support the pattern through the use of ad-hoc processes however it is unclear how it is possible to ensure that each task in the ad-hoc process is executed precisely once.

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. An offering is rated as having partial support if it has limitations on the range of tasks that can be coordinated (e.g. tasks must be in the same process block) or if it cannot enforce that tasks are executed precisely once or ensure tasks are not able to be suspended once started whilst other tasks in the interleave set are commenced.

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.