[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
+1 to Alex's points. Catchall, btw, isn't necessarily a bad way to handle system faults. If a process ends up in catch all then it knows two things: #1 - Something bad happened #2 - It wasn't something bad that the process was explicitly expecting The proper response in such a situation is to do exactly the sorts of things Alex described, clean up any outstanding transactions and rethrow the fault. This isn't about fixing things, this about failing gracefully from an unrecoverable fault. That the fault is a system fault is neither here nor there. Yaron Alex Yiu wrote: > Hi, > > My viewpoint is more inline with Danny's. > We may have decided not to support any explicit language-based modularizing in > BPEL 2.0. (related to issue 2). The base language BPEL 2.0 must allow > modularization for tools (BPEL composition) and future modularization features > in BPEL 3.0 or so. > > Here are more detailed reasons why current proposal associated with Issue 190 is > NOT a good idea: > > We need to equip BPEL developers to program a fault-tolerant to deal with the > nature of a long running BPEL process. Here are more reasons: > > * _BPEL system level faults are often triggered by an application level faults._ > > E.g. we can have a sequence like this: > > <sequence> > <receive partnerLink="p1" ... /> > ... > <invoke partnerLink="p2" ... /> > ... > <reply partnerLink="p1" ... /> > </sequence> > > If an application fault happens in the middle of receive and reply, we > would have a missingReply fault. (BTW, there are some semantics of > missingReply not well-defined. But, that is another issue.) > > Of course, one can say that BPEL process definition is faulty or not > bullet proof enough. However, this kind of mistake are made very often by > typically programmer (e.g. Java programmer), let alone the BPEL developers > who may be business analysts ahd have less training in traditional > defensive programming. > > * _What about Default Compensation?_ > Say, we have this piece of code: > > <scope name="S1"> > <sequence> > <scope name="SA"> ... </scope> > <scope name="SB"> ... </scope> > </sequence> > </scope> > > After scope-A is finished, a system level fault happens in scope B, > scope-A will not even got a chance to be compensated? > > * _Default catchAll handler is already doing the right thing - ending the > process gracefully _ > The default fault handler will invoke compensation and rethrow the fault > to the parent scope. If BPEL does not add any system-fault specific > handler or override the default catchAll handler, the default behavior > fits with most of the expectaiton of submitter's proposal. That is the > whole process will be ended gracefully with compensation. > > * _Modularization of BPEL code and Parallel BPEL Branches_ > Also, +1 to Danny's point. A complicated BPEL will pieces of BPEL fragment > (<scope>) coming from different BPEL developers. We must provide a way for > BPEL developers to shield error from other developers. > > Particularly, in the issue 6 (early completion) context, we may have a > flow to deal with 3 different suppliers for quotation with slightly > different logic in a <flow>. What the BPEL proceses needs just at least > one quotation. If one <scope> (with an overriden <catchAll>) inside <flow> > have system level fault <catchAll> , while the other 2 <scope> completed > succeeded. Why we cannot proceed with the rest of the BPEL??? > > * _Data-Triggered Fault_ > Some system level fault (e.g. selectionFailure and unsupportedReference > fault) are actually relatively minor and triggered by unexpected values in > incoming data, NOT a BPEL logic mistake. In those cases, a BPEL > adminstrator should be able to repair the process instance by repairing > the data. > > > > > Thanks! > > > > Regards, > Alex Yiu > > > > > Danny van der Rijn wrote: > >> >> >> Francisco Curbera wrote: >> >>>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. >>> >>> >> Whether the language supports it or not, I would imagine that tooling will. >> >>>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. >>> >>> >>> >> Dieter's suggestion is to terminate the process immediately. I don't see this >> as the best possible way. I can imagine saying that such behavior is >> unspecified, but I'm not comfortable with that. Which leaves me preferring >> exactly what's there now. We may have to agree to disagree on this, though, >> since I doubt my argument is anything new to you. >> >>>Paco >>> >>> >>> >> Danny >> >>> >>> 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]