2007 Will be the Year of the ESB... What's an ESB Again?

SOA in Action Blog

« Here are MORE Shining Examples of SOA in Action | Main | The Best SOA: Keep It Loose, Very Loose »

December 28, 2006

2007 Will be the Year of the ESB... What's an ESB Again?

As has been the case with UDDI and BPEL, the ESB concept has taken its share of knocks over the years. While proponents say ESBs provide a quick on-ramp to SOA, detractors say they are only temporary fixes at best, and create even more incompatible islands at worst. One analyst, Loek Bakker, even equated ESBs to the phenomenon of a "one-day fruit fly," existing for only a brief time on this earth to serve some mysterious biological purpose.

However, the enterprise service bus has been gaining a lot of respectability as of late.

David Clark of Cape Clear went as far as to say that noted that ESBs are the "next generation application server." In a session at last month's SOA in Action conference here at ebizQ, Clark said that ESBs are currently "the best way to implement SOA." In addition, he added, "we consider ESB the principal container for business logic."

MIchael Meehan of SearchWebServices ranked the resurgence of the ESB as one of the top eight SOA news stories of 2006, noting that a lot of acquisition and open-source activity over the past year has been around ESBs. (Progress bought Actional and combined it with Sonic Software ESB; Sun Microsystems offered an ESB as part of its Composite Application Platform; IONA released Celtix.) "Clearly the ESB was evolving far beyond its messaging roots," Meehan wrote. However, in the same article, ZapThink's Ron Schmelzer cautioned that "the idea of the SOA mega-suite is too un-SOA in philosophy," he said.

The only tangible product we have in the SOA market too un-SOAish? Can that be true? In a new post here at ebizQ, Ronan Bradley warns that there's a simple problem to all the happy talk on ESBs: no one can really define what an "ESB" is. "The core problem with the category has not been resolved and in fact have got worse," Ronan says. "Although every vendor seems to have one, nobody can agree on precisely what one is."

At the same SOA in Action session as David Clark, Sonic Software's Dave Chappell agreed that "unfortunately it's the IT departments who are trying understand and evaluate ESBs that suffer the most from the current lack of clarity of a definition of ESB in the marketplace." Chappell did offer up a definition of ESB, calling it a platform "used to connect mediate and control the interactions between a diverse set of applications that are exposed through the bus using service level interfaces." Clark added that ESBs will continue to change as approaches to SOA change, he added. "As the level of capability and sophistication and understanding of how you can implement SOA increases or evolves, the definition of ESB and how it should rightly behave will also evolve."

Todd Biske, however, took issue with Clarke's declaration of an ESB taking on the role of "application server" while also being pushed as a mediation platform. "You can’t have your cake and eat it too, yet this is the confusion currently being created. The IT teams are being thrown under the bus trying to figure out appropriate use of the technology," Bisk said in a recent post.

"The problem is that the ESB products on the market can be used to both connect consumers and providers and build new services," Todd explains, adding that the orchestration/service building capabilities of ESBs are "getting lost in all the debate because it’s being packaged together with the mediation capabilities." The mediation side of ESBs have "struggled to gain mindshare, since they are more operational focused than developer focused. A product sold on those capabilities isn’t as attractive to a developer. Likewise, a product that emphasizes the service construction capabilities may get implemented without regard for how part of it can be used as mediation framework, because the developers aren’t concerned about the externalization of those capabilities."

Ronan says the role of ESBs as part of the middleware stack is unclear -- and "it appears the industry is speaking, or at least mumbling, with different voices on this one." Ronan observes that a vendor calling its product an ESB "can mean anything from reliable messaging with bells-and-whistles added, all the way across to what was formerly known as EAI."

Ronan also warns that there are now four open-source ESB products on the market, creating additional uncertainty about the long-term viability of commercial ESB products. Not only that, Ronan cautions that the open-source projects also face an uncertain future, "as these are mostly single-vendor backed rather than relying on a broad developer community."

So, the vendors appear to be pretty hot on the ESB concept, which is understandable -- ESBs are one of the few tangible SOA products they can latch on to. (SOA is an architectural concept, not a technology, after all.) But the debate over ESB rages on -- is it a one-day fruit fly for tactical, get-it-out-ASAP service deployments, or are there long-term advantages to building SOA on an ESB backbone? Is ESB for developers, or for operational teams, or both?

Posted by joemckendrick in SOA | Digg This | Add to del.icio.us