Author: buildbot
Date: Fri Nov 23 17:11:00 2012
New Revision: 839340
Log:
Staging update by buildbot for ode
Modified:
websites/staging/ode/trunk/content/ (props changed)
websites/staging/ode/trunk/content/atomic-scopes-extension-for-bpel.html
Propchange: websites/staging/ode/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Fri Nov 23 17:11:00 2012
@@ -1 +1 @@
-1412892
+1412987
Modified:
websites/staging/ode/trunk/content/atomic-scopes-extension-for-bpel.html
==============================================================================
--- websites/staging/ode/trunk/content/atomic-scopes-extension-for-bpel.html
(original)
+++ websites/staging/ode/trunk/content/atomic-scopes-extension-for-bpel.html
Fri Nov 23 17:11:00 2012
@@ -82,33 +82,33 @@
<div class="row">
<div class="span12">
<p><a name="AtomicScopesExtensionforBPEL-Introduction"></a></p>
-<h3 id="introduction">Introduction</h3>
-<p>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.</p>
+<h1 id="introduction">Introduction</h1>
+<p>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.</p>
<p>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.</p>
<p><a name="AtomicScopesExtensionforBPEL-AtomicScopes"></a></p>
-<h3 id="atomic-scopes">Atomic Scopes</h3>
-<p>An <em>atomic scope</em> is marked with the attribute <em>atomic</em> set
to <em>yes</em>. This attribute applies to processes, <em>scope</em> activities
and event handlers (their implicit scopes).</p>
+<h1 id="atomic-scopes">Atomic Scopes</h1>
+<p>An <em>atomic scope</em> is marked with the attribute <code>atomic</code>
set to <code>yes</code>. This attribute applies to processes, <em>scope</em>
activities and event handlers (their implicit scopes).</p>
<p>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.</p>
<p><a name="AtomicScopesExtensionforBPEL-StateChangesandAssignments"></a></p>
-<h3 id="state-changes-and-assignments">State Changes and Assignments</h3>
-<p>Atomic scopes provide '<em>all-or-nothing</em> behavior for all state
changes made during the execution of activities inside the scope, and the
status of all links crossing the scope boundary.</p>
+<h1 id="state-changes-and-assignments">State Changes and Assignments</h1>
+<p>Atomic scopes provide '<em>all-or-nothing</em>'' behavior for all state
changes made during the execution of activities inside the scope, and the
status of all links crossing the scope boundary.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>Since atomic scopes provide all-or-nothing semantics, <em>assign</em>
activities inside the scope are not by themselves atomic. Rather, all
<em>assign</em> activities occurring in the scope are collectively atomic,
since the scope will discard all state changes if it throws a fault.</p>
-<p>However, catching and handling the <em>bpws:selectionFailure</em> fault or
any other fault throws by an <em>assign</em> 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.</p>
+<p>However, catching and handling the <code>bpws:selectionFailure</code> fault
or any other fault throws by an <em>assign</em> 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.</p>
<p><a name="AtomicScopesExtensionforBPEL-ActivitiesThatWait"></a></p>
-<h3 id="activities-that-wait">Activities That Wait</h3>
+<h1 id="activities-that-wait">Activities That Wait</h1>
<p>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.</p>
<p>Atomic scope are not allowed to use the <em>receive</em>, <em>wait</em> and
<em>pick</em> 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.</p>
<p>An atomic scope may begin by receiving a message from a partner. In this
case it can use the <em>receive</em> activity if that <em>receive</em> 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 <em>pick</em>
activity with two or more <em>onMessage</em> handlers if no other basic or
<em>pick</em> activity is allowed to execute before it.</p>
<p>Such a scope may begin with the block activity <em>sequence</em> or
<em>flow</em> as long as it can guarantee that the first basic activity to
execute is the <em>receive</em> or <em>pick</em> activity. These restrictions
are similar to the start activity of a process.</p>
-<p>An <em>onEvent</em> event handler can use the <em>atomic</em> 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 <em>receive</em>
activity for that message. All other atomic scope restrictions are applied to
the implicit scope created by the event handler.</p>
+<p>An <em>onEvent</em> event handler can use the <code>atomic</code> 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 <em>receive</em>
activity for that message. All other atomic scope restrictions are applied to
the implicit scope created by the event handler.</p>
<p>If an atomic scope has a <em>receive</em> activity for a request-response
operation, it must also include all <em>reply</em> activities that may send the
corresponding response message. Specifically, it is an error for a
<em>receive</em>/<em>reply</em> pair to cross the boundaries of an atomic
scope.</p>
<p>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.</p>
-<p>If the process engine detects a violation of these restrictions if must
throw an <em>atomic:scopeRollback</em> fault. If the process engine detects
such a violation during static analysis, it should reject the process
definition.</p>
+<p>If the process engine detects a violation of these restrictions if must
throw an <code>atomic:scopeRollback</code> fault. If the process engine detects
such a violation during static analysis, it should reject the process
definition.</p>
<p><a name="AtomicScopesExtensionforBPEL-FaultsandTermination"></a></p>
-<h3 id="faults-and-termination">Faults and Termination</h3>
+<h1 id="faults-and-termination">Faults and Termination</h1>
<p>Atomic scopes complete with one of three possible outcomes:</p>
<ol>
<li><em>Successful Completion</em> -- The <em>scope</em> activity, process or
event handler completes without throwing a fault. For the <em>scope</em>
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.</li>
@@ -119,9 +119,9 @@
<p>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.</p>
<p>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.</p>
<p>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.</p>
-<p>In terminating the atomic scope, the implementation must force a rollback
outcome, effectively throwing an <em>atomic:scopeRollback</em> 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.</p>
+<p>In terminating the atomic scope, the implementation must force a rollback
outcome, effectively throwing an <code>atomic:scopeRollback</code> 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.</p>
<p><a name="AtomicScopesExtensionforBPEL-Compensation"></a></p>
-<h3 id="compensation">Compensation</h3>
+<h1 id="compensation">Compensation</h1>
<p>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.</p>
<p>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.</p>
<p>Consider a non-atomic outer scope <em>So</em>, enclosing an atomic scope
<em>Sa</em>, itself enclosing an inner scope <em>Si</em> (perhaps an
<em>invoke</em> activity). The scope <em>Si</em> installs a compensation
handler <em>Ci</em>. The default fault handler associated with the scope
<em>Si</em> will invoke the compensation handler <em>Ci</em> in that atomic
scope, and then discard all state changes (by rethrowing the fault).</p>
@@ -134,32 +134,32 @@
<p>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).</p>
<p>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.</p>
<p><a name="AtomicScopesExtensionforBPEL-WebServiceInvocation"></a></p>
-<h3 id="web-service-invocation">Web Service Invocation</h3>
+<h1 id="web-service-invocation">Web Service Invocation</h1>
<p>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.</p>
<p><a name="AtomicScopesExtensionforBPEL-Request-ResponseOperations"></a></p>
-<h4 id="request-response-operations">Request-Response Operations</h4>
+<h2 id="request-response-operations">Request-Response Operations</h2>
<p>The atomic scope invokes a service using a distributed transaction protocol
(e.g. <em>WS-AtomicTransaction</em>) 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.</p>
<p>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.</p>
<p>The following rules govern the outcome of the atomic scope and associated
distributed transaction:</p>
<ol>
<li><em>Commit</em> -- The atomic scope can complete, successfully or
unsuccessfully, only if the transaction outcome has been determined to be
<em>commit</em>.</li>
<li><em>Rollback on fault</em> -- If the atomic scope throws a fault, it must
vote for the outcome of <em>rollback</em>. Therefore, it must determine that it
can complete before allowing the transaction outcome of <em>commit</em>.</li>
-<li><em>Fault on rollback</em> -- If the transaction outcome is
<em>rollback</em> and the atomic scope has not thrown a fault, then it must
throw the fault <em>atomic:scopeRollback</em>.</li>
+<li><em>Fault on rollback</em> -- If the transaction outcome is
<em>rollback</em> and the atomic scope has not thrown a fault, then it must
throw the fault <code>atomic:scopeRollback</code>.</li>
<li><em>Retry</em> -- 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.</li>
</ol>
-<p>The <em>invoke</em> activity is not allowed to use the <em>atomic</em>
attribute as a shortcut for a scope. However, it is allowed to use the
<em>atomic</em> attribute with the value <em>no</em> 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.</p>
+<p>The <em>invoke</em> activity is not allowed to use the <code>atomic</code>
attribute as a shortcut for a scope. However, it is allowed to use the
<code>atomic</code> attribute with the value <code>no</code> 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.</p>
<p>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.</p>
<p><a name="AtomicScopesExtensionforBPEL-One-WayOperations"></a></p>
-<h4 id="one-way-operations">One-Way Operations</h4>
+<h2 id="one-way-operations">One-Way Operations</h2>
<p>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.</p>
<p>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 <em>invoke</em>, the one-way
<em>receive</em> activity does not use a distributed transaction protocol.</p>
<p>A message that was <em>consumed</em> will not be available again to the
process. A message that was not consumed may be available again to be received
by a different <em>receive</em> activity, or by the same <em>receive</em>
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.</p>
<p><a name="AtomicScopesExtensionforBPEL-Concurrency"></a></p>
-<h4 id="concurrency">Concurrency</h4>
+<h2 id="concurrency">Concurrency</h2>
<p>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.</p>
<p>In addition, <em>assign</em> 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 <em>flow</em> and <em>foreach</em> 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.</p>
<p><a name="AtomicScopesExtensionforBPEL-Appendix"></a></p>
-<h3 id="appendix">Appendix</h3>
+<h1 id="appendix">Appendix</h1>
<p>Stuff that comes here:
<em> Namespace URL.
</em> Syntax for atomic attribute on scope/invoke.
