Re: (possible) WS-RX use cases

+1

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295

public-ws-addressing-request@w3.org wrote on 02/06/2006 04:04:40 PM:

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