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.
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.
>
>
>
--
----------------------------------------------------
Tom Rutt email: ;
Tel: +1 732 801 5744 Fax: +1 732 774 5133
