← Prev in month ← Prev in thread
Next in thread → Next in month →

Issue 190 - BPEL Internal Faults (New Proposed Issue Announcement

From
Tony Fletcher <>
Date
2005-02-03T15:55:37+00:00
ID
000201c50a08$c8bfdb40$
Thread
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 
FaultsStatus: 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                           

  
  

    
      

    
      
Tony 
      Fletcher

      
Technical 
      Advisor 
      
Choreology 
      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:  
      

  

    
      
Home: 
      
← Prev in month ← Prev in thread
Next in thread → Next in month →