Pattern 31 (Blocking Partial Join)

FLASH animation of Blocking 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 has been enabled (where 2 = n < m). The join construct resets when all active incoming branches have been enabled once for the same process instance. Subsequent enablements of incoming branches are blocked until the join has reset.

Examples

When the first member of the visiting delegation arrives, the check credentials task can commence. It concludes when either the ambassador or the president arrived. Owing to staff constraints, only one instance of the check credentials task can be undertaken at any time. Should members of another delegation arrive, the checking of their credentials is delayed until the first check credentials task has completed.

Motivation

The Blocking Partial Join is a variant of the Structured Partial Join that is able to run in environments where there are concurrent process instances, particularly process instances that have multiple concurrent execution threads.

Overview

Figure 49 illustrates the operation of this pattern. The Blocking Partial Join functions by keeping track of which inputs have been enabled (via the triggered input place) and preventing them from being re-enabled until the construct has reset as a consequence of receiving a trigger on each incoming place. After n incoming triggers have been received for a given process instance (via tokens being received in n distinct input places from i1 to im), the join fires and a token is placed in output o1. The completion of the remaining n-m branches have no impact on the join except that it is reset when the last of them is received.

Figure 49: Blocking partial join pattern

The pattern shares the same advantages over the Structured Partial Join as the Blocking Discriminator does over the Structured Discriminator, namely greater flexibility as it is able to deal with the situation where a branch is triggered more than once e.g. where the construct exists within a loop.

Context

There are no specific context conditions associated with the pattern.

Implementation

The approach to implementing this pattern is essentially the same as that for the Blocking Discriminator except that the join fires when n incoming branches have triggered rather than just the first. The Blocking Partial Join is partially supported by BPMN, XPDL and UML 2.0 ADs as it is unclear how the join condition is specified.

Issues

None identified.

Solutions

N/A.

Evaluation Criteria

An offering achieves full support if it provides a construct that satisfies the description for the pattern. 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.

Product/Language

Version

Score

Motivation

Staffware 10 - Not supported.
Websphere MQ 3.4 - Not supported. There is no direct support for multiple instance activities.
FLOWer 3.51 - Not supported. The remaining subplan activities are forced to complete.
COSA 5.1 - Similar to WCP30, no direct support.
iPlanet 3.0 - Not supported. No ability to block activity triggerings.
SAP Workflow 4.6c - Not supported because of the structured/safe nature of SAP workflow.
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 +/- 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 does not support this pattern.
Enhydra Shark 2 - Enhydra Shark does not directly support this pattern.