Re: [wsbpel] Issue - 229 - Fault handling and compensation handlingallows selective compensation of child scopes

[Alastair Green <alastair.green@choreology.com>]

Hi Alexandre,

I am jet-lagged, and half-brain-dead, so what I am about to type may be misconceived, but I think that the proposal was to drop the ability to compensate scope by name altogether (and that the original issue was: it's too complicated to allow such selective compensation). My objection was to the notion that selective compensation, under parental control, should be eliminated. I think that this  will reduce compensation to some kind of glorified atomic transaction, when compensations require a more flexible, application-driven understanding of what it means to "reverse" or "counter" a putative effect. From this flows the need to allow complete app control over the order and number of compensations processed when a "compensation point" is reached. If that principle is accepted then I am hugely less sensitive to the actual syntactic solution.

Let me expand the point. While a compensation handler is always at liberty to use the process state variables value as a form of parameter, it is not true that its understanding of that state is equal in power to that of the parent scope. The parent scope can be programmed to reason about the interdependencies between child A's work and child B's work. Child A may not know (often should not need to know) that child B even exists, let alone what the by-products of its work are. It follows that the two ends of the relationship must divide the labour (their understanding is partial, and hierarchical). The child understands its own domain, and should accept the instruction to compensate, as best it knows how, and (ideally) irrespective of the wider context in which led to the instruction. The parent has a higher, wider understanding that should (ideally) dictate the issuance of the instruction, and its relation to other such instructions to other children. If compensate is automatically invoked then the parental logic (understanding) must be shared with all children, and all children must evaluate the parental predicate to understand if their instruction is in fact an instruction to no-op. This seems pointlessly complicated. Let the parent decide -- if we end that control we have begun to liquidate the concept of a scope, which is, I believe, a powerful instrument for the simplification of  process-programming.

Alastair

Alexandre Alves wrote:

Hi Alastair,

Isn't it already possible to break this reverse order invariant by
having the user explicitly compensate named scopes:

<scope name="root">
    <faultHandlers>
        <catchAll>
          <compensate scope="a">
          <compensate scope="b"> <!-- does not follow reverse order -->
        </catchAll>
    </faultHandlers>
    <compensationHandler>
        <compensate scope="a">
    </compensationHandler>
    <sequence>
      <scope name="a">
      ...
      </scope>
      <scope name="b">
      ...
      </scope>
      <scope name="c">
      ...
      </scope>
</sequence>

If so, it seems to me that parameterized compensation handlers are
already needed. And this scenario is not very different from the
proposed solution n. 4:

	  <catchAll>
          <compensate scope="a">
          <compensate /> <!-- default compensation -->
        </catchAll>

I do think we should open this issue. 

I would volunteer that one possible solution to this problem could be to
(conditionally) raise a fault if the reverse order invariant is broken.

Best regards,
Alexandre

-----Original Message-----
From: Green, Alastair J. [mailto:Alastair.Green@choreology.com] 
Sent: Tuesday, September 27, 2005 10:48 AM
To: chris.keller@active-endpoints.com; Yuzo Fujishima;
wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue - 229 - Fault handling and compensation
handling allows selective compensation of child scopes

I think I disagree with the premise of this issue, that a change is
needed in this area.

The default behaviour, as I recall, is that the compensation handlers of
children will be processed in reverse order of scope processing.

This facility allows an override, to permit selective and partial
reversals. 

If this is removed then the process designer is forced to create shared
state to parameterize compensation handlers such that they know the
context in which they have been called, which is more fragile,
error-prone and difficult to code than allowing parental dictation.

Unless I am missing something, there is no compulsion to use this
feature. It seems like a useful facility, and a case of caveat emptor.

Alastair 

-----Original Message-----
From: Chris Keller [mailto:chris.keller@active-endpoints.com] 
Sent: 27 September 2005 16:45
To: 'Yuzo Fujishima'; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue - 229 - Fault handling and compensation
handling allows selective compensation of child scopes

Hi Yuzo,

Interesting suggestion.

I have one question on your option.  If a user creates a catch block for
a
fault or a compensation handler that doesn't use <compensate/> will
compensation handling of child scopes be done before or after the user's
code or not at all?

One disadvantage of the suggestion is that if you have invokes not in a
scope of their own (or declaring a compensation handler of its own) then
the
user may need to interleave its compensation with that of child scopes.
That
requires the user to dictate the order of compensation which would be
prohibited by this option.  Of course we could say the user must add a
compensation handler directly to the invoke itself for appropriate
interleaving with child scopes, which is probably the lesser of evils.

- Chris

-----Original Message-----
From: Yuzo Fujishima [mailto:fujishima@bc.jp.nec.com] 
Sent: Monday, September 26, 2005 9:32 PM
To: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 229 - Fault handling and compensation
handling
allows selective compensation of child scopes

Chris,

I would like to propose the fifth option:

5. Disallow specifying the target scope for the compensate activity.
   I.e., legal:   <compensate/>
         illegal: <compensate scope="...*/>
   Have the compensation handler of the scope, not the caller,
   decide whether the compensation should be done.

Rationale:

I think the source of the problem is that
the current specification makes the caller of the compensation handlers
decide which scopes should be compensated while only each scope's
compensation handler knows how and if compensation needs to be done.

Yuzo

ws-bpel issues list editor wrote:
  

This issue has been added to the wsbpel issue list with a status of 
"received". The status will be changed to "open" if a motion to open
    

the 
  

issue is proposed and that motion is approved by the TC. A motion
    

could 
  

also be proposed to close it without further consideration. Otherwise
    

it 
  

will remain as "received".

The issues list is posted as a Technical Committee document to the
    

OASIS 
  

WSBPEL TC pages <http://www.oasis-open.org/apps/org/workgroup/wsbpel>
    

on 
  

a regular basis. The current edition, as a TC document, is the most 
recent version of the document entitled ** in the "Issues" folder of
    

the 
  

WSBPEL TC document list 
<http://www.oasis-open.org/apps/org/workgroup/wsbpel/documents.php> - 
the next posting as a TC document will include this issue. The list 
editor's working copy, which will normally include an issue when it is
    

announced, is available at this constant URL 
<http://www.choreology.com/external/WS_BPEL_issues_list.html>.


    Issue - 229 - Fault handling and compensation handling allows
    selective compensation of child scopes

*Status:* received
*Date added:* 26 Sep 2005
*Categories:* Compensation <#category_compensation>
*Date submitted:* 21 September 2005
*Submitter:* Chris Keller <mailto:chris.keller@active-endpoints.com>
*Description:* Currently fault handling and compensation handling
    

allows 
  

users to selectively compensate work done by child scopes. This can
    

lead 
  

to errors in the process especially as users change their processes
    

over 
  

time. In addition it does not seem to be in the spirit of the BPEL
    

fault 
  

handling and compensation handling model in general (as well as good 
modular programming practice). Take the following example:

<scope name="root">
   <faultHandlers>
       <catchAll>
         <compensate scope="a">
       </catchAll>
   </faultHandlers>
   <compensationHandler>
       <compensate scope="a">
   </compensationHandler>
   <sequence>
     <scope name="a">
     ...
     </scope>
     <scope name="b">
     ...
     </scope>
     <scope name="c">
     ...
     </scope>
</sequence>

If a fault is caused by scope "c" the catchAll will only compensate
    

"a" 
  

leaving "b" uncompensated. Let's assume programmer 1 created the
    

process 
  

and didn't bother to compensate "b" since "b" at that time didn't do
    

any 
  

real work. Now programmer 2 picks up that process later and adds real 
work and a compensation handler for it to scope "b" not realizing that
    

the catchAll will not compensate "b" and that the work will not be 
compensated.

Additionally if the real work added to scope "b" was accomplished by 
programmer 2 by adding a child scope "b1" to "b". Programmer 2 looking
    

at scope "b" may think that default compensation handling is in place 
and feel safe that their new work will be compensated. Not realizing 
that the scope "root" has selectively chosen not to compensate "b" and
    

thereby "b1" in the process.

Possible solutions:

   1. After user defined fault handling and compensation handling is
      executed default handling will execute to compensate all other
      completed child scopes left uncompensated.
   2. If after user defined fault handling and compensation handling
    

is
  

      executed there remains child scopes that have not been
    

compensated
  

      throw an bpws:missingCompensation exception.
   3. Do nothing and say selective compensation is legal and good. And
      add a note that users should take care when changing business
      processes to ensure that user defined fault handling and
      compensation handling call compensate on the child scopes
    

correctly.
  

   4. Same as 3 with one exception after a user calls <compensate
      name="..."> allow them to call <compensate/> which will
    

compensate
  

      all remaining child scopes in the default order. This would
      require changing the following text at the end of 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." 


*Changes:* 26 Sep 2005 - new issue

To comment on this issue (including whether it should be accepted), 
please follow-up to this announcement on the
    

wsbpel@lists.oasis-open.org 
  

list (replying to this message should automatically send your message
    

to 
  

that list), or ensure the subject line as you send it *starts* "Issue
    

- 
  

229 - [anything]" or is a reply to such a message. If you want to 
formally propose a resolution to an open issue, please start the
    

subject 
  

line "Issue - 229 - Proposed resolution", without any Re: or similar.

To add a new issue, see the issues procedures document (but the
    

address 
  

for new issue submission is the sender of this announcement).

Choreology Anti virus scan completed
    

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


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


  

Choreology Anti virus scan completed