It sounds to me like verbiage that's going out of its way to say that RPC over HTTP is purely coincidental. SOAP is designed to be layered on top of, or "bound" to, any protocol. So far the only protocol binding defined in the specification is HTTP.

In the current SOAP 1.2 working draft, SOAP for RPC has been moved into the "Part 2, Adjuncts" portion of the spec, the place where optional features are kept. Another visible indication of the desire for SOAP to become asynchronous is evident in the XMLProtocol Abstract Model, which clearly talks about asynchronous interactions across multiple intermediaries.

WSDL (Web Services Description Language) describes whether an invocation style is "document" or "rpc". It defines four operation modes ­ one-way and request/response modes are used to describe an inbound asynchronous receive by a service or an inbound/outbound synchronous RPC. Notification and solicit/response are used to describe the reciprocal of those operations, when the operation is initiated by the server to the client. All operation modes are equal citizens in the world of Web services interactions.

Synchronous RPC provides the luxury of immediately knowing whether an operation was successful. However, performing a synchronous operation across multiple processes is an all-or-nothing proposition. If one of the processes isn't available, the application initiating the request must somehow make note of the failure, try again later, or take some other more drastic course of action ­ like inform a human that they are simply out of luck.

In contrast, asynchronous messaging allows each communication operation between two processes to be a self-contained, standalone unit of work. Each intermediary in a multi-process communication can have its own distinct conversation with its sender and its sendee. The process initiating the original request need only be concerned with initiating the "request", knowing that it will eventually receive a "response" asynchronously. Asynchronous processing also allows critical failures to be centrally reported and dispatched via an administrative alert system.

Asynchronous Reliability
Asynchronous processing also brings with it the requirement of ensuring reliability. In Web services, there are multiple ways of achieving that.

One approach to achieving asynchronous reliability between Web services is to provide a reliable protocol at the SOAP level. In this approach, message acknowledgements and delivery receipts are encoded in predefined SOAP envelope header constructs. An example of this is specified in the ebXML Message Service. However, be careful about jumping on that bandwagon just yet. Microsoft, one of the major players leading the charge in defining Web services, isn't participating in ebXML. This same problem is likely to be addressed eventually by SOAP itself.

Another alternative is to extend reliability to the HTTP layer. HTTPR has been proposed by IBM but to date has not been submitted to any standards bodies. The Java Message Service (JMS) provides message queuing and guaranteed delivery semantics, which ensure that "unavailable" applications will get their data queued and delivered at a later time. It accomplishes this via a rigid set of rules governing message persistence and message acknowledgements. JMS has been used for several years to transport XML data between applications asynchronously and reliably.

In the end, the clear solution is a Web services deployment that's based largely on JMS, yet allows the ability to "extend and blend" SOAP-over-HTTP with SOAP-over-JMS.

Gartner further claims that more than 70% of application integration deployments today are based on asynchronous processing rather than synchronous request/reply. I'm a firm believer that the lion's share of Web services projects in the next few years will still involve some form of "application integration." The analysts might give this phenomenon a new name, but the problems are still best addressed by asynchronous processing. New services will be built that act as participants in a larger composite application. Many of these will be coarse-grained interfaces to legacy applications.

The Gartner predictions look promising ­ somewhere between 25% and 70% of Web services interactions will be asynchronous in the not-too-distant future. I actually believe the percentages will be higher. However, even if they're right on the money, I'll be extremely happy with that.