Pattern 28 (Blocking Discriminator)
The convergence of two or more branches into a single subsequent branch following one or more corresponding divergences earlier in the process model. The thread of control is passed to the subsequent branch when the first active incoming branch has been enabled. The Blocking Discriminator construct resets when all active incoming branches have been enabled once for the same process instance. Subsequent enablements of incoming branches are blocked until the Blocking Discriminator has reset.
The check credentials task can commence once the confirm delegation arrival or the security check task has been completed. Although these two tasks can execute concurrently, in practice, the confirm delegation arrival task always completes before security check task. Another instance of the check credentials task cannot be initiated if a preceding instance of the task has not yet completed. Similarly, subsequent instances of the confirm delegation arrival and the security check tasks cannot be initiated if a preceding instance of the check credentials task has not yet completed.
The Blocking Discriminator pattern is a variant of the Structured Discriminator pattern that is able to run in environments where there are potentially several concurrent execution threads within the same process instance. This quality allows it to be used in loops and other process structures where more than one execution thread may be received in a given branch in the time between the first branch being enabled and the Blocking Discriminator being reset.
Figure 44 illustrates the operation of this pattern. It is more robust than the Structured Discriminator as it is not subject to the constraint that each incoming branch can only being triggered once prior to reset. The Blocking Discriminator functions by keeping track of which inputs have been triggered (via the triggered input place) and preventing them from being re-enabled until the construct has reset as a consequence of receiving a trigger on each incoming branch. An important feature of this pattern is that it is able to be utilized in environments that do not support a safe process model or those that may receive multiple triggerings on the same input place e.g. where the Blocking Discriminator is used within a loop.
Figure 44: Blocking discriminator pattern
There are no specific context conditions associated with the pattern.
In the event of concurrent process instances attempting to simultaneously initiate the same Blocking Discriminator, it is necessary to keep track of both the process instance and the input branches that have triggered the Blocking Discriminator and also the execution threads that are consequently blocked (including the number of distinct triggerings on each branch) until it completes. The Blocking Discriminator is partially supported by BPMN, XPDL and UML 2.0 ADs.
An offering achieves full support if it provides a construct that satisfies the description for the pattern. If there is any ambiguity in how the join condition is specified, an offering is considered to provide partial support for the pattern.
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. Only the XOR-join and AND-join are possible using normal steps and wait steps respectively.|
|Websphere MQ||3.4||-||Not supported. The evaluation of start conditions for an activity only occurs when all preceding activities have completed.|
|FLOWer||3.51||-||Not supported. Note that the auto complete condition of a dynamic subplan cannot be used to continue processing at a higher level while blocking the dynamic subplan until all instances complete.|
|COSA||5.1||-||There is no modelling construct that directly corresponds to this pattern and although the behaviour can be indirectly achieved, the process model required to do is too complex.|
|iPlanet||3.0||-||Not supported. No ability to block activity triggerings.|
|SAP Workflow||4.6c||-||The block structured nature of SAP workflow does not allow for concurrent execution treads within the same instance. Hence a discriminator cannot be activated multiple times.|
|BPEL||1.1||-||Not supported. There is no dedicated language construct and links cannot be used in conjunction with an OR joinCondition as the join requires the status of all incoming links to be known before evaluation, not just the identification of the first positive link.|
|Websphere Integration Developer||6.0||-||Not supported. There is no dedicated language construct and links cannot be used in conjunction with an OR joinCondition as the join requires the status of all incoming links to be known before evaluation, not just the identification of the first positive link.|
|Oracle BPEL||10.1.2||-||Not supported. There is no dedicated language construct and links cannot be used in conjunction with an OR joinCondition as the join requires the status of all incoming links to be known before evaluation, not just the identification of the first positive link.|
|BPMN||1.0||+/-||Although support for this pattern is referred to in the BPMN 1.0 specification, it is unclear how the IncomingCondition expression on the COMPLEX-join gateway is specified.|
|XPDL||2.0||+/-||Although the COMPLEX-join gateway appears to offer support for this pattern, it is unclear how the IncomingCondition expression is specified.|
|UML ADs||2.0||+/-||The specific configuration of the JoinSpec condition to achieve this is unclear.|
|EPC (implemented by ARIS toolset 6.2)||-||Not supported.|
|jBPM||3.1.4||-||jBPM does not support this pattern.|
|OpenWFE||1.7.3||-||OpenWFE does not support this pattern.|
|Enhydra Shark||2||-||Enhydra Shark does not directly support this pattern.|