[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 20 - installing compensation handlers for faulted scopes
Ram, Your pattern (c) is actually likely to be not uncommon since processes often perform risky optional work. This then becomes the "don't care" case. The scope's success\failure will likely be reflected in shared data and integrated into the logic that way. Regarding alternative completion one can already do that with conditional work following an unsuccessful scope completion. Not fully integrated at the scope level but it seems less complex to understand than explicit control over installation of compensation handling in fault cases. Satish -----Original Message----- From: Ram Jeyaraman [mailto:Ram.Jeyaraman@Sun.COM] Sent: Sunday, September 21, 2003 5:40 PM To: wsbpel@lists.oasis-open.org Subject: [wsbpel] Issue - 20 - installing compensation handlers for faulted scopes Following up on the conversation at the F2F meeting last week, Normally, a control flow is short-circuited when a fault occurs. The application may trap the fault and perform corrective actions { undo or redo }, and may decide to suppress the fault or rethrow the fault, depending on whether it is able to recover fully. (a) Fault suppression upon redo In the case of a successful redo, the application may choose not to rethrow the fault and hence allow normal forward progress. But, as observed earlier, attempting redo or alternative normal completion may be hard to implement in most cases, due to the relative complexity in implementing an appropriate compensation logic that accounts for such alternate successful completions. (b) Fault rethrow upon undo: The application may perform cleanup, undo, etc., and rethrow the fault, thereby short-circuiting the normal control flow. No issues. (c) Fault suppression upon undo: This is a bit problematic, since the control flows forward, just as normally as it would have otherwise, in spite of the fact that a full recovery was not performed. While this is a valid usage pattern, it is hard to program a sequential control flow, since each forward step may now have to adapt its behavior according to the outcome of previous completion or completions. Summary: 1. It may serve to warn against the potential anomalies of usage pattern (c). 2. Regarding usage pattern (a): It is possible applications may want to perform alternate normal completions in simple cases. Enabling such an usage would mean installing a compensation handler for a faulted scope, upon *explicit* application request. That is, a fault handler may explicity request that a compensation handler be installed for the faulted scope, since it was able to perform an alternate normal completion for the faulted scope. Providing for such explicit enablement of compensation handlers may serve applications that attempt alternative normal completions in simple cases. To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr oup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]