Re: [wsrm] Discussion on Duplicate elimination issue from 6/14 minutes

[Sunil Kunisetty <Sunil.Kunisetty@oracle.com>]

 Here is the mail I sent on Duplicate Elimination a week ago.
 It has the summary, possible solutions and my preferred solution.

 -----------------------------------------------------------------------------------------------------
 I'd like to summarize the options of using Duplicate Elimination for a
 Request-Response MEP.

 1) Cache the message until the original request expires and Send the
    "payload  response" for every subsequent request.
 2)  Send an empty SOAP envelope.
      (Note that when there is no AckRequested, there won't be any Ack and
      hence the SOAP envelope will have empty Header/body).
 3)  Send a signal that it is a "Duplicate Message".
 4)  Spec. says that this is combination is not supported.

 While I personally like (4),  we can't do it as the TC voted to support
 this combination.

 I'm very un-comfortable with (2) as it will cause all kinds of issues and
 as such it is meaningless/un-informative to send "empty signal".

 As per (1), while it is theoritcally reasonable and easy to implement,
 it is impractical from a product/solution perspective.

 Here are few reasons:
 (i) Potentially can throttle the server with memory being sucked up.
    Generally speaking, expire time is used optimistically and will have a
    large life span. Caching responses that long is not too good .
(ii) I believe this thing (async. responses) is beyond the scope
    of this specification and should be handled  in the "OASIS Asynchronous
    Service Access  Protocol TC"  [1]
(iii) There are many subtle things about caching responses:
         - there should be mechanism to invalidate the cache
         - what if the request has time sensitive information. for ex.,
           if I ask for getStockQuote for Oracle with a duration of say 1 hr...
           Assume the first  message is lost.
           Say the RMP resent the same message after 10 mins... they may
           get a stock quote that was 10 mins. ago.
           So if time sensitive data exists, there should be mechanism
           for data resync..

 So for these reasons, I just like a RM signal [3] solution so that
 the application can resend the request.

 If so, how to achieve this:
   a)  Send a SOAP Fault.
   b)  Send a RM Signal/Warning.

 Between these two, I prefer (b), but not both.

 Or,  an option to support both (1) & (3) is also acceptable.


 -Sunil


[1] -  http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=asap


Tom Rutt wrote:

> 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
>
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.