The ESB Question

I think the issues with ESBs that Joe McKendrick highlights in some of his recent posts have to do with the way in which some vendors have implemented the concept rather than with the concept itself.
Enterprises need infrastructure for SOA deployment. In the debate about ESBs everyone can at least agree on the fact that the ESB is designed to meet requirements for SOA infrastructure.
However as Joe and others correctly point out, most vendors interpret this requirement as an excuse to reuse, repurpose, or reface their existing message bus technology with Web services and a bunch of fancy add ons.
The dilemma for us was whether or not to align ourselves with the ESB product category since we have a completely different approach, one that meets SOA requirements far better. Unfortunately, there isn’t another product category that’s a better fit for us. So I guess we just have to try to gain consensus that ours is the right approach ;-).
In the debate the need for a distributed infrastructure is recognized, like the one used in the Web. That’s exactly what we have done. We live at the application endpoints, service enabling them (you don’t need a Web server or an app server) and connecting the services however you want – peer to peer, point to point, or even hub and spoke (although we would recommend against this pattern for SOA).
Our architecture is definitely the right way to go, though. It’s microkernel based with plug ins, endpoint oriented, multi-communications protocol, multi-data format, with high performance, language neutrality, and enterprise quality of service – all based on WSDL and WS-*. This is what our customers told us they needed and wanted – and among our customers are some of the largest deployed SOAs in the world.
I believe this is also the reason Anne Thomas-Manes doesn’t like to include IONA in the ESB category. I hate it when we get lumped in with the other guys that just don’t get it, and we end up getting criticized along with the JMS centric crowd. An ESB is not JMS + Web Services +++ Not if it’s really going to meet customer requirements for SOA infrastructure.


2 responses to “The ESB Question

  1. Great comment, Eric!
    One thing I would add is the necessity, economic or otherwise, to make use of existing applications and code in the best and easiest possible way.
    I’m working with a customer in SC, USA, that has code going back 25 years and more, most of it in COBOL using flat files.
    He’s really not interested in ESB, Web Services and other acronyms as 1) he needs to get the job done with what he has, 24*7*365 and 2) his staff does not have the time or expertise to rewrite everything by tomorrow afternoon.
    So, if we can offer him something which allows the service-oriented, i.e., end-user and business-oriented approach to current and future applications, then he and the business are more than happy.
    What I believe is so often missed in all these discussions is the “simple” ability to re-use existing code and expose it in a secure, scalable and reliable fashion. If that includes the use of WS-* or JMS or CORBA or .NET or whatever, then that’s also good.
    After all, have we not been trying to write service-oriented software for at least 30 years? Now that we’re close to be able to do it in a decent and timely fashion, why are we getting so stuck with these almost artificial arguments about ESB, JMS, WS-*?

  2. Mark Little

    I couldn’t agree with you more Eric: I personally hate the term ESB because it has been used to mean so many different things in the past and, like the word “transaction” means different things to different people. From what I’ve seen so far, I like the approach you’re taking: it fits far better with what I’d consider to be important – requirements instead of buzzwords!