Transport, Transfer and Application - levels in Reliable Messaging

My first post on Reliable Messaging: What kind of reliability do I get with Web Services Reliable Exchange (WS-RX)? just scratched the surface and now it's time to get a little deeper into it.

In the current version of Web Services Reliable Messaging (WS-ReliableMessaging) (Committee Draft 04, August 11, 2006) the layering are explained in section 2 Reliable Messaging Model:

Figure 1 below illustrates the entities and events in a simple reliable exchange of messages. First, the Application Source Sends a message for reliable transfer. The Reliable Messaging Source accepts the message and Transmits it one or more times. After accepting the message, the RM Destination Acknowledges it. Finally, the RM Destination Delivers the message to the Application Destination. The exact roles the entities play and the complete meaning of the events will be defined throughout this specification.

Alright, so the message is not delivered to the application but to the RM Destination! I've found an interesting discussion from the xml-dist-app list that touches on this subject with the title Action Item - Part I: WSRX and MEP signaling on the wire. In a reply from Christopher B Ferris he writes:

I have long argued that if you need an application-level ack, then have the application send one. The purpose, as I see it, of the reliable messaging layer is to ensure a successful hand-off, not to ensure that the application does, or even can, process the message.

That was for seperating the application from the other layers, but it's not that simple since the non-application level can worked with as well (se this post):

> The reliability standards I've seen distinguish between submit/deliver and
> transmit/receive.

i.e. they distinguish between transfer and transport (respectively).

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

If it's a transfer protocol, that's *exactly* what it implies.

Sorry for my terseness, but I'm simultaneously bleeding from the ears,
pulling out my hair, and gritting my teeth, wondering why oh why folks
continue to treat application protocols like HTTP as transport
protocols, when what you clearly need *is* a transfer protocol!!

I'm not sure I get the fine details here, but I guess the meaning is that HTTP is transfer protocol for Hyper Text, which is used by the XHTML application called a browser (in line with the application/xhtml+xml media type instead of good ol' text/html). In another branch of this thread it ends in a architectural discussion between Mark Baker and David Hull:

> It's the *same* target, hence the suspicious similarity. Really.
> That's why I've been so vocal about this for the past 6 years!!
> Loosely coupled document exchange between distributed applications;
> that's what we're all after, right?
>
>
Only if you agree that messaging is essentially the same as loosely
coupled document exchange, which I don't. From my point of view,
document exchange is one useful segment of the design space. Messaging
is another. See my previous post for more detail.

Well I don't know who's right but from my current level of understanding I agree with Mark Baker, that is loosely coupled document exchange and adding a level upon it to ex. ensure in order doesn't change that for me.

Intermediaries

One aspect is the application stack another and very SOAP-ish is that of intermediaries (Actors) that I haven't had any use of yet, here also single out that aspect:

> As far as I can tell, there shouldn't be any significant difference > from the reliability layer's point of view between forwarding a > message along another hop and doing some other sort of processing > before declaring it delivered. In either case, I don't send back an > ack until something arbitrarily long-running and outside my control > finishes happening.

Respectfully, I disagree.