Hand me that ESB to your left….

In 2002 Sonic Software invented the term ESB to differentiate their middleware from everyone else’s middleware. This is an old marketing tactic when you can’t differentiate your product from the others – just invent a new category. To lend credence, you need the collusion of an analyst and Gartner was there to knock this marketechture into the hype-stratosphere. We can also thank Sonic for the crap notion that an “ESB is a prebuilt SOA“.

ESBs have been back in the news again with the usual attendant vitriol and this has revived the perpetual question – “what is an ESB and why do I need one“?

I’ve seen ESBs referred to in two rather broad contexts. The first context refers to a distributed infrastructure that allows your Service Providers and Service Consumers to find each other and work together in a scalable and loosely coupled manner. This is often referred to as the “ESB as design pattern” and I think it is what many people would like ESB to mean. This “Service Bus” is effectively an extension of the “Message Bus” concept and is what I had in mind when I wrote about this subject a while ago.

The second context is ESB as a tool or a “thing you buy from a vendor” and this seems to be the terminology that calls forth all manner of vituperations. In this context ESB is secret marketing code for what used to be called “integration middleware.” This is also the thing that Jim Webber calls the “Erroneous Spaghetti Box.”

In this context, the eternal ESB question becomes – “in an SOA world, do I really need integration middleware?” I really think you can make more sense of the ESB debate by recasting into this terminology. The SOA pragmatists (including myself) see that there is a role for “integration middleware” as tools within your SOA infrastructure.

Eric Roch thinks of an ESB as a “productivity tool for integration” and points out that The legacy integration problem hasn’t gone away yet.

ZapThink say that an ESB could play the role of a Service Intermediary where transformations and content-based routing are essential requirements.

Todd Biske characterises five different types of ESB product each supporting different functions such as legacy integration, orchestration, mediation and transport, SOAP wrapping and gateways. The key insight here is how the label “ESB” has come to be applied to so many disparate products. “ESB” has come to mean everything and nothing and should be banished from our vocabulary.

So I agree with the pragmatists – design your SOA infrastructure to support your business requirements. Consider the so-called ESB products as tools and if you need mediation, or orchestration or transformation or integration to legacy systems then consider using the scads of tools – both proprietary and opensource – out there that support this stuff. And whatever you do, don’t try to author XSLT using Notepad.