[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] Summary of WS-Reliability 1.01* issues discussed over past week
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 Doug Bunting wrote: > 3) The description of duplicate elimination in section 3.2.2 does not > describe the content of either the immediate underlying protocol > response nor an RM-Reply that may be sent later (in the callback or poll > RM-Reply cases). In particular, whether or not consumer payloads from > the response sent the first time (in the case when the earlier response > had been lost) may be returned during this iteration is left > unspecified. As Sunil has stated, some have implementation issues with > caching payloads in the receiving RMP though this is the most > appropriate way to handle the duplicate message. We might thus avoid a > new requirement but concentrate on ensuring caching is allowed. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]