Re: [wsrm] Summary of WS-Reliability 1.01* issues discussed over past week

[John Fuller <jfuller@wernervas.com>]

While I agree that literal caching is something I deliberately avoid in  
implementations,
I'd like to discuss ii).

The Asynchronous Service Access Protocol is about communicating with
stateful service instance resources:  the "service" we talk to is  
asynchronous in
that we kick it off and get a uri (create an instance from a factory),
we can then communicate with it while it runs,
and it notifies subscribed observers when things change (state  
changes/completion).

This is to say, the ASAP TC is not about asynchronous messaging for  
services
but messaging for asynchronous services.

I introduced some of the ASAP work to the WSRM TC when the different  
message exchange
patterns were introduced, but I was convinced by people's arguments that
it might be too heavy weight to consider requests for message delivery  
to be instances
of asynchronous service
(though this would let people cancel delivery, inquire as to the state,  
etc),
but that instead ASAP could sit on top of WSRM so that
our requests to create service instances could be recoverable using
an RMPs mechanisms
(should people not implement their own commit-before-http-response  
recovery).

It could be that I don't understand the argument and need more  
clarification
about what ASAP could do for this situation;
on the other hand, I thought it wouldn't hurt to clarify the intent of  
ASAP.



On Jun 14, 2004, at 4:30 PM, Sunil Kunisetty wrote:

>
>  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.
>>
>
>
> To unsubscribe from this mailing list (and be removed from the roster  
> of the OASIS TC), go to  
> http://www.oasis-open.org/apps/org/workgroup/wsrm/members/ 
> leave_workgroup.php.
>