Pattern 33 (Generalized AND-Join)

FLASH animation of Generalized AND-Join pattern

Description

The convergence of two or more branches into a single subsequent branch such that the thread of control is passed to the subsequent branch when all input branches have been enabled. Additional triggers received on one or more branches between firings of the join persist and are retained for future firings. Over time, each of the incoming branches should deliver the same number of triggers to the AND-join construct (although obviously, the timing of these triggers may vary).

Examples

When all Get Directors Signature tasks have completed, run the Complete Contract task.

Accumulate engine, chassis and body components from the various production lines. When one of each has been received, use one of each component to assemble the basic car.

Motivation

The Generalized AND-Join corresponds to one of the generally accepted notions of an AND-join implementation (the other situation is described by the Synchronization pattern) in which several paths of execution are synchronized and merged together. Unlike the Synchronization pattern, it supports the situation where one or more incoming branches may receive multiple triggers for the same process instance (i.e. a non-safe context) before the join resets. The classical Petri net uses semantics close to this pattern. This shows that this semantics can be formulated easily. However, the intended semantics in practice tends to be unclear in situations involving non-safe behaviour.

Overview

The operation of the Generalized AND-Join is illustrated in Figure 51. Before transition A can be enabled, an input token (corresponding to the same case) is required in each of the incoming places (i.e. i1 to i3). When there are corresponding tokens in each place, transition A is enabled and consumes a token from each input place and once it has completed, deposits a token in output place o1. If there is more than one token at an input place, it ignores additional tokens and they are left intact.

Figure 51: Generalized AND-join pattern

The process analogy to this sequence of events is that the AND-join only fires when a trigger has been received on each incoming branch for a given process instance however additional triggers are retained for future firings. This approach to AND-join implementation relaxes the context condition associated with the Synchronization pattern that only allows it to receive one trigger on each incoming branch after activation but before firing and as a result, it is able to be used in concurrent execution environments such as process models which involve loops as well as offerings that do not assume a safe execution envirionment.

Context

There are no specific context conditions associated with the pattern.

Implementation

This need to provide persistence of triggerings (potentially between distinct firings of the join) means that this construct is not widely supported by the offerings examined and only FileNet provides a construct for it. Token-based process models such as BPMN and XPDL have an advantage in this regard and both modelling notations are able to support this pattern. EPCs provide a degree of ambiguity in their support for this pattern - whilst most documentation indicates that they do not support it, in the ARIS Simulator, they exhibit the required behaviour - hence they are awarded a partial support rating on account of this variance.

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 associated with the specification or use of the construct, 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.