OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] Issue - 204 - Proposal to vote



Hi Danny,

I guess it loops back to two main issues:

(1) Whether it is OK for a scope instance to do some work which cannot be compensated (i.e. no well-defined way to compensate)?  (e.g. the case of <eventHandler> without a child scope)

(2) Consider the following code fragment sample:
Is <compensate scope="inner" /> legal?
If illegal, will it be too surprising to users?
If legal, what exactly is it semantics and given the existence of implicit counter variable?
At the compensationHandler inside scope "inner", is it legal to use "counter" variable?

Using the same code sample, we can illustrate another aspect of (1): How do we compensate the work of  <invoke operation="xyz" ...> in this case?


---------------------------------
<scope>
    <faultHandler>
          <catchAll>
                <compensate scope="inner" />
          </catchAll>
    <sequence>
          ...
          <forEach parallel="yes" counter ... >
                <sequence>
                    <invoke operation="xyz" ...>
                             <toPart part="branch" fromVariable="counter" />
                     </invoke>
                    <scope name="inner" >
                         ...
                            <variable name="fooVar" ...  />
                         ...
                        <compensationHandler> ... </compensationHandler>
                         <sequence>
                             <assign> <copy>
                                    <from>$xyz/foo[$counter]</from>
                                    <to variable="fooVar" />
                             </copy> </assign>
                             <invoke variable="foo" ... />
                         </sequence>
                    </scope>
                </sequence>
          </while>
    </sequence>
</scope>
---------------------------------

Other points of consideration:

For parallel-ForEach, people need to declare an inner scope anyway for 99%.

I think at this stage of the spec, we should try to avoid any "smart-macro" in <forEach> similar to the "invoke+compensationHandler" combo, which already gives us a number of edge cases to think about.


Thanks!


Regards,
Alex Yiu



Danny van der Rijn wrote:


Alex Yiu wrote:

Hi, Danny,

(1)
<while> and <repeatUntil> do not introduce implicit variables.

Right.  So if you need to use those variables in compensation, use a scope-child, and get the implicit behavior that I described.  (Or have to make it explicit yourself?)

(2)
And, <while> and <repeatUntil> are executed serially ... It would be much easier to track how many iteration of works has been finished at given point of time (say when a fault happens) (e.g.by checking the counter and other flag-like variables used in the while loop).

For the dynamic parallelism case of <forEach>, if there is no local scope within the <forEach>, users need to need to handle a collection / array of flags to keep track of the progress of  the bunch of parallel works ... (And, we have not defined related facilties / construct in BPEL standard for this kind collection of flags yet.)


If you want to keep track, then you put that scope in, and install compensation handlers there.  Same as I would do for while.  I wouldn't find the counter or other flags to be preferable to having my own compensation handler, if I cared, since finishing a scope and changing the counter aren't going to happen in ACID fashion.

Maybe this gets to your meaning of "can not be compensated" but again, I don't think there's anything fundamental here that isn't *really* there with a while.


Thanks!


Regards,
Alex Yiu


Danny van der Rijn wrote:
Alex -

I'm not sure that I understand what you're getting at.  You wouldn't be able to compensate the forEach *by name* but it could still be compensated.  Why is this any different from compensating <while> or <repeatUntil>? 

Danny

Alex Yiu wrote:

Hi Danny,

Do you mean that: if the explicit scope is not introduced, a ghost (implicit) scope is introduced and the work performed (e.g. by <onMessage>) CANNOT be compensated in that case?

That may work for <eventHandler>, because that can be considered the "side-job" of a scope. But, it may not work for <forEach>, which would be extensively as parts of the "main-job" of a scope.

Would people prefer treating "eventHandler" and "forEach" differently in this context?

[ Just a list of questions with an open mind on my side ... ]

Thanks!


Regards,
Alex Yiu


Danny van der Rijn wrote:
IMO this adds unneeded complexity for those (many) cases where these handlers are not going to be compensated.  What you are, in effect, proposing is this:

<onEvent messageType="foo:bar" variable="vbl">
    <scope/>
</onEvent>

should be read as:

<onEvent messageType="foo:bar" variable="vbl">
    <scope>
       <variables>
          <variable name="vbl">
             $vbl
          </variable>
       </variables>
    </scope>
</onEvent>

