Re: (possible) WS-RX use cases

Christopher B Ferris wrote:

>
> > Does any of this make sense to you?
>
> Yes,
>
> See http://www.w3.org/Submission/ws-polling/

Saw it.  Liked it.  Forget how it interacts with WS-RX and end-to-end acks.

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