Enterprise Service Bus? Give Me an Extra Special Bitter Instead

I went to a talk on BizTalk and ESB at lunch today that was sponsored by the local connected systems user group. Like many terms in this space (SOA and governance to name two others), ESB doesn’t seem to have a consistent definition. The industry seems to be inventing terms at a fair clip as vendors attempt to differentiate themselves on what to me seem like fairly minor solution aspects.

Today’s speaker talked at length about a “large health care company in California” that he had personally worked with, building an ESB for them with BizTalk. He spoke in glowing terms of the size of the BizTalk environment and the number of messages passing through the bus every day. Then someone asked how many systems this unnamed company had hooked up to the bus. He paused, then admitted: “Six”.

Six? Not six whole systems! That’s gotta be a record!

Of course, I realize that there are deployed ESB’s out there that are integrating more than six systems. My group – the Integration Center of Excellence (ICoE for short) – runs a comparably sized BizTalk environment and we’re connecting around 50 internal systems and hundreds of external partners. But 50 is still a fairly small number. I can’t help but wonder how well will this ESB approach is going scale as the number of systems goes up a couple orders of magnitude. Frankly, I think the answer is “not well”.

The problem I have with ESB is that it’s a centralized approach. Given that one of the overriding trends of society in general and IT in particular is decentralization, the ESB approach feels like it’s swimming against the current instead of with it.

As an analogy, consider how well would the Internet work if every connection went thru a central hub? See what I mean? Centralized systems don’t scale like decentralized ones do.

I admit that there are scenarios where ESB-esque technology solves a practical problem. Transport adaptation and content based routing leap to mind. Services that need those capabilities should leverage ESB-esque technology. But whenever I listen to ESB proponents, I feel that the need for these capabilities is exaggerated to the point that every message exchanged between every service inside your enterprise travels on a central bus, which doesn’t seem realistic to me.

Am I wrong about this characterization? Do ESB proponents think that all messages must travel on the bus? How about you? What do you think? Inquiring minds (aka me) want to know…

This entry was posted by DevHawk on April 25, 2007. It was posted in Architecture. It was tagged SOA.

Comments:

Harry, The problems that you are attributing to ESB's are really those of the Broker style that BizTalk supports. That central hub you talk about is not a part of message exchanges in the Bus style, although many ESB's do have some sort of central location to jumpstart interactions. This is the main problem I have with Microsoft's ESB message. BizTalk is a broker and will not be a bus until it is redesigned from the ground up. At least, that's what I think :)
This comment was posted by Udi Dahan - The Software Simplis on April 25, 2007 at 9:47 PM.
Harry, I couldn't agree more that a centralized approach to messaging has some less than desired side effects, as you mentioned. However, consider an alternative, point to point. If you go down this path, for example using WCF just like it is (any channel you choose), how do you deal with all of the management issues you guys are dealing with in ICOE, or deployment, or service reuse, or mediation, or versioning, etc.? I'm confident you would agree there are a certain set of common capabilities required to have a decent messaging solution, as well as some nice to have's you could throw in there. If we did that, why not consider that a definition of an ESB? What that collection of specific features is called isn't as important, I'll offer, as the fact that were abstracting common elements of an enterprise communications system into a reusable pattern, and delivering that as a real solution, reusable, and available today. This saves, time, money, etc. We've crafted a solution, using all MSFT technologies that achieves exactly this http://www.neudesic.com/esb, is available now, is super easy to use, dramatically reduces the cost of wiring together services, and provides features that enable many of the promises of distributed, loosely coupled architectures to be realized. Our solution is not physically centralized, it is logically centralized, but physically decentralized. This gives you the best of both worlds; the maintenance ease of a centralized system, with the flexibility, performance, etc. of a decentralized solution. Check it out, I have implemented these kinds of solutions for nearly 20 years, and it's great to finally have a complete MSFT solution, now we can introduce a product that is very easy to use, into an existing environment, with no impact on the current communications, and bring all of the power of CBR, CEP, BPM, BAM, QoS, security, mediation, reconfigurability, BRE, workflow, and many other fantastic tools, in a matter of minutes. Shoot me an email, if you want to know more, I'm always happy to prove it, not just say it!!! The correct communications tools (read good ESB) can and does do wonders for small, medium, and large projects. Cheers!!!
This comment was posted by Curt Peterson on April 26, 2007 at 1:28 PM.
Hi,Harry We had a fairly large Biztalk env. in our company and we already implemented 2 hub's one in EU, one in US in 2004. Then we added the ESB concepts so we can deploy federated biztalk servers around the globe with central routing tables and central console. We can use messaging and services in the ESB design and can scale as large as you want, just add more hubs to the ESB. We also wrote ESB-switches which can also route the messages thoughout the ESB and we to dynamic routing so we can re-route if a hub is down -All hubs use services to check for new routing and give hartbeats to our main hub's. We also implemeted enterprise dymensionnal routing so we can monitor and simulate the impact of changes in routing. Currently we're implementing 15 federeted hub across the globe. Hans.
This comment was posted by Hans Valcke on April 29, 2007 at 5:41 AM.

Categories

Tags

Series

Disclaimer

The information in this weblog is provided "AS IS" with no warranties, and confers no rights. This weblog does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion. Inappropriate comments will be deleted at the authors discretion.