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

Title: Message

[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                          
  

  
    
      

        
        

        
        
        
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: