Pattern 15 (Multiple Instances without 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 and is not known until the final instance has completed. Once initiated, these instances are independent of each other and run concurrently. At any time, whilst instances are running, it is possible for additional instances to be initiated. It is neccesary to synchronize the instances at completion before any subsequent tasks can be triggered.
The despatch of an oil rig from factory to site involves numerous transport shipment tasks. These occur concurrently and although sufficient tasks are started to cover initial estimates of the required transport volumes, it is always possible for additional tasks to be initiated if there is a shortfall in transportation requirements. Once the whole oil rig has been transported, and all transport shipment tasks are completed, the next task (assemble rig) can commence.
This pattern is an extension to the Multiple Instances with a priori Run-Time Knowledge pattern which defers the need to determine how many concurrent instances of the task are required until the last possible moment - either when the synchronization of the multiple instances occurs or the last of the executing instances completes. It offers more flexibility in that additional instances can be created "on-the-fly" without any necessary change to the process model or the synchronization conditions for the task.
Similiar to other multiple instance patterns, there are two variants to this pattern depending on whether the initial round of instances are started sequentially or simultaneously. These scenarios are depicted in Figures 20 and 21. It should be noted that it is possible to add additional instances of task C in both of these implementations via the add instance transition at any time up until all instances have completed and the join associated with them has fired triggering the subsequent task (B).
Figure 20: Multiple instances without a priori run-time knowledge pattern (variant 1)
Figure 21: Multiple instances without 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 completion of the multiple instance task (note that the final number of instances does not need to be known when initializing the MI task).
Only one of the offerings examined - FLOWer - provides direct support for this pattern. It does this through the dynamic subplan 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||-||Not supported. The number of instances is based on the array values at the moment the step is executed and cannot be changed later.|
|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. It is possible to create new instances during execution. There is a setting "User may create 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||-||Not supported. The only way to realize this is through the use of loop construct together with a counter variable indicating how many instances are to be synchronized by the subsequent join. This number can be modified at run-time. However, the designer has to do the book-keeping to link events to activities.|
|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||-||Not supported. No direct means of initiating additional instances of a multiple activity (e.g. as created by the <flowN> construct) is available.|
|BPMN||1.0||-||Not supported. There is no means of adding further instances to a multiple instance task once started.|
|XPDL||2.0||-||Not supported. There is no means of adding further instances to a multi-instance loop once started.|
|UML ADs||2.0||-||Not supported. No means of adding additional activity instances after commencement.|
|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. The <concurrent-iterator> construct can only be used when the number of instances to be created is known before the commencement of the multiple instance task. The repeated invocation of a sub-process within a loop with the attribute forget = "true" (which is the solution proposed in OpenWFE Specification, Chapter 7 Workflow Patterns, Pattern 15) does not synchronize the created instances and hence does not capture the full semantics of the pattern.|
|Enhydra Shark||2||-||Enhydra Shark does not support this pattern.|