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] 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.


[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]