Pattern 38 (Piled Execution)
FLASH animation of Piled Execution pattern
Description
The ability to initiated the next instance of a task (perhaps in a different case) once the previous one has completed with all associated work items being allocated to the same resource. The transition to Piled Execution mode is at the instigation of an individual resource. Only one resource can be in Piled Execution mode for a given task at any time.
Example
The next Clean Hotel Room work item can commence immediately after the previous one has finished and it can be allocated to the same Cleaner.
Motivation
Piled Execution provides a means of optimising task execution by pipelining instances of the same task and allocating them to the same resource.
Overview
Piled Execution involves a resource undertaking work items corresponding to the same task sequentially. These work items may be in different cases. Once a work item is completed, if another work item corresponding to the same task is present in the work queue, it is immediately started. In effect, the resource attempts to work on piles of the same types of work items. The aim with this approach to work distribution is to allocate similar work items to the same resource which aims to undertake them one after the other thus gaining from the benefit of exposure to the same task. This pattern is illustrated by the transition R:piled_execution in Figure 7. It is important to note that this transition is represented by a dashed line because it jumps from one work item to another, i.e., it links the life-cycles of two different work items in distinct cases.
Context
There are no specific context conditions associated with this pattern.
Implementation
To implement this pattern requires like work items to be allocated to the same resource and the ability for the resource to undertake related work items on a sequential basis, immediately commencing the next one when the previous one is complete. This is a relatively sophisticated requirement and none of the offerings examined support it. It is included in this taxonomy as it constitutes a logical extension of the concepts that underpin the Commencement on Creation pattern enabling instances of the same task across multiple cases to be allocated to a single resource.
Issues
None identified.
Solutions
N/A.
Evaluation Criteria
An offering achieves full support if it satisfies the description for 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 | - | Not supported |
Websphere MQ Workflow | 3.4 | - | Not supported |
FLOWer | 3.0 | - | Not supported |
COSA | 4 | - | Not supported |
iPlanet | 3.1 | - | Not supported |
BPMN | 1.0 | - | Not supported |
UML | 2.0 | - | Not supported |
Oracle BPEL | 10.1.2 | - | Oracle BPEL PM offers no support for this pattern |
jBPM | 3.1.4 | - | jBPM does not support this pattern, as a work item can not be started by the system. A resource alone can initiate the execution of a work item. |
OpenWFE | 1.7.3 | - | OpenWFE does not support this pattern as a work item can not be started by the system. A resource alone can initiate the execution of a work item. |
Enhydra Shark | 2 | - | Enhydra Shark does not support this pattern. |
Summary of Evaluation
+ Rating |
+/- Rating |
---|---|
|
|