What is ESB and do you need it?
October 11th, 2007The ESB term has been thrown around a lot lately. It stands for Enterprise Service Bus and from what I can gather it is a system for orchestrating services. It comes out of the push to SOA (Service Oriented Architecture) which was hyped a lot in recent years and has started to mature most recently. Real world examples appear everywhere. Sites like Flickr have publicly accessible services that can be consumed to create composite applications with services from multiple sources. The success of these existing services and the application built to use them indicates to me that an ESB solution is redundant.
Perhaps the best example I have seen to date is an application that integrates SalesForce.com with Google Ads using services. The sales campaigns managed by SalesForce.com are directly integrated with the ads served by Google in a single application which gives the user some real value. You can find video about this great solution at Yahoo Video.
But creating these composite applications, or mashups, does not require an ESB. A developer can simply design an application to work with a set of services without any need for major infrastructure in most cases. I am sure that the services offered by Flickr and Google will be in place for quite some time and I can reliably make use of them as a part of my application for the foreseeable feature. And occasionally there will be updates, with a reasonable schedule allowing me some time to update my application to use the newer services as older services are deprecated. This is something that has already happened for me with Google Maps and GPlotter. Previously years ago I experienced the same scenario with shipping purchases from e-commerce websites and getting the shipping cost from services provided by UPS. That was back in 1997 when I did CGI programming with Perl. The idea of versioning and deprecating services is nothing new and I see that continuing.
Given that there are already services that are in use across organizations which have no direct partnership, it seems to me that an ESB is hardly necessary. Now there are real needs for service provisioning and automatic configuration as well as notifications for service retirement, but as far as I can tell those are features that fall outside of the scope of an ESB. In the case of the UPS services, you had to sign up to a mailing list which would notify developers of coming changes and the associated schedule for phasing out deprecated services. That is a simple and pragmatic solution for the versioning concern.
Still, I leave room for the ESB in some scenarios, but the whole discussion reminds me of the Java discussion over Enterprise Java Beans. They were supposed to allow major enterprises to scale, and maybe the jury is still out on whether they were really helpful or just over-engineering, but as best I can tell EJBs were dramatically scaled back in response to criticism by the developer community. The ESB approach looks like the classic mistake of trying to solve one problem with an ideal solution only to end with two problems that need solving. And like with EJB situation, I am certain that lightweight solutions will emerge, like my WCF hosting solution.
One thing is certain, the discussion and misinformation about the ESB approach will continue for a few more years. The best we can do for now is at least be aware of the promises of the "vaporware" and be mindful that it is still an immature concept. Once an ESB solution actually solves a tangible problem and can be clearly defined, then I will consider it to be a real option.
Additional Reading
- Microsoft ESB Guidance
- What is an ESB?
- Is BizTalk Server an ESB?
- Keeping it real on SOA
- Some thoughts on ESB vs. REST + Dynamic Languages
December 16th, 2007 at 1:06 am
Brennan:
You are really wrong about your take on ESB. The ESB concept is about 100 years old, starting with the telephone switch board operators connecting all those service requests.
I worked for Google for 3 years and the whole thing is one giant ESB. Serious, without it, there would be no Google.
December 16th, 2007 at 10:18 am
@Ben (not your real name I assume) OD?
I wrote that I left open the possibility that in some scenarios. I am suggesting that smaller applications do not need an ESB just because they are using a few web services. However, it makes sense for a larger enterprise like Google to use an ESB.
The point that I did not cover directly is that if you choose to integrate using an ESB, it does not have to be BizTalk in a .NET environment. There are alternatives that will not break your budget and may even fit better anyway. My main point is that development teams that are moving toward an SOA architecture should not get excited about all these new buzzwords, like ESB. SOA has been charged enough as it is. IBM goes around selling SOA like it is something you can just install on all of your computers. The concept is being distorted and exploited by companies that make money on selling products that nobody understands.
If you choose to use an ESB approach, you should be informed about what is available and make sure you know what features you really need.