Pattern 30 (Stateful Reallocation)
The ability of a resource to allocate a work item that they are currently executing to another resource without loss of state data.
Stateful Reallocation provides a resource with the ability to offload currently executing work items to other resources whilst maintaining the current state of the work item and the results of work undertaken on it to date. In the main, this centres on the ability to retain the current values of all data elements associated with the work item. It is motivated by the need for a resource to pass on a work item to another resource without losing the benefit of any work that has already been undertaken in regard to it.
This pattern corresponds to the R:reallocation_with_state arc in Figure 6. It is interesting to note the similarities between this pattern and the Delegation pattern. Both patterns result in a work item being reassigned to another resource. The main difference between them is that Delegation can only occur for a work item that has not yet commenced execution where as this pattern applies to work items that are currently being executed.
There are no specific context conditions associated with this pattern.
Staffware, WebSphere MQ, COSA and Oracle BPEL all support the notion of reallocating a work item to another resource with preservation of state in some form. Staffware only allows suspended work items to be reallocated hence it achieves a partial support rating. WebSphere MQ, COSA and Oracle BPEL provides support for reallocation through the transfer, reroute and reassign functions respectively.
There are two potential issues associated with the reallocation of a work item to another resource whilst still preserving state information: (1) managing the transfer of state data without introducing issues related to the concurrent use of the same data elements and (2) ensuring the resource to which the work item is reallocated is entitled to execute it and access the associated state information.
There are a number of potential solutions to the first of these issues. One solution is to limit access to relevant state data elements to the resource executing the work item. This is the approach adopted by WebSphere MQ and COSA which use data containers to manage the data elements being passed between work items and work item specific data elements to manage state respectively. Staffware neatly avoids this issue by only allowing work items that suspended to be reallocated.
The second of these issues is potentially more problematic. Staffware and WebSphere MQ do not impose any restrictions on the resources to which work items can be reallocated and any reassignments that a resource makes may be potentially inconsistent with the work distribution strategy implied by the process model. COSA provides an authorisation framework over work items in addition to the work distribution mechanism. Where a work item is reallocated to another resource, that resource must have the required authorisation to execute the task otherwise they will not be able to undertake it and will be required to further reallocate it to a resource that can.
An offering achieves full support if it satisfies the description for the pattern. It achieves a partial support rating if there are any limitations on the type of work items that can be reallocated.
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||+/-||Only supported for pending (not started) activities|
|Websphere MQ Workflow||3.4||+||Supprted for pending and suspended items|
|COSA||4||+||Supported though the reroute function|
|Oracle BPEL||10.1.2||+||Any work item can be "reassigned" to a new set of users/group. If the user has updated a task, after the reassignment the data provided by this user is visible to the new assignee, i.e. the state data is not lost|
|jBPM||3.1.4||-||jBPM does not support this pattern.|
|OpenWFE||1.7.3||+||In OpenWFE, once started a work item can be reallocated to another group of resources, which is done through the "delegate" menu. This form of reallocation is stateful. Reallocation of a work item can only be initiated by users who possess the "delegate" right on the store for which they are executing the work item in question.|
|Enhydra Shark||2||-||Enhydra Shark does not support this pattern. The Reassign button in the Work list Console is currently not enabled.|
Summary of Evaluation