[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 190 - Proposal For Vote
I prefer Choice B. I am also not in favor of scope level override of the ExitOnStandardFault attribute. Flexibility is nice but the price in semantic complexity in this case does not seem worth it to me.
From: Alex Yiu [mailto:alex.yiu@oracle.com]
Proposed changes *not* included in the wording below: (-) There has been a proposal to ignore exitOnStandardFault="yes" if there is an explicit fault handler for a particular standard fault. I would prefer not doing so in order to keep more consistency with the behavior for "bpws:joinFailure". If one has an explicit fault handler for "bpws:joinFailure" and specify suppressJoinFailure="yes", then the fault handler will never be executed. The same should apply for exitOnStandardFault="yes", i.e., explicit fault handlers for standard faults are not executed.
I want to handle selectionFailure myself. All other system faults (e.g. "missingReply") will trigger the process to <exit>.
If "exitOnStandardFault" attribute is set to "yes" and if the fault is a WS-BPEL standard fault, the process instance MUST exit immediately.
if "exitOnStandardFault" attribute of a particular <process> or <scope> is set to "yes", a <catch> fault handler construct which targets a WS-BPEL standard fault MUST not be used. This condition MUST be detected by static analysis and the process definition of this kind MUST be rejected.
Revised resolution proposal for issue 190. Changes included in the wording below: (1) Apply this 190 issue resolution to all standard faults except "bpws:joinFailure". (2) Change the default for the process attribute "exitOnStandardFault" to "no". (3) Similar to "suppressJoinFailure", the default for the "exitOnStandardFault" is inherited from the actual attribute value on the enclosing scope or process. Proposed changes *not* included in the wording below: (-) There has been a proposal to ignore exitOnStandardFault="yes" if there is an explicit fault handler for a particular standard fault. I would prefer not doing so in order to keep more consistency with the behavior for "bpws:joinFailure". If one has an explicit fault handler for "bpws:joinFailure" and specify suppressJoinFailure="yes", then the fault handler will never be executed. The same should apply for exitOnStandardFault="yes", i.e., explicit fault handlers for standard faults are not executed. (-) There has been a proposal to move the attribute exitOnStandardFault to the catchAll element. I prefer not doing so in order to keep the behavior consistent between explicit and implicit catchAll fault handlers. For the latter, one obviously cannot specify an attribute. ================================================ Submitter's proposal: Standard faults (except "bpws:joinFailure") generally represent modeling errors. There exist BPEL processes that would not want to handle BPEL standard faults, in particular in catchAll fault handlers, and would like to be able to indicate that on the process definition. Instead of allowing processes to catch these as standard faults, we propose that the process instance can *exit* immediately when such a situation is encountered. Rationale: The behavior of "exit" is well-defined in BPEL -- as far as BPEL is concerned the instance execution ends when exit is encountered without any fault handling behavior. Additional facilities for extended support for, e.g., repair and continue, are definitely out of scope. 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" ...> ================================================ Section 6.2. The Structure of a Business Process Add a new bullet under "The top-level attributes are as follows": * exitOnStandardFault. If set to "yes" then a process must exit immediately when any standard fault except "bpws:joinFailure" has been encountered (in the same way as if an exit activity was reached). If set to "no" then a process can handle the standard fault using a regular fault handler. The default is "no". ================================================ New section 13.4.X Handling BPEL Standard Faults If the exitOnStandardFault attribute on a scope is set to "yes", then a process must exit immediately when any standard fault except "bpws:joinFailure" has been encountered in this scope (in the same way as if an exit activity was reached). If it is set to "no" then a scope can handle the standard fault using a regular fault handler. Similar to the behavior for the suppressJoinFailure attribute, the default for the "exitOnStandardFault" is inherited from the actual attribute value on the enclosing scope or process. ================================================ Appendix C. XML Schemas (add @exitOnStandardFault to complex types "tProcess" and "tScope") --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]