Re: [wsbpel] RE: Questions (RE: [wsbpel] Proposed agenda for May28-29 WS BPEL TC face to face)

[Assaf Arkin <arkin@intalio.com>]

Satish Thatte wrote:

>Assaf,
> 
>The second (parameter) question is not all that obscure despite not having a defined feature for passing parameters to compensations.  Because the key point is simply that parameters can't be used in default behavior.  Thus anything clever we can imagine with combinations of commutative and non-commutative compensations will run into difficulties in being applicable to parameterized compensation, which I believe to be a far stronger requirement.  
>  
>
I understand that there's an input and an output and so you can't use 
the default behavior. You can still use <compensate> if you are able to 
pass all the inputs upfront to all the compensation handlers.

The first question is, can you pass data inbetween instances of the 
compensation handler when doing <compensation scope>? This is a 
requirement on our side to be able to do things like tally how much 
compensation was done, or operate on shared data (no concurrency issues 
if invocation is serial). This of course conflicts with invoking 
compensation handlers concurrently, since merging outputs become an 
issue. I consider this feature as important, and actually a way to do 
compensation concurrently while invoking compensation handlers serially.

The second question is, can you pass that data between any set of 
compensation handlers using <compensate>, or do you always have to use 
<compensation scope> when passing parameters?

> 
>My third question was simply pointing out that once we go beyond the dichotomy of default-reverse and wholly custom ordering, any number of requirements can pop up for ordering which we may not be able to satisfy, so I am hesitant to get on the slippery slope of accumulating that class of requirements without a good idea of potential clean solutions.
>  
>
You can support any order of compensation if you allow individual 
compensation handlers to somehow exchange data with the enclosing scope 
compensation/fault handler. So if you have an other-than-reverse order 
you want to support, and the ability to exchange data with the 
compensation handler, you can support it without having to complicate 
the language in any way.

That's why, although we do have scenarios where we could benefit from 
doing other-than-reverse order, assuming a specification that allows you 
to pass parameters to compensation handlers, I do not at the moment have 
any issue to raise against such a specification. Or you may say that the 
issue is doing other-than-reverse order compensation and the resolution 
is to use parameter passing ;-)

arkin

> 
>Satish
>  
>