Asynchronous Web Services

In a recent "Strategic Planning" research note, Gartner issued a prediction that "by 2004, more than 25 percent of all standard Web services traffic will be asynchronous...." and "by 2006, more than 40 percent of the standard Web services traffic will be asynchronous."

One of the cornerstones of Web services interoperability is the SOAP (Simple Object Access Protocol). SOAP began simply as a way of performing a synchronous RPC (Remote Procedure Call) across the Internet over an HTTP connection.

However, the current "owners" of SOAP the XML Protocol WG at the W3C have been trying to break free of that limiting portrayal. The SOAP spec itself says:

"SOAP messages are fundamentally one-way transmissions from a sender to a receiver, but as illustrated above, SOAP messages are often combined to implement patterns such as request/response.

SOAP implementations can be optimized to exploit the unique characteristics of particular network systems. For example, the HTTP binding... provides for SOAP response messages to be delivered as HTTP responses, using the same connection as the inbound request."

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.

Author Bio
David Chappell is vice president and chief technology evangelist for Sonic Software. He is responsible for articulating Sonic's vision for secure, reliable Web services infrastructure. Dave is co-author of The Java Message Service, Professional ebXML Foundations, and Java Web Services. chappell@sonicsoftware.com

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.