Pattern 12 (To Multiple Instance Task)
Description
The ability to pass data elements from a preceding task instance to a subsequent task which is able to support multiple execution instances. This may involve passing the data elements to all instances of the multiple instance task or distributing them on a selective basis. The data passing occurs when the multiple instance task is enabled.
Examples
- The Identify Witnesses task passes the witness list to the Interview Witnesses task. This data is available to each instance of the Interview Witnesses task at commencement.
- The New Albums List is passed to the Review Album task and one task instance is started for each entry on the list. At commencement, each of the Review Album task instances is allocated a distinct entry from the New Albums List to review.
Motivation
Where a task is capable of being invoked multiple times, a means is required of controlling which data elements are passed to each of the execution instances. This may involve ensuring that each task instance receives all of the data elements passed to it (possibly on a shared basis) or distributing the data elements across each of the execution instances on some predefined basis.
Overview
There are three potential approaches to passing data elements to multiple instance tasks as illustrated in Figure 12.
Figure 12: Data interaction approaches for multiple instance tasks
As a general rule, it is possible either to pass a data element to all task instances or to distribute one item from it (assuming it is a composite data element such as an array or a set) to each task instance. Indeed the number of task instances that are initiated may be based on the number of individual items in the composite data element. The specifics of each of these approaches are discussed below.
- Instance-specific data passed by value - this involves the distribution of a data element passed by value to task instances on the basis of one item of the data element per task instance (in the example shown, task instance B1 receives M[1], B2 receives M[2] and so on). As the data element is passed by value, each task instance receives a copy of the item passed to it in its own address space. At the conclusion of each of the task instances, the data element is reassembled from the distributed items and passed to the subsequent task instance.
- Instance-specific data passed by reference - this scenario is similar to that described above except that the task instances are passed a reference to a specific item in the data element rather than the value of the item. This approach avoids the need to reassemble the data element at the conclusion of the task instances.
- Shared data passed by reference - in this situation all task instances are passed a reference to the same data element. Whilst this allows all task instances to access the same data element, it does not address the issue of concurrency control should one of the task instances amend the value of the data element (or indeed if it is altered by some other component of the process).
Context
There are no specific context conditions associated with this pattern.
Implementation
FLOWer provides facilities for instance-specific data to be passed by reference whereby an array can be passed to a designated multiple instance task and specific sub-components of it can be mapped to individual task instances. It also allows for shared data elements to be passed by reference to all task instances. UML 2.0 ADs allow data to be partitioned (and aggregated) across multiple task instances using the ExpansionRegion construct.
Issues
Where a task is able to execute multiple times but not all instances are created at the same time, an issue that arises is whether the values of data elements are set for all execution instances at the time at which the multiple instance task is initiated or whether they can be set after this occurs for the invocation of a task instance.
Solutions
In FLOWer, the Dynamic Plan construct allows the data for individual task instances to be specified at any time prior to the actual invocation of the task instance. The passing of data elements to specific task instances is handled via Mapping Array data structures. These can be extended at any time during the execution of a Dynamic Plan, allowing for new task instances to be created "on the fly" and the data corresponding to them to be specified at the latest possible time. This issue does not arise in offerings such as UML 2.0 ADs as all instances must be created at the commencement of the task.
Evaluation Criteria
An offering achieves full support if it has a construct that satisfies the description of the pattern.
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.
Product/Language |
Version |
Score |
Motivation |
|---|---|---|---|
| Staffware | 9 | - | Multiple instance tasks not supported |
| Websphere MQ Workflow | 3.4 | - | No support for multiple instances |
| FLOWer | 3.0 | + | Each instance of a dynamic plan can have discrete data elements which can be passed to/from it |
| COSA | 4.2 | - | Not supported |
| XPDL | 1.0 | - | No support for multiple instances |
| BPEL4WS | 1.1 | - | Not supported |
| BPMN | 1.0 | - | Not supported |
| UML | 2.0 | + | Directly supported by the ExpansionRegion construct (where the ExpansionKind mode is set to parallel). |
| Oracle BPEL | 10.1.2 | +/- | Not supported by all variants of MI tasks |
| jBPM | 3.1.4 | - | jBPM does not support this pattern as it lacks a notion for multiple instances tasks. |
| OpenWFE | 1.7.3 | - | OpenWFE does not support this pattern as it lacks (multiple instances) task data. |
| Enhydra Shark | 2 | - | Enhydra Shark does not support this pattern as it lacks (multiple instances) task data. |
Summary of Evaluation
+ Rating |
+/- Rating |
|---|---|
|
|