Pattern 13 (Distribution by Offer - Multiple Resources)
The ability to distribute a work item to a group of selected resources on a non-binding basis.
The Sell portfolio work item is offered to multiple Stockbrokers .
This pattern provides a means of distributing a work item to multiple resources on a non-binding basis. The resources are informed of the work item being offered but are not committed to executing it and can either ignore the work item or redistribute it to other resources should they choose not to undertake it.
Offering a work item to multiple resources is the process analogy to the act of "calling for a volunteer" in real life. It provides a means of advising a suitably qualified group of resources that a work item exists with the expectation that one of them will actually commit to undertaking the activity although the onus is still with the system to find a suitable resource should none of them agree to undertake it. Once a task has been enabled that is distributed on this basis, a means of actually informing the selected resources of the pending work item is required. The mechanism chosen, should notify the resources that a work item exists that they may wish to undertake, however it should not commit any of the resources to its execution. Typically this is achieved by adding the work item to the work lists of the selected resources with an offered status although other notification mechanisms are possible. This pattern directly corresponds to the state transition denoted by arc S:offer_m in Figure 4.
There are no specific context conditions associated with this pattern.
Several offerings support the notion of work groups and allow work items to be allocated to them. A work group is a group of resources with a common organisational focus. When a work item is allocated to the group, each of the members of the group is advised of its existence, but until one of them commits to starting it and advises the system of this fact, it remains on the work queue for each of the resources.
There are several possibilities for resources being advised of group work items - they may appear on each of the individual resource's work queues, each resource may have a distinct work queue for group items on which they may appear or all resources in a work group may have the ability to view a shared group work queue in addition to their own dedicated work queue (footnote 2).
Distinct offerings handle the offering of a work item to multiple resources in different ways:
- WebSphere MQ and Oracle BPEL both treat work items offered to multiple resources in the same way as work items allocated to a specific resource and they appear on the work list of resources to whom they are offered. When a multiply-offered work item is accepted by one of the resources to which it is offered, it is removed from the work lists of all other resources.
- Staffware and COSA support the concept of distinct user specific work queues and group work queues. Where a multiply-offered work item is accepted by a resource, it remains on the group work list but is not able to be selected for execution by other resources.
- iPlanet supports distinct work queues for offered and queued (i.e. allocated) work items. Once a multiply-offered work item has been accepted by a resource, it is removed from all offered work queues and only appears on the queued list for the resource which has accepted it.
An offering achieves full support if it satisfies the description of the pattern.
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||+||Directly supported for group queues|
|Websphere MQ Workflow||3.4||+||Work queues combine work item items specifically offered to this resource and those offered to multiple resources|
|FLOWer||3.0||+||Default work allocation mechanism is to offer a work item to all participants in a role|
|COSA||4||+||Directly supported for multiple resources via group queues|
|iPlanet||3.1||+||Directly supported for offered and queued work items|
|Oracle BPEL||10.1.2||+||Oracle BPEL PM supports this pattern directly by specifying the name of a group as an assignee of the task. As a result, the task will be offered to all members of a group, and any of the members may acquire it. After the work item has been acquired, not other users may acquire this work item any more.|
|jBPM||3.1.4||-||jBPM does not support this pattern.
(In a later tested release (i.e. 3.2.1), jBPM seems to be preparing support for distribution by offer to multiple resources, however such support is not yet available.)
|OpenWFE||1.7.3||+||OpenWFE supports distribution by offer to multiple resources.|
|Enhydra Shark||2||+||Enhydra Shark supports distribution to a single resource by supporting mapping of a Participant in the workflow model to a Group User to whose participants the work items are offered.|
Summary of Evaluation