Pattern 12 (Multiple Instances without Synchronization)
Within a given process instance, multiple instances of a task can be created. These instances are independent of each other and run concurrently. There is no requirement to synchronize them upon completion. Each of the instances of the multiple instance task that are created must execute within the context of the process instance from which they were started (i.e. they must share the same case identifier and have access to the same data elements) and each of them must execute independently from and without reference to the task that started them.
Multi threading without synchronization, spawn off facility.
A list of traffic infringements is received by the Transport Department. For each infringement on the list an Issue-Infringment-Notice task is created. These tasks run to completion in parallel and do not trigger any subsequent tasks. They do not need to be synchronized at completion.
This pattern provides a means of creaing multiple instances of a given task. It caters for situations where the number of individual tasks required is known before the spawning action commences, the tasks can execute independently of each other and no subsequent synchronization is required.
There are two possible variants to the way in which this pattern can operate. The first is illustrated by Figure 14 in which the create instance task runs within a loop and the new task instances are created sequentially. Place p2 indicates the number of instances required and is decremented as each new instance is created. New instances can only be created when the token in p2 has a value greater than zero - the guard on the create instance task ensures this is the case. When all instances have been created, the next task (B) can be enabled - again the guard on task B ensures this is also the case.
Figure 14: Multiple instances without synchronization pattern (variant 1)
In Figure 15, the task instances are all created simultaneously. In both variants, it is a requirement that the number of new instances required is known before the creation task commences. It is also assumed that the task instances can be created that run independently (and in addition to the thread of control which started them) and that they do not require synchronizing as part of this construct.
Figure 15: Multiple instances without synchronization pattern (variant 2)
There is one context condition associated with this pattern: the number of task instances (i.e. numinst) is known as design time and is a fixed value.
Most offerings - COSA, iPlanet, BPEL, BPMN, XPDL and UML 2.0 ADs - support the sequential variant of this pattern (as illustrated in Figure 14) with the task creation occuring within a loop. SAP Workflow also does so, but with the limitation that a new process instance is started for each task instance invoked. BPMN also supports the second variant, as do Staffware and FLOWer, and they provide the ability to create the required number of task instances simultaneously.
An offering achieves full support if it provides a construct that satisfies the description for the pattern. Where the newly created task instances run in a distinct process instance to the task that started them or it cannot access the same data elements as the parent task, the offering achieves only partial support.
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||+||Staffware supported static and dynamic subprocedure steps. The static subprocedure step is simply a step corresponding to a subprocess. When Staffware processes a dynamic sub-procedure step, it looks at the array field that has been defined for the sub-procedures to start. This array field may contain no data (i.e. no sub-procedures need to be started) or multiple data elements (i.e. multiple sub-procedures need to be started) concurrently|
|Websphere MQ||3.4||-||Although it is possible to to replicate an activity by including it in a block activity with an exit condition that is satisfied when all instances have completed, it is not possible for these instances to run concurrently.|
|FLOWer||3.51||+||Directly supported through dynamic subplans. The dynamic subplan can be put into another plan such that subsequent plan elements do not have to wait for the completion of the plan.|
|COSA||5.1||+||COSA has a three level workflow model, i.e., workflow, flow, and activity. Flows (i.e., workflow instances) can be grouped in one workflow and share information. This combined with a trigger mechanism to create new flows is a possible solution where folders are used to facilitate shared access to common data.|
|iPlanet||3.0||+||Supported via asynchronous subprocess activities.|
|SAP Workflow||4.6c||+/-||The pattern is partially supported through data objects and events triggering workflows, i.e. a state change of an object may trigger a workflow. By changing states in a loop it is possible to trigger multiple instances. Note that the newly created instances run in a distinct process instances that has no relation to the instance of the activity activating them. Hence only partial support is given.|
|FileNet||3.5||+||Supported via invoke in the loop.|
|BPEL||1.1||+||Supported by <invoke> statement within <while> loop.|
|Websphere Integration Developer||6.0||+||Supported by the <invoke> activity within a <while> loop.|
|Oracle BPEL||10.1.2||+||Supported by the <invoke> construct within a <while> loop.|
|BPMN||1.0||+||Supported via multiple instance task with MI Flow_Condition attribute set to none.|
|XPDL||2.0||+||Supported by spawning off activity instances in a loop.|
|UML ADs||2.0||+||Supported by spawning off new activity instances in a loop.|
|EPC (implemented by ARIS toolset 6.2)||-||This is not supported. There is no explicit notion of instances and there is no notation for inter-process connections.|
|jBPM||3.1.4||+||jBPM supports this pattern as new instances of tasks can be spawned off through the use of a loop|
|OpenWFE||1.7.3||+||OpenWFE supports this pattern through a loop launching new instances of the multiple instances task as subprocesses. Setting the forget attribute to "true" ensures that synchronization over the created instances will not take place.|
|Enhydra Shark||2||+||Enhydra Shark supports this pattern through a loop launching new instances of the multiple instances task as sub-flows (i.e. subprocesses). Setting the Subflow Execution attribute to "Asychronous" ensures that the sub-flows can run in parallel and any synchronization of them wil not take place.|