WebServices dot org

This article will discuss how standards that exist today with real implementations can fit together to address the need for loosely coupled, reliable, asynchronous Web services.

To Asynch or not to Asynch

One of the cornerstones of Web services interoperability is 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, SOAP is designed to be layered on top of, or "bound" to, any protocol. In practice, its use has expanded beyond simple RPC to embrace asynchronous communications as well.

WSDL (Web Services Description Language) describes whether the invocation style is "document" or "rpc". WSDL defines 4 operation modes - oneway 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, when performing a synchronous operation across multiple processes, it is an all-or-nothing proposition. If one of the processes is not available, the application initiating the request must somehow make note of the failure, try it again later, or take some other more drastic course of action - like inform a human that they are simply out of luck. Also, as the number of applications and services that need to communicate with each other approaches 100, and each one is unavailable for only 1% of the time...well, you get the idea.

Loosely-coupled Interactions

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. In a complex interaction across multiple processes and services, the "response" may never go to the original requestor. Each "response" may be in the form of a new message being generated to be sent to a forwarding address. A number of forwarding addresses may be strung together in the form of an itinerary. Asynchronous processing also has the advantage of allowing critical failures to be centrally reported and dispatched via an administrative alert system.

Loosely-coupled Interfaces

Asynchronous message-based interactions typically require very loosely coupled interfaces. In an environment where multiple applications and services need to interact with each other, it is not practical that every application be required to know the intimate details of every other application's myriad of method calls and parameters. In an environment involving tightly coupled interfaces, the number of interfaces that needs to be created and maintained quickly becomes unwieldy. As the number of applications and services increases, the formula for calculating the number of interfaces between them is n(n - 1)/2. This means if the number is 5, the number of interfaces is 10. Not too bad. If the number is 100, then the number of interfaces between them becomes 4,950.

Its more appropriate that an asynchronous message be an autonomous unit of work that carries data and context around with it from place to place, and it's up to each node that processes the message to look into its contents to get the data that it needs, and determine what to do next.

Asynchronous Reliability

But asynchronous processing also brings with it a requirement of ensuring reliability. In the world of Web services, there are multiple ways of achieving that.

One approach to achieve asynchronous reliability between Web services is by providing 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 today is specified in the ebXML Message Service. However, be careful about jumping on that bandwagon just yet. Microsoft, who is one of the major players leading the charge in defining Web services, is not participating in ebXML. Also, this same problem is likely to be eventually addressed by SOAP itself.

Another alternative proposal is to add reliability through extensions to the HTTP layer. This proposal, commonly referred to as HTTP-R, has been proposed by IBM. To date it exists as a whitepaper on the IBM web site and has not been submitted to any standards bodies.

Java Message Service

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. Figure 1 shows the steps involved with message persistence, message acknowledgement, and reconnect behavior for a "durable" topic subscriber that disconnects and reconnects to a JMS provider. The disconnect and reconnect could be the result of a failure and recovery of a receiving application or service. A similar model exists for point-to-point message queues. JMS has been used for a number of years now to transport XML data between applications asynchronously and reliably.

[Figure 1: JMS transports SOAP and XML data asynchronously and reliably.]

Enterprise Connectivity

Some JMS vendors provide the ability to extend themselves across firewall boundaries using some form of HTTP tunneling. However, JMS does not define interoperability at the wire-protocol level. This means that in order to utilize JMS communications across geographically dispersed locations, over the Internet, requires that the a piece of the JMS vendor's software be installed at every remote location. A perfectly viable solution, if you have that kind of control over every remote node that you want to communicate with.

However, different types of business relationships call for different approaches to connectivity. Some of the business entities that you wish to establish remote communications with might be casual business partners. You can't necessarily dictate to a business partner that they must install your software at their site just so they can send you electronic purchase orders occasionally. As illustrated in Figure 2, using the HTTP protocol is more appropriate for this situation.

[Figure 2: Geographically Dispersed Connectivity. The protocol of choice depends on the nature of the business relationship and the level of control over remote locations ]

SOAP-over-HTTP, SOAP-over-JMS

The clear solution is a Web services deployment that is largely based on messaging, and allows the ability to "extend and blend" SOAP-over-HTTP with SOAP-over-JMS.

The key to bridging the gap between these two worlds is to have an architecture that provides one unified set of SOAP envelope interfaces, and allows the details of the transport protocols to be abstracted as a deployment choice. There are two primary requirements:

• A seamless bi-directional mapping between the HTTP protocol and JMS Topic and Queue destinations.

• A JMS client API that allows the message payload to be constructed and deconstructed using familiar SOAP Envelope APIs, such as Apache SOAP, Apache Axis, JAXM, or JAX-RPC APIs.

Bridging the Protocol Gap

In order to achieve the bi-directional mapping between SOAP-over-HTTP and SOAP-over-JMS, the notion of mapping layer is introduced. For those of you familiar with the J2EE web container concept, this mapping would conceptually be accomplished at the servlet/JSP container level (see Figure 3). For those of you familiar with .NET, this would conceptually be accomplished at the IIS/ASP level. I use the word "conceptually" here, because in practice one would never see this layer at the programming level. It should be hidden by the vendor implementation and administratively configured - hence the word seamless.

[Figure 3: SOAP Protocol Handler bridges the gap between SOAP-over-HTTP and SOAP-over-JMS]

