Hi,
+1 to that in general.
Another suggestion:
Regarding to section 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."
We should update that sentence to reflect the addition of
locally-scoped partnerLink.
"If the process or scope instance reaches the end of its
behavior, and one or
more inbound message activities (e.g. <receive>) which make
uses a partnerLink declared in the process or scope remain open,
then the standard fault
bpws:missingReply MUST be thrown by a compliant implementation."
Make sense?
Regards,
Alex Yiu
Danny van der Rijn wrote:
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
---------------------------------------------------------------------
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
|