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: Issue 190 - BPEL Internal Faults (New Proposed Issue Announcement

Title: Message
This issue has been added to the wsbpel issue list with a status of "received". The status will be changed to "open" if the TC accepts it as identifying a bug in the spec or decides it should be accepted specially. Otherwise it will be closed without further consideration (but will be marked as "Revisitable")

The issues list is posted as a Technical Committee document to the OASIS WSBPEL TC pages on a regular basis. The current edition, as a TC document, is the most recent version of the document entitled in the "Issues" folder of the WSBPEL TC document list - the next posting as a TC document will include this issue. The list editor's working copy, which will normally include an issue when it is announced, is available at this constant URL.

Issue 190: BPEL Internal Faults

Status: received
Date added: 3 Feb 2005
Categories: Fault handling
Date submitted: 3 February 2005
Submitter: Dieter Koenig1
Document: WS-BPEL Working Draft, December, 2004
Related Issues: Issue 163 : languageExecutionFault, Issue 169 : Transition condition error handling clarification, and Issue 187 : Legality of Explicitly throwing or rethrowing Standard faults.
There are a number of cases in the current spec where the behavior of a process is described as *undefined*, in particular, after recognizing 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.

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

Changes: 3 Feb 2005 - new issue

Best Regards,


Tony Fletcher

Technical Advisor
Choreology Ltd.
68, Lombard Street, London EC3V 9L J   UK


+44 (0) 1473 729537


+44 (0) 7801 948219


+44 (0) 870 7390077




Business transaction management software for application coordination

Work: tony.fletcher@choreology.com

Home: amfletcher@iee.org


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