Issue - 207 - Compensation Model Clarifications

[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 the TC accepts it as identifying a bug in the spec or decides it should be accepted specially. Otherwise it will be closed without further consideration (but will be marked as "Revisitable")

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 - 207 - Compensation Model Clarifications

Status: received
Date added: 17 May 2005
Categories: Compensation
Date submitted: 16 May 2005
Submitter: Yaron Y. Goland
Description:

process
    faultHandler
       catchAll
          scope name="A"
             compensate
    sequence
       ...
       scope name="B"
          compensationHandler
             ...
       throw something

The language in section 13.3.3 would lead one to believe that the compensate activity call in scope A would cause the compensation handler on scope B to be executed. But this conclusion is more implicit than explicit given the existing specification text.

process
    ...
    scope name="D"
       compensationHandler
          scope name="C"
             compensationHandler
                ...
       ...
    ...

As near as I can tell scope "C"'s compensation handler is unreachable but is that correct? If so, then what happens to the compensation handler? Is it illegal? Should this situation be statically detected and rejected?

scope name="E"
    faultHandlers
       catchAll
          sequence
             scope name="F"
                compensationHandler
                   ...
                ...
             compensate
    ...

Is scope "F" a child of scope "E" for purposes of deciding what gets compensated in a call to the compensate command? This is the general impression I get from the language on default compensation handlers in section 13.4.1 which says things like "Run all available compensation handlers for all directly and indirectly enclosed scopes...". But in that case what about:

scope name="G"
    faultHandlers
       catchAll
          sequence
             scope name="H"
                compensationHandler
                   ...
                ...
             compensate *SCOPE = "H"*
    ...

Seems to me that if "F" can be compensated by the default compensation handler then "H" should be compensatable using a named compensation handler. But where would I figure that out from the existing text?

Another variant is:

scope name="J"
    compensationHandler
       sequence
          scope name="K"
             compensationHandler
                ...
          compensate
    ...

The previous example just generalizes the problem to include compensation handlers as well as fault handlers.

Thanks to Alexandre Alves for pointing these issues out.
Submitter’s proposal: I think we need to define some kind of model to describe our compensation behavior. The model would define that when a scope instantiates a compensation handler that handler gets 'linked' to the scope's parent and is only reachable from that parent. This 'linking' (yes, I know, we need to use a different term) can happen even if the scope's parent scope is faulted or already in compensation. This linking can also happen even if the scope with the installed compensation handler is itself defined inside of a compensation or fault handler. Any compensation handler that is linked to a scope can be called either by name or by the default compensation handler from the scope it is linked to. However if the scope a compensation handler is linked to exits (either after fault or compensation handling) without calling a linked compensation handler then the compensation handler is unreachable by the BPEL code.

We also need to clean up the language a bit in 13.3.3 to make it clearer that when compensate is called it is called on the 'pool' of 'linked' scopes available on the scope that contains the immediately enclosing fault or compensation handler that the compensate is enclosed by.

The previous would resolve the first A/B example by stating that when compensate is called in scope "A" the immediately enclosing fault handler belongs to the entire process which has scope B's compensation handler 'linked' to it and therefore the call to compensate will compensate scope B.

In the case of C/D when scope C successfully exits it adds its compensation handler to scope D's "pool" of "linked" compensation handlers. But scope D is already being compensated and no further action is being taken by the compensation handler (as defined in the example) therefore the compensation handler will exit, scope D will then exit and scope C's compensation handler will become unreachable. I don't think this should be an error but it is something that a good BPEL implementation should warn the programmer about.

In the case of E/F, scope E's compensation handler becomes "linked" to F's "pool" and therefore is available for compensation with compensate.

The same logic applies to G/H except in this case scope H's compensation handler is invoked by name. When using "compensation scope="XX"" the scope name is resolved by looking in the "pool", since H was in G's pool, named compensation was possible. Note, btw, that this requires that we tighten the language in 13.3.3. It currently states "In order for a compensation handler to be invoked by name, all scopes and activities directly nested in a scope MUST be uniquely named.". We need to make it clearer that this name uniqueness requirement includes scopes defined in compensation and fault handlers as well.

The J/K example is a straight forward variant of E/F and the same logic applies.
Changes: 17 May 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 - 207 - [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 - 207 - 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