[
https://issues.apache.org/jira/browse/ODE-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karthick Sankarachary updated ODE-396:
--------------------------------------
Attachment: atomic-scopes-and-processes.txt
This patch delivers the atomic scopes and processes feature.
> Atomic Scopes And Processes
> ---------------------------
>
> Key: ODE-396
> URL: https://issues.apache.org/jira/browse/ODE-396
> Project: ODE
> Issue Type: New Feature
> Components: Axis2 Integration, BPEL Compilation/Parsing, BPEL
> Runtime, JBI Integration
> Affects Versions: 1.2
> Environment: platform-independent
> Reporter: Karthick Sankarachary
> Fix For: 2.0
>
> Attachments: atomic-scopes-and-processes.txt
>
> Original Estimate: 504h
> Remaining Estimate: 504h
>
> In general, WS-BPEL processes are susceptible to transient errors that stem
> from faulty service interactions. Most real-world applications make an
> attempt to recover gracefully from such errors by retrying the piece of work
> that failed, taking care to roll it back first. If the probability of the
> error reoccurring is low, then chances are that the application will be able
> to move forward. To facilitate this type of behavior in WS-BPEL, we introduce
> the notion of atomicity that (a) guarantees all-or-nothing semantics (b)
> induces rollback-and-retry on transient errors and (c) induces
> rollback-and-fault on persistent errors.
> We define atomicity in terms of the "atomic" extension attribute (marked
> "yes"), which may be applied on the following WS-BPEL elements:
> a) The <process> element, which denotes the top-most unit-of-work, and has an
> implicit scope of its own. If the process starts with an inbound message
> activity, then in case of a rollback, the process will block until a new
> message is received.
> b) The <scope> element, which denotes a fine-grained unit-of-work and
> provides the context for its enclosed activity. If the scope starts with an
> inbound message activity, then in case of a rollback, the scope will block
> until a new message is received.
> c) The <onEvent> element, which denotes a concurrent unit-of-work and is
> triggered by an inbound message. Note that its atomicity is independent of
> that of its enclosing scope. Also, while the child within an event handler is
> always a <scope> activity, making that atomic will not cause the process to
> block until a new event arrives.
> Note that in order to achieve the all-or-nothing behavior, we must begin,
> commit or rollback a JTA global transaction when the execution of an atomic
> element starts, succeeds or fails, respectively. In addition, we implicitly
> commit the process when it hits a blocking activity, such as a receive.
> Consequently, we disallow the use of a <receive> activity anywhere inside an
> atomic activity, except as its first basic activity. A healthy side-effect of
> this constraint is that it frees us from deadlocks that might otherwise arise
> due to circular service interactions.
> The retry logic of atomic activities may be configured using the following
> two configuration properties:
> a) scopes.atomic.retry.count: This number indicates the number of times the
> atomic activity will be "retried" before it gives up, which defaults to 3.
> Specifically, it may be executed at most one more time than this count.
> Strictly speaking, the first attempt at executing the atomic activity is not
> considered to be a "retry".
> b) scopes.atomic.retry.delay: This number indicates the number of seconds the
> process will wait before "retrying" a previously failed atomic activity,
> which defaults to one minute.
> If the atomic activity successfully completes during its first try or one of
> its subsequent retries, the process will proceed to the following activity,
> as it normally would have. If the atomic activity repeatedly fails and the
> allowed number of retries is exceeded (i.e., the error is no longer
> transient, but rather persistent), it will in turn throw a ode:scopeRollback
> fault, which may be caught and handled by one of its enclosing scopes (or
> not).
> Let us now discuss the rollback aspect of an atomic activity. In the event of
> a failure, before we retry it, we will revert the state of the process back
> to the point when it was just about to commence execution. As a result, we
> discard any change to the process state caused by copy operation assignments,
> message activity variable and correlation initialization, link status
> evaluations, and so on. Furthermore, one-way messages meant to be sent on
> success are discarded and two-way messages already sent have the consumed
> service rolled back. Speaking of two-way messages, we limit the scope of our
> initial implementation to message exchanges with processes and services that
> co-exist in the same server (node). Supporting atomicity across external
> services would require the use of a web service transaction protocol such as
> WS-AtomicTransaction, but that standard is neither specified nor implemented
> fully.
> For more details, please refer to
> http://ode.apache.org/atomic-scopes-extension-for-bpel.html.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
