Re: [wsbpel] installing compensation handlers for faulted scopes

[Assaf Arkin <arkin@intalio.com>]

Let's say you are doing some activity in parallel of repeatedly, e.g. 
getting quotes from different suppliers.

One of these instances encounters an unexpected fault and so cannot 
complete. The fault happens somewhere inside the activity, so it's 
handled very coarse grained, e.g. by doing compensation for any internal 
work. You now have three options:

1. The activity has completed and a compensation handler is installed. 
However, since it already did backward recovery, the logic for this 
compensation handler would be different then the one used had the 
activity completed without handling a fault. In this model you need two 
different compensation handlers, or more specific logic in the 
compensation handler (e.g. check if a fault occurred or not).

2. The activity completed but no compensation handler is installed. 
Since the activity was able to do backward recovery, it's overall effect 
is zero, so you can start a new instance (e.g. talk to a different 
supplier), or just continue doing the other instances (e.g. you may end 
up receiving only 2 quotes for the 3 RFQs you sent). This is a graceful 
way to get around errors and still get work done.

3. The only way the activity can not install a compensation handler is 
by throwing a fault. This model saves you from the need to define two 
compensation handlers (#1) but does not allow you to gracefully allow 
activities to fail and keep going about your business (#2).

In our experience with business processes it seems that #2 is the most 
general case. It lets you distinguish between backward recovery before 
completion (fault handler) and backward recovery after completion 
(compensation), and handle failures gracefully.

There is always the case where some activity A does a sequence of 
activities A1 and A2. Should A2 fail the activity A can still complete 
successfully and should be able to install a compensation handler. In 
this case it makes more sense to provide a fault handler for A2 that 
lets it complete, and then allows A to complete as if no fault happened.

arkin


Ram Jeyaraman wrote:

>issue: should a faulted scope be deemed successfully completed or not?
>
>currently, i beleive, a compensation handler is not installed for a faulted
>scope, irrespective of whether the fault is propagated-up or not.
>
>i realize, as Satish pointed to, there are issues with allowing the fault
>handler to attempt alternative normal completion.
>
>however, i would like to discuss this further to help convince ourselves that
>we are embarked on the right model for fault/compensation handling.
>
>(a) Normally, if a fault handler were to be able to handle the fault itself,
>that is, do corrective actions (both undo and redo), then the fault is not
>rethrown, and the forward action can proceed as normally intended.
>
>(b) On the other hand, if the fault handler is not able to handle the fault,
>perhaps it failed somewhere in its attempt to undo/redo, it rethrows the fault,
>and the normal execution is short-circuited.
>
>in the case of (a), it seems reasonable to install a compensation handler,
>since the fault was successfully handled, and forward progress can be made. If
>this is not the case, the problem is that every forward action has to check if
>the previous action(s) had successfully completed, which is non-trivial. In
>such a case, the developer is most-likely going to almost *always* rethrow* a
>fault in order to avoid having to check for every action if the previous one(s)
>had successfully completed. 
>
>in the case of (b), it seems reasonable to *not* install a compensation
>handler, since the fault was not successfully handled, or rather the action did
>not completed successfully.
>
>summary: the fact whether a fault was rethrown by a fault handler may be used
>to decide whether to install a compensation handler or not. thanks.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>  
>