OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

Tom Rutt wrote:

> I propose to allow both 1) and 3) behaviours , that is:
> 1) Sending rmp allowed to return buffered response from previous 
> invocation with rm-acknolwedgement indication, or
> 3) define a new RM-Fault called "Response Payload Not Available for 
> Duplicate request" which gets sent with
> a soap fault in the case where the duplicate invoke requires  a 
> response which is not available because of duplicate request elimination.
 Sending both RM and SOAP Fault is wrong in my opinion. See the other 
thread for the reasons.

 Coming to this issue, while I'm not against having 2 options in 
principle, the concern I've here is
 interoperability. Since we don't have a corresponding RM agreement item 
or policy negotiation
 that 2 (RMP) endpoint can decide upfront, how is it going to be 
interoperable as the behavior
 is subject to change between 2 different Receiving RMP endpoints.

> Tom Rutt
> Sunil Kunisetty wrote:
>> Tom Rutt wrote:
>>> I have one question inserted below.
>>> Tom Rutt
>>> Sunil Kunisetty wrote:
>>>> 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.
>>> The situation that causes the most trouble is when the response had 
>>> been previously sent, so the responder RMP
>>> has no response payload to return since it did not invoke the second 
>>> deliver. Thus the sender resending will
>>> not help all all.
>>> The reason to give an indication is so the sender will not continue 
>>> to resend the duplicate, in cases where the original
>> Right. That's why I said I like to send a RM signal so that the 
>> Sender can either resend the Message
>> with a different MessageId or query as you suggested.
>> Option 2 (sending an empty SOAP envelope) is the wrong thing to do.
>>> response is lost. However an indication will let the sender know it 
>>> SHOULD NOT resend the duplicate. Instead, it
>>> could invoke other operations to query the server state (eg, get the 
>>> current ballance of the account to see if the
>>> first invoke actually happened.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]