Title: Atomic Scopes Extension for BPEL Category: documentation # Introduction 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. # Atomic Scopes 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. # State Changes and Assignments 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. # Activities That Wait 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. # Faults and Termination Atomic scopes complete with one of three possible outcomes: 1. *Successful Completion* -- The *scope* activity, process or event handler completes without throwing a fault. For the *scope* activity this also includes evaluation of all transition conditions. All state changes made by the scope become visible to enclosing scopes and the compensation handler is installed. 1. *Unsuccessful Completion* -- A fault is thrown in the atomic scope and is handled by a fault handler. The behavior is similar to successful completion with the exception that the compensation handler is not installed. 1. *Scope Rollback* -- A fault is thrown by the *scope* activity or event handler, or the process terminates. All state changes made by the scope are discarded, no compensation handler is installed, and the status of all links originating from the scope is set to false. 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. # Compensation 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: 1. *Installing* -- Scopes nested inside an atomic scope (including the *invoke* activity shortcut) are not allowed to define a compensation handler. 1. *Invoking* -- Atomic scopes are not allowed to invoke any compensation handler through use of the *compensate* and *compensateScope* activities (or any other mechanism). 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. # Web Service Invocation 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. ## Request-Response Operations 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: 1. *Commit* -- The atomic scope can complete, successfully or unsuccessfully, only if the transaction outcome has been determined to be *commit*. 1. *Rollback on fault* -- If the atomic scope throws a fault, it must vote for the outcome of *rollback*. Therefore, it must determine that it can complete before allowing the transaction outcome of *commit*. 1. *Fault on rollback* -- If the transaction outcome is *rollback* and the atomic scope has not thrown a fault, then it must throw the fault ```atomic:scopeRollback```. 1. *Retry* -- In cases 2 and 3, when the atomic scope creates the transaction context, the implementation is allowed to rollback the transaction and execute the scope again using a different transaction context. 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. ## One-Way Operations 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. ## Concurrency 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. # Appendix Stuff that comes here: * Namespace URL. * Syntax for atomic attribute on scope/invoke. * Definition of atomic:rollback fault. * Reference to relevant specifications.