While JMS is by-and-large intended for asynchronous processing, it also has a request-reply model built into it for when it's needed. To accomplish this, the sender creates a destination that will be used for the response message, imbeds that destination in the request message, and then listens on that destination for the response. This is referred to as the "replyTo" destination. JMS also has both a synchronous request-reply, and an asynchronous request-reply model. In the synchronous case, the sender blocks and waits for a response from the replier. In the asynchronous case, the sender and the replier make use of a correlation ID imbedded in the response message in order to correlate an asynchronous reply with a message that was sent at an earlier time.

In addition, there is nothing that really dictates that the "replyTo" address be the original requestor. It may actually represent a forwarding address. This allows message invocations to be strung together to form an itinerary that gets carried with the message as it traverses from process to process over its lifetime.

Dispatching to the Destination
When an inbound SOAP-over-HTTP message arrives at the protocol handler layer, there could be multiple approaches for determining which JMS Topic or Queue the SOAP message needs to be dispatched to:

• Defined by WSDL extensions.

• SOAPAction, or other elements defined in the HTTP header.

• SOAP Header. The dispatch mechanism may choose to look into the Header element.

• Content based routing. All messages for a particular HTTP listener may be placed "as-is" onto a queue which routes to a content based routing service, which may apply XPATH expressions, or look at directly at the Header and Body elements of the SOAP envelope to determine where to route the message next.

The level of conversion may vary as well. The protocol conversion layer may simply place the whole SOAP envelope as-is inside of a JMS TextMessage or BytesMessage. This requires the receiver of the message be capable of parsing and understanding SOAP envelope constructs. It may also choose to do some conversions. For instance, it may take the contents of the HTTP headers or the SOAP headers and place them inside of JMS properties, and place the SOAP Body element in the JMS message payload. In the extreme case it may completely transform the SOAP envelope into a vanilla JMS message such that the JMS replier does not need to know anything about SOAP.

The JMS-SOAP Replier
The replier uses a combination of the JMS APIs and some form of SOAP envelope APIs. The SOAP envelope APIs could be based on Apache SOAP, Axis, JAXM, JAX-RPC, or some other api of choice. In our example we will assume that there exists a special JMS message type that combines the JMS APIs with the Apache SOAP APIs. Listing 1 shows what this looks like:

Listing 1: JMS SOAP Replier

J2EE Connector Architecture

The J2EE Connector Architecture (JCA) allows a standard contract between an application and a JCA container. The JCA container may be owned by an application server or by an EAI framework. Simply put, JCA provides for applications what JDBC provides for databases. An EIS (Enterprise Information System) application implements its part of the JCA contract by implementing a JCA compliant resource adaptor that plugs into the JCA container. The idea behind JCA is that application vendors such as SAP or PeopleSoft will provide their own resource adaptors, which will obviate the need for expensive proprietary 3rd party adapters.

Bridging the Gap Between J2EE, .NET, and Packaged/Legacy Applications

As shown in figure 4, remote clients may be implemented using JAXM, JAX-RPC, Apache SOAP, Axis, or .NET. These clients can send or receive SOAP messages through the internet over HTTP. The protocol conversion layer maps SOAP messages to the JMS enterprise message bus. JCA is used to Connect to EIS/legacy apps. JCA and Message Driven Beans is also used to call into an EJB server when necessary.

[Figure 4: Bridging the GAP between .NET, J2EE, and Packaged/Legacy Applications]

Web Service Endpoints become truly abstracted

As also indicated in Figure 4, the interactions between the "Enterprise" and the external "Internet" based clients are bi-directional. The external SOAP clients may themselves be Web service endpoints, which may be invoked via an outbound HTTP request. Whether the endpoints are external calls over HTTP, or internal destinations located across JMS destinations is simply a deployment choice.

Get on the Bus -- The Enterprise Service Bus

The result is a Service Oriented Architecture where all applications and services are viewed equally as service endpoints, regardless of their physical location or protocol used to reach them. Put together, these technologies and concepts should be collectively thought of as the "Enterprise Service Bus" (ESB). Using the ESB concept, applications and services plug into the bus using standards based technologies such as SOAP, HTTP, JMS, and JCA as illustrated in figure 5.

[Figure 5: The Enterprise Service Bus connects together applications and services using standards such as SOAP, WSDL, HTTP, JMS, and JCA]

Applications and services simply plug into the ESB, post their data to the ESB, or receive data from it. The ESB takes care of the rest of the "heavy lifting":

• Coordinating the interactions between applications and services, exposing Web service endpoints to outside business partners using WSDL, HTTP, and SOAP.

• Calling out to external Web services using the same technologies.

• Routing data based on content, translating data from one form to another.

• Connecting into legacy / packaged applications using J2EE Connector Architecture.

• Tying it all together with a reliable backbone based on JMS messaging.

Large scale Web service deployments across multiple applications and services require reliable asynchronous communications. The means for deploying large-scale, asynchronous, reliable, Service Oriented Architectures are available today, given the right blend of standards based technologies.

David Chappell is vice president and chief technology evangelist for Sonic Software. He has over 18 years of industry experience building software tools and infrastructure for application developers, spanning all aspects of R&D, sales, marketing and support services. Chappell is co-author of, Java Web Services (O'Reilly & Assoc., 2002), The Java Message Service (O'Reilly & Assoc., 2001) and Professional ebXML Foundations (Wrox, 2001).