Pattern 3 (Deferred Distribution)

FLASH animation of Deferred Distribution pattern

Description

The ability to specify at design-time that the identification of the resource(s) to which instances of this task will be distributed will be deferred until runtime.

Example

Identification of who will execute the Assess Damage task is deferred until runtime. During execution of a case, the next_resource field will hold the identity of the resource to whom instances of the task should be allocated.

Motivation

Deferred Distribution takes the notion of indirect work distribution one step further and allows the process designer to defer the need to identify the resource for a specific task (or work items corresponding to the task) until runtime. One means of achieving this is to nominate a data field from which the identity of the resource to which a work item should be routed can be determined at runtime. The identity of the resource can be changed dynamically during process execution by updating the value of the data field, thus varying the resource allocation of future work items which are contingent on it.

Overview

The Deferred Distribution pattern is specified as a relationship between a task and a (non-empty) group of data elements. Each data element is assumed to hold either a resource or role name. At runtime, when an instance of the task is triggered, the values of the data element(s) is retrieved and are aggregated to give a set of resources to which work item(s) associated with the task may be distributed. The work item(s) is then distributed to these resources.

Context

There is one context condition associated with this pattern: the offering supports direct or role-based distribution.

Implementation

This approach to work distribution is generally achieved by associating the name(s) of the data element which will contain the resource identity with the task at design time. In order to facilitate this, the name needs to be a data element within the scope of the task at runtime - usually a case level data element. It is possible that more than one data element (and hence more than one resource) could be taken into account when deciding on the allocation at runtime. Staffware, WebSphere MQ and Oracle BPEL directly support this pattern.

Issues

Two significant issues arise in implementing this pattern:

Solutions

The first of these issues is usually addressed by ensuring that the names used for specific resources, groups and roles are disjoint. This means that a name cannot be used in more than one context and hence there is no potential for ambiguity at runtime.

The second issue is more problematic as a data element can potentially contain any value and there is no means of ensuring that it corresponds to an actual resource in the organisational model or to specify the action to take when the resource name is invalid.

Evaluation Criteria

Full support for this pattern is demonstrated by any offering which provides a construct which satisfies the description when used in a context satisfying the context assumption.

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