Pattern 17 (Interleaved Parallel Routing)
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).
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.
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.
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.
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.
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.
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.
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. There is no way to interleave steps without specifying an order.|
|Websphere MQ||3.4||-||Not supported. There is no way to interleave activities without specifying an order.|
|FLOWer||3.51||+/-||Due to the case metaphor there is only one actor working on the case. Therefore, there is no true concurrency and any parallel routing is interleaved. Since true concurrency is not possible, a partial support rating is given.|
|COSA||5.1||+||Directly supported through places and also an optional setting of the workflow engine.|
|iPlanet||3.0||-||There is no way to interleave activities without actually enumerating all possible execution sequences within the process model and selecting one of them at runtime.|
|SAP Workflow||4.6c||-||Not supported, the concept of a state is completely missing and there seems no way to influence the fork construct to only allow for interleavings (and not true concurrency).|
|BPEL||1.1||+/-||Indirectly supported via serializable scopes but limited to activities within the same scope.|
|Websphere Integration Developer||6.0||+/-||Indirectly achievable via serializable scopes but this limits the activities to those within the same scope.|
|Oracle BPEL||10.1.2||-||Supported by BPEL spec but not implementable in Oracle BPEL.|
|BPMN||1.0||-||Supported for simple tasks via an ad-hoc process but no support for interleaving groups or sequences of tasks.|
|XPDL||2.0||-||Supported for single activities (but not sequences) by grouping them using the ActivitySet construct with the AdHoc attribute set.|
|UML ADs||2.0||-||Not supported. No notion of state within UML 2.0 ADs.|
|EPC (implemented by ARIS toolset 6.2)||-||Not supported.|
|jBPM||3.1.4||-||jBPM does not support this pattern.|
|OpenWFE||1.7.3||+/-||OpenWFE partially supports this pattern through the construct <interleaved>. The support is partial since any block defined within the interleaved construct, once started can not be interrupted so that other branches from the interleaved construct can be executed in between.|
|Enhydra Shark||2||-||Enhydra does not support this pattern. The Ad Hoc construct present in XPDL is not implemented in Enhydra Shark.|