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]