The goal of this specification is to provide a simple extension to WS-BPEL 2.0 that enables atomic scopes. Atomic scopes allow the process definition to demarcate atomic transactions against any number of invoked services, and participate in a distributed transaction.
The extension defines atomic scope as an extension of the already defined isolated scopes. It describes the atomic semantics for state changing operatings, such as assignments, for service invocations and for receiving and responding to service calls. It also covers the use of compensation handlers and event handlers.
An atomic scope is marked with the attribute atomic set to yes. This attribute applies to processes, scope activities and event handlers (their implicit scopes).
Atomic scopes provide isolation semantics, inheriting these semantics from isolated scopes. However, atomic scopes are not isolated scopes, specifically their compensation handler do not have isolated semantics. Atomic scopes cannot be nested inside atomic scopes or isolated scopes, and cannot enclose isolated scopes.
Atomic scopes provide 'all-or-nothing'' behavior for all state changes made during the execution of activities inside the scope, and the status of all links crossing the scope boundary.
State changes include changes to variables, partner links and correlations sets declared in any scope enclosing the atomic scope. These state changes are not visible outside the atomic scope until the scope activity completes (successfully or unsuccessfully). These state changes are discarded if the atomic scope throws a fault in the enclosed scope.
The status of links that cross the boundary of an atomic scope and have a source activity inside the atomic scope is set only when the scope completes. If the scope completes without throwing a fault, the status of these links is set as per the result of their transition conditions. If the scope throws a fault, the status of all these links is set to false.
The status of message exchange is not affected by the atomic scope. Specifically all message exchanges made inside the atomic scope must complete before the scope is allowed to complete.
Since atomic scopes provide all-or-nothing semantics, assign activities inside the scope are not by themselves atomic. Rather, all assign activities occurring in the scope are collectively atomic, since the scope will discard all state changes if it throws a fault.
However, catching and handling the bpws:selectionFailure fault or any other fault throws by an assign activity could lead to partial assignments if the scope is allowed to complete. If fault handlers must be used inside the atomic scope, use them with discretion. This rule also applies to other unintended consequences of indiscriminately catching and handling faults inside an atomic scope.
Since atomic scopes are intended to complete in a short duration of time, they are not allowed to wait for events occurring outside the scope, with the exception of events that trigger the scope.
Atomic scope are not allowed to use the receive, wait and pick activities, except for the case described below. Atomic scopes are not allowed to use event handlers, including not in any scope nested within the atomic scope.
An atomic scope may begin by receiving a message from a partner. In this case it can use the receive activity if that receive activity is the first basic activity to execute in the scope and no other basic activity is allowed to execute before it. Alternatively, it can use a pick activity with two or more onMessage handlers if no other basic or pick activity is allowed to execute before it.
Such a scope may begin with the block activity sequence or flow as long as it can guarantee that the first basic activity to execute is the receive or pick activity. These restrictions are similar to the start activity of a process.
An onEvent event handler can use the atomic attribute to specify atomic behavior for its implicit scope. In this case, the received message is treated as if the event handler started with a receive activity for that message. All other atomic scope restrictions are applied to the implicit scope created by the event handler.
If an atomic scope has a receive activity for a request-response operation, it must also include all reply activities that may send the corresponding response message. Specifically, it is an error for a receive/reply pair to cross the boundaries of an atomic scope.
An atomic scope is allowed to include an activity that is the target of a link, where the source activity resides outside the scope, only if the status of the link is determined before the atomic scope begins executing that activity.
If the process engine detects a violation of these restrictions if must throw an atomic:scopeRollback fault. If the process engine detects such a violation during static analysis, it should reject the process definition.
Atomic scopes complete with one of three possible outcomes:
The first two outcomes are similar to the successful and unsuccessful completion of non-atomic scopes. The last outcome is the case of a non-atomic scope throwing a fault, with the exception that all state changes are discarded.
An atomic scope that catches a fault and its fault handler rethrows that fault or throws a different fault, would result in the rollback outcome and discard all state changes.
It is recommended not to use fault handlers inside atomic scopes, since atomic scopes already provide a mechanism for dealing with failure, and indiscreminate use of fault handlers could lead to partial state changes and other unexpected results. However, there are some cases where fault handling is necessary, and the spec allows the use of fault handlers to deal with these situations.
Atomic scopes are intended to execute for a short duration of time, in particular since they may tie up global resources beyond the specific process. Like atomic activities, they cannot be interrupted by a fault thrown in an enclosing scope. However, implementations would terminate scopes that take too long to complete. It is up to the implementation to decide on the appropriate time duration.
In terminating the atomic scope, the implementation must force a rollback outcome, effectively throwing an atomic:scopeRollback fault in the enclosing scope. The behavior is similar to the way termination occurs in non-atomic scopes, with the exception that the scope has to terminate quickly and all state changes are discarded. As such, atomic scopes are not allowed to use termination handlers.
The compensation handler associated with an atomic scope is not by itself atomic. Some atomic scopes can use atomic compensation, however, other atomic scopes can only use non-atomic compensation. We cannot enforce an atomic scope to have an atomic compensation handler. To perform atomic compensation, the compensation handler may itself use an atomic scope.
The behavior of a compensation handler depends not on the scope in which it is defined, but the scope in which it is invoked. This could lead to situations where the compensation handler is potentially invoked in three different and incompatible scopes.
Consider a non-atomic outer scope So, enclosing an atomic scope Sa, itself enclosing an inner scope Si (perhaps an invoke activity). The scope Si installs a compensation handler Ci. The default fault handler associated with the scope Si will invoke the compensation handler Ci in that atomic scope, and then discard all state changes (by rethrowing the fault).
The atomic scope Sa can have a compensation handler Ca that invokes the compensation handler Ci from a non-atomic scope. However, the outer scope So may have a compensation handler that invokes Ca and through it Ci from within an atomic scope. Besides these three explicitly defined handlers, we also have to consider default and defined compensation, fault and termination handlers of each enclosing scope. This makes it hard to define compensation handlers that execute reliably.
Atomic scopes are generally simple in their logic and do not benefit much from the ability to compose compensation handlers though invocation of inner compensation handlers. In favor of simplicity the specification imposes the following constraints:
Since scopes nested inside an atomic scope are not allowed to install compensation handlers, the default fault handling behavior of an atomic scope is to rethrow the fault. The behavior is consistent with the outcome that discards all state changes (scope rollback).
Since atomic scopes are not allowed to invoke compensation handlers explicitly, and are not allowed to enclose compensation handler, a compensation handler is never invoked from within an atomic scope, explicitly of from a default compensation handler or fault handler.
Atomic scopes are primarily used to provide all-or-nothing behavior that includes Web service invocations. As such they must use appropriate protocols that guarantee operations complete only if the scope completes, and rollback if the scope outcome is a rollback.
The atomic scope invokes a service using a distributed transaction protocol (e.g. WS-AtomicTransaction) to propagate a transaction context to the invoked service. The invoked service enrolls in the transaction and participates in determining the transaction outcome. An atomic scope must use the same transaction context with all services invoked in that scope.
An atomic scope that begins by receiving a message using a distributed transaction protocol must enroll in the transaction and participate in determining the outcome of that transaction. The atomic scope must then use that transaction context with all service invocations. If the scope begins without receiving a message, or receives a message without using a distributed transaction protocol, it creates its own transaction context.
The following rules govern the outcome of the atomic scope and associated distributed transaction:
atomic:scopeRollback.The invoke activity is not allowed to use the atomic attribute as a shortcut for a scope. However, it is allowed to use the atomic attribute with the value no to invoke a service without using a distributed transaction protocol. Such an invocation does not affect the rules above, but could break the isolation and atomicity semantics of the distributed transaction.
In either case, the service must be invoked using a synchronous protocol, such as sending the request and response messages over the same HTTP connection.
The atomic scope invokes a service using a one-way operation by sending the message only if the scope completes. If the scope throws a fault, the message is discarded. No transaction context is propagated to the invoked service, since the transaction must commit before the message is sent.
An atomic scope that receives a message from a one-way operation consumes the message only if the scope activity completes. If the scope throws a fault, the message is not consumed. As with one-way invoke, the one-way receive activity does not use a distributed transaction protocol.
A message that was consumed will not be available again to the process. A message that was not consumed may be available again to be received by a different receive activity, or by the same receive activity if the atomic scope is restarted. The availability of messages not consumed is left up to the implementation, this specification does not address the possibility of message loss.
Performing concurrent service invocations using the same transaction context can lead to a diamond scenario, whereby two services are operating on the same shared resource without any means to coordinate their work. Such scenarios are impossible to detect by looking at the process definition alone, and the risk from failure outweighs any benefits from allowing them.
In addition, assign activities are not atomic when enclosed in an atomic scope. As such, atomic scopes are not allowed to perform basic activities concurrently. Atomic scopes that use parallel composition such as the flow and foreach activity must serialize all basic activities with respect to each other. Basic activities can assume they are not executed concurrently, but cannot assume any order of execution unless they use links to establish dependencies.
Stuff that comes here: Namespace URL. Syntax for atomic attribute on scope/invoke. Definition of atomic:rollback fault. Reference to relevant specifications.