Subject: RE: [wsbpel] Issue 190 - BPEL Internal Faults (New Proposed Issue Announcement)
The only substantive difference between what Dieter originally suggested and my subsequent embellishment is that I suggested we allow “exit” (formerly terminate) to carry fault-like data and then treat all current “internal” faults (except joinFailure) as exits (as Dieter suggested) but with such data. This allows engines dealing with such exited aka frozen process instances to privately support notions such as “convert an exit to a fault and proceed” or “repair process and continue”.
From: Alex Yiu [mailto:firstname.lastname@example.org]
If I understand your first question correctly, that was my notion of the convert-terminate-to-fault-and-continue behavior. And then yes, the failure could be capped to a scope, since the "modeling" fault at that point will be treated like any other ordinary fault.
From: Alex Yiu [mailto:email@example.com]
Sent: Fri 2/11/2005 11:49 AM
To: Satish Thatte
Cc: firstname.lastname@example.org; Francisco Curbera; Prasad Yendluri; Danny van der Rijn; email@example.com; firstname.lastname@example.org
Subject: Re: [wsbpel] Issue 190 - BPEL Internal Faults (New Proposed Issue Announcement)
I guess I undestand you point ...
More questions: Say:
If we don't call it "fault", after the process is "freezed" ...
and after user-inspection, he/she consider the fault should not affect
the compensation logic, can the user select the action to activate a
fault handler of a related scope which does the compensation logic and
marked the scope faulted and continue rest of the process?
It is important to cap the system failure to one of child scopes, not
the whole process, for fault-tolerant design [ Oh my ..... the term
"fault" comes again ... do we really want to avoid that term? ]
Thinking out loud again: maybe we should still call them as fault and
have a clear explanation on how system failure will be handled
differently from an application fault?
Satish Thatte wrote:
Alex,I agree with what you say except I would rather not call it "fault" because a normal fault does not cause a process to freeze. Our terminate semantics is as close to a freeze as possible already. But if we want to rename terminate as something else (actually didn't we rename it exit already?) that captures the intent better I have no issues with that.As for how the intention is expressed, that will clearly have to be platform specific. We don't have any official notion of deployment descriptor, but it would have to be some sort of extension or external configuration parameter, which I think is what you intended to say.Satish________________________________From: Alex Yiu [mailto:email@example.com]Sent: Thu 2/10/2005 8:45 PMTo: Satish ThatteCc: firstname.lastname@example.org; Francisco Curbera; Prasad Yendluri; Danny van der Rijn; email@example.com; firstname.lastname@example.orgSubject: Re: [wsbpel] Issue 190 - BPEL Internal Faults (New Proposed Issue Announcement)Hi, Satish,If I read Satish's comments correctly, then I would say it is more fair to say:The semantics on how to handle a BPEL fault no longer is "exit"/"quit"/"terminate".The process basically "freezes" / "suspend" before any further code execution. Then, it is up to the BPEL implementation / BPEL site admin / BPEL developer to decide what to do with this "freezed" or "suspended" process.And, I may add more question: May their decision be just the plain old default "compensate and rethrow" semantics in BPEL 1.1? Can their decision be expressed by a deployment descriptor? or extension attribute in BPEL?Regards,Alex YiuSatish Thatte wrote:There are two points at issue here.1. Are undefined-runtime-semantics "faults" really faults in the sensethat one would write specific catch handlers for things likeconflictingReceive, or correlationViolation in the same way as one wouldwrite catch handlers for approvalDenied?2. Admitting that undefined-runtime-semantics "faults" will occur sincewe do not mandate pessimistic static analysis to prevent them, whatexactly is a reasonable way to deal with these "faults"?I would hope that we have no disagreement that specific handlers forcorrelationViolation and such would be extremely rare. CatchAll is theway these "faults" would be intercepted if at all. And in that contextthere is very little one can do except suppress the fault, i.e., limitits impact, and possibly notify someone that it happened. I have notseen anyone argue otherwise.The primay disagreement seems to be about the second question, andespecially about the tradeoff between the approaches ofA. Explicitly define impact boundaries ("modularity" entered thediscussion as an example for such boundaries) even forundefined-runtime-semantics "faults" and within those boundaries applythe usual unravel and compensate logic that gets applied by default.B. There is no reasonable way to define the impact boundaries in mostcases and in a lot of important processes the usual unravel andcompensate logic would create unintended havoc and destroy years of workif blindly allowed to proceed by default and oversight.By the way, neither approach helps as far as letting a partner know whatis going on in cases like missingReply. For that we would have to goback to my suggestion of explicitly declaring MEP instances in scopesand then defining standard wire-faults in case an MEP instance went outof scope without completing. To be clear, I am *not* suggesting we godown that road at this point.I don't think we can settle this with arguments based on examplesbecause "allowing ordinary compensation to proceed" can be viewed asbeing either desirable or disastrous depending on the scenario you havein mind.I disagree with Yaron that his setting#1 which corresponds to myapproach B is possible today without preventing the BPEL engine fromactually carrying out prescribed runtime semantics. But I agree withhim that the two approaches need to be made possible via someplatform-specific switch, i.e., made compatible with BPEL normativesemantics. One way is to extend our notion of "terminate" to includeoptional fault data. I would then argue that a BPEL engine is free toprovide a (private) switch that chooses betweenterminate-then-optionally-repair-and-continue behavior as well asauto-convert-terminate-to-fault-and-continue behavior.Satish-----Original Message-----From: Yaron Y. Goland [mailto:email@example.com]Sent: Monday, February 07, 2005 12:13 PMTo: Francisco CurberaCc: Prasad Yendluri; Danny van der Rijn; firstname.lastname@example.orgSubject: Re: [wsbpel] Issue 190 - BPEL Internal Faults (New ProposedIssue Announcement)I think the core of the problem is another part of our ever increasingelephant.Lots of systems are going to have a magic switch that I stronglyencourage us not to attempt to specify in BPEL both because it's atleast 80% out of scope and because it will take a long time to agree onthe semantics.That switch will specify (either on a process level or perhaps a scopelevel) what to do if certain kinds of faults are thrown. One of the keyfaults 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 processand 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 adminbut 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 thesecond behavior is pretty much our default behavior.Issue 190 would make the second setting effectively impossible since itwould be illegal to ever allow system faults to go through normal faulthandling. But as Alex and others have convincingly argued there are manyinteresting cases in which it makes sense to allow system faults to gothrough normal fault handling.In terms of maximizing portability I think we should stick with ourcurrent behavior and leave the 190 style behavior to out of scopeextensions.YaronFrancisco Curbera wrote:I guess one of the points of the immediate termination condition isthattermination is essentially always invisible to partners of theprocess. Thenet effect of this change (and from my perspective the actual aim ofthisproposal) would be to allow engines the flexibility to deciding how todealwith these situations, termination being an option. Any form ofstandardfault semantics limit that flexibility because the engine would beforcedto follow the usual scope termination/fault propagation behavior withlikely the result of discarding many recoverable process instances -andposisble days or months of process work.PacoPrasadYendluri<mailto:pyendluri@webmetTo:FranciscoCurbera/Watson/IBM@IBMUShods.com> cc: Danny van derRijnSubject: Re: [wsbpel]Issue 190- BPEL Internal Faults (New Proposed Issue02/04/2005 02:30Announcement)PMHi,1. Isn't this the same issue as the one raised by issue 187 where weask ifthere are any constraints in handling of the standard faults? This isproposing a specific resolution where it is recommended that theprocessalways terminates immediately.2. I tend to side with Danny on this. I don't think we should requirethatthe process terminates immediately always. IMO in at least certaincasesthis may not be a fatal situation for the whole process (it could beconfined to the scope) and other parts of the process may be able tocontinue by compensating for pertinent. Perhaps the impact couldlimited tothe immediately confining scope and the process could continue,perhaps thearea the fault occurred could be non-fatal to whole process (e.g.relatedlook-up rather than modification of any information) or caused by sometransient condition that could go away on a retry etc. I think theprocess(fault handler) should be given a chance to handle the situationratherthan 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 intelligentifthe faults could be attached some "fault data" (ref issues 187 and185).Regards, Prasad-------- Original Message --------Subject Re: [wsbpel] Issue 190 - BPEL Internal Faults (New ProposedIssue: AnnouncementDate: Fri, 4 Feb 2005 13:23:17 -0500From: Francisco Curbera <email@example.com> <mailto:firstname.lastname@example.org>To: Danny van der Rijn <email@example.com> <mailto:firstname.lastname@example.org>Hi Danny,BPEL so far does not support any technique for modularizing processauthoring, so the situation you describe is a bit out of scope rightnow.In any case, my view is that the idea that authors of business processaregoing to be adding code to deal with things like unsupportedReferenceisjust not realistic. I would even argue that those faults don'tactuallybelong at the BP modeling level and need to be dealt with in adifferentway.Dieter's suggestion allows implementations to manage these situationsinthe best possible way. This is specially important in the case oflongrunning processes, where months or years of work can be thrown out thewindow when one of these faults is encountered (the current semanticsrequire the complete unwinding of the execution stack if the fault isnotcaught and a generic catch all is essentially good for nothing).Typicallyyou want to allow manual intervention to figure out whether theprocess canbe repaired, terminated if not.Paco>From: Danny van der Rijn>cc:>Subject: Re: [wsbpel] Issue 190 - BPEL Internal Faults (NewProposedIssue Announcement02/03/2005 01:47 PM[Resending this with appropriate header to save Tony/Peter thetrouble]-1As I pointed out in our last face to face, this kind of approach willmakeany kind of modularization extremely difficult. It will give no wayfor adeveloper of a piece of BPEL code to protect against the "modellingerror"(legacy term: "programming error") of another modeller whose attempttomodel the real world failed in a tangible instance.DannyTony Fletcher wrote:This issue has been added to the wsbpel issue list with a statusof"received". The status will be changed to "open" if the TCaccepts itas identifying a bug in the spec or decides it should beacceptedspecially. Otherwise it will be closed without furtherconsideration(but will be marked as "Revisitable")The issues list is posted as a Technical Committee document totheOASIS WSBPEL TC pages on a regular basis. The current edition,as aTC document, is the most recent version of the document entitledinthe "Issues" folder of the WSBPEL TC document list - the nextpostingas a TC document will include this issue. The list editor'sworkingcopy, which will normally include an issue when it is announced,isavailable at this constant URL.Issue 190: BPEL Internal FaultsStatus: receivedDate added: 3 Feb 2005Categories: Fault handlingDate submitted: 3 February 2005Submitter: Dieter Koenig1Document: WS-BPEL Working Draft, December, 2004Related 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 thebehavior ofa process is described as *undefined*, in particular, afterrecognizing internal errors described as standard faults.With the exception of "bpel:joinFailure", *all* of thesesituationsrepresent modelling errors that cannot be dealt with by thebusinessprocess itself in a meaningful way. This behavior becomes evenmorequestionable for catchAll handlers that try to deal withmultipleapplication faults and unexpectedly encounter a standard fault.Submitter's proposal: Instead of allowing processes to catchthese asstandard 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 asBPELis concerned the instance execution ends when terminate isencountered without any fault handling behavior. Any additionalfacilities for extended support for, e.g., repair and continue,isdefinitely out of scope.This approach would also create a clear direction for dealingwithany pathological situation within an inlined language (Issue163) andtherefore also for errors within transition conditions (Issue169).Changes: 3 Feb 2005 - new issueBest Regards,TonyTo unsubscribe from this mailing list (and be removed from the rosterof theOASIS TC), go tooup.php.To unsubscribe from this mailing list (and be removed from the roster ofthe OASIS TC), go tooup.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_workgroup.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_workgroup.php.