Pattern 32 (Cancelling Partial Join)
FLASH animation of Cancelling Partial Join pattern
Description
The convergence of two or more branches (say m) into a single subsequent branch following one or more corresponding divergences earlier in the process model. The thread of control is passed to the subsequent branch when n of the incoming branches have been enabled where n is less than m. Triggering the join also cancels the execution of all of the other incoming branches and resets the construct.
Examples
Once the picture is received, it is sent to three art dealers for the examination. Once two of the prepare condition report tasks have been completed, the remaining prepare condition report task is cancelled and the plan restoration task commences.
Motivation
This pattern provides a means of expediting a process instance where a series of incoming branches to a join need to be synchronized but only a subset of those tasks associated with each of the branches needs to be completed.
Overview
The operation of this pattern is shown in Figure 50. It operates in the same way as the Cancelling Discriminator except that, for this pattern, the cancellation is only triggered when n distinct incoming branches have been enabled.
Figure 50: Cancelling partial join pattern
Context
There is one context condition associated with the use of this pattern: once the Cancelling Partial Join has been activated and has not yet been reset, it is not possible for another signal to be received on the activated branch or for multiple signals to be received on any incoming branch. In other words, all input places to the Cancelling Partial Join (i.e. i1 to im) are safe.
Implementation
The approach to implementing this pattern is essentially the same as that for the Cancelling Discriminator except that the join fires when n incoming branches have triggered rather than just the first. The Cancelling Partial Join is supported by SAP Workflow and UML 2.0 ADs. BPMN and XPDL achieve a partial support rating as it is unclear exactly how the join condition is specified.
Issues
As for the Cancelling Discriminator pattern.
Solutions
As for the Cancelling Discriminator pattern.
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 considered to provide partial support for the pattern if there are undesirable side-effects associated with the construct firing (e.g. tasks in incoming branches which have not completed being recorded as complete) or if ther semantics associated with the join condition are unclear.
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 | - | Although simple versions of this pattern (e.g. 1-out-of-2 join) can constructed using withdrawn action, the solution is not safe and does not scale up well to more complex joins. |
Websphere MQ | 3.4 | - | Not supported. There is no direct support for multiple instance activities. |
FLOWer | 3.51 | - | Not supported. Dynamic subplans can have an auto complete condition however this is only evaluated when all subplans have completed. |
COSA | 5.1 | - | Similar to WCP30, no direct support. |
iPlanet | 3.0 | - | Not supported. No ability to cancel portions of a process model. |
SAP Workflow | 4.6c | + | SAP workfow only supports structured workflows. In the case of the partial join, this is supported by a fork that can start M branches in parallel and the fork completes after the completion of N of these branches. The remaining branches are cancelled. |
FileNet | 3.5 | - | Not supported. |
BPEL | 1.1 | - | Not supported. As for WCP30. |
Websphere Integration Developer | 6.0 | - | Not supported. As for WCP30. |
Oracle BPEL | 10.1.2 | - | Not supported. As for WCP30. |
BPMN | 1.0 | +/- | Although support for this pattern is referred to in the BPMN 1.0 specification, it is unclear how the IncomingCondition expression on the COMPLEX-join gateway is specified. |
XPDL | 2.0 | +/- | Although the COMPLEX-join gateway appears to offer support for this pattern, it is unclear how the IncomingCondition expression is specified. |
UML ADs | 2.0 | + | Supported by incorporating the incoming branches to the join in an interruptible region. The join has an outgoing weight of N from the interruptible region to the subsequent activity effectively cancelling all other branches when the Nth branch reaches the join. |
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 <concurrence> construct with the attribute settings count = "X" and remaining = "cancel", where X is the number of treads to be joined |
Enhydra Shark | 2 | - | Enhydra Shark does not directly support this pattern. |