Author: vanto
Date: Fri Nov 23 17:10:52 2012
New Revision: 1412987
URL: http://svn.apache.org/viewvc?rev=1412987&view=rev
Log:
markup fix.
Modified:
ode/site/trunk/content/atomic-scopes-extension-for-bpel.mdtext
Modified: ode/site/trunk/content/atomic-scopes-extension-for-bpel.mdtext
URL:
http://svn.apache.org/viewvc/ode/site/trunk/content/atomic-scopes-extension-for-bpel.mdtext?rev=1412987&r1=1412986&r2=1412987&view=diff
==============================================================================
--- ode/site/trunk/content/atomic-scopes-extension-for-bpel.mdtext (original)
+++ ode/site/trunk/content/atomic-scopes-extension-for-bpel.mdtext Fri Nov 23
17:10:52 2012
@@ -1,19 +1,20 @@
Title: Atomic Scopes Extension for BPEL
+
<a name="AtomicScopesExtensionforBPEL-Introduction"></a>
-### Introduction
-The goal of this specification is to provide a simple extension to WSBPEL 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.
+# 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.
<a name="AtomicScopesExtensionforBPEL-AtomicScopes"></a>
-### 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
+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.
<a name="AtomicScopesExtensionforBPEL-StateChangesandAssignments"></a>
-### 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 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.
@@ -21,35 +22,35 @@ The status of links that cross the bound
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.
+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.
+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.
<a name="AtomicScopesExtensionforBPEL-ActivitiesThatWait"></a>
-### Activities That Wait
+# 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.
+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.
+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.
+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.
+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.
+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.
+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.
<a name="AtomicScopesExtensionforBPEL-FaultsandTermination"></a>
-### Faults and Termination
+# 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.
+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.
@@ -59,64 +60,64 @@ It is recommended not to use fault handl
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.
+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.
<a name="AtomicScopesExtensionforBPEL-Compensation"></a>
-### Compensation
+# 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).
+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.
+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).
+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.
<a name="AtomicScopesExtensionforBPEL-WebServiceInvocation"></a>
-### Web Service Invocation
+# 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.
<a name="AtomicScopesExtensionforBPEL-Request-ResponseOperations"></a>
-#### 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.
+## 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.
+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.
+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.
<a name="AtomicScopesExtensionforBPEL-One-WayOperations"></a>
-#### One-Way Operations
+## 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.
+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.
+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.
<a name="AtomicScopesExtensionforBPEL-Concurrency"></a>
-#### Concurrency
+## 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.
+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.
<a name="AtomicScopesExtensionforBPEL-Appendix"></a>
-### Appendix
+# Appendix
Stuff that comes here:
* Namespace URL.
* Syntax for atomic attribute on scope/invoke.
