Scopes

As suggested in Figure 7.3, the scope is a world of meaning, where the names of some variables and handlers are known and where specific data values and handler effects are available, while the names of other variables and handlers are unknown. A scope includes a single activity, which (if structured) can include others. An important characteristic is that a scope can be compensated without interfering with the behavior of activities and handlers in other scopes.

Figure 7.3: Scope

A BPEL process can include many scopes, and they provide a way for you to organize your work. Each scope

• can include one or more scopes, called nested scopes.

• can have peer scopes, which are scopes that are neither nested nor nesting in relation to one another.

• can include (within a nested scope) other nested scopes, to any nesting depth, as suggested in Figure 7.4. All the nested scopes within a scope are said to be the scope's descendants. All superior scopes are said to be ancestor scopes, and an immediately superior scope is said to be a parent.

Figure 7.4: Peer and nesting scopes

The rules of access for each category of name (for variables, partner links, and so on) are similar to the rules in other languages. Consider the case of variables:

• Variables declared in the topmost level of a process are global to the process.

• Variables declared in a scope are visible both in the scope and in the scope's descendants.

• Variables declared in a scope are not visible to any ancestor or peer scopes.

• A variable declared in a nested scope hides any same-named variable in a superior scope, and the variable in the superior scope is hidden not only from the nested scope but also from descendants of the nested scope.

A scope can include its own partner links, variables, correlation sets, event handlers, fault handlers, and message exchanges. In addition, two other handlers are available in a scope. A compensation handler is a set of activities that compensate for a change made successfully by the scope and that run after being invoked by a parent scope. A termination handler is a set of activities issued when a running scope is being forced to terminate.

The BPEL engine forces termination in any of the following cases:

• if the BPEL process has faulted

• if an ancestor scope has faulted

• if the scope is in a compensation handler, fault handler, or termination handler and the handler has faulted

• if a particular situation is in effect inside a forEach activity, as described in Chapter 8

When a scope is active at run time, the embedded event handlers are available, along with the scope's other activities. A scope

• is active as soon as the BPEL engine issues an activity in the scope

• is active until the BPEL engine gives control to a different scope (other than a descendant) or to the top level of the process

• begins and ends several times if embedded in a loop or event handler

A scope is said to have completed successfully if no faults occur in the scope. A fault may occur in a nested scope, however, and if the fault is handled without affecting the scope that encloses the nested scope, the enclosing scope may complete successfully.

If a fault occurs in a scope, the scope is said to have failed, and compensation is unavailable. Last, if the scope is in a loop, compensation is available only for the scope instances that succeeded.