RE: Issue - 223 - Replying to faulted Replies

Hi,

This is a draft proposal for Issue 223, please let me know what you think. This issue can be sub-divided into two parts, one dealing with the missingRequest fault, and another dealing with the missingReply fault. The latter has dependencies on 221 (Issue 221 - Questions around missingReply), so it is not included in this proposal, but will eventually be part of the final proposal.

--- begin ---

Change the following paragraphs from Section 11.4:

If a reply activity cannot be associated with an incomplete receive activity by matching the tuples and this error situation is not caught during static analysis, then bpws:missingRequest fault MUST be thrown within the BPEL process on the reply activity. Because conflicting requests should have been rejected at the time inbound message activity is executed, there cannot be more than one corresponding inbound message activity at the time <reply> is executed

To the following:

A reply activity that faults, that is, that throws some BPEL fault, such as bpws:correlationViolation fault, is not considered to have completed its associated open inbound message activity. This means that the inbound message activity remains incomplete and hence a associated reply activity can still be performed without causing a bpws:missingRequest to be thrown.

--- end ---

There is a caveat to this, what happens when you have two concurrent flow links that both have a reply activity associated to the same inbound message activity and are executed at the same time? Because we state in the spec that: ‘…An incomplete inbound message activity describes the state of a BPEL process from the point that a request/response receive activity starts execution until its associated reply begins execution…’, keyword being ‘begins’, it seems to me to indicate that the 2^nd reply activity (which ever it is) would raise a missingRequest fault, because the 1^st reply activity already started executing and thus has completed the IMA (inbound message activity). But what if the 1^st reply activity actually fails (e.g. correlationViolation fault) afterwards, in this case the IMA will again be set to open, but the 2^nd reply activity would already have failed with the missingRequest fault. This seems messy.

There are options to work-around this caveat:

- Consider the reply activity as atomic, in which case the 2^nd reply would have blocked until the 1^st reply activity finishes (successfully or not); or

- Define the IMA to be scoped to the ‘end’ of the execution of the reply activity, in which case we open the door for more race conditions; or

- Don’t allow for faulted replies to be re-executed;

None of which seem attractive.

Moreover, a IMA defines a state (i.e. open, completed), but I don’t think we have ever defined how this state plays out with the isolated scopes. If one replies within a isolates scope, is the state change (open -> completed) of the IMA seen by the rest of the process before the isolated scope finishes?

Thanks,

From: ws-bpel issues list editor [mailto:peter.furniss@choreology.com]
Sent: Tuesday, July 19, 2005 1:59 AM
To: wsbpel@lists.oasis-open.org
Subject: [wsbpel] Issue - 223 - Replying to faulted Replies

This issue has been added to the wsbpel issue list with a status of "received". The status will be changed to "open" if a motion to open the issue is proposed and that motion is approved by the TC. A motion could also be proposed to close it without further consideration. Otherwise it will remain as "received".

The issues list is posted as a Technical Committee document to the OASIS WSBPEL TC pages 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 - 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.

Issue - 223 - Replying to faulted Replies

Status: received
Date added: 19 Jul 2005
Categories: Syntax and validation
Date submitted: 18 July 2004
Submitter: Yaron Y. Goland
Description: Imagine that one has a reply which fails due to a correlation violation. One can imagine having a fault handler that catches this fault and tries to reply to the partner with a fault message.

Is that legal? That is, if a reply has been 'started' but doesn't 'complete' due to a fault then is an attempt to complete the reply later by another reply activity an invalidReply? The current language around messageExchange would certainly make it seem so.

If it is legal and the system decides not to send a second reply (e.g. the program, upon receiving the fault, just gives up on that message exchange and lets it time out) then must a missingReply fault be sent out since the reply still could be completed?
Submitter’s proposal: It seems somewhat futile to allow people to catch the fault but not do the obvious thing with it, which is successfully complete the reply by sending an error message of some sort to the partner. At the same time, those choosing not to finish off the reply after a fault shouldn't now have to deal with a second missingReply fault. I suspect we need language that says something along the lines of 'yes you MAY try a second reply (no promises it will work, depending on the fault that was thrown) but the missingReply fault MUST NOT be thrown for replies that have already faulted for other reasons.'
Changes: 19 Jul 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 - 223 - [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 - 223 - 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).

wsbpel message

Issue - 223 - Replying to faulted Replies