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 - BPEL Internal Faults (New Proposed IssueAnnouncement)

Hi, Paco,

I got a bit confused about your position. Just to clarify:
Is it OK from your viewpoint to allow BPEL developers to add optional BPEL code to take control of BPEL system faults?

Currently, the default behavior for BPEL system fault is: to compensate and rethrow. I think that the default way is a graceful way to end a process. Therefore, I would say users are not forced to handle system fault explicitly.

I agree that we should not try to standardize any magic switch here (e.g. "freeze-and-repair" semantic.)

However, there may be a number of relatively standard semantics that are related on how to handle BPEL system fault
  1. let users-specified code handle
  2. <compensate>-and-<rethrow>
  3. <compensate>-only : no rethrow, that means the completion of the scope is optional to the whole process
  4. <empty>
  5. <exit> (i.e. exit/terminate the process immediately)

I would say we should still allow users to do (1). And, (5) is what Dieter proposed, I think.

If people feel strongly about BPEL system fault are so different from Application fault, we might want to create a switch for people to choose from (1) to (5), with (1) as the default. The switch can appear in both <process> and <scope> level.

Please note:
  • I am not a big fan of this switch. Just try to find a balanced point where most people in TC would feel comfortable.
  • Any other "magic" semantics (e.g. "freeze-and-repair") should exist as extension


Alex Yiu

Francisco Curbera wrote:
I think the idea is not to get into the business of specifying the magic
switch but to recognize that real world engines will need to provided it.
Any solution that relaxes the requirement to process this situations as
formal faults would help. I like Dieter's proposal in particular but I
don't think that is the one. For example, a process author may be given the
ability may decide if he/she wants to explicitly take control of system
faults or not - that would also help. My point is that the current
situation forces process authors to do this and disallows other forms of
engine support.


                      "Yaron Y. Goland"                                                                                                 
                      <ygoland@bea.com>        To:       Francisco Curbera/Watson/IBM@IBMUS                                             
                                               cc:       Prasad Yendluri <pyendluri@webmethods.com>, Danny van der Rijn                 
                      02/07/2005 03:12          <dannyv@tibco.com>, wsbpel@lists.oasis-open.org                                         
                      PM                       Subject:  Re: [wsbpel] Issue 190 - BPEL Internal Faults (New Proposed Issue              
                      Please respond to         Announcement)                                                                           

I think the core of the problem is another part of our ever increasing

Lots of systems are going to have a magic switch that I strongly
encourage us not to attempt to specify in BPEL both because it's at
least 80% out of scope and because it will take a long time to agree on
the semantics.

That switch will specify (either on a process level or perhaps a scope
level) what to do if certain kinds of faults are thrown. One of the key
faults this switch will focus on are system faults.

This switch will typically have at least two settings.

Setting #1 - If a system fault is thrown immediately freeze the process
and call the admin for help who can then edit the process to fix things.

Setting #2 - If a system fault is thrown then send a note to the admin
but let the fault go through the normal fault handlers.

Both the first and second settings are possible with the existing spec.
The first behavior through an out of scope operational override and the
second behavior is pretty much our default behavior.

Issue 190 would make the second setting effectively impossible since it
would be illegal to ever allow system faults to go through normal fault
handling. But as Alex and others have convincingly argued there are many
interesting cases in which it makes sense to allow system faults to go
through normal fault handling.

In terms of maximizing portability I think we should stick with our
current behavior and leave the 190 style behavior to out of scope


Francisco Curbera wrote:
I guess one of the points of the immediate termination condition is that
termination is essentially always invisible to partners of the process.
net effect of this change (and from my perspective the actual aim of this
proposal) would be to allow engines the flexibility to deciding how to
with these situations, termination being an option. Any form of standard
fault semantics limit that flexibility because the engine would be forced
to follow the usual scope termination/fault propagation behavior with
likely the result of discarding many recoverable process instances - and
posisble days or months of process work.




                      <pyendluri@webmet        To:       Francisco

                      hods.com>                cc:       Danny van der
<dannyv@tibco.com>, wsbpel@lists.oasis-open.org

                                               Subject:  Re: [wsbpel]
Issue 190
- BPEL Internal Faults (New Proposed Issue

                      02/04/2005 02:30







1. Isn't this the same issue as the one raised by issue 187 where we ask
there are any constraints in handling of the standard faults? This is
proposing a specific resolution where it is recommended that the process
always terminates immediately.

2.  I tend to side with Danny on this. I don't think we should require
the process terminates immediately always. IMO in at least certain cases
this may not be a fatal situation for the whole process (it could be
confined to the scope) and other parts of the process may be able to
continue by compensating for pertinent. Perhaps the impact could limited
the immediately confining scope and the process could continue, perhaps
area the fault occurred could be non-fatal to whole process (e.g. related
look-up rather than modification of any information) or caused by some
transient condition that could go away on a retry etc. I think the
(fault handler) should be given a chance to handle the situation rather
than terminate always.

3. If we do end-up going the "terminate" always way, we must minimally
*not* preclude logging the condition, which could be more intelligent if
the faults could be attached some "fault data" (ref issues 187 and 185).

Regards, Prasad

-------- Original Message --------


 Subject Re: [wsbpel] Issue 190 - BPEL Internal Faults (New Proposed
       : Announcement


   Date: Fri, 4 Feb 2005 13:23:17 -0500


   From: Francisco Curbera <curbera@us.ibm.com>


     To: Danny van der Rijn <dannyv@tibco.com>


     CC: wsbpel@lists.oasis-open.org


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

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).
you want to allow manual intervention to figure out whether the process
be repaired, terminated if not.


 >From: Danny van der Rijn
 >To:       wsbpel@lists.oasis-open.org


 >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]


As I pointed out in our last face to face, this kind of approach will
any kind of modularization extremely difficult.  It will give no way for
developer of a piece of BPEL code to protect against the "modelling
(legacy term: "programming error") of another modeller whose attempt to
model the real world failed in a tangible instance.


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
      as identifying a bug in the spec or decides it should be accepted
      specially. Otherwise it will be closed without further
      (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
      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
      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
      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
      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)
      therefore also for errors within transition conditions (Issue 169).

      Changes: 3 Feb 2005 - new issue

      Best Regards,

To unsubscribe from this mailing list (and be removed from the roster of
OASIS TC), go to


To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.


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