Pattern 40 (Interleaved Routing)
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.
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.
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.
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
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.
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.
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.
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 only way to model this is to enumerate sequences and explicitly select paths through conditions.|
|Websphere MQ||3.4||-||Not supported. 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.|
|FLOWer||3.51||+/-||As for Interleaved Parallel Routing, the case metaphor allows a user to work on any of its constituent activities without regard to their overall sequence. A case is completed when all of its activities have been completed. Although there is no direct means of ensuring that activities are only undertaken one at a time, the fact that they are all undertaken by the same user obviates any potential for concurrency and ensures that they are interleaved.|
|COSA||5.1||+||Supported through the use of a mutex place to prevent nominated activities from executing concurrently.|
|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. There are no mechanisms other than events and cancellations to support interactions between parallel branches.|
|BPEL||1.1||+||Supported by serializable scopes.|
|Websphere Integration Developer||6.0||+||Supported by serializable scopes.|
|Oracle BPEL||10.1.2||-||Supported by the BPEL spec but not implementable in Oracle BPEL.|
|BPMN||1.0||+/-||Indirectly supported via an ad-hoc process containing all of the activities to be interleaved with AdHocOrdering set to sequential however it is unclear what the required AdHocCompletionCondition should be to ensure each activity is executed precisely once.|
|XPDL||2.0||+/-||Indirectly supported via an AdHoc process containing all of the activities to be interleaved with AdHocOrdering set to sequential however it is unclear what the required AdHocCompletionCondition should be to ensure each activity is executed precisely once.|
|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 supports this pattern through the construct <interleaved>.|
|Enhydra Shark||2||-||Enhydra Shark does not support this pattern. (The Ad Hoc construct is present in XPDL 2.0 and hence not implemented in Enhydra Shark which supports XPDL 1.0).|