W3C home > Mailing lists > Public > public-ws-addressing@w3.org > February 2006

Re: (possible) WS-RX use cases

From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Date: Mon, 06 Feb 2006 13:04:40 -0800
Message-ID: <43E7B9E8.4020000@oracle.com>
To: David Hull <dmh@tibco.com>
CC: "public-ws-addressing@w3.org" <public-ws-addressing@w3.org>

There is also another case:

   * I send you a message.
   * You don't ack it immediately, but instead just send an empty 202.
   * I send you another message
   * You send me WS-RX acks for the previous message. But the ack header 
does not acknowledge the current message.


David Hull wrote:
> In the case of WS-RX acks coming back in the HTTP response with any 
> application-level response going elsewhere, just which cases are we 
> considering?  I can think of at least two:
>    1. WS-RX ack of the HTTP request
>         * I send you a message.
>         * You send me back a WS-RX ack of that message with a 202.  You
>           might also send some other message somewhere, but I don't
>           think that's relevant here.
>    2. General WS-RX ack, for example
>         * I send you a message.
>         * You don't ack it immediately, but instead just send an empty 202.
>         * I send you another message
>         * You send me WS-RX acks for both messages.
> Case 1 seems almost pointless.  If all I need to know is that you got 
> the message, any HTTP response will do.
> Case 2 seems much more useful.  In this case the HTTP response (whatever 
> it is) means you got the message, while the WS-RX ack means something 
> else, e.g., you were able to forward it on and it reached its final 
> destination.
>  >From a SOAP MEP point of view I don't see much difference between 1 
> and 2 (except that 1 always expects a non-empty 202).  Case 2 can be 
> viewed as abuse of HTTP, particularly since 202 seems to be aimed at 
> conveying status of the particular HTTP response.  On the other hand, 
> one can argue that the sender is legitimately POSTing messages to be 
> delivered and the receiver is legitimately responding with status 
> information.  It really depends on how you view the flow, which is why I 
> tend to fall back to whether the wire-level behavior works.
> Actually, there's an interesting third option, a variant of the second.  
> Here's one possible example:
>     * I send you a message
>     * You send back an empty 202.
>     * I send you a request message
>     * You send back a response, with a 200.  That message also happens
>       to contain a WS-RX header with an ack for my first message.
> My personal feeling (at the moment) is that case 2 is not quite right, 
> because of the semantics defined for 202, but /would/ be alright (and in 
> line with case 3) if the acks had a 200 status.  This takes the view 
> that the acks are a SOAP-level response just like any other.  Whatever's 
> receiving and dispatching the response has to take this into account: It 
> might get back a 200 response that doesn't filter up to the 
> application.  Put another way, the various WS* headers may not all be 
> visible to the application, and given this, it's possible that there's 
> nothing left after they've been filtered out.
> The key question here in any case is, does the receiver of a message 
> know enough to handle it appropriately?  I'm particularly concerned 
> about non-empty 202 messages in this respect, and I'd like to see a bit 
> more detail about how they would be dispatched.
Received on Monday, 6 February 2006 21:05:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:12 UTC