Pattern 17 (Interleaved Parallel Routing)

FLASH animation of Interleaved Parallel Routing pattern

Description

A set of tasks has a partial ordering defining the requirements with respect to the order in which they must be executed. Each task in the set must be executed once and they can by completed in any order that accords with the partial order. However, as an additional requirement, 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).

Synonyms

None.

Examples

When despatching an order, the pick goods, pack goods and prepare invoice tasks must be completed. The pick goods task must be done before the pack goods task. The prepare invoice task can occur at any time. Only one of these tasks can be done at any time for a given order.

Motivation

The Interleaved Parallel Routing pattern offers the possibility of relaxing the strict ordering that a process usually imposes over a set of tasks. Note that Interleaved Parallel Routing is related to mutal exclusion, i.e. a semaphore makes sure that tasks are not executed at the same time without enforcing a particular order.

Overview

Figure 23 provides an example of Interleaved Parallel Routing. Place p3 enforces that tasks B, C and D be executed in some order. In this example, the permissible activity orderings are: ABDCE, ABCDE and ACBDE.

Figure 23: Interleaved parallel routing pattern

In the situation where there is no specific ordering required of the interleaved tasks, then the scenario is actually one of Interleaved Routing and is described by pattern WCP40.

Context

There is one context condition associated with this pattern: tasks must be initiated and completed on a sequential basis and 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 surprisingly not Oracle BPEL) can indirectly achieve similar effects using serializable scopes within the context of a <pick> construct although only tasks in the same block can be included within it. It also has the shortcoming that every permissible execution sequence of interleaved tasks must be explicitly modelled. 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.

Issues

None identified.

Solutions

N/A

Evaluation Criteria

Full support for this pattern is demostrated by any offering which provides a construct which satisfies the description when used in a context satisfying the context assumption. It achieves a partial support rating if there are any limitations on the set of tasks that can be interleaved or if tasks can be suspended during execution.

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.