[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 > >