Re: (possible) WS-RX use cases

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.

-Anish
--

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