in other words, declaring a variable of the same name on the scope which is initialized to the value of the ghost scope's variable.

While I think that this makes sense, I disagree that this should require that "ghost scopes" be made corporeal.  Why don't we just say that WHEN ghost scopes' immediately enclosed activities are scopes, that the above "macro" occurs.

Danny

Alex Yiu wrote:

Hi all,

The attached HTML is the proposal to vote for Issue 204.

Thanks!


Regards,
Alex Yiu




Clarify on how to compensate an EventHandler

Proposal Draft for Issue 204

Last modified: July 18, 2005 - 1pm PDT

Summary:
To restrict that the child activity of:
(a) an <onEvent> and <onAlarm> under <eventHandler>
(b) a <forEach> activity (introduced by Issue 147)
MUST be a <scope> activity.

Rationale:
Currently, <eventHandlers> and <forEach> are two constructs in BPEL which:
  • introduces new variables without any explicit declaration (<onEvent> implicitly declares message-related variables, while <forEach> implicitly declares counter variable), and,
  • introduces dynamic parallelism (i.e. having parallel branches of which number is not known ahead of time)

Due to these two special natures, there is no well-defined way to compensate the work performed by these 2 constructs from perspectives of:
  • lack of a well-defined scope-snapshot
  • lack of a way to refer to dynamic parallel work being done (e.g. <compensate scope="aScopeName" /> )
Some clarification is needed to fill in the gap between BPEL's compensation model and semantics introduced by these constructs.

(Note: <catch> also introduces variable to hold fault related data without any explicit declaration. However it is used in "backward" work, while <onEvent>, <onAlarm> and <forEach> can be used in "forward" work. Hence, this kind of clarification is not needed for <catch>.)

Choices:

To fill in the gap between the compensation model and these two constructs, two choices were presented:
  • Implicit-Scope: treating <onEvent>/<onAlarm> (under <eventHandler>) and <forEach> constructs as a way to add an implicit scope, similar to the <invoke> macro (i.e. <invoke> plus <compensationHandler>/<faultHandler> shorthand)
  • Explicit-Scope: asking developers to use a <scope> explicitly as the child activity under these constructs instead of adding any implicit scopes
The implicit-scope approach is relatively acceptable in the case of <invoke> because there is no nested activity within <invoke> which performs "forward" work. If an implicit scope is added as a result of <forEach> or <onEvent>, any lexically direct child scopes under those constructs will NOT be accessible by the fault handler / compensation handler of the related parent scope.

For example:

<scope name="A">
   <faultHandler>
      <catchAll>
         <compensate scope="C" />
      </catchAll>
   </faultHandler>
   <eventHandlers>

      <onEvent ... >
         <sequence>
           ...
           <scope name="C"> ... </scope>
           ...
         </sequence>
      </onEvent>
   <eventHandlers>
   ...

</scope>


If the implicit-scope approach is adopted, <compensate scope="C" /> will become illegal. This kind of semantics is perceived as too implicit and surprising to users. Therefore, the implicit-scope approach is not preferred. Also, <onEvent> and <onAlarm> will be "upgraded" to become an activity, because it will need an activity name if the implicit-scope-marco is applied.

After the explicit-scope approach is adopted, the example would look like the following:

<scope name="A">
   <faultHandler>
      <catchAll>
         <compensate scope="B" />
      </catchAll>
   </faultHandler>
   <eventHandlers>

      <onEvent ... >
        <scope name="B">
           <sequence>
             ...
             <scope name="C"> ... </scope>
             ...
           </sequence>
        </scope>
      </onEvent>
   <eventHandlers>
   ...

</scope>


With the explicit scope introduced, the semantics of scope-snapshot and scope-specific <compensate> activity becomes well-defined now.

(Note: The above choices discussion was briefly conducted during Palo Alto F2F June-2005.)


Recap and More Details:
To restrict that the child activity of:
(a) an <onEvent> and <onAlarm> under <eventHandler>
(b) a <forEach> activity
MUST be a <scope> activity.

This restriction MUST be enforced during static analysis. (XSD will be updated to reflect this restriction).

Variables introduced by these constructs (i.e. message related variables at <onEvent> and counter variable at <forEach>) will be declared implicitly as local variables of <scope> under <onEvent> and <forEach>. (Hence, scope snapshot semantic is clarified.)



END



--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]