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: Bug Issue (?): BPEL Internal Faults

Bug Issue (?): BPEL Internal Faults

Related Issues:
187 - http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue187
163 - http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue163
169 - http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue169

There are a number of cases in the current spec where the behavior of a
process is described as *undefined*, in particular, after recognizing a
internal errors described as standard faults.

With the exception of "bpel:joinFailure", *all* of these situations
represent modelling errors that cannot be dealt with by the business
process itself in a meaningful way. This behavior becomes even more
questionable for catchAll handlers that try to deal with multiple
application faults and unexpectedly encounter a standard fault.

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).

Kind Regards

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]