The problem with using SOAP over JMS in SOA

Bookmark Blog Post

	del.icio.us
	Digg
	DZone
	Furl
	Reddit

Paul Done's Blog | March 28, 2007   8:44 AM | Comments (3)

Sometimes I talk to people who seem to view the use of SOAP over JMS as the perfect combination to enable loosely coupled asynchronous shared services. However, when I dig deeper these people have invariably assumed that JMS is an 'over-the-wire' protocol, like HTTP. It is not.

Question: Why is this a problem?

Answer: Interoperability, plain and simple.

HTTP is a standard 'over-the-wire' protocol. HTTP belongs in the Application Layer of both the OSI model (layer 7) and the Internet Protocol Suite (layer 4 or 5). SOAP is a 'standard' (or W3C recommendation at least) transport agnostic protocol which uses an XML payload.

Due to the standard and technology agnostic nature of both SOAP and HTTP, many platforms and toolkits out there, written in different languages and on different operating systems, can interoperate using SOAP over HTTP by simply adhering to both of these standards (or at least the WS-I version of these standards).

However, JMS is not an 'over-the-wire' protocol. It is a Java API which requires that a client application uses a JMS provider library (JAR) provided by the vendor of the JMS Server hosting the services. This is analogous to requiring a JDBC driver for a particular vendor's database before a Java application can talk to that database. The actual 'over-the-wire' protocol used under the covers within the JMS provider library is not defined (it could be IIOP for example, or it could be some high speed non-standard vendor specific protocol).

As a result, in most cases, the only types of applications which can talk to a specific vendor's JMS Server are other Java based applications. It gets worse. If, for example, the JMS server vendor is IBM WebSphere and the service consumer is running within Oracle's Application Server, there may be problems even getting IBM's JMS client provider library working from within Oracle's Application Server in the first place, due to JMS implementation clashes. Some JMS Server vendors provide one or two non-Java based JMS libraries too (for example for C++ or .NET), but these are often limited in functionality and scope and often only support specific versions of specific platforms and operating systems.

In other words, the onus of interoperability, when using SOAP over JMS, is on the support of the vendor of the JMS server for all possible service consumer environments rather than the onus being on the service client's host environment support for standards. Vendors cannot scale to provide JMS support for all of the wide mix of programming languages, application servers and operating systems (including different versions) out there, so interoperability will take a big hit. Even for consumer applications that can use the JMS provider, one has to give the service consumer the provider library first before it can invoke services - not very loosely coupled I think.

As a result, an enterprise's design choice to use SOAP over JMS, as the default mechanism for interoperability for an enterprise's mix of heterogeneous systems, is likely to be fundamentally flawed in my opinion.

It is important to state that I am not saying that Message Oriented Middleware (MOM) does not have a place in a SOA framework. In fact, quite the opposite is true. To achieve capabilities such as asynchronous messaging, guaranteed delivery, only once delivery, and publish/subscribe mechanisms, MOMs are an essential part of the SOA fabric. That's why many vendor's ESB platforms are built on the underlying technology of Message Oriented Middleware. However, what I am saying is that JMS should not be the preferred API for exposing shared services to remote service clients. Using middleware such as an ESB for example, a service with an asynchronous interface can be exposed via a SOAP over HTTP interface, for example, where the ESB performs the switching between the consumer facing synchronous invocation protocol and the underlying internal asynchronous message passing mechanism which may or may not use JMS internally.

With the right organisation and governance in place, I believe it can be valid to decide to expose a shared service via SOAP/JMS in addition to SOAP/HTTP or another more 'open' protocol, where there are valid exceptional circumstances (eg. high performance requirements). However, it is probably best to treat these decisions on an exception by exception basis because the overhead of supporting two access methods for a service does have an additional overhead due to increased configuration, maintenance, and testing costs.

Is HTTP the perfect transport for SOAP, especially for asynchronous services? Not at all. However, if consumers can't invoke these services in the first place - that's worse.

Have I got something against JMS? Not at all. Its one of my favourite JavaEE APIs. I'm not talking about JavaEE here. I am talking about SOA.

Soundtrack for today: Happy Man by Sparklehorse

Comments

• here you can get some more info on the specifics for the sca binding framework http://www.osoa.org/display/Main/SCA+Bindings The main idea on my comment is that the service infrastructure shouldnt be tied to an specific "default" or recommended transport, on my opinion the real service reuse can be achieved by providing shared business service available tru a number of transports, by letting solutions like esb's or frameworks like sca the responsability for the transport binding.

  Posted by: n4hum on April 7, 2007 at 9:52 PM

• From my perspective, SCA is not something we can use yet, and I don't yet know enough about it to know whether, when we do have SCA, this will fulfil the requirement to be implementation agnostic or the requirement to be interface (inc. transport) agnostic, or both?.

  Part of BEA's SOA approach for today, is for a business to establish a Reference Architecture including a baseline Service Exposure protocol for exposing Shared Business Services. I believe that one of the biggest long term paybacks for a business adopting SOA is re-use. Therefore, the fulfillment of these Shared Business Services is key. For Service Enablement (integration) the most appropriate protocol (whether proprietary or standard) will need to be used to integrate with s back-end system, which for certain systems may well be JMS. However for Service Exposure of the resulting Shared Business Services, interoperability is a key requirement.

  Posted by: pdone on April 7, 2007 at 3:56 AM

• Even i agree with you on the technical side, isnt soa about the contract more than the transport? in a service oriented it infrastructure, specially when is acomplished by esb's, the consumer app shouldnt be worried about the transport binding (read the bea sponsored sca initiative :) Now even i find http the best option today for interoperativility, i really believe that jms (just like mq and even tux) may be a better option when you want to include the legacy apps scene in an enterprise soa deployment.

  Posted by: n4hum on April 5, 2007 at 2:55 PM