Pattern 8 (Multi-Merge)

FLASH animation of Multi-Merge pattern

Description

The convergence of two or more branches into a single subsequent branch such that each enablement of an incoming branch results in the thread of control being passed to the subsequent branch.

Synonyms

None.

Examples

The lay_foundations, order_materials and book_labourer tasks occur in parallel as separate process branches. After each of them completes the quality_review task is run before that branch of the process finishes.

Motivation

The Multi-Merge pattern provides a means of merging distinct branches in a process into a single branch. Although several execution paths are merged, there is no synchronization of control-flow and each thread of control which is currently active in any of the preceding branches will flow unimpeded into the merged branch.

Overview

The operation of this pattern is illustrated in Figure 9. Any threads of control on incoming branches to p1 should be passed on to the outgoing branch. the analogy to this in CP-net terms, is that each incoming token to place p1 should be preserved. The distinction between this pattern and the Simple Merge is that it is possible for more than one incoming branch to be active simultaneously and there is no necessity for place p1 be safe.

Figure 9: Multi-merge pattern

Context

There is one context condition associated with this pattern: the Multi-Merge must be associated with a specific preceding Multi-Choice construct.

Implementation

iPlanet allows the Multi-Merge pattern to be implemented by specifying a trigger condition for a task that allows it to be triggered when any of its incoming routers are triggered. BPMN and XPDL directly implement it via the XOR-join construct and UML 2.0 ADs have an analogue in the form of the MergeNode construct. EPCs also provide the XOR-join construct, however they only expect one incoming thread of control and ignore subsequent simultaneous triggers, hence they do not support the pattern. FLOWer is able to support multiple concurrent threads through dynamic subplans however its highly structured nature does not enable it to provide general support for the Multi-Merge pattern. Although COSA is based on a Petri Net foundation, it only supports safe models and hence is unable to fully support the pattern. For example, both A and B in Figure 9 will block if there is a token in p1. Staffware attempts to maintain a safe process model by coalescing subsequent triggerings of a step whilst it is active into the same thread of control hence it is also unable to support this pattern. This behaviour is quite problematic as it creates a race condition in which all of the execution sequences ABC, BAC, ACBC and BCAB are possible.

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. Partial support is awarded to offerings that do not provide support for multiple branches to merge simultaneously or do not provide for preservation of all threads of control when this does occur.

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.