Re: [wsbpel] Issue 147 - Proposal For Vote

[Alex Yiu <alex.yiu@oracle.com>]

Hi, Yaron,
(cc'ing Assaf and Satish as well)

Yaron Y. Goland wrote: (in an email on Issue 6.2 thread)

Indeed, I don't see any compelling reason to introduce an explicit scope on D. It doesn't add anything. In fact, if you want to start slapping scopes everywhere then you should first start with event handlers who have a similar variable assignment issue to for-each.

    Yaron

Alex Yiu wrote:

(D) BTW, if we pass Issue 147 parallel for-each, I tend to think a scope-based restriction should be applied again to child activity in a parallel-each for to hold the iterator value properly for compensation  ... (Of course, that should be the discussion of 147 ... and of course ... Yaron will yell at me again after he read this part of email ... )

[1]
Yes indeed. There are similarity between parallel for-each and event handler.
Yaron ... you prompt me to ask a number of questions regarding to our compensation model that I have in my mind for a while ... But never got a chance to ask. Now, it's time to ask.

Consider this scope:
<scope name="A1">
    ...
    <eventHandlers>
        <onEvent partnerLink="buyer" operation="cancel"
                 messageType="ns:cancelOrder" variable="cancelDetails" >
             ...
        </onEvent>
    </eventHandlers>
    ...
</scope>

[a]
In the current text of the spec, we do NOT explicitly state that whether the compensation handler of scope "A1" is supposed to undo the work of eventHandlers for "cancel" from "buyer".
One way or the other: we SHOULD state that explicitly.

[b]
If we say the compensation handler is NOT supposed to undo the work of eventHandlers, then our life is simple.

Else-If we say the compensation handler is NOT supposed to undo the work of eventHandlers, then here are problems/questions:

• Typically "cancel" operation is called multiple times within the lifetime of scope "A1". And, multiple copies of "cancelDetails" variables got created.
  
• One of core concept in our compensation model is "scope snapshot", which freezes the local states which will be used later by the compensation handler (of scope "A1" in this example.)
• Assume that for now the onEvent handler of "cancel" does not have a local scope attached to it. The life span of "cancelDetails" are not well-defined in our spec as of these moment. Are multiple copies of "cancelDetails" considered the local states of scope "A1"?
• If we consider them local, how do we freeze them? How do we make them available and exposed properlty to the logic inside the compensation handler of scope "A1"? Even if we find a way to expose that collection of "cancelDetails" copies, I believe the compensation logic for eventHandler work would be much easier to express, if we express it locally within the eventHandler itself.
  

That's why I prefer:

• having a <scope> as the child activity of eventHandlers, OR,
• or have eventHandler based "tScope" syntax. (I believe that is what Assaf mentioned before.)
  

[2]
<invoke> marco - a potential trap for naive users?

If we treat the convenient syntax of adding <compensationHandler> and etc into <invoke> as a pure macro, we may have created a potential trap for naive users when a variable is being reused more than once in a scope.

Quoted from the spec:
"Semantically, the specification of local fault and/or compensation handlers is equivalent to the presence of an implicit scope immediately enclosing the activity and providing those handlers. The name of such an implicit scope is always the same as the name of the activity it encloses."

Consider this example:

<scope name="A2">
  <sequence>
    <receive variable="orderVar" operation="receiveOrder" ... />
    <!-- orderVar = Order#A54321 -->
    <!-- some other BPEL logic here to validate the order -->
    <invoke name="inv01" inputVariable="orderVar" operation="processOrder" ... >
          <compensationHandler>
                <invoke inputVariable="orderVar" operation="cancelOrder" ... >
          </compensationHandler>
    </invoke>
    <!-- process second order -->
    <receive variable="orderVar" operation="receiveOrder" ... />
    <!-- orderVar = Order#B34567 -->
    <!-- some other BPEL logic here to validate the order ... NOW a fault happened here ... -->
    <invoke name="inv02" inputVariable="orderVar" operation="processOrder" ... >
          <compensationHandler>
                <invoke inputVariable="orderVar" operation="cancelOrder" ... >
          </compensationHandler>
    </invoke>
  </sequence>
</scope>

A scope recieves and processes two orders (Order#A54321 and Order#B34567).

The above BPEL may look correct and normal to most BPEL users.

But in fact if one looks more closely, the compensation logic is actually specified incorrectly. If a fault happen before invoke "inv02", then the value of "orderVar" is already pointing to "Order#B34567".  And, the fault will trigger a fault handler which will trigger the compensation of completed child scope (in this case "inv01"). And, the compensation logic for "inv01" will be executed with a wrong order!

If people specify the compensation logic in a full blown compensation handler of scope "A2", people will more naturally think about what values should be put into the "cancelOrder" call, as opposed to the implicit presumption one may make about the values of "orderVar" based on syntax proximity location in the shortcut version of compensation logic.

Suggestion:
(a) we may want to revise the "scope snapshot" semantic for this implicit scope for syntax shortcut, OR,
(b) we should put more on warning notes on this potential pitfall in the spec for both BPEL end users and BPEL vendors.

I may try to file "bug issues" to track down the above situation ...

[3]
Back to the parallel for each discussion:
Actually, I have difficulty in coming up meaning-rich examples of a parallel-foreach without using scope as a child activity. Because, most typical parallel-foreach naturally needs a local partnerLink or local variables to hold the "output" or "intermediate" result of individual branches. Without using a <scope> as a child activity, both forward-work within the sequence within the for-each and the backward work in compensation handler becomes unnecessarily complicated and prone to buggy. (If you guys really need an example to be convinced about my point, I would be happy to do so in my next email)

Ok. Let's say we have an extreme simple parallel-foreach which does not need any local partnerLink or variables.

<scope name="A3">
  ...
  <sequence>
     ...
     <foreach iteratorVariableName="POVar"
        iteratorVariableType="..." parallel="yes">
         <expression>for_each_element_in_the_list_of_POs</expression>
                  <invoke partnerLink="Seller" operation="syncSendPO" inputVariable="POVar" ... />
     </foreach>
     ...
  </sequence>
  ...
</scope>

The very same problem that I described in [1] for eventHandler occurs again for "POVar" the iteratorVariable. What is the lifetime of "POVar"? How do we handle the "scope snapshot" aspect for these "POVar" for compensation handler of scope "A3"?



Thanks!




Regards,
Alex Yiu