Pattern 14 (Multiple Instances with a priori Run-Time Knowledge)
Within a given process instance, multiple instances of a task can be created. The required number of instances may depend on a number of runtime factors, including state data, resource availability and inter-process communications, but is known before the task instances must be created. Once initiated, these instances are independent of each other and run concurrently. It is necessary to synchronize the instances at completion before any subsequent tasks can be triggered.
When diagnosing an engine fault, multiple instances of the check-sensor task can run concurrently depending on the number of error messages received. Only when all messages have been processed, can the identify-fault task be initiated;
In the review process for a paper submitted to a journal, the review paper task is executed several times depending on the content of the paper, the availability of referees and the credentials of the authors. The review process can only continue when all reviews have been returned;
When dispensing a prescription, the weigh compound task must be completed for each ingredient before the preparation can be compounded and dispensed.
The Multiple Instances with a priori Run-Time Knowledge pattern provides a means of executing multiple instances of a given task in a synchronized manner with the determination of exactly how many instances will be created being deferred to the latest possible time before the first of the tasks is started.
As with other multiple instance patterns, there are two variants of this pattern depending on whether the instances are created sequentially or simultaneously as illustrated in Figures 18 and 19. In both cases, the number of instances of task C to be executed (indicated in these diagrams the variable numinst) is communicated at the same time that the thread of control is passed for the process instance.
Figure 18: Multiple instances with a prior run-time knowledge pattern (variant 1)
Figure 19: Multiple instances with a priori run-time knowledge pattern (variant 2)
There is one context condition associated with this pattern: the number of task instances (i.e. numinst) is known at runtime prior to the creation of instances of the task. Once determined, the number of task instances is a fixed value.
Staffware, FLOWer and UML 2.0 ADs support the simultaneous variant of the pattern through the use of dynamic subplan and ExpansionRegion constructs respectively. BPMN and XPDL support both options via the multi-instance loop task construct. In the case of FLOWer, BPMN and XPDL, the actual number of instances required is indicated through a variable passed to the construct at runtime. For UML 2.0 ADs, the ExpansionRegion construct supports multiple instantiations of a task based on the number of instances of a defined data element(s) passed at run-time. Oracle BPEL supports the pattern via its (unique) <flowN> construct.
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.
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||+||Supported using the dynamic subprocedure step.|
|Websphere MQ||3.4||-||Not supported. No means of facilitating multiple instances of an activity at runtime.|
|FLOWer||3.51||+||Directly supported through dynamic subplans. One can specify a variable number of instances.|
|COSA||5.1||-||There is no means of denoting that an activity should be executed multiple times.|
|iPlanet||3.0||-||Not supported. No means of designating that multiple instances of an activity are required.|
|SAP Workflow||4.6c||+||Supported directly via the "dynamic processing with a multi-line container element" as indicated for the previous pattern. The number of rows is only relevant at the moment of activitation and does not need to be fixed before.|
|BPEL||1.1||-||Not supported. No direct means of denoting multiple activity instances are required.|
|Websphere Integration Developer||6.0||-||Not supported. No direct means of denoting multiple instances are required.|
|Oracle BPEL||10.1.2||+||Supported through the use of the <flowN> construct which allows multiple concurrent instances of an activity to be created.|
|BPMN||1.0||+||Supported via multiple instance task with MI_Condition attribute set at runtime to the actual number of instances required.|
|XPDL||2.0||+||Supported by the multi-instance loop construct where MI_Ordering = parallel.|
|UML ADs||2.0||+||Supported through the use of the ExpansionRegion construct.|
|EPC (implemented by ARIS toolset 6.2)||-||Not supported.|
|jBPM||3.1.4||-||jBPM does not support this pattern.|
|OpenWFE||1.7.3||+||OpenWFE implements this pattern through the <concurrent-iterator> construct. To the on-field-value attribute of the <concurrent-iterator> a list of variables retrieved during run-time is sent. Each of the items in this list will result in the creation of a corresponding instance. The created instances will run in parallel and synchronized after completion.|
|Enhydra Shark||2||-||Enhydra Shark does not support this pattern. Multiple instances of a task can be spawned through a loop which invokes a sub-flow in every iteration of it. However these sub-flows can not be synchronized, as the sub-flow execution setting has to be set to "asynchronous", so that the start up of the instances shall not be blocked.|