Pattern 41 (Thread Merge)

FLASH animation of Thread Merge pattern

Description

At a given point in a process, a nominated number of execution threads in a single branch of the same process instance should be merged together into a single thread of execution.

Examples

Instances of the register-vehicle task run independently of each other and of other tasks in the Process Enquiry process. They are created as needed. When ten of them have completed, the process-registration-batch task should execute once to finalise the vehicle registration system records update.

Motivation

This pattern provides a means of merging multiple threads within a given process instance. It is a counterpart to the Thread Split pattern which creates multiple execution threads along the same branch.

Overview

The operation of this pattern is illustrated in Figure 59. Note that numinsts indicates the number of threads to be merged.

Figure 59: Thread merge pattern

Context

There is one context consideration for this pattern: the number of threads needing to be merged (i.e. numinsts) must be known at design-time.

Implementation

Implementation of this pattern implies that an offering is able to support the execution of processes in a non-safe context. This rules out the majority of the offerings examined from providing any tractable forms of implementation. BPMN and XPDL provide direct support for the pattern by including a task after the spawned task in which the StartQuantity attribute is set to the number of threads that need to be synchronized. The StartQuantity attribute specifies the number of incoming tokens required to start a task. UML 2.0 ADs offer a similar behaviour via weights on ActivityEdge objects. BPEL provides an indirect means of implementation based on the correlation facility for feedback from the <invoke> action although some programmatic housekeeping is required to determine when synchronization should occur.

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 assumption. If any degree of programmatic extension is required to achieve the same behaviour, then the partial support rating applies.

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	-	No support for user-specified thread merging. The system automatically merges distinct control threads which reach the same step in a process instance.
Websphere MQ	3.4	-	No support. Process models are block structured and safe.
FLOWer	3.51	-	Not supported. The case metaphor prevents any possibility of multiple threads of execution.
COSA	5.1	-	No ability to merge threads as the process in inherently safe.
iPlanet	3.0	-	No ability to coalesce threads of control from independent sub-process activities.
SAP Workflow	4.6c	-	Not supported because of the structured/safe nature of SAP workflow.
FileNet	3.5	-	Not supported.
BPEL	1.1	+/-	The correlation facility for invoked activities provides the basic for coalescing distinct threads of control but programmatic extensions are necessary to keep track of when the merge should occur.
Websphere Integration Developer	6.0	+/-	The correlation facility for invoked activities provides the basis for coalescing distinct threads of control but programmatic extensions are necessary to keep track of when the merge should occur.
Oracle BPEL	10.1.2	+/-	The correlation facility for invoked activities provides the basis for coalescing distinct threads of control but programmatic extensions are necessary to keep track of when the merge should occur.
BPMN	1.0	+	Directly supported by setting the StartQuantity attribute on activities immediately following the MI activity.
XPDL	2.0	+	Directly supported by setting the StartQuantity attribute on activities immediately following the MI activity.
UML ADs	2.0	+	Supported by including a weighted edge after the MI activity to any subsequent activity.
EPC (implemented by ARIS toolset 6.2)		-	Not supported. It is impossible to merge a specified number of threads into one.
jBPM	3.1.4	+/-	In jBPM the behavior of this pattern can be achieved through programmatic extensions by defining a new Node behavior. (According to the evaluation criteria of the pattern, this gives a +/- ranking).
OpenWFE	1.7.3	-	OpenWFE does not support this pattern.
Enhydra Shark	2	-	Enhydra Shark does not support this pattern.