Adopting an ESB -- or not

The care and feeding of services is relatively straightforward. The most confusing SOA decisions involve how services communicate and what sort of mediation should sit between them.

In an ideal world, each service in an SOA would be a standards-compliant Web service, robust and directly accessible by the broadest number of authorized applications or services that need the functionality or XML payload that service delivers. But on the ground, enterprises need to deal with legacy systems that use proprietary protocols from MQ to AS2. And many argue that Web services messaging won’t achieve enterprise-class reliability levels until draft Web services protocols such as WS-ReliableMessaging are fully baked and widely implemented.

So, in rushes the ESB — the one product category now most closely associated with SOA. An ESB is a messaging bus and service platform that makes it relatively easy to hook up legacy systems and manage and orchestrate services. As do EAI (enterprise application integration) products, ESBs also transform and route messages. ESB vendors make a big deal about their products being standards-based, although most use JMS (Java Message Service) or some proprietary messaging protocol in order to deliver the necessary reliability.

Proponents like the way ESBs allow them to provision services and manage their communications. After several years without one, ADP recently introduced a distributed ESB because “it’s difficult to maintain a bunch of one-to-one messaging,” says Bob Bongiorno, CIO of employer services at the payroll-processing giant. The company’s number of services grew from nine to more than 30, but along the way, “the management complexity has far more than tripled,” he says.

“We’re now selecting an enterprise service bus, but we would have wanted one if it had existed three or four years ago,” says Paul Kaptur, system architect at General Motors. “We’re doing that today because the products are becoming mature.”

Click for larger view.

ESBs work well for long-running processes that need to be orchestrated, such as order processing, where steps must be done in a certain sequence and validations performed along the way, Intuit’s Moseley says. For example, an order process might need to validate a customer’s address before calculating shipping costs or authorizing a credit card (because the address is often needed to validate a credit card), and all steps must be taken before a bill of goods can be sent to shipping. Intuit’s order-processing system uses such a mediated services approach.

But there are those who see ESBs as warmed-over EAI — and feel they defy the open nature of SOA. “EAI is fundamentally different than SOA,” says Anne Thomas Manes, an analyst at Burton Group. “EAI is about bridging business process silos; SOA is about breaking them down.” She has no problem with using an ESB to provision a service, or even to orchestrate fine-grained services into a widely accessible coarse-grained service. But she bridles at the notion of a bus as the gateway to all services, especially when conversion to and from an ESB message transport incurs additional overhead.

Manes also finds fault with the notion that, without an ESB, difficult-to-manage “point-to-point” services are held up as the spaghettilike alternative: Point-to-point is an integration metaphor, whereas the idea of SOA is to expose services that can be reused by many applications or other services. And that needn’t mean lack of control. One alternative to the ESB approach is to use XML appliances — also called gateways — to route messages, handle transformation and mapping, and proxy services so they can be governed and secured effectively.