To ESB or not to ESB, that is the question

The enterprise service bus, or ESB, has been regarded as a quick on-ramp to service-oriented architecture for some time. However, industry experts have been divided as to whether they actually hurt or help SOA in the long run. Will putting ESBs in place to meet certain needs result in incompatible islands of services that will need to be unraveled at a later time?

You can have your ESB and eat it too

Lately, there's been a line of thinking that says, 'go ahead and put ESBs where they are needed, and you'll be able to eventually bring them together under a larger SOA umbrella.' Not only SOA, but also Web 2.0-type platforms.

There's a strong case to be made for the capabilities ESBs bring to emerging SOA environments. I just moderated an ebizQ Webcast -- which featured Gartner SOA guru Roy Schulte and IBM SOA expert Lief Davidson -- exploring the emerging role of ESBs not only in SOA proper, but also in emerging computing paradigms such as Software as a Service. (I'll post a link as soon as it becomes available.)

Lief talked about "ESBs without limits," and Roy connected the dots thusly:

"As people do more and more work with Software as a Service, as people outsource more in other ways, as people create these business processes and composite applications that deal with other business units even within their own company, they’re going to find that having a federated approach to ESB saves them a lot of time and money, and perhaps most important, it gives them quicker time to benefit. It lets them change the application more quickly, and start using that new application or process, because they’re able to do it on a systematic basis."

In essence, Roy said, as these new SOA and extra-SOA initiatives take place, ESBs help provide a platform that enables enterprises to coordinate security policies, quality of service, and process integrity policies. "The enterprise service bus is acting as a catalyst for the maturing and the enhancing for the whole notion of service oriented architecture."

But ESBs are springing up all over the place, and no two look or act the same. How can this help SOA? Federation is the key, and vendors are beginning to embrace this notion. IBM, for one, talks about its "SMART SOA" strategy, which offers federation between the three types of ESBs it offers into the market. And, in a recent post, ZDNet colleague Dana Gardner cites IONA's latest announcement, which leverages the idea that many ESBs can be brought together as one, while still serving their separate purposes.

The trend, Dana says, is a "growing practice of multiple ESBs within enterprises, often associated in a federated manner, and sometimes using ESBs tasked with specific types of integration duties."

Dana notes that "these moves reflect how enterprises and service providers are using ESBs in innovative ways, in effect creating distributed ESBs to support SOA, SaaS, and guerrilla SOA — while building a path to holistic SOA that follows a crawl, walk run ramp-up."

Lorraine Lawson observes that there has been constant confusion in the market over what, exactly enterprise service bus means, but agrees that it is taking on a more important role as SOAs mature. Part of the confusion comes from the fact that ESBs actually come in two flavors -- either as an alternative to SOA, or as a support platform for SOA.

Lorraine quotes WSO2's Paul Fremantle, who observes that ESBs themselves have evolved, from actual communications "buses" to centralized integration platforms. Of course, this creates some issues if you have various types of ESBs serving various purposes across your organization.

Fremantle warns, however, that by their nature, ESBs discourage the shared ownership of services that are the core of SOA: "Providing a centralized broker that encourages users to keep their existing middleware and protocols definitely makes life easy, but it doesn’t help foster the right ownership and encapsulation that is the point of SOA. Instead it forces a central ESB team to understand and deal with every different application, format and protocol in the enterprise."

Agreed, that's definitely not what SOA is about.

The move to more federated approaches may help address the issues of emerging islands of services that may be supported by various types of ESBs. Dana says we should expect to see organizations employing a mix of many ESBs serving many purposes under one roof, which may ultimately provide more flexibility "than one honking ESB swallowing everything up."

That's more what SOA is all about.