Just a few quick observations on the atomic scopes<http://ode.apache.org/atomic-scopes-extension-for-bpel.html> spec:
a) The state of a scope consists of not just its variables but also its correlation sets. So, just like assigns are collectively atomic, correlation sets must be collectively atomic too. The easiest way to implement this would be to take a checkpoint of all variable and correlation state when the atomic scope begins, so that if anything should go wrong, we simply rollback to that checkpoint. b) The spec doesn't say how atomic scopes should be retried in the case of faults. Apparently, there already exists a fault & recovery<http://ode.apache.org/activity-failure-and-recovery.html> spec that addresses retries. To use that feature, I suggest replacing the atomic:scopeRollback fault with the ext:activityFailure fault. In particular, if a two-way invoke inside an atomic scope fails due to a distributed rollback or some other invoke-specific fault, then it should throw an ext:activityFailure, which is caught and retried in the <ext:failureHandling> element defined for the atomic scope. In addition, we should extend the failure mechanism to the other message activities, such as receive and reply, so that they too are able to trigger the retry mechanism in an atomic scope. c) In section 4, the spec says that the receive/reply must not cross the boundary of the atomic scope. However, this is not really a new requirement, since the standard already says that a bpel:missingReply be thrown in such cases. d) Is there a reason why we can't propagate the transaction context in one-way invokes? The spec contradicts itself by saying that "one-way receives doesn't use a distributed transaction protocol" (in section 7.2), and stating that "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" (in section 7.1). Personally, I think that both one-way receives and one-way invokes should propagate the transaction context, if at all possible. In the case of one-way invokes, we should try to send the message right away along with the context, and perform a 2-phase commit with the invoked service when the scope ends. If the transaction context cannot be propagated, then we should wait for the atomic scope to end before sending the message. Similarly, in the case of one-way receives, if the incoming message contains a transaction context, then we consume the message (from our internal queue) right away. If no context was sent, then we consume the message only if the atomic scope completes, because the partner will not re-send it. e) In addition to intermediate one-way invokes, we should allow intermediate one-way receives too. I understand the need to keep atomic scopes short-running, but there may be cases where you may want an intermediate receive to be part of the atomic transaction. If the message sent to a one-way receive has a transaction context, then the atomic scope joins with the partner's transaction. When the atomic scope ends, we first prepare all global transactions, and commit all transactions only if all the prepares were successful. To ensure that such atomic scopes don't run forever, the user should be able to optionally set a transaction timeout. f) What kinds of distributed transaction protocols do we want to support? There's a Axis2-based implementation of WS-AtomicTransaction called Kandula, but that's only going to work for the Axis2 IL. What about the SCA and JBI ILs? Alternatively, do we want to use JTA in the case of message activities that are backed by a co-located resource, such as a database? The advantage of JTA is that it is not IL-specific, but on the flip side, it is not a generic solution. Best Regards, Karthick Sankarachary
