The 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.
- 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