Defining ESB: Why It Matters to Your SOA

Loraine Lawson

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.

Add Comment      Leave a comment on this blog post
Dec 14, 2007 1:20 AM Mike Kavis Mike Kavis  says:
I use this simple analogy to describe an ESB. Reply
Dec 14, 2007 10:22 AM Lori MacVittie Lori MacVittie  says:
Hi Lorraine, While Fremantle's announcement sounds fascinating, WSO2 is not the "first" open source SOA registry out there, unless he was playing off the fact that WSO2 would likely be built on UDDI instead of the competing ebXML standard. freebXML has been available for some time, and is in fact the basis for Sun Microsystems' SOA registry solution. An overview of SOA Governance I researched in 2006 has a good overview of the players (at the time). Softwar AG has since acquired webMethods which acquired Infravio, and Flashline has since been acquired by BEA. Lori Reply
Dec 19, 2007 9:59 AM Loraine Lawson Loraine Lawson  says:
Thanks, Lori - yes, I misspoke in this post about the first open source registry. I explained it better in the original post.CentraSite also offers one, which is free. (, what's different about WSO2's registry is that it uses REST instead of UDDI, according to Fremantle's post. He also explains all the issues he has with UDDI in that post. Reply

Post a comment





(Maximum characters: 1200). You have 1200 characters left.



Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.