Dessert topping or floor wax? The ESB debate rages on

Many of you may remember the classic parodied commercial from Saturday Night Live's days of yore, when a husband and wife argued whether a new product, Shimmer, is a dessert topping or a floor wax, when an announcer cut in and proclaimed that "Shimmer is both a floor wax and a dessert topping."

Nowadays, a similar debate is raging around the purpose of enterprise service buses. Is it a platform or a mediation system?  Or both? Or neither?

Some commentators, like Loek Bakker, even say ESBs are only around for some brief, mysterious purpose and then quickly die, like a fruit fly.  Another commentator, David Clark of Cape Clear, said ESBs are actually the next-gen application server.

The debate rages on into 2007. Most recently, Ronan Bradley, Anne Thomas Manes, and Todd Biske restirred the pot in the ongoing debate.

In a post at ebizQ, Ronan warned that there's a simple problem to 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."  Plus, with four open-source ESB products on the market, anything could happen.

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."

In a discussion group thread post, Anne Thomas Manes made the point that the problem with ESBs is that they "are fundamentally focused on integration rather than service-orientation. Organizations that rely too heavily on ESBs wind up doing integration rather than designing shared, reusable services." She also observes that "depending on a single product is harmful to a SOA initiative."

In some cases, ESBs are pressed into service as mediation services, to do dynamic service resolution, routing, load balancing, and occasional message validation and/or transformation, Anne said. However, ultimately, Anne thinks the ESB functions better as a "'platform' (hosting services) rather than a 'mediation system' (managing message traffic and flow)."

Moreover, she adds that ESBs should function primarily as legacy-to-SOA platforms. "The primary role of an ESB is to "service-enable functionality that is trapped in a legacy system. In many cases, it isn't economically feasible to refactor functionality in legacy systems into shared services, therefore the functionality is likely to stay put for some time. In these circumstances, you often need to use arcane integration techniques ( e.g., adapters, transformation, protocol switching, etc) to enable open access to the functionality. And that's what ESBs do best. And conceptually, this type of capability is 'platform' rather than 'mediation.'"

She adds that "ESBs are not very efficient as mediators, and most ESBs have pretty limited mediation capabilities," because they "typically don't support operations monitoring and control, and they rarely support security mediation -- authentication, authorization, auditing, credential mapping, federation, etc. Other mediation systems, such as XML gateways and SOA management systems are much better at mediation than ESBs."

Todd Biske (MomentumSI) also questions whether ESB should take 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," Todd 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."

There you have it. ESB is a floor wax. And a dessert topping. And does windows. (And given the fact that Microsoft has recently embraced the term, also does Windows...)