Pattern 37 (Local Synchronizing Merge)

FLASH animation of Local Synchronizing Merge pattern


The convergence of two or more branches which diverged earlier in the process into a single subsequent branch such that the thread of control is passed to the subsequent branch when each active incoming branch has been enabled. Determination of how many branches require synchronization is made on the basis on information locally available to the merge construct. This may be communicated directly to the merge by the preceding diverging construct or alternatively it can be determined on the basis of local data such as the threads of control arriving at the merge.




The Local Synchronizing Merge provides a deterministic semantics for the synchronizing merge which does not rely on the process model being structured (as is required for the Structured Synchronizing Merge) but also does not require the use of non-local semantics in evaluating when the merge can fire.


Figure 55 illustrates one approach to implementing this pattern. It is based on the use of "true" and "false" tokens which are used to indicate whether a branch is enabled or not. After the divergence at transition A, one or both of the outgoing branches may be enabled. The determinant of whether the branch is enabled is that the token passed to the branch contains both the case id as well as a Boolean variable which is "true" if the tasks in the branch are to be executed, "false" otherwise. As the control-flow token is passed down a branch, if it is a "true" token, then each task that receives the thread of control is executed otherwise it is skipped (illustrated by the execution of the bypass task associated with each task). The Local Synchronizing Merge, which in this example is illustrated by transition E, can be evaluated when every incoming branch has delivered a token to the input places for the same case.


Figure 55: Local Synchronizing merge pattern

Another possible solution is provided by Rittgen [Rit99]. It involves the direct communication of the number of active branches from the preceding OR-Join(s) divergence to the Local Synchronizing Merge so that it is able to determine when to fire.


There are two context conditions associated with the use of this pattern: (1) once the Local Synchronizing Merge has been activated and has not yet been reset, it is not possible for another signal to be received on the activated branch or for multiple signals to be received on any incoming branch, i.e. all input places to the Local Synchronizing Merge (place p4 and p5) are safe and (2) the Local Synchronizing Merge construct must be able to determine how many incoming branches require synchronisation based on local knowledge available to it during execution.


WebSphere MQ, FLOWer, COSA, BPEL and EPCs provide support for this pattern. UML 2.0 ADs seems to provide support although there is some ambiguity over the actual JoinSpec configuration required.


None identified.



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. If there is any ambiguity as to the manner in which the synchronization condition is specified, then it rates as partial support.

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. The concept of a step waiting for all preceding activities to finish when they are optional is not possible in any form.
Websphere MQ 3.4 + Supported through the use of dead path elimination where "true" and "false" tokens are passed down branches that are and are not enabled respectively. This allow the OR-join to determine when it should fire.
FLOWer 3.51 + Supported inside the static, dynamic and sequential subplans. Each plan model is a directed acyclic graph of nodes representing various plan elements and actions. Nodes with multiple incoming arcs wait for the predecessors to be completed or skipped (called "refused"). If all preceding nodes are skipped or all incoming arcs have a guard evaluating to false, a node is skipped. Otherwise normal processing is resumed.
COSA 5.1 + The condition on an input arc to an activity can specified such that it will not be considered when the join condition for the activity is evaluated if the branch to which it belongs is not live.
iPlanet 3.0 - No means of providing information to an OR-join to enable local determination of when it should fire.
SAP Workflow 4.6c - Not supported for two reasons. First of all, it is not possible to create optional parallel branches other than explicitly skipping the branches that are not selected. Second, the join construct of a fork is unaware of the number of truly active branches. Therefore, any synchronizing merge needs to be rewritten as a mix of forks and conditions.
FileNet 3.5 - Not supported.
BPEL 1.1 + Supported by links within a <flow> construct.
Websphere Integration Developer 6.0 + Supported by links within a <flow> construct.
Oracle BPEL 10.1.2 + Supported by links within a <flow> construct.
BPMN 1.0 - The OR-join gateway assumes it will be used in a structured context.
XPDL 2.0 - The OR-join gateway assumes it will be used in a structured context.
UML ADs 2.0 +/- The specific configuration of the JoinSpec condition to achieve this is unclear.
EPC (implemented by ARIS toolset 6.2) + See pattern 7. The language allows for this. However, we know of no workflow management systems that implement this. Note that the ARIS simulator uses a rather odd solution: the OR-join connector has a time-out mechanism attached to OR-joins, i.e., the join waits for a pre-specified time and then consumes all folders that are pending.
jBPM 3.1.4 - jBPM does not support this pattern.
OpenWFE 1.7.3 +/- OpenWFE partially supports this pattern. The scenario from the animation of the pattern is achieved through the <concurrrence> construct containing a number of if-then statements for starting the desired activities. The end of the </concurrence> will synchronize these of them which were started. In order to simulate the unstructured part of the scenario (where one of the parallel activities starts a branch that shall not be synchronized) a sub-process (containing this branch) is invoked. The attribute setting forgot = "true" in the sub-process invocation has to be done. If defines the execution of the sub-process as asynchronous which enables the continuation of the main process in parallel to the execution of its sub-process. Forcing this asynchronous execution entails the limitation that the sub-process (including all activities in it) can not later on be synchronized with any activity within the main-process.
Enhydra Shark 2 - Enhydra Shark does not directly support this pattern. (Structured Synchronizing merge, which is a simpler form of this pattern, is not supported.)