Discussion on Duplicate elimination issue from 6/14 minutes

[Tom Rutt <tom@coastin.com>]

Here is the discussion from the 6/14 minutes, to tip off discussion.

5.3 PC25

PC25 Spec


Technical
Open
Doug Bunting
Title: Duplicate message responses
Description: http://www.oasis-open.org/archives/wsrm/200406/msg00078.html

Proposal: under discussion
Resolution:

• RE: [wsrm] clarification on Respond primitive
 From Jacques Durand <JDurand@us.fujitsu.com> on 14 Jun 2004 06:19:04 -0000

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).

Jacques: the discussions on the Mailing list have been about A.

Doug: in this thread you have described a related, but somewhat 
different problem. Two ways for the receiving rmp to response can 
happen. The sending RMP needs to ensure the notify is not sent more than 
ones.

Tom: we need to add text about not having the notify sent twice.

Jacques: the respond and notify message flow is not subject to reliability.

Doug: I was no suggesting that. There are many ways to get duplicate 
response.

Tom: we should allow the caching solution for the duplicate response, 
but we should not require.

Jacques: we had earlier proposed a reliable response. We cannot 
guarantee delivery of response.

Tom: Are you concerned about the receiving RMP being allowed to send a 
cached response.

Doug; I would prefer recommended to cache, but I have not proposed a 
must for the cached response. No one has suggested a three way handshake 
to ensure the response is received. I am hoping to allow the consumer 
payloads to ride on the duplicate response. I do not want to require a 
soap fault in this condition, which will prevent invisible reuse of 
cache payload.

(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...)

Tom: are you suggesting a new reply type, acked duplicate. This would 
not be a fault.

Jacques: this is getting into the solution space. We need to clarify the 
spec in this area.

Tom: I am not sure we need this new reply type. We need to discuss it 
further.

Doug: I am not entirely sure that this new indicator would solve the 
problem.

Jacques I suggest we leave this for discussion.

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.

Jacques; where we bring value with WS reliability, is that an 
independent spontaneous poll, the sender would know whether the request 
was correctly delivered is valuable. If the request/response failed 
should not depend on whether the response is delivered.

Tom: this needs to be discussed further on the list.

Thx,

Jacques

-----Original Message-----
From: Doug Bunting [mailto:Doug.Bunting@sun.com]
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


-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133