Pattern 30 (Structured Partial Join)

FLASH animation of Structured Partial Join pattern

Description

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).

Examples

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.

Motivation

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.

Overview

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

Context

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.

Implementation

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.

Issues

None identified.

Solutions

N/A.

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 assumptions. If there is any ambiguity in how the join condition is specified, an offering is considered to provide partial support for the pattern.

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.