Pattern 30 (Stateful Reallocation)

FLASH animation of Stateful Reallocation pattern

Description

The ability of a resource to allocate a work item that they are currently executing to another resource without loss of state data.

Example

Motivation

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.

Overview

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.

Context

There are no specific context conditions associated with this pattern.

Implementation

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.

Issues

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.

Solutions

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.

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 limitations on the type of work items that can be reallocated.

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.

Summary of Evaluation