Pattern 3 (Scope Data)

FLASH animation of Scope Data pattern

Description

Data elements can be defined which are accessible by a subset of the tasks in a case.

Example

The initial tax estimate variable is only used within the Gather Return Data, Examine Similar Claims and Prepare Initial Return tasks in the Prepare Tax Return process.

Motivation

Where several tasks within a process coordinate their actions around a common data elements or set of data elements, it is useful to be able to define data elements that are bound to that subset of tasks in the overall process.

Overview

One of the major justifications for scopes in processes is that they provide a means of binding data elements, error and compensation handlers to sets of related tasks within a case. This allows for more localized forms of recovery action to be undertaken in the event that errors or concurrency issues are detected. Figure 4 illustrates the declaration of data element X which is scoped to tasks A, B and C. It can be freely accessed by these tasks but is not available to tasks D and E.

Figure 4: Scope level data visibility

Context

There are no specific context conditions associated with this pattern.

Implementation

The definition of scope data elements requires the ability to define the portion of the process to which the data elements are bound. This is potentially difficult in PAIS that are based on a graphical process notation but less difficult for those that utilise a textual definition format such as XML.

A significant distinction between scopes and blocks in a process context is that scopes provide a grouping mechanism within the same address space (or context) as the surrounding case elements. They do not define a new address space and data passing to tasks within the scope does not rely on any specific data passing mechanisms other than normal task-to-task data transfer facilities.

BPEL is the only offering examined that fully supports the notion of scope data elements. It provides support for a scope construct which allows related tasks, variables and exception handlers to be logically grouped together. FLOWer supports "restricted data elements" which can have their values set by nominated tasks although they are more widely readable.

Issues

The potential exists for variables named within a scope to have the same name as a variable in the surrounding block in which the scope is defined.

Solutions

The default handling for this BPEL is that the innermost context in which a variable is defined indicates which variable should be used in any given situation. Variables within a given scope must be unique.

Evaluation Criteria

An offering achieves full support if it satisfies the description for the pattern. It achieves a partial support rating if the accessibility of data elements cannot be restricted to the defined scope.

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