Steve Maine's assessment of centralized ESBs, inspired by what he dubbed "Rich Turner's 'little rant against ESBs'," is right on the money. Radovan also considers ESBs harmful.
Unfortunately the term "ESB" is not at all clear. For some, it implies the centralized entity that Steve and others are correctly questioning. Vendors pushing such centralized ESBs are essentially telling you
"Hey, I can solve all of your integration needs. All you need to do is make everything in your enterprise tie into my centralized ESB. Just make sure everything you want to hang off my bus can either speak its protocols and handle its data formats, or can be adapted to do so. Direct all your messages and data through this centralized bus, and all your integration woes will magically go away."
It's just EAI all over again.
"But Steve," you might say, "isn't your Artix product an ESB?" Yes, it's classified that way, but it's about as far from a centralized ESB as you can get. Frankly, there's nothing else like it, which is why we call it an extensible ESB.
One of the best ways to use Artix is to embed it directly into an endpoint, thus allowing that endpoint application to speak multiple protocols and data formats. That's how you move integration to the edges, thus achieving the decentralized integration dream of WS-* without buying into the flawed assumption that SOAP/HTTP can solve all integration needs. It can also be used as a lightweight switch that can do protocol or format switching. Its extensibility means that making Artix handle a different protocol or format is very straightforward. But Artix does all that and more without requiring centralization and without requiring that it becomes the main player in your system. It just kind of "flows around" the systems you're trying to integrate, letting them function exactly as designed while opening them up to interworking cleanly with other disparate systems.
IONA is basically the Switzerland of middleware and integration. Other players essentially feed you quotes like the hypothetical one above. We're the ones who come in after you've fallen for their empty promises, and we get your integration projects working the way the others wish they could. We deliver fast, efficient, flexible, and cost-effective integration, allowing you to protect your investments in your existing systems by maintaining their existing protocols and formats while opening them up to other protocols and formats. This makes them even easier to integrate going forward. And we do all this without requiring EAI-like centralization, and without assuming that SOAP/HTTP is a universal answer.

Comments (1)
Sonic is starting to talk about the requirements that the most useful ESBs will be multi-protocol routers. ESBs should not be about EAI, but should be about operations at the bus level.
Posted by JP Morgenthal | May 7, 2005 8:20 PM
Posted on May 7, 2005 20:20