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

[Danny van der Rijn <dannyv@tibco.com>]

That would make sense to me, but I never saw such language.  The current 
language brings up the issue that I raised.

Yaron Y. Goland wrote:

> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in 
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>