Pattern 23 (Resource-Initiated Execution - Offered Work Item)
FLASH animation of Resource-Initiated Execution - Offered Work Item pattern
Description
The ability for a resource to select a work item offered to it and commence work on it immediately.
Example
The Courier Driver selects the next Delivery work item from those offered and commences work on it.
Motivation
In some cases it is preferable to view a resource as being committed to undertaking a work item only when the resource has actually indicated that it is working on it. This approach to work distribution effectively speeds throughput by eliminating the notion of work item allocation. Work items remain on offer to the widest range of appropriate resources until one of them actually indicates they can commence work on it. Only at this time is the work item removed from being on offer and allocated to a specific resource.
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:start_s) or to multiple resources (R:start_m). In both cases, the work item has its status changed from offered to started. It remains in the work list of the resource which initiated the work item. 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 one resource can actually work on it.
Context
There are no specific context conditions associated with this pattern.
Implementation
This approach to work distribution is adopted by Staffware, WebSphere MQ and COSA for shared work queues (e.g. group queues). For these systems, a work item remains on the queue until a resource indicates that it has commenced it. At this point, its status changes and no other resource can execute it although it remains on the shared queue until it is completed. iPlanet and Oracle BPEL adopt a similar approach for all work items and effectively presents each resource with a single amalgamated queue of work items allocated directly to it and also those offered to a range of resources. The resource must indicate when it wishes to commence a work item. This results in the status of the work item changing and it being removed from any other work queues on which it might have existed.
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 | + | Directly supported for group queues |
Websphere MQ Workflow | 3.4 | + | Supported for work items distributed via shared work queues |
FLOWer | 3.0 | - | Not supported |
COSA | 4 | + | Supported for work items on shared work queues |
iPlanet | 3.1 | + | Standard approach to initiating work items |
BPMN | 1.0 | - | Not supported |
UML | 2.0 | - | Not supported |
Oracle BPEL | 10.1.2 | + | Oracle BPEL PM supports this pattern directly. When a user is offered a work item, and the user "acquires" it, he commences work on it immediately |
jBPM | 3.1.4 | - | jBPM does not support this pattern. |
OpenWFE | 1.7.3 | + | In OpenWFE, a work item offered to a shared group list is automatically started by a resource in the group by the resource selected "edit" for that work item. |
Enhydra Shark | 2 | + | Enhydra Shark supports this by resources ticking the work items they intend to perform. Selected work items become becomes automatically started, their start time is set and they become invisible for the remainder of the resources in a group (if any). |
Summary of Evaluation
+ Rating |
+/- Rating |
---|---|
|
|