[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 221 - Questions around bpel:missingReply
Did we ever agree to put in language that made it clear that while missingReply was guaranteed to be thrown before a process finally exits it nevertheless can be thrown at any earlier point as soon as the engine determines that a reply cannot be executed? E.g. process sequence request ... if ... reply ... Assuming that the only use of the reply activity in the entire process is inside of the if and assuming that on this execution the if condition failed so the reply wasn't executed then a smart processor could throw the missingReply fault at any point from when the if's condition failed until just before the process exits. An alternative approach would be to mandate that at the instant that it is impossible for the reply to ever be called the engine MUST throw the missingReply fault. The purpose in having a more restrictive interpretation is that this would give some 'locality' to where the fault will be thrown and allow people to put fault handlers to deal with this situation somewhere other than the global scope. Just thinking out loud, Yaron ws-bpel issues list editor 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 <http://www.oasis-open.org/apps/org/workgroup/wsbpel> 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 > <http://www.oasis-open.org/apps/org/workgroup/wsbpel/documents.php> - > 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 > <http://www.choreology.com/external/WS_BPEL_issues_list.html>. > > > Issue - 221 - Questions around bpel:missingReply > > *Status:* received > *Date added:* 30 Jun 2005 > *Categories:* Fault handling <#category_fault_handling> > *Date submitted:* 30 June 2005 > *Submitter:* Danny van der Rijn <mailto:dannyv@tibco.com> > *Description:* The last sentence of 14.5: > > If the process instance reaches the end of its behavior, and one or > more receive activities remain open, then the standard fault > bpws:missingReply MUST be thrown by a compliant implementation. > > Q1: have the process' faultHandlers been uninstalled? > A1a: If yes, then the only thing that happens here is that the process > ends in a faulted state, instead of a success state. > Q1a: Does this difference have normative meaning? > A1b: If no, then a faultHandler has the chance to catch the fault. > Q2b: What happens if that fault handler doesn't reply? Does the fault > get somehow suppressed the 2nd time around? Does the fault get caught > again by that eventHandler? Do we allow an infinite loop? > *Changes:* 30 Jun 2005 - new issue > > To comment on this issue (including whether it should be accepted), > please follow-up to this announcement on the wsbpel@lists.oasis-open.org > list (replying to this message should automatically send your message to > that list), or ensure the subject line as you send it *starts* "Issue - > 221 - [anything]" or is a reply to such a message. If you want to > formally propose a resolution to an open issue, please start the subject > line "Issue - 221 - Proposed resolution", without any Re: or similar. > > To add a new issue, see the issues procedures document (but the address > for new issue submission is the sender of this announcement). > > Choreology Anti virus scan completed >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]