OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsbpel] Issue 6.2 - What about compensation handlers?


I think you meant "completionHandlers" below, in 
 
"I would suggest that 6.2 needs completion conditions just as badly as
Satish's original proposal and therefore suffers from the same
complications."
 
and so on.

________________________________

From: Yaron Y. Goland [mailto:ygoland@bea.com]
Sent: Tue 5/3/2005 11:45 AM
To: Alex Yiu
Cc: wsbpeltc
Subject: Re: [wsbpel] Issue 6.2 - What about compensation handlers?



The problem with the current termination text is that it presumes that
the root of the termination is always a scope (since the language was
specifically written to deal with termination caused by faults). But in
your first example you require us to deal with termination in a case
where these is no surrounding scope. So as things now stand the 6.2
proposal is incomplete because it doesn't describe how to change the
termination language to deal with this situation.

But perhaps more importantly I would argue that the semantics of this
proposal are incomplete. Today, when someone writes a termination
handlers, they do so knowing that they were terminated because of a
fault. This proposal would change that. Now they could be terminated as
the consequence of a fault or they could be terminated as the
consequence of a completion condition and in many cases it's impossible
to tell the difference.

This distinction often matters. For example, if a bid request was made
and a response received the compensation handler for a fault based
termination may say 'Sorry but I won't be talking to you anymore because
of an internal failure, this is an irrecoverable situation.' On the
other hand compensation that occurs as a consequence of a completion
condition would want to send a completely different message 'Thank you
for your bid but it has been rejected because someone else beat you on
price.'

The need to distinguish 'successful' failure (e.g. termination as a
consequence of a completion condition) from simple failure is what led
Satish to introduce completion conditions and it was the complications
of that proposal that caused him to withdraw it.

I would suggest that 6.2 needs completion conditions just as badly as
Satish's original proposal and therefore suffers from the same
complications.

I suspect there are solutions to all of these problems but we shouldn't
be looking for them in the BPEL TC. The TC is not a R&D project. We do
not have the resources to create new experimental features, flesh them
out and deliver them. We should restrict ourselves to well understood areas.

                Yaron



Alex Yiu wrote:
> Hi Yaron,
>
> Assuming that we take Satish's interpretation that we allow a partial
> termination of a <scope>. That is, NOT forcing using <scope> within a <flow>
> with a completionCondition.
>
> If I read the termination part of spec correctly and understand Satish's
> interpretation of the spec, the compensationHandlers under the while will NOT be
> lost. Let me put more words to illustrate what I expect:
>
> --------------------------------
> scope name="A"
>     flow
>        completionCondition ...
>           ...
>        while
>           scope name="C"
>              compensationHandler
>                 ...
>              ...
>        sequence name="done"
>           ...
> --------------------------------
>
> Say the while loop execute from 1 to 10. During the execution of loop #4, the
> sequence of name "done" triggers the early completion condition. Hence, a
> termination happens to <while> loop.
>
> The scope #1, #2, #3 (of name="C") got successfully executed. The
> compensationHandlers are installed for these 3 scopes. The scope #4 got
> terminated and its terminationHandler got triggered. Again, as we allow a
> partial termination, the compensationHandler of the first 3 scopes will remain
> untouched. They will be available to the scope-A to call, if needed in the
> compensationHandler or faultHandler of scope-A.
>
> On the other hand, if one puts a scope-B around <while>-activity and within the
> <flow>. The termination/compensation will be different.
>
> --------------------------------
> scope name="A"
>     flow
>        completionCondition ...
>           ...
>        scope name="B"
>            while
>               scope name="C"
>                  compensationHandler
>                     ...
>                  ...
>        sequence name="done"
>           ...
> --------------------------------
>
> The scope #1, #2, #3 (of name="C") got successfully executed. The
> compensationHandlers are installed for these 3 scopes.
>
> After the completionCondition is triggered, whe whole scope-B is being
> terminated. The termination of scope-B will involve two parts:
>
>     * cascade the termination to scope #4 (Hence, its terminationHandler got
>       triggered).
>     * invoke the compensation handlers of scope #1, #2, #3.
>
> In this case, the whole scope-B got terminated. So, the compensation handlers of
> scope #1, #2, #3 will NOT be available to the scope-A to call. Please note: this
> semantic has NOTHING to do with early completion logic. It just shows a scope
> works today.
>
> I believe that once we incorporate Satish's interpretation and clarification
> about the possibility of a partial termination of a scope. Then, this proposal
> would provide crispy clear picture and foundation on how an early completion
> would work in BPEL. And, we should be ready to go for the formal voting.
>
>
> Thanks!
>
>
>
> Regards,
> Alex Yiu
>
>
> Yaron Y. Goland wrote:
>
>> Imagine the following sample code:
>>
>> flow
>>    completionCondition ...
>>       ...
>>    while
>>       scope
>>          compensationHandler
>>             ...
>>          ...
>>    sequence name="done"
>>       ...
>>
>> Now imagine that the "done" sequence completes triggering the completion
>> condition and terminated the while. But the while had already completed a few
>> iterations and instantiated a number of compensation handlers. What happens to
>> those handlers?
>>
>> Using the current termination language those handlers would be lost when the
>> parent scope is terminated. I suspect most programmers would find this
>> behavior to be surprising.
>>
>>         Yaron
>>
>>
>> ---------------------------------------------------------------------
>> 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





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]