RE: [wsbpel] Issue 229 - Proposal for vote

[Dieter Koenig1 <dieterkoenig@de.ibm.com>]

Yes, this is what I had in mind ...
Kind Regards
DK



                                                                           
             "Chris Keller"                                                
             <chris.keller@act                                             
             ive-endpoints.com                                          To 
             >                         Dieter Koenig1/Germany/IBM@IBMDE,   
                                       <alex.yiu@oracle.com>               
             15.12.2005 19:08                                           cc 
                                       "'ws bpel tc'"                      
                                       <wsbpel@lists.oasis-open.org>       
             Please respond to                                     Subject 
               chris.keller            RE: [wsbpel] Issue 229 - Proposal   
                                       for vote                            
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Hi Dieter,

I am not sure which text you are suggesting to replace (or add to) with
this
text. Is it the same text as Alex is suggesting to change?

Thanks,
Chris

-----Original Message-----
From: Dieter Koenig1 [mailto:dieterkoenig@de.ibm.com]
Sent: Thursday, December 15, 2005 3:36 AM
To: alex.yiu@oracle.com; chris.keller@active-endpoints.com
Cc: 'ws bpel tc'
Subject: Re: [wsbpel] Issue 229 - Proposal for vote

+1

Here is one more ...:

User-defined fault handlers, compensation handlers, or termination handlers
may use <compensate scope="..."> to compensate a specific child scope
and/or <compensate/> to compensate all child scopes in default order. Any
repeated attempt to compensate an individual child scope is treated as a
no-op.

Kind Regards
DK




             Alex Yiu
             <alex.yiu@oracle.
             com>                                                       To
                                       chris.keller@active-endpoints.com
             14.12.2005 22:00                                           cc
                                       "'ws bpel tc'"
                                       <wsbpel@lists.oasis-open.org>, Alex
                                       Yiu <alex.yiu@oracle.com>
                                                                   Subject
                                       Re: [wsbpel] Issue 229 - Proposal
                                       for vote











Hi Chris,

Thank you again for sending the proposal out.

I am for general direction of this proposal.

"Explicit invocation of compensation for such a scope nested within S
effectively removes the scope from the default-order compensation, but the
remainder of the compensation order is preserved. If a <compensate/> is
used prior to a <compensate scope="Sx"/> the latter is treated as a no-op"

Technically, what your text describe is consistent with my understanding
and preference.

However the wording of "effectively removes" make me worry this text gives
people an impression that the default-order compensation is mutable upon
<compensate scope="Sx" />. In fact, we have no mechanism to change the
default-order.

Thinking out loud here ... how about:
"After any explicit invocation of compensation for such a scope nested
within S, the default-order compensation is still available via
<compensate/> activity. During the default-order compensation, any attempt
to compensate a scope which has been already explicity compensated is a
no-op. On the other hand, if a <compensate/> is used prior to a <compensate
scope="Sx"/> the latter is treated as a no-op"

I guess it will have less room of misunderstanding.
What do you think?


Thanks!


Regards,
Alex Yiu


Chris Keller wrote:
      Issue 229

      Proposal Summary: Allow <compensate/> after <compensate scope="Sx"/>
      and emphasize that user defined fault and compensation handlers must
      explicitly call compensate for child scope compensation to occur.

      Changes to current specification
      --------------------------------

      Section 13.3.3

      "...Note that the <compensate/> activity in a fault or compensation
      handler attached to scope S causes the default-order invocation of
      compensation handlers for completed scopes directly nested within S.
      The use of this activity can be mixed with any other user-specified
      behavior except the explicit invocation of <compensate scope="Sx"/>
      for scope Sx nested directly within S. Explicit invocation of
      compensation for such a scope nested within S disables the
      availability of default-order compensation, as expected."

      Change to:

      "...Note that the <compensate/> activity in a fault or compensation
      handler attached to scope S causes the default-order invocation of
      compensation handlers for completed scopes directly nested within S.
      The use of this activity can be mixed with any other user-specified
      behavior including the explicit invocation of <compensate
      scope="Sx"/> for scope Sx nested directly within S. Explicit
      invocation of compensation for such a scope nested within S
      effectively removes the scope from the default-order compensation,
      but the remainder of the compensation order is preserved. If a
      <compensate/> is used prior to a <compensate scope="Sx"/> the latter
      is treated as a no-op.

      The compensate activity MUST be used by user defined fault handlers
      and compensation handlers for child scope compensation to be called.
      If a user defined fault handler or compensation handler does not use
      the compensate activity child scopes will not be compensated."


      Section 14.6

      --- Remove this section as it is not applicable per issue 209
      resolution ---


      Appendix A -

      --- Remove repeatedCompensation fault as it is not applicable per
      issue 209 resolution ---









---------------------------------------------------------------------
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