Rage against the ESB machine

Rage against the ESB machine

Summary: World Wide Webber takes on ESB middleware


Jim Webber, co-author of the recently published book, Developing Enterprise Web Services: An Architect's Guide, doesn't like enterprise service buses. He made that abundantly clear in a new post, in which he reacted to quotes from Paul Patrick, BEA's chief architect for SOA and service infrastructure.

Within the article that stirred Jim's passions -- written, incidentally, by yours truly and posted at the Webservices.Org site -- Patrick observed that enterprises need some type of intermediary middleware to manage changes that may move up and down the network stack:

“I’ve seen a lot of companies go out and just grab Web services as a WSDL and do a point-to-point connection; then they make a change to the service, and it’s all busted,” he said. “I don’t think people have fully understood the power of intermediaries like service buses, and how they can create nice evolution points in an enterprise.”

Jim Webber (whom I have tremendous respect for, by the way) responds in his post that "there is no correlation between services exposing a contract (even if it is in WSDL) and point-to-point connections." He adds that:

"It's rich coming from a vendor that makes it easy to bind WSDL contracts to Java components to bemoan the fact that changes to the service ripple through the system and break consumers. Of course they do! But the solution is not to build services in such a crummy way, not to deploy more middleware to hack round the problem."

Patrick fears reliance on a gateway strategy may move too much processing to the client. “The age-old problem is if we put all knowledge back in the clients – about where things physically are, how to get there, and how to do retries and handle exceptions – then we’re repeating two-tier client/server computing again. I shudder when I think about gateways a little bit, because I picture spoke-and-hub scenarios. The reality is, as time goes by, we won’t have one ESB, but a federation of ESBs from which we build a virtual bus.”

However, Webber notes that "the 'age-old problem' of putting smarts in your endpoints is exactly what makes the Internet work. Putting smarts in your endpoints is good, putting smarts in your network is not. SOAP (or for the jihadis, HTTP plus XML) messaging is your bus. Welcome to the new reality of minimal middleware computing systems."

Does middleware such as ESBs abstract a problem away, or just create a new layer of problems? This is a debate I have been hearing since the early 1990s, and the acceptance of the middleware concept seems to ebb and flow in a fad-like style. For a while, at the beginning of this decade, "middleware" had even become a dirty word.

In my interview with Patrick, he acknowledged that there is a great deal of misunderstanding around the role ESBs should play, or even what the exact definition of an ESB should be. Often, they have not delivered value to their organizations, he added. “Depending on whom you’re talking to, ESBs could be messaging systems; they could be everything and anything. I even saw someone talking about having adapters as their ESBs,” he said. “I also keep seeing a lot of people doing their own home-grown ESBs. Messaging systems have been the classic approach.”

The vendors are all hot on ESBs, from BEA (AquaLogic) to IBM (with two, count 'em two, ESB offerings) to Sun (SeeBeyond), as well as pure-play SOA vendors. They obviously see a demand in the market for intermediaries. But, at the end of the day, are these just temporary workarounds for services built in a "crummy" way?

Topic: Enterprise Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Middleware is a good thing

    Poor architecture is poor architecture. It's not the middleware's fault nor is it the middleware that makes everything great. The concepts of abstraction , loose coupling, resiliency etc all apply whether you are using middleware or not. Having said that, the concept of Event Driven Architecture (Real Time) in a large enterprise without middleware is pretty rediculous.

    I surely don't want hundreds of mini integration layers deployed across my enterprise. I agree that SOA does not imply or require the use of an ESB or middleware in general. However the reality is that you are going to be better off with it than without. Especially in large companies.

    Vendors are always going to hype their stuff. This is not really any different than what the EAI vendors were hyping a while back. The truth is somewhere in the middle.:)

  • The ESB is a one-day fly

    Just like one-day flies serve a specific purpose in the natural ecosystem (don't ask me what purpose, I am an IT strategist, not a biologist), ESBs also serve a specific purpose in the current evolution towards service-oriented and event-driven architectures. It is just that they will not be around for a very long time, as their life expectance is short I think.
    That's the conclusion of my personal 0.02 cents at http://loekb.blogspot.com/2006/03/esb-is-one-day-fly.html
  • Useful but confusing

    The problem with ESBs is that there are some very useful, if not essential, aspects to their feature set, but vendors are doing a poor job of articulating what's different this time.

    I think what's often missing is a shared understanding of why SOA is important. To some, it's all about web services and SaaS. To others, that's only part of the story -- it's generally a way of driving more agility with IT and alignment between business and IT through having a productive way of building intermediary services. An ESB to me is just another technology of building a service endpoint, one that often is in-between others, but doesn't necessarily have to be. ESBs will succeed or fail based on how well they meet the needs of an enterprise, which, in my view, is mainly around service contract mediation and service lifecycle management. This isn't always necessary or appropriate to consumer web services.
  • Bus Architectures do not scale

    The only thing I do not like about ESBs is the Service Bus concept. An ESB can perform much useful tasks in an SOA: transform, route, compose, script, queue, publish/subscribe. What they should *not* do is to try to become the center of any SOA, but just integrate with it as any other service.

    Bus architectures try to limit with the complexity of the distributed environment of an SOA by putting a centralized behemoth into it. But this does not scale: as the SOA grows you have to feed the ESB with CPUs for everything to work, and if it fails you're dead. The solution is distribution, not centralization.

    To avoid hardwired point-to-point the solution is not an ESB, but dynamic URL resolution by means of UDDI (why is it not used in this way?), or distributed agents like Amberpoint and the like. Interface-oriented design (instead of service-oriented design) also helps: you do not mind who implements the interface as long as it does it well, so you can redefine services easily.

    More about this in http://javicamara.blogspot.com/2005/12/will-esb-kill-uddi-star.html