Re: (possible) WS-RX use cases

David,

Please see my comments inlined below.

Cheers,

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/02/2006 01:18:44 PM:

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

Actually, I have to take exception to this. A WS-RX ack covers the entire 
range
of messages within a Sequence. It has been designed in this manner to 
ensure that
the SequenceAcknowledgements need not be sent reliably. If a 
SequenceAcknowledgement
is lost in transit between the RM Destination and RM Source, or if a given 
SequenceAcknowledgement
cannot be transmitted because either the RM Source is unavailable at the 
time, or
because the network is impaired, then a subsequent SequenceAcknowledgement 
will
provide the same information. 

Thus, in the case you describe, in which there is no failure, it may seem 
as
if the 202 with no entity body would suffice. However, as we all know, 
s#!t happens.
The 202 response may never reach the HTTP client, in which case the source 
would
be left in an in-doubt status with regards to whether the message carried 
in the
HTTP request message were successfully received.

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

That is not the intent of the SequenceAcknowlegement. A 
SequenceAcknowledgement
means that the message has been successfully *received* by the role of
RM Destination. It does not in any way infer whether the message has been
processed. It only means that the role of RM Destination has assumed 
responsibility
for delivering the message to the application destination (eventually).

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

You can do that, yes. However, it is not necessarily the case that
a "oneway" message (from an application perspective) would be followed
by a request/response such as you describe.

> 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 

I should certainly hope so!

> about non-empty 202 messages in this respect, and I'd like to see a 
> bit more detail about how they would be dispatched.

What is the antecedent of "they" in this context? Are you referring to
the handling of a SOAP envelope carried on an HTTP 202 Accepted response?
Are you referring to the processing of the SOAP envelope carried in the
HTTP request?