Sunday, July 26, 2009

Why All SOAs Need ESBs

I've recently asked one of my developers to research some integration and middleware technologies for a project we're working on. After spending a couple days on this, he said to me "these things are all part of ESBs now". I.e. all the integration and middleware vendors have pretty much taken these capabilities and bundled them into their ESB platforms. "Oh you need a message bus? That's part of our ESB now." "Oh you need this adapter? That's included in our ESB." In most cases when you're implementing an SOA, you will need some piece of middleware or integration technology. With just about every vendor making these things part of their ESB suites, you're probably gonna end up getting an ESB even if you don't need a whole freakin' ESB. That's why all SOAs need ESBs (regardless of whether or not you really need them)!

Bookmark and Share

4 comments:

Thomas Rischbeck said...

Apart from the marketing slant i think one justification for this is that often you may want to combine various capabilities for your integration needs. it can make sense then to not implement every capability or "infrastructure service" (say messaging, adapters, transformation) in separation. The reason are performance and maintenance aspects.

Tieu H Luu said...

That is certainly true. If you need multiple capabilities it can be nice to have all of those coming from a single integrated suite. I can see the benefits of that from say, an interoperability or maintenance perspective. From a performance perspective, I'm not that convinced performance improves because one is using capabilities from a single suite.

Rich Newcomb said...

I see a lot of teams implementing integration solutions using Apache Camel and ActiveMQ. In many cases they are choosing an OSGi version of ServiceMix to host these capabilities -- but that is for the OSGi container and management capabilities instead of the ESB capabilities (JBI).

Tieu H Luu said...

Hi Rich. Thanks for the comment, hope things are going well for you over at Progress. That's an interesting approach you describe using ServiceMix. I didn't know it was also an OSGi container.