Pattern 33 (Generalized AND-Join)

FLASH animation of Generalized AND-Join pattern


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


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.


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.


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.


There are no specific context conditions associated with the pattern.


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.


None identified.



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.





Staffware 10 - Not supported. Although join constructs require triggering on all branches, subsequent triggers received on branches before the join has completed are lost.
Websphere MQ 3.4 - Not supported. Process models are inherently block structured and an activity cannot receive multiple threads of control from the same incoming branch.
FLOWer 3.51 - Not supported. Note that FLOWer models are "safe" (1-bounded).
COSA 5.1 - Only safe Petri net diagrams can be used.
iPlanet 3.0 - Not supported. No ability to buffer activity triggers.
SAP Workflow 4.6c - Not supported because of the structured/safe nature of SAP workflow.
FileNet 3.5 + Supported by a collector step.
BPEL 1.1 - Not supported. There is no notion of multiple execution threads through a single path in a process instance.
Websphere Integration Developer 6.0 - Not supported. There is no notion of multiple execution threads through a single path in a process instance.
Oracle BPEL 10.1.2 - Not supported. There is no notion of multiple execution threads through a single path in a process instance.
BPMN 1.0 + Supported by the AND-join gateway.
XPDL 2.0 + Supported by the AND-join construct.
UML ADs 2.0 - Not supported. JoinNode semantics prevent this situation from arising.
EPC (implemented by ARIS toolset 6.2) +/- Most papers and books on EPCs assume that joins block if multiple folders arrive. However, the ARIS simulator implements this more like in a Petri net.
jBPM 3.1.4 + jBPM - The semantics of the Join node captures the captures the semantics of the Generalized AND-Join pattern.
OpenWFE 1.7.3 - OpenWFE does not support it, due to its structured nature.
Enhydra Shark 2 - Enhydra Shark does not directly support this pattern. A workflow can not be in a non-safe state.