OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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]
Sent: Tuesday, June 14, 2005 5:15 PM
To: dieterkoenig@de.ibm.com
Cc: wsbpel@lists.oasis-open.org; Alex Yiu
Subject: Re: [wsbpel] Issue 190 - Proposal For Vote

 


Hi, DK,

Thank you for incorporating most of my concerns.
I am comfortable with most parts of the proposal except the following part:

Dieter Koenig1 wrote:

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.
  


The proposal text does not address clearly on how we handle the following:
------------------------------
<process exitOnStandardFault="yes">
    <faultHandlers>
       <catch faultName="selectionFailure"> ... </catch>
    </faultHandlers>
    <sequence>
       ...
    </sequence>
</process>

------------------------------

I would say drawing suppressJoinFailure and exitOnStandardFault might not be that suitable in this context.

Because, suppressJoinFailure controls whether a "joinFailure" fault  is thrown at the activity level, while the faultHandler for "joinFailure" is specified on the enclosing scope level. These two constructs are operating on two different levels. Hence, no direct contradiction on each other. On the other hand, both "exitOnStandardFault" and the faultHandler for "selectionFailure" are specified at same level (i.e. <process> or <scope>). The potential  contradiction implication is bigger.

Also, the granularity of control is also different. suppressJoinFailure controls only "joinFailure" fault, while "exitOnStandardFault" controls all system fault (e.g. "selectionFailure", "missingReply" and etc).  For the above sample BPEL code, it can be very well interpreted as:

I want to handle selectionFailure myself. All other system faults (e.g. "missingReply") will trigger the process to <exit>.


[Choice-A]
**If** we want to use the above semantics, a paragraph similar to the following may need to be added right before the <catchAll> item in the catch-matching precedence rule ("Otherwise if there is a catchAll handler "):

If "exitOnStandardFault" attribute is set to "yes" and if the fault is a WS-BPEL standard fault, the process instance MUST exit immediately.


[Choice-B]
**If** we want to go with DK's proposed semantics, we should at least reject the process definition by static analysis. Because, the intention of parts of process definition seems to be contradicting with each other. We may want to add the following statement to the proposal:

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.




Thanks!



Regards,
Alex Yiu



Dieter Koenig1 wrote:

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]