Pattern 30 (Structured Partial Join)
The convergence of two or more branches (say m) into a single subsequent branch following a corresponding divergence earlier in the process model such that 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. Subsequent enablements of incoming branches do not result in the thread of control being passed on. The join construct resets when all active incoming branches have been enabled. The join occurs in a structured context, i.e. there must be a single Parallel Split construct earlier in the process model with which the join is associated and it must merge all of the branches emanating from the Parallel Split. These branches must either flow from the Parallel Split to the join without any splits or joins or be structured in form (i.e. balanced splits and joins).
Once two of the preceding three Expenditure Approval tasks have completed, trigger the Issue Cheque task. Wait until the remaining task has completed before allowing the Issue Cheque task to fire again.
The Structured Partial Join pattern provides a means of merging two or more distinct branches resulting from a specific Parallel Split or AND-split construct earlier in the workflow process into a single branch. The join construct does not require triggers on all incoming branches before it can fire. Instead a given threshold can be defined which describes the circumstances under which the join should fire - typically this is presented as the ratio of incoming branches that need to be live for firing as against the total number of incoming branches to the join e.g. a 2-out-of-3 join signifies that the join construct should fire when two of three incoming arcs are live. Subsequent completions of other remaining incoming branches have no effect on (and do not trigger) the subsequent branch. As such, the Structured Partial Join provides a mechanism for progressing the execution of a process once a specified number of concurrent tasks have completed rather than waiting for all of them to complete.
The Structured Partial Join pattern is one possible variant of the AND-Join construct where the number of incoming arcs that will cause the join to fire (n) is between 2 and m-1 (i.e. the total number of incoming branches less one, i.e. 2 ≤ n < m). There are a number of possible specializations of the AND-join pattern and they form a hierarchy based on the value of n. Where only one incoming arc must be live for firing (i.e. n=1), this corresponds to one of the variants of the Discriminator pattern (cf. WCP9, WCP28 and WCP29). An AND-Join where all incoming arcs are considered (i.e. N=M) is either the Synchronization (WCP 3) or Generalized AND-Join pattern (WCP33).
The pattern provides a means of merging two or more branches in a process and progressing execution of the process as rapidly as possible by enabling the subsequent (merged) branch as soon as a thread of control has been received on n of the incoming branches where n is less than the total number of incoming branches. The semantics of the Structured Partial Join pattern is illustrated in Figure 48. Note that B requires n tokens in place p1 to progress.
Figure 48: Structured partial join pattern
There are two context conditions associated with the use of this pattern: (1) once the Structured 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 singals to be received on any incoming branch. In other words, all input places to the Structured Partial Join (i.e. i1 to im) are safe and (2) once the associated Parallel Split has been enabled none of the tasks in the branches leading to the Structured Partial Join can be cancelled before it has been triggered. The only exception to this is that it is possible for all of the tasks leading up to the Structured Partial Join to be cancelled.
There are two possible variants on this pattern that arise from relaxing some of the context conditions associated with it. Both of these improve on the efficiency of the join whilst retaining its overall behaviour. The first alternative, the Blocking Partial Join (WCP 31) removes the requirement that each incoming branch can only be enabled once between join resets. It allows each incoming branch to be triggered multiple times although the construct only resets when one triggering has been received on each input branch. It is illustrated in Figure 49. Second, the Cancelling Partial Join (WCP 32) improves the efficiency of the pattern further by cancelling the other incoming branches to the join construct once n incoming branches have completed. It is illustrated in Figure 50.
One of the difficulties in implementing the Structured Partial Join is that it essentially requires a specific construct to represent the join if it is to be done in a tractable manner. iPlanet does so via the router construct which links preceding tasks to a target task. A router can have a custom trigger condition specified for it that causes the target task to trigger when n incoming branches are live. SAP Workflow provides partial support for this pattern via the fork construct although any unfinished branches are cancelled once the first completes. None of the other offerings examined offer a dedicated construct. Staffware provides for a 1-out-of-2 join, but more complex joins must be constructed from this resulting in an over-complex process model. Similar difficulties exist for COSA. Of the business modelling languages, both BPMN and XPDL appear to provide support for the Structured Partial Join via the complex gateway construct but the lack of detail on how the IncomingCondition is specified results in a partial rating. UML 2.0 ADs also suffers from a similar lack of detail on the JoinSpec configuration required to support this pattern. There is no ability to represent the construct in BPEL.
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 assumptions. If there is any ambiguity in how the join condition is specified, an offering is considered to provide partial support for the pattern.
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.
|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||-||There is no modelling construct that directly corresponds to this pattern and although the behaviour can be indirectly achieved, the process model required to do is too complex.|
|iPlanet||3.0||+||Supported through the use of a customised trigger condition for an activity that only fires when the Nth incoming router is activated.|
|SAP Workflow||4.6c||+/-||SAP workflow 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 the first N branches. The remaining branches are cancelled hence this construct only achieves partial support.|
|BPEL||1.1||-||Not supported. Similar to the discriminator, there is no dedicated language construct and links cannot be used in conjunction with an OR joinCondition as the join requires the status of all incoming links to be known before evaluation, not just the identification of the first N positive links.|
|Websphere Integration Developer||6.0||-||Not supported. Similar to the discriminator, there is no dedicated language construct and links cannot be used in conjunction with an OR joinCondition as the join requires the status of all incoming links to be known before evaluation, not just the identification of the first N positive links.|
|Oracle BPEL||10.1.2||-||Not supported. Similar to the discriminator, there is no dedicated language construct and links cannot be used in conjunction with an OR joinCondition as the join requires the status of all incoming links to be known before evaluation, not just the identification of the first N positive links.|
|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||+/-||The specific configuration of the JoinSpec condition to achieve this is unclear.|
|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 = "forget", where X is the number of treads to be joined.|
|Enhydra Shark||2||-||Enhydra Shark does not directly support this pattern. A work around based on the solution proposed in (Shark) for Structured Discriminator can be constructed.
XPDL defines a Complex Join construct, which is however not implemented in Enhydra Shark.