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] installing compensation handlers for faulted scopes


Addendum:

In a control flow, execution of an action (forward progress) is dependent on
successful completion of prior action(s), otherwise the execution path is
short-circuited at the point of failure.

This simple assumption of successful completion of prior action(s), makes it
easier for the developer in describing the process flow. If this assumption is
taken away, then each action has to *adapt* its behavior depending on the
outcome of prior action(s), which complicates the programming model.

For example,

<process>

   <sequence>

      <scope> <!-- Scope A -->
        ...     
        <faultHandlers>
           ...
        </faultHandlers>
        <compensationHandler>
           ...
        </compensationHandler>
      </scope>

      <scope> <!-- Scope B -->
        ...     
        <faultHandlers>
           ...
        </faultHandlers>
        <compensationHandler>
           ...
        </compensationHandler>
      </scope>

   </sequence>

   <faultHandlers> 
     ...
   </faultHandlers>

</process>

Using the current model,

Let us assume that a fault happens while processing scope A. A's fault handler
compensates (undo) the original action, and does not rethrow the fault. Upon
completion of fault handling, scope B is executed.

When B begins execution, it needs to check the outcome of A, and behave
accordingly, since its behavior is dependant on the outcome of scope A. That
is, if A had completed without a fault, B may choose to perform action x,
otherwise it would choose to perform action y. This is undesirable, and
complicates the programming model.

Due to this, the process description/logic becomes complicated. This has the
inadvertant effect of forcing the developer to always rethrow a fault and not
handle it, so as to short-circuit the control flow and avoid having to adapt to
multiple possible completion states.

Summary:

If faulted scopes that do not rethrow faults were to be allowed to complete
normally, the control flow becomes natural. This frees successor action(s) from
having to adapt to multiple possible completion states of predecessor
action(s), or rather allows the successor action(s) to make the simple
assumption of successful predecessor completions, and simplifies the
programming model.

In that case, a fault handler may:

1. 'rethrow fault' implies that a fault handler failed in its attempt to handle
the fault. This could mean that the handler attempted undo/redo and it failed
during undo/redo. This also could mean that the handler simply does not want to
handle the fault.

2. 'handle fault' implies that a fault handler succeeded in handling the fault.
This means that the action has been successfully completed, just as it would
have, if no fault had occured. That is, it is a *complete* recovery, not just
an undo. This is an important semantic guarantee required for forward progress
in a sequential control flow.

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


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