Re: Action Item - Part I: WSRX and MEP signaling on the wire

Apologies for the belated response... too much travel. Please see my 
comments 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

xml-dist-app-request@w3.org wrote on 01/04/2006 05:24:37 PM:

> This is a bit more free-form than I'd originally intended, but bear 
> with me.  I think we get somewhere.
> 
> First, a motivating use case involving reliability.  I believe there
> are WSRX members on this list or at least lurking nearby.  If so, 
> please let me know if I've missed something fundamental.
> 
> The reliability standards I've seen distinguish between 
> submit/deliver and transmit/receive.  Transmitting and receiving are
> transport-level concepts and carry no particular guarantee of 
> reliability.  An acknowledgment message acknowledges not that a message 
was 
> received at the transport level, but that it was delivered to its 

Not so. The WS-RM SequenceAcknowledgement merely acknowledges that the
message was successfully received. It makes no claims whatsoever that the
message has, or even will, be delivered to the ultimate recipient.
It is effectively the equivalent of the HTTP 202 Accepted response in its
meaning. The distinction is that an HTTP 202 Accepted is returned on the
same connection as the HTTP request message, whereas the WS-RM SeqAck
can be returned on a separate connection and that it covers the complete
range(s) of received messages received, such that it need not be 
transmitted
(or transferred as the case may be) reliably.

> ultimate recipient.  Just exactly what this means is left out of 
> scope.  Essentially a message is considered received if the sending 
> side learns of an acknowledgment for it according to whatever 
> acknowledgment scheme is in effect.
> 
> The upshot here is that, even if I use a TCP-based transport, and 
> even if that transport allows for status codes or some other 
> indication of a successful exchange, successful transmission of a 
> message does not imply successful delivery.  Delivery might depend 
> on some further application-level processing, forwarding to another 
> destination, or whatever.

See above. 

> 
> To be concrete, suppose I am using WSN or similar to manage sending 
> notifications to a given node.  I have provided an HTTP endpoint 
> reference for the consumer of the subscriptions, and I have 
> specified (using WSN's not-yet-specified policy assertions :-) that 
> these notifications should be delivered reliably.

Actually, you would specify the use of WS-RM using the WS-RM Policy 
Assertion:-)

> 
> Notifications are inherently one-way.  Given HTTP as a transport, we
> would want to use the request-optional-response MEP to send 
> notifications.  I'm not sure if WSRX does (or doesn't) support what 
> I'm about to describe, but I would expect that the producer (or 
> something acting on its behalf, but that's a separate issue) send 
> notifications to the consumer by POSTing SOAP messages to the HTTP 
> address given in the subscription request.
> 
> What comes back?
> 
> In the absence of other information, I would expect that each 
> notification POST should get as its response either a 202 or a SOAP 
> message containing acknowledgment information for some set of 
> previous messages.  The 202 would happen if there were no 
reliability-level
> acknowledgments available.  Alternatively, the server could send 
> always back an acknowledgment message.  If there were nothing new to
> acknowledge, it would be identical to the previous one.  I don't 
> have a strong opinion as to which of these is better; my intuition 
> is to allow for either.

Agreed, especially given that there is no requirement in WS-RM that 
a SequenceAcknowledgement be sent for each and every received message.
In fact, technically, there is only one SequenceAcknowledgement required;
the one that covers the entire range of messages in the Sequence.

In practice, however, it is likely that implementations will send a
"naked" SequenceAcknowledgement message in the HTTP response entity
body for oneway notifications/messages on each response. It should be 
noted
that the SequenceAcknowledgement may not necessarily include the message 
number of the message transferred on the HTTP request message.

> 
> An interesting variant occurs when the producer is sending multiple 
> streams of notifications to the consumer, in which case a 
> notification in one stream might elicit an acknowledgment for a 
> notification from a different stream.  Why not?  The HTTP response 
> channel is available and might not be available again for arbitrarily 
long.

This is supported by WS-RM. 

> 
> Notable points:
> The transport-level MEP is always request response.

In the context of the HTTP binding, yes (although I am 
SURE that MB will cringe at the use of the term "transport-level" :-)

> The SOAP MEP is always request-optional-response
> The application-level MEP is always one-way
> The potentially complex part here is in the reliability layer.  It 
> sees two streams of messages: notifications coming out and 
> acknowledgments coming back.  From this point of view
> The flow of acknowledgments is independent of the transport-level 
> flow (a given HTTP response acknowledges zero or more notifications)
> The flow of acknowledgments is independent of the application-level 
> flow (for the same reason)

yes

> The flow of notifications ought to be independent of the transport 
> level flow.  If nothing else, WSN allows for boxcarring of 
> notifications: a given "notify" SOAP message may contain several 
> notifications (but does the reliability layer know this?).

No, WS-RM would only be concerned with the message, not its contents.

> Further, since the reliability layer may retransmit, so a given 
> application-level notification may trigger more than one transport-
> level message.
> The recurring theme I'm seeing here is that each level has its own 
> view of message flow.  Often, those views will converge, but they 

Bingo.

> can diverge for any number of perfectly ordinary reasons, even 
> leaving aside cases involving cell phones and tunnels:
> A request-response operation may be realized as more than one 
> transport-level exchange (the WSA "async request-response" case)
> A one-way operation may be realized as a request-response, either as
> a push operation or through polling.

Even a oneway message over the HTTP binding involves a request/response.
The distinction, as I have seen in other emails, in this and related
threads, is the SOAPiness of the response.

> Retransmission means that one application-level operation may 
> manifest as several transport-level operations, even where the 
> application-level operation would otherwise match the transport level.
> Boxcarring, where applicable, means that several application-level 
> operations may manifest as a single transport-level operation. 
> Reliability-level acknowledgments boxcar by design.

Don't know if I would necessarily use that term, but yes... as discussed
above, the SeqAck covers the entire range of messages in the Sequence, not
just the last one received as would be the case of an HTTP 2xx response.

> This may seem complex, but there is a bright side.  The various concerns 

> have to be separated, so we might as well gain from this separation.

You go, girl! This has been my point all along.

> In particular, SOAP can focus narrowly on abstracting the 
> characteristics of the transport and not worry about anything else. 
> I'm more and more convinced that we're about done as far as HTTP is 
concerned:
> The SOAP request-(optional-)response MEP describes a SOAP message 
> going out and something SOAPy optionally coming back.

As Noah points out, something optionally SOAPy coming back.

> The SOAP response MEP describes a non-SOAP request and something 
> SOAPy coming back.
> Um, how do we describe a SOAP request and something non-SOAPy coming 
back?
> We shouldn't have to worry about non-SOAP out and non-SOAP back, right?

Correct.