Adopting an ESB—Or Not
Should services be wrapped into an ESB? Or should they be managed and mediated some other way? Proponents, detractors face off.
Mon, November 06, 2006
InfoWorld — 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.”
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.