Enterprise IT is badly broken in most of it’s current incarnations. This is due to a wide range of influences – organizational, political and technical. I think there are ways to increase productivity and reduce cost and risk by changing enterprise IT practices towards:

1. A collaborative business and IT culture that owns and manages risk rather than just outsource and lose control.
2. An Enterprise IT strategy and Architecture that provides “cohesion” so that smaller, agile projects can deliver strategic value.
3. Using (and developing in-house) development frameworks that enhance productivity by:
   • encouraging in-house standards and best practices,
   • operating at a high level of abstraction – business processes, services, events, rules
   • foster developer skills beyond “commodity” levels.

I had the pleasure of attending two conferences in recent weeks – the Australian Architecture Forum in Melbourne, and JAOO in Sydney. Both conferences held some surprises and in particular I was struck by the very different attitudes toward SOA.

The Architecture Forum was of course aimed at IT Architects and as a result it was about SOA, SOA and SOA…with a bit of SOA as well. Even when you tried to not talk about SOA (as one bold presenter attempted)…the conversation still swung around to SOA. By contrast, at JAOO, there was nary a mention of SOA. You don’t have to look far to understand why…JAOO’s by-line is “by Developers for Developers”…so the target audience and attendees were – Developers. Hence much of the content was around languages, platforms and agile methodologies.

What I enjoyed most about JAOO was the chance to meet and talk with the great lineup of speakers. Kudos to Dave Thomas for wrangling these people to this unfashionable side of the planet. Among the highlights were: Gregor Hohpe talking about the challenges of distributed systems, Martin Fowler expounding on the virtues of simplicity in design, Jim Webber trying to reconcile his two loves in life and Steve Vinoski on how a portfolio of languages helps us develop better solutions. All of this gave me the opportunity to consider the perspectives of architects versus developers. Gregor Hohpe captured the tone with his statement that an “architects dream is often a developers nightmare”.

An Enterprise Architect is generally focussed on the larger components in the IT infrastructure – how they are owned, sourced, maintained, combined and deprecated. And an architect considers not only machines and software but also data, processes and organizational structure. A key consideration for architects is how these things work together and therefore standards are important.

Developers care about delivering solutions for a particular business requirement. They care about the languages and platforms and methodologies that support their needs for correctioness, quality and maintainability. Developers have evolved techniques to deliver these qualities which are sometimes at odds with the needs of Architects and associated standards. From a developers perspective, many of the web-services standards conflict with their best practices. For example, XML is not really a language and cannot be completely treated like a language. Source-code management systems often have difficulty with XML. XML-based “languages” such as WSDL and BPEL are so complex that they require visual interfaces and complex IDEs that are at a higher abstraction than the XML “code”. The ability of these visual interfaces to “diff”, “merge” and debug are often pretty poor. Recently there has been a welcome move away from the masses of XML configuration files in J2EE in favour of java annotations. And perhaps there is further value in domain specific languages like Integration Flow Language in project Fuji.

Architects and Developers are in a symbiotic relationship which is definitely not frictionless. A good understanding on both sides of the needs and drivers of the other party will help to get everyone working in the same direction. Each should know the languages, techniques and platforms used by the other and a common understanding will lead to better ways of achieving what is ultimately a common goal.

One of the original and fundamental tenets of the SOAP standard was that the SOAP message is independent of the underlying transport. Ostensibly you could use SOAP over HTTP, JMS, email, FTP etc. but the reality is that a standard binding has only ever existed for SOAP over HTTP. To paraphrase Henry Ford – “you can have any SOAP transport you like, as long as its HTTP”.

While HTTP is undoubtedly a good choice for SOAP – given its ubiquity – there is at least one other transport which demands attention. This is the JMS transport which is widely used inside the firewall of many organizations. Of all the companies that I work with, their SOA infrastructure heavily relies on JMS transports inside the firewall, with HTTP transports outside the firewall or to selected service end-points such as web pages. Of course my experience has significant selection effects, but nevertheless JMS is an important transport in many SOAs. Testament to this is that every major web-services product vendor (save Microsoft) supports SOAP over JMS (and even Microsoft now has SOAP over MSMQ as an important part of WCF).

The fly in the ointment is that there has never been a standardized binding for SOAP over JMS and as a result there is little interoperability between SOAP/JMS solutions provided by different platform vendors. If you happen to have any combination of different web-service platforms in your organization, then they cannot easily communicate with each other using SOAP over JMS without performing some unnatural acts.

Some of issues that need to be considered with a SOAP binding to JMS are:

• How do you represent the message content – text or binary? Most vendors have chosen a text message representation, but that has problems with multi-byte encodings, so other vendors have gone with a byte message representation.
• What headers do you define and what should their names be? How do you use the standard JMS headers? different vendors have different naming conventions and semantics.
• In the WSDL description, how do you represent the connection details to the JMS provider?
• How do your service endpoints manage the different message exchange patterns that are available with message-oriented transports?

Each of the vendors went their own way on many of these issues and as far as interoperability was concerned they basically ceded the field to HTTP. They made life difficult for large organizations with heterogeneous platforms and in my opinion didn’t do themselves any favours on the way. (Actually SOAP-encoding interoperability was so broken for a while that noone noticed the JMS issues…so maybe it wasn’t so bad).

Subsequently it was great to see some of the vendors get together a couple of years ago to agree on a standard SOAP binding for JMS that addresses most of the important considerations. The result was a Member Submission to W3C in September last year. My understanding is that this submission was previously circulated through most of the vendor community so hopefully it has general agreement on the technical details.

This has now taken its first steps to standardization with the initiation of a SOAP-JMS Binding Working Group who aim to publish a recommendation by April next year. Hopefully vendor support of the binding will be hot on its trail.

Note that the standard binding won’t address the fact that different JMS implementations do not interoperate. For example, a TIBCO JMS client will not be able to talk to a Websphere JMS provider because JMS is an API standard, not a wire-protocol standard. What the SOAP/JMS binding standard does mean is that once you have settled on a standard JMS provider for your services, you could define your service description in standard WSDL and your service provider (say Websphere or TIBCO or WSO2) and your service consumer (say TIBCO or WebLogic or Axis) would be able to communicate directly using SOAP over JMS “out of the box”.

Its been eight years (almost to the day) since SOAP 1.1 came out with the HTTP binding. Wouldn’t it be great if a standard JMS binding could be achieved within the decade! It’s been a very long wait. The JMS binding should have happened a lot sooner and I can’t say the “wait has been worth it” but it does fill an important hole in the Web-Services standards.

So what do we do in the meantime? You can eschew JMS altogether and stick with HTTP, but that requires another lot of hard work. You can stick with one and only one service platform, but that is difficult in large heterogeneous organizations – which is where SOA is supposed to provide maximum benefit. Or you can continue to do what many SOA implementers have done and deal with SOAP directly at the JMS layer – effectively using SOAP as plain-old-XML over JMS. I wrote more about this approach recently.

Another thing you can do in the meantime is ask your vendor when will they support the new SOAP/JMS binding?