Defining ESB: Why It Matters to Your SOA

Recently, a reader pointed out that he didn't know the acronym ESB and that we should have spelled it out on first reference in "Advice for Writing a Useful SOA RFP." This is a writing rule I generally do follow, because it is designed to help readers understand terms, the assumption being that the meaning will be made clear once you can see the words behind the acronym.

But in technology, that theory doesn't always apply. On the contrary, sometimes people know the acronym and the meaning behind it before they know the full term that it actually abbreviates. It's easy to see why, because in technology, as in medicine, the full term behind the abbreviation doesn't necessary define the actual item.

The Enterprise Service Bus is a great example of this. As my editor pointed out, if you don't know what ESB means, you aren't going to learn it just by seeing the words Enterprise Service Bus spelled out.

And then again, sometimes in IT, people are actually using the same term to mean something slightly or, in some cases, completely different.

As it turns out, the ESB is a great example of this, too, as my predecessor, Mike Stevens, pointed out over a year ago.

And in this case, the different definitions could impact your service-oriented architecture (SOA) implementation, according to Paul Fremantle.

Fremantle is the co-founder and VP of technical sales at WSO2 and a former IBM staff member who lead the team that developed what the Web Services Gateway. If that name sounds familiar for another reason, it could be because I mentioned Fremantle in the integration announcement roundup Friday, after he announced that WSO2 would begin work on the first open source SOA registry.

Fremantle traces the meaning of ESB and how it's evolved both as a term and a product in his post, "Reclaiming the ESB." He argues this is important, because some ESBs sold today are actually antithetical to an SOA, some ESBs can be used to support SOA and some are designed with SOA in mind. That's three very different designs that could impact your buying plans.

In the beginning, he writes, the ESB was just a middleware designed to be a "uniform communications system with every party talking in a common format where anyone could connect to anyone else -- well of course that is a 'bus,'" writes Fremantle. You probably didn't even need an ESB product to do this. Instead, in this case, an ESB is just "a virtual construct made up of the various applications communicating via a uniform set of protocols and schemas," he explains.

But then research firms started talking about ESBs, which at the time vendors didn't even sell. Needless to say, EAI vendors added XML and Web services adapters into their EAI hub and the ESB was born.

Here's the problem: At this point, the ESB became a centralized integration platform. This is a problem because when integration is handled in a hub, you just stopped building self-contained services because the service isn't encapsulated and can't be owned.

He explains this in great detail, complete with a wonderful services-as-taxes metaphor and technology examples. And along the way, he gives a nice, understandable history of SOA.

The question then becomes how do you separate the ESBs that support services from those that don't. Fremantle offers several guidelines, starting with how the ESB handles message routing and distribution.

It's a thorough, fascinating post that offers a good deal of insight into the background of ESBs and SOA. You'll definitely walk away with questions for any vendors offering to sell you an ESB for your SOA - assuming you decide you even need an ESB for your SOA.

It should be noted, however, that his company does offer an ESB. That doesn't mean you shouldn't listen to him or believe he's misleading you. It's just a potential bias to keep in mind.