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

[ws-bpel issues list editor<peter.furniss@choreology.com>]

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

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

Status: received
Date added: 26 Sep 2005
Categories: Compensation
Date submitted: 21 September 2005
Submitter: Chris Keller
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