[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 190 - BPEL Internal Faults (New Proposed Issue Announcement)
Satish, I don't think that the expected behavior of a standard fault would be to immediately and silently exit a process if it were encountered. Since the proposed attribute was exitOnStandardFault one would reasonably expect that the behavior would be the same as if the process executed an "exit" activity. The exit activity does kick in the default terminationHandler, which when not explicitly defined does compensate the completed scopes. As you point out this rollback (unraveling) is also what happens when one doesn't catch a fault, which is why I suggested it had the same effect. I am in complete agreement on allowing the implementation to do other interesting things like suspend (freeze) when one of these faults is encountered. That is another reason why I don't want to mandate an exit, which I pointed out in my email. I have seen people add catchAll when multiple declared faults (WSDL declared that happen as the result of invokes in the scope) should end up doing the same thing (e.g. replying with an error response to an outstanding request). Often they don't understand or expect that BPEL standard faults will also be sent there. It would be nice if a user could easily differentiate between catching declared and runtime failures. In lieu of a fault hierarchy in BPEL, I suggested we introduce the idea of standard (runtime faults) faults being only caught when the user wants to catch them. - Chris -----Original Message----- From: Satish Thatte [mailto:email@example.com] Sent: Saturday, February 19, 2005 8:30 PM To: firstname.lastname@example.org; Dieter Koenig1; email@example.com Subject: RE: [wsbpel] Issue 190 - BPEL Internal Faults (New Proposed Issue Announcement) Chris, How would changing catchAll behavior cause the same effect as exitOnStandardFault? If catchAll doesn't catch standard fault such faults would simply unravel the entire instance including default compensation, rather than freezing the instance so one can (using private means) fix and continue. Satish ________________________________ From: Chris Keller [mailto:firstname.lastname@example.org] Sent: Thu 2/17/2005 7:45 PM To: 'Dieter Koenig1'; email@example.com Subject: RE: [wsbpel] Issue 190 - BPEL Internal Faults (New Proposed Issue Announcement) Hi Dieter, I think the scope of the proposed attribute is not right. Instead of this process level attribute perhaps we could add a flag to the catchAll (imo the primary culprit for catching these faults when you don't want or expect to), which allows the user to specify that it shouldn't catch standard faults (similar to the difference between catching Throwable vs. Exception in java). <catchAll includeStandardFaults="yes|no"/> The default could still be no. In many ways this ends up being the same as the proposal since the behavior would be implicit fault handling which is terminate. This option gives users more fine grained control of their fault handling. It also opens up the ability for engines to have interesting options like suspend on uncaught standard faults. Certainly that is out of the scope of this specification, but could be a nice option as opposed to saying the default is that an engine MUST terminate a process on standard faults. - Chris -----Original Message----- From: Dieter Koenig1 [mailto:firstname.lastname@example.org] Sent: Thursday, February 17, 2005 6:52 AM To: email@example.com Subject: [wsbpel] Issue 190 - BPEL Internal Faults (New Proposed Issue Announcement) I would like to modify my original Submitter's proposal for 190 by adding a suggestion for an explicit process/scope attribute (see the last paragraph below). Kind Regards DK Submitter's proposal: Instead of allowing processes to catch these as standard faults, we propose that the process instance must *terminate* immediately when such a situation is encountered. The behavior of terminate is well-defined in BPEL -- as far as BPEL is concerned the instance execution ends when terminate is encountered without any fault handling behavior. Any additional facilities for extended support for, e.g., repair and continue, is definitely out of scope. This approach would also create a clear direction for dealing with any pathological situation within an inlined language (Issue 163) and therefore also for errors within transition conditions (Issue 169). In order to support the behavior suggested here and also allow process modelers to continue using the current behavior, an explicit boolean attribute can be added to the <process> and <scope> elements: <process/scope ... exitOnStandardFault="yes|no" ...> where the default is "yes". 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_workgroup. php. 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_workgroup. php. 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_workgroup. php.