Pattern 21 (Resource-Initiated Allocation)
FLASH animation of Resource-Initiated Allocation pattern
Description
The ability for a resource to commit to undertake a work item without needing to commence working on it immediately.
Example
The Clerk selects the Town Planning work items that she will undertake today although she only commence working on one of these at this point.
Motivation
This pattern provides a means for a resource to signal its intention to execute a given work item at some point although it may not commence working on it immediately.
Overview
There are two variants of this pattern as illustrated by the bold arcs in Figure 5, depending on whether the work item has been offered to a single resource ( R:allocate_s ) or to multiple resources ( R:allocate_m ). In both cases, the work item has its status changed from offered to allocated. It remains in the work list of the resource which initiated the allocation. In the latter case, the work item has been offered to multiple resources and it is therefore necessary to remove it from all other work lists in which it may have appeared as an offer. This ensures that only the resource to which it is now allocated can actually commence working on it.
Context
There are no specific context conditions associated with this pattern.
Implementation
The implementation of this pattern generally involves the removal of the work item from a globally accessible or shared work list and its placement on a work queue specific to the resource to which it is allocated. Surprisingly only two of the offerings examined supports this function. COSA allows a resource to reserve a work item that is displayed on a shared or global worklist for later execution by a user, however in doing so, the entire process instance is locked by the resource until the work item is completed or the reserve timeout is reached. In FLOWer, cases are retrieved for a given resource via a case query which specifies the distribution criteria for cases that can be allocated to the resource. Where a resource executes a case query and a matching case is identified, all of the work items in the case are effectively allocated to the resource. Each of these work items is listed in the resource's work tray but is not commenced until specifically requested by the resource.
Issues
None identified.
Solutions
N/A.
Evaluation Criteria
An offering achieves full support if it satisfies the description for the pattern. It achieves a partial support rating if there are any side effects associated with the implementation 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 | - | Not supported |
Websphere MQ Workflow | 3.4 | - | Not supported |
FLOWer | 3.0 | + | Directly supported |
COSA | 4 | +/- | The act of a resource reserving a work item on a shared work list has the effect of locking the process instance |
iPlanet | 3.1 | - | Not supported |
BPMN | 1.0 | - | Not supported |
UML | 2.0 | - | Not supported |
Oracle BPEL | 10.1.2 | - | Oracle BPEL PM does not support this pattern directly. If a work item is assigned to a set of users or a group, one of the users in the list can "acquire" the task. However, this corresponds to the commence working on it immediately |
jBPM | 3.1.4 | - | jBPM does not support this pattern. |
OpenWFE | 1.7.3 | - | OpenWFE does not support this pattern. |
Enhydra Shark | 2 | - | Enhydra Shark does not support this pattern. In order to be initiated a work item first needs to be allocated, a state which does not exist in Enhydra Shark. |
Summary of Evaluation
+ Rating |
+/- Rating |
---|---|
|
|