Title: RE: [wsrm] clarification on Respond primitive
I think we need to state clearly the problem we try to solve here, as it seems
to exceed the one summarized in #3:
(A) Are we trying to guarantee the delivery of the response in an underlying request-response MEP,
("Respond" invocation on receiving RMP)? (or of a complete request-response transaction?)
Which, as we have investigated long ago (study September 03), is not that simple and subject
to severe implementation limitations, not just caching. I thought we had decided to leave it
out for this release.
(note that in such case, a duplicate generated by resending should be treated differently from
a duplicate generated from network problem).
(B) Or, more modestly, are we trying to avoid some side effect of acknowledging duplicates
in underlying request-response MEP, which translates into the receiving RMP sending back
a response (to the duplicate) that looks like a valid
message to the sending RMP (with an RM Reply, and whatever payload) but that the sending RMP
must NOT pass to its Producer ("Notify")? The safest way to do allow this filtering,
I believe, is for the RM Reply to tag the message ID in the RM Reply, as "duplicate" instead of ack.
(That is what I was suggesting, though that is more than editorial...)
NOTE: messages produced by a COnsumer via "Respond" could still have guaranteed delivery
even if we don't solve (A). The problem lies in the underlying request-response MEP,
so we don't have to tie - in our spec - the use of "Respond" with the response leg of such an MEP.
Note also that if a Producer could be notified - e.g. by a subsequent Poll - that its request
has been well delivered (acked) even if the response is lost, that might be quite sufficient, and allow
the Producer to take appropriate action, which may vary depending on whether the request was idempotent or not.
Thx,
Jacques
-----Original Message-----
From: Doug Bunting [mailto:]
Sent: Saturday, June 12, 2004 8:30 PM
To: Jacques Durand
Cc: wsrm
Subject: Re: [wsrm] clarification on Respond primitive
Jacques,
On 11-Jun-04 14:11, Jacques Durand wrote:
...
> Now, here is a position on the duplicate issue:
> - The response to a duplicate - whether acknowledged or not - should never
> be passed through the WS stack of the sending side. It should be caught
> by the RMP
> and discarded. The Producer should never be aware of it, simply because
> the Producer
> in the first place did not / cannot have generated this duplicate ! (it
> has to originate
> at RMP level, because a duplicate Submit call on an RMP will translate
> into different message IDs.)
> - so the question is : how can the receiving RMP "mark" this response so
> that
> teh sending RMP will not pass it to the Producer?
This question implies an all-powerful receiving RMP that also has complete
control over the underlying protocol and can assure itself that no
duplicates or unequal delays will occur during message transfer. The
sending RMP must be responsible for filtering duplicate RM-Replies it
receives and preventing redundant Notify invocations. Such a requirement
is entirely reasonable since the sending RMP already tracks message
identifiers for which RM-Replies are outstanding.
Unless, of course, you have reversed our abstract model's identification of
the sending and receiving RMP? In the model, the receiving RMP publicizes
information and "sends" RM-Replies to the sending RMP.
> Jacques
thanx,
doug
