Re: [wsbpel] Issue - 221 - Questions around bpel:missingReply

["Yaron Y. Goland" <ygoland@bea.com>]

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
>