Re: (possible) WS-RX use cases

> Does any of this make sense to you?

Yes,

See http://www.w3.org/Submission/ws-polling/

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 03:40:53 PM:

> First, it seems that even in case 1, the ack coming back may not be 
> (solely) for the response being sent.  I.e.,:
> I send a request.
> I see a failure, but in fact you got the request (s#!t happens).  Um
> ... if it's req-response, how does your response get back?  So 
> suppose it's one-way ...
> I send another message
> I get back an ack for both messages.
> I believe this is what you were describing?  If so, the strictly 
> speaking it's already probably afoul of the semantics of 202.
> 
> The scenario I had in mind was more like this:
> I POST messages to a mailbox
> An intermittently connected device GETs those messages whenever it can.
> I want to know when it gets them (and not just when they landed in 
> the mailbox).
> This doesn't seem exotic to me; it's inches away from web mail, 
> especially if you throw in return-receipt.  Naturally, you can also 
> do the same thing with email, with the same concern.  SMTP will only
> tell you that the server got the message, not that the remote device
> retrieved it.
> 
> Mark Baker pointed out (IIUC) that this is basically building a 
> transfer protocol on top of HTTP and (IIUC) that it would be better 
> just to implement such a protocol directly between me and that 
> intermittently connected device.  I largely agree with both 
> sentiments (whether or not Mark does :-), but I may disagree on the 
> implications.
> 
> As far as I can tell, a major piece of potential value added by WS-*
> is the ability to use the features of various protocols end-to-end 
> on a pay-as-you-go basis.  For example, TCP provides (among other 
> things) reliability and packet reassembly.  In the case in point, I 
> need reliability very much like that provided by TCP, but I don't 
> need packet reassembly  (packets are effectively arbitrarily big). 
> Further, TCP generally treats intermittent connectivity past a 
> fairly short interval as an error.  In all, implementing some form 
> of TCP between myself and the remote device seems like a bad fit.
> 
> By using WS-RX, I can get end-to-end reliability regardless of 
> whether the "packets" are sent directly, POSTed to and GOT from a 
> mailbox, sent via email, or whatever.
> 
> If you buy this as a use case, it seems pretty clear that sending 
> back acks in the manner I proposed would be very useful.  It 
> wouldn't be strictly necessary.  The mailbox needs to provide a 
> separate GET operation for acks anyway, because I don't always want 
> to wait until I've got something new to send to find out if previous
> stuff arrived.  Given that, I could do a GET(acks) after every 
> POST(message) and get the same effect as piggybacking.  This seems 
> inefficient, though.
> 
> Does any of this make sense to you?
> 
> Christopher B Ferris wrote: 
> 
> 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?