Related link: http://www.oetrends.com/cgi-bin/page_display.cgi?109

I’m a big proponent of using Web Services. I’m convinced that they are just a better way of getting certain things done. In particular, I think that Web Services provide a great way of integrating two systems that are built using different technologies.

But there’s a problem. Some applications require very high
reliability for individual transactions. Soap over HTTP is limited in this type of application. The basic problem is that HTTP itself just doesn’t provide guaranteed delivery. It wasn’t designed to and it doesn’t look as if, without modification to the protocol, it ever will. (In fact, href="http://www-106.ibm.com/developerworks/library/ws-phtt/">the
HTTPR proposal from IBM is designed to meet this challenge. Unfortunately it is still just a proposal…)

One way that companies are beginning to get over this challenge is by running SOAP over JMS. What is SOAP over JMS? There are a couple answers to this question.

The first answer lies in using JMS as a replacement for HTTP as the underlying transport for SOAP communications. Using Apache Axis, this means sending messages using the Axis API’s, but having the actual communications to the SOAP server be processed using JMS instead of being sent over HTTP. This is a great improvement in reliability for mission critical applications.

The second answer (for Axis again) is using HTTP for communications between the SOAP client and server, but having the SOAP messages be persisted in JMS inside the Web Service client before they are sent; this way they are persisted until the HTTP communications return successfully. In a different situation, it could also mean persisting the SOAP Messages using JMS inside the Web Service server application once they are received. These two features still allow for integration with other Web Service architectures, such
as .NET, but provide additional reliability by using JMS.

One approach to enhancing the reliability of Web Service
communications is to use JMS as the underlying transport directly when communicating inside your enterprise (on the ‘Intranet’), and then bridge from JMS to HTTP at the ‘edge’ of the enterprise (when going to the ‘Internet’ or an ‘Extranet’).

These features are either already a part of Axis 1.0, or are on the horizon. For more information see href="http://www.oetrends.com/cgi-bin/page_display.cgi?109">this
article recently posted on the Open Enterprise Trends site or the Apache Axis site at http://xml.apache.org/axis .