ESBs are patterns, not products

Thomas Rischbeck, a contributor to Thomas Erl's SOA Design Patterns, wants to clear the air on some of  the confusion and controversy that has been associated with enterprise service buses (ESBs).

From day one, ESBs have suffered from lack of standards

That is, he writes in a new article, "The essence of an ESB can be much more easily grasped by talking about the ESB as a pattern: the pattern of applying an intermediate proxy to service communication. The ESB pattern is about performing integration tasks and adding value to client-service communication in an SOA – all completely transparent to the participants."

The confusion with ESBs date back to their very start, when vendors took the lead with pushing these products out to market. But they rushed things because they were under the gun, Thomas says:

"Faced with market domination by IBM, [message-oriented middleware vendors were the first to jumpstart the ESB concept with the aim of developing a unique selling proposition. They added Web service and EAI capabilities on top of existing message broker capabilities, and with analyst support coined the term ESB. ESB was positioned as a low-cost alternative to EAI and panacea for all integration needs – tell-tale signs of hype. Unfortunately, the standards community was too late to get on the bandwagon. In the absence of standards guidance and the lack of a clear definition, each vendor interpreted ESB to its advantage. As a result, comparing ESBs is like comparing apples and oranges. No two products are compatible today with severe consequences (in terms of vendor lock-in) for end users."

As a result of all this vendor confusion and FUD-creation, ESBs mean a lot of different things to different people. Instead of thinking of ESBs in terms of what vendors say they are, Thomas urges thinking of ESBs as a pattern -- as he puts it, "the pattern of applying an intermediate proxy to service communication."

He provides a more detailed definition for the ESB pattern:

"The ESB pattern is about performing integration tasks and adding value to client-service communication in an SOA – all completely transparent to the participants. ...The ESB is a compound pattern that pulls together many enablement and enforcement capabilities that come in handy to the SOA practitioner. Reliable Messaging, Message Manipulation, Data Format and Data Model Transformation as well as Protocol Bridging are just some sub-patterns examples under the ESB umbrella. These are all enablement aspects where the ESB allows communication between endpoints not possible otherwise."

There are two major alternatives to ESBs, Thomas adds -- either application servers everywhere or nothing at all.  While doable, this makes efforts to support delivery of services more complicated than they are, he says. Of course, there are many SOA proponents that say ESBs are essentially useless appendages that do more harm than good in the long run. Perhaps elevating the discussion to more vendor-neutral territory will help clarify what, if any, roles ESBs could play in tomorrow's SOAs.