More on ESB

The important point that ESB makes is that you need to have a messaging fabric underlying an SOA. But that messaging fabric doesn't have to be an enterprise service bus. If the scope of your SOA is very limited, then you may be able to get by with just a few point-to-point links. If you already have an enterprise-scale proprietary messaging infrastructure, such as IBM's MQ Series, then that may well fulfil all your needs. If you want total flexibility, then you'll need a fully distributed messaging fabric. ESB falls somewhere in-between the last two. It's not proprietary (although most packaged ESB offerings tie you to JMS and thus a J2EE server implementation). But it is a single bus, a core pipeline through which all messages must flow. Whereas a fabric may consist of several autonomous pipelines or point-to-point infrastructures or proprietary messaging systems, all of which interconnect. I know that sounds like a plate of spaghetti — it will probably look and feel like one, and be just as challenging to manage — but real life is often like that, and the trouble with ESB as vendors present it today is that they make it sound like a nice, easy solution to all your SOA messaging needs, which is either naive over-optimism or misleading over-simplification.

There have been several articles over the past ten day or so that, collectively, reinforce the above points more eloquently and in more detail than I ever could alone:

• ESB implementations are proprietary: Flashline's CEO Charles Stack, quoted at the end of an Information Week article on SOA, Paving The Way For Web Services (you'll need to click through to page 2 and scroll to the end) warns that Java Message Service is "a standard that gets implemented various ways. No two JMS services function the same way and, consequently, don't easily talk to each other, he says."
• No two ESBs are the same: IBM's Scott Cosby, program director for WebSphere, speaking to ZDNet for a very good article called The enterprise service bus--a ride you shouldn't miss, makes the point that there are no set rules for what makes up an ESB: "The most important thing to remember when considering the definition of an ESB is that flexibility is key. There's no fixed way to build one. As long as you have a connectivity layer that optimizes information distribution between service requestors and service providers, one that can respond to event, message, or service-oriented contexts, then it's safe to say what you have fits the description."
• No ESB is complete in itself: Analysts from Forrester Research argued in a contributed article, Commentary: Hop on the bus? at CNET News.com that "at this time there are limits to what can be accomplished with a commercial ESB product without custom-developed extensions." Sonic Software's CTO Gordon Van Huizen was quick to leap to ESB's defence by agreeing with their analysis: "ESBs, by design, offer a generalized, standards-based platform that can be extended and customized to fit specific needs." Published on Sonic's website, his fired-up article, Missing the Bus?, is a good read in itself, because he takes analysts to task for competing over acronyms rather than "illuminating the truly vital issues and assisting with industry-wide convergence around best models and practices." (Surely though Gordon has missed the point? Analysts do acronyms. If you want illumination and best practice, read publications like Loosely Coupled monthly digest).
• Enterprises will have multiple ESBs: Systinet's Radovan Janecek, picking up on my previous post on ESBs in his own blog, says ESB? No, thank you: "... outsourcing functionality from 'dumb' endpoints to some kind of shared infrastructure just does not work for many reasons (technical, business, political). This is what discourages me from ESB ... I'm just curious when people will have to cope with integration of multiple ESBs in order to be finally happy..."