[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] installing compensation handlers for faulted scopes
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]