Speaking of David Chappell, he has another very interesting blog posting, Making Loose Coupling Real: The Need for Interoperable Queued Messaging.
He points out that SOA tends to assume services are invoked as Web services, but current WS-* specs don't support what he nicely summarizes as interoperable queued messaging. (QM is what you get with JMS providers like WebSphere MQ and the Service Integration Bus, as well as non-JMS messaging systems like MSMQ.) He points out that you need QM for loose coupling; and you need I for, well, interoperability, the holy-grail of Web services (otherwise, why put up with HTTP?). He argues that WS-ReliableMessaging doesn't really get the job done (not that it's exactly universal these days anyway--are you using it? Who is?).
I'm a JMS/messaging kind of guy; I have a book on messaging patterns. To me, the way applications should talk to each other is via asynchronous messaging. This is how a service coordinator (more) should invoke a service provider, using Request-Reply messaging. As for invoking services using SOAP-over-HTTP protocol, I'm fine with SOAP (or at least that's another conversation), but HTTP is just too darn fragile. Like David points out, you need queued messaging.
As I described in Reliable Web Services, I see WS-ReliableMessaging (or perhaps WS-Reliability) as a way to make messaging systems interoperable (see More on Interoperability vs. Integration). So rather than replacing messaging systems like WMQ, WS-Relia<something> can augment existing messaging products to make them work together, and do so over the Web/HTTP/IP/whatever.
Like David and others are pointing out, this is something we need for all this SOA stuff to really work, not just within enterprises but between them as well.
Interoperable Queued Messaging