Re: [wsbpel] installing compensation handlers for faulted scopes

[Assaf Arkin <arkin@intalio.com>]

Ram Jeyaraman wrote:

>Assaf Arkin wrote:
>  
>
>[snip]
>  
>
>>Another possibility:
>>
>>3. 'throw a new fault' implies that the fault handler may have succeeded
>>to undo/redo the activity and so the activity has been recovered.
>>However, the activity did not return any outcome that is useful for
>>activity B and so activity B should not execute.
>>    
>>
>
>if one were to make the assumption that the process execution has to make
>forward progress, irrespective of whether predecessor action(s) completed
>successfully or not, then i suppose the current model in the spec works quite
>well, since the fault handler simply cleans up the failed action, in spite of
>the fact that the successor action(s) have to track more state. thanks.
>
I've tried to play with both models for the language design and this is 
the one that works best. The alternative model, where an activity can 
perform forward work in its fault handler, actually sounds much simpler 
and for the extremely simple case it is in fact simpler. But the 
extremley simple case is not the common one, the common one is the 
simple case, and the simple case may be as simple as do X and Y in 
parallel, which becomes hairy to support in the fault handler. Did I 
fail after performing X but during Y? After performing Y but during X? 
While performing X and Y neither of which completed?

So then you decide to look at some common cases and realize that the 
best practice is to always do recovery in the fault handler. This sounds 
like a constraint that prevents you from doing simple things, but in 
fact it doesn't. It lets you model complex cases including parallel work 
with understandable logic if you use it correctly. And the best practice 
becomes very easy to write and adhere to.

That doesn't mean you can't get anywhere should a failure ensue. Let's 
say that some activity is talking to a supplier and encounters a problem 
and all it can do in its fault handler is recover from that and 
complete. But it's outcome is not a successful one, and by putting it 
inside a loop you can repeat it and have it talk to a different supplier 
until you get the desired outcome. You can repeat that any number of 
times, if you have N suppliers you can talk to all of them until you get 
a successful outcome.

Now, try to do that in a fault handler. Let's say the activity fails and 
so its fault handler picks another supplier and also fails. Its fault 
handler would pick another supplier and so forth. The definition is not 
recursive, and even though it can be made extremley efficient for an 
engine to process imagine a user trying to determine what the process is 
doing right now, how many suppliers were used in this experiment or how 
long each interaction took. Working with an iterative list of activities 
(the loop) is much simplier than looking at a stack of activities*.

arkin

* If it's not evident consider that the time to complete for the 
top-level activity is long than the time to complete of its child 
activity, which is longer than the time to complete of its child 
activity, etc. This is not an accurate measurement.

>---------------------------------------------------------------------
>To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>  
>