Rage against the ESB machine

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?