Pattern 3 (Deferred Distribution)

FLASH animation of Deferred Distribution pattern


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.


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.


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.


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.


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


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.


Two significant issues arise in implementing this pattern:

  • Determining whether the value in the data field relates to a specific resource, group or role name. This determination is important as it varies the approach taken to work distribution.
  • Ensuring that the data field contains a valid resource identity.


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.





Staffware 9 + Directly supported
Websphere MQ Workflow 3.4 + Directly supported
FLOWer 3.0 - Not supported
COSA 4 - Not supported
iPlanet 3.1 - Not supported
BPMN 1.0 - Not supported
UML 2.0 - Not supported
Oracle BPEL 10.1.2 + Oracle BPEL PM supports this pattern directly. It allows specifying a task assignee by means of an XPath expression which is evaluated at run time
jBPM 3.1.4 + jBPM supports deferred allocation. It is implemented using variables which receive their values at runtime before the commencement of the relevant task.
OpenWFE 1.7.3 + OpenWFE supports deferred allocation. It is implemented using variables which receive their values at runtime before the commencement of the relevant task.
Enhydra Shark 2 + Enhydra Shark does not support deferred allocation. It is implemented using variables. A Performer variable can be specified for an activity and its value set during runtime.

Summary of Evaluation

+ Rating

+/- Rating

  1. Workflow engine provides support for nominating the allocation strategy for a work item at run-time.
  2. Identification for the resource allocation is derived from a data fields.
  3. Direct, group or role-based allocation is supported.
  1. Similar effect can be achieved through programmatic extensions