Pattern 21 (Resource-Initiated Allocation)

FLASH animation of Resource-Initiated Allocation pattern


The ability for a resource to commit to undertake a work item without needing to commence working on it immediately.


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.


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.


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.


There are no specific context conditions associated with this pattern.


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.


None identified.



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.





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

  1. Resources are able to commit to executing an offered work item, resulting in it being allocated to their work queue. They are not obliged to commence working on it immediately.
  1. Resources can reserve a work item for later execution by suspending execution of the workflow case.