[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 190 - BPEL Internal Faults (New Proposed IssueAnnouncement
Hi Danny,
BPEL so far does not support any technique for modularizing process
authoring, so the situation you describe is a bit out of scope right now.
In any case, my view is that the idea that authors of business process are
going to be adding code to deal with things like unsupportedReference is
just not realistic. I would even argue that those faults don't actually
belong at the BP modeling level and need to be dealt with in a different
way.
Dieter's suggestion allows implementations to manage these situations in
the best possible way. This is specially important in the case of long
running processes, where months or years of work can be thrown out the
window when one of these faults is encountered (the current semantics
require the complete unwinding of the execution stack if the fault is not
caught and a generic catch all is essentially good for nothing). Typically
you want to allow manual intervention to figure out whether the process can
be repaired, terminated if not.
Paco
Danny van der
Rijn To: wsbpel@lists.oasis-open.org
<dannyv@tibco.com cc:
> Subject: Re: [wsbpel] Issue 190 - BPEL Internal Faults (New Proposed Issue Announcement
02/03/2005 01:47
PM
[Resending this with appropriate header to save Tony/Peter the trouble]
-1
As I pointed out in our last face to face, this kind of approach will make
any kind of modularization extremely difficult. It will give no way for a
developer of a piece of BPEL code to protect against the "modelling error"
(legacy term: "programming error") of another modeller whose attempt to
model the real world failed in a tangible instance.
Danny
Tony Fletcher wrote:
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.
Description:
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
|------------------------+ -------------------------------------|
|(Embedded image moved to|Tony | |
|file: pic06667.gif) |Fletcher | |
| |Technical| |
| |Advisor | |
| |Choreolog| |
| |y Ltd. | |
| |68, | |
| |Lombard | |
| |Street, | |
| |London | |
| |EC3V 9L J| |
| |UK | |
|------------------------+---------+-------------------------------------|
| |Phone: |+44 (0) 1473 729537 |
|------------------------+---------+-------------------------------------|
| |Mobile: |+44 (0) 7801 948219 |
|------------------------+---------+-------------------------------------|
| |Fax: |+44 (0) 870 7390077 |
|------------------------+---------+-------------------------------------|
| |Web: |www.choreology.com |
|------------------------+---------+-------------------------------------|
Cohesions™ | |
-------------------------------------|
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]
