email article printer friendly get the code more resources

Making Web Services More Flexible
Combining asynchronous messaging transports like Java Message Service with SOAP means that Web services can have more uses
by David Chappell and Tony Hong

Until recently, Web services have centered on the synchronous request/reply model that comes with HTTP. This focus was natural because the first use cases for Web services have been centered on Remote Procedure Call (RPC) and distributed component interaction. Yet this focus overlooks a huge part of the IT landscape of today: asynchronous messaging, which is valued precisely because it brings a level of reliability and flexibility to data movement and processing that often can be more difficult to achieve with synchronous messaging. The marriage of SOAP over asynchronous messaging transports like Java Message Service (JMS) means that the Web services standards in development today can be extended into a much wider set of potential uses.

The most popular use for this marriage of technology is in business-critical integration scenarios. This area has been dominated by Electronic Data Interchange (EDI), Enterprise Application Integration (EAI), and business to business (B2B)—yet has corporate IT looking for more streamlined, cost effective, and standards-based approaches. In these areas, it is desirable to trade off the immediacy of synchronous RPC for characteristics such as reliable delivery capabilities; loosely coupled, coarse-grained interfaces more suitable for business-oriented transactions; document-oriented asynchronous interactions; and support for wire protocols and transport mechanisms.

Let's see how the JMS is being used as a means for reliable transport of asynchronous SOAP messages. We will also examine how you can use JMS as a means for reliable Web services invocations. (You can download the sample code here; note that it requires you to accept a license agreement and register on the www.xmethods.net Web site.)

	Figure 1. Multiparty Synchronous Communication.

Many Web services use a synchronous RPC model, in which the service exposes fine-grained interfaces and a Web services client invokes RPC-style interactions. In an RPC-style environment, all applications and services that participate in a single communication stream need to be available and reachable for a multiparty communication to be successful. In some cases, the synchronous model is necessary, such as when the information delivered by the service is real-time in nature (for example, an inventory lookup). However, this synchronous processing is an all-or-nothing proposition. If a downstream service is unreachable for any reason, the requesting application and its upstream participants need somehow to cope with that error processing in the application code (see Figure 1).

Reliable asynchronous communications means that all parts of the system don't have to be available at any given moment in time for the overall environment to remain healthy. Even with a simple two-party client/service interaction, the use of reliable asynchronous communications means that the service being invoked need not be available at the time the client of that service makes a request of it. The client passes a request to an asynchronous reliable transport and it is out of the conversation for the time being. The client can then become unavailable itself, and the service invocation will still happen, eventually, when the service becomes available again.