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)


Satish Thatte wrote:

>I agree with you if you take "switch" literally, but the switch idea is
>just a manner of speaking.  Since this is private it can be an extension
>if one likes.  The crucial point is to fix the normative semantics such
>that the private extension/switch/deployment-descriptor/whatever would
>be compatible, i.e., would not require override of the normative
>semantics.
>  
>
I definitely agree with the need for this fix.

So are you saying that an implementation could have the choice whether 
catchAll will catch all faults, or some faults, or some faults after 
user intervention, and those would all be normative choices for behavior?

Assaf

>-----Original Message-----
>From: Assaf Arkin [mailto:arkin@intalio.com] 
>Sent: Thursday, February 10, 2005 7:08 PM
>To: Satish Thatte
>Cc: ygoland@bea.com; Francisco Curbera; Prasad Yendluri; Danny van der
>Rijn; wsbpel@lists.oasis-open.org
>Subject: Re: [wsbpel] Issue 190 - BPEL Internal Faults (New Proposed
>Issue Announcement)
>
>Satish Thatte wrote:
>
>  
>
>>I disagree with Yaron that his setting#1 which corresponds to my
>>approach B is possible today without preventing the BPEL engine from
>>actually carrying out prescribed runtime semantics.  But I agree with
>>him that the two approaches need to be made possible via some
>>platform-specific switch, i.e., made compatible with BPEL normative
>>semantics.  One way is to extend our notion of "terminate" to include
>>optional fault data.  I would then argue that a BPEL engine is free to
>>provide a (private) switch that chooses between
>>terminate-then-optionally-repair-and-continue behavior as well as
>>auto-convert-terminate-to-fault-and-continue behavior. 
>> 
>>
>>    
>>
>The problem with the switch is that there is no clear way for the 
>process designer to indicate 'this scope was designed to cleanly recover
>
>from any possible error condition'.
>
>Assaf
>
>
>  
>
>>Satish
>>
>>
>>-----Original Message-----
>>From: Yaron Y. Goland [mailto:ygoland@bea.com] 
>>Sent: Monday, February 07, 2005 12:13 PM
>>To: Francisco Curbera
>>Cc: Prasad Yendluri; Danny van der Rijn; wsbpel@lists.oasis-open.org
>>Subject: Re: [wsbpel] Issue 190 - BPEL Internal Faults (New Proposed
>>Issue Announcement)
>>
>>I think the core of the problem is another part of our ever increasing 
>>elephant.
>>
>>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 
>>extensions.
>>
>>	Yaron
>>
>>
>>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. The
>> 
>>
>>    
>>
>>>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
>>>   
>>>
>>>      
>>>
>>deal
>> 
>>
>>    
>>
>>>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.
>>>
>>>Paco
>>>
>>>
>>>
>>>
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>>>                     Prasad 
>>>Yendluri
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>>>                     <pyendluri@webmet        To:       Francisco 
>>>Curbera/Watson/IBM@IBMUS                                            
>>>
>>>                     hods.com>                cc:       Danny van der
>>>   
>>>
>>>      
>>>
>>Rijn 
>> 
>>
>>    
>>
>>><dannyv@tibco.com>, wsbpel@lists.oasis-open.org            
>>>
>>>                                              Subject:  Re: [wsbpel]
>>>   
>>>
>>>      
>>>
>>Issue 190 
>> 
>>
>>    
>>
>>>- BPEL Internal Faults (New Proposed Issue             
>>>
>>>                     02/04/2005 02:30          
>>>Announcement)
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>>>                     
>>>PM
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>>>
>>>Hi,
>>>
>>>1. Isn't this the same issue as the one raised by issue 187 where we
>>>   
>>>
>>>      
>>>
>>ask if
>> 
>>
>>    
>>
>>>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
>>>   
>>>
>>>      
>>>
>>that
>> 
>>
>>    
>>
>>>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 to
>> 
>>
>>    
>>
>>>the immediately confining scope and the process could continue,
>>>   
>>>
>>>      
>>>
>>perhaps the
>> 
>>
>>    
>>
>>>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
>>>   
>>>
>>>      
>>>
>>process
>> 
>>
>>    
>>
>>>(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
>>>   
>>>
>>>      
>>>
>>Issue
>> 
>>
>>    
>>
>>>      : 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
>>>   
>>>
>>>      
>>>
>>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
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>From: Danny van der Rijn
>>>>To:       wsbpel@lists.oasis-open.org
>>>>        
>>>>
>>>>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
>>>
>>>
>>>
>>>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_workg
>>    
>>
>r
>  
>
>>oup.php.
>> 
>>
>>
>>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_workg
>>    
>>
>r
>  
>
>>oup.php.
>>
>>
>>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_workgr
>oup.php.
>  
>
>> 
>>
>>    
>>
>
>
>  
>

begin:vcard
fn:Assaf Arkin
n:Arkin;Assaf
org:Intalio
adr;dom:;;1000 Bridge Parkway Ste 210;Redwood City;CA;94065
email;internet:arkin@intalio.com
title:Chief Architect
tel;work:(650) 596-1800
x-mozilla-html:TRUE
url:http://www.intalio.com
version:2.1
end:vcard

S/MIME Cryptographic Signature



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