Re: (possible) WS-RX use cases

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?