Destination: integration

The enterprise service bus as a concept has increasingly gained currency in the IT marketplace, even as vendor camps have squabbled over what exactly an ESB is. As a result, many organizations remain uncertain about the need for and role of an ESB in their IT infrastructures. Is an ESB just gussied-up message-oriented middleware, or is it a genuinely new approach to integration?

In response to client enquiries regarding the definition of an ESB, Mike Gilpin, an analyst at Forrester Research, published a report in August that described the technology as "software infrastructure that enables service-oriented architectures (SOA) by acting as an intermediary layer of middleware through which a set of reusable business services are made widely available."

An ESB typically has some sort of "bus" messaging technology, such as Java Message Service or IBM's MQSeries, and support for Web services standards. The standards support is designed to let enterprises map data from disparate systems, route messages, ensure that services are delivered -- and in the correct order -- and enforce security rules automatically by using XML instead of changing code in the interfaces of services.

The ESB has evolved to meet users' demands for a way to integrate applications that's easier than traditional enterprise application integration. EAI systems require coding to link applications and can cost as much as 10 times more.

Enterprises are looking to ESBs to provide the runtime infrastructure for making loosely coupled applications work, says Ron Schmelzer, an analyst at ZapThink.

"If you have a bunch of services doing different things, an ESB can compose them together," he says. "It allows you to run these processes over a long period of time. This bus must be very reliable, meaning that it can guarantee that your message has been received."

The largest group of companies using ESBs are those that need Web services for integration with existing message-oriented Common Object Request Broker Architecture (Corba) or other integration technologies, Gilpin says.

"Companies want to move toward a service-oriented approach, but they can't throw away the investments they have made so far," he notes. "The stuff you have is always a logical place to start."

For example, when Raymond James & Associates needed to integrate data from a real-time reporting system operated by the Municipal Securities Rulemaking Board (MSRB) into its trading and reporting system, it opted for an ESB tool from Iona Technologies. The investment broker has been buying traditional EAI products from Iona for more than 10 years.

Using Iona's Artix ESB, Raymond James can integrate data feeds every 15 minutes detailing municipal bond trades throughout the market from the MSRB's system. The ESB allows the company to integrate feeds from MSRB's IBM WebSphere MQ messaging software into its own Corba-based system, says Martin Kullman, vice president and manager of fixed-income technology at Raymond James.

"Artix enabled us to have a layer . . . to be able to input or bring in information from any source," Kullman says.

About 25 percent of companies using ESBs are replacing existing EAI platforms with the technology, says Gilpin.

"They are saying that EAI was oversold and it didn't fulfill all their expectations," he says. "If it turns out that 80 percent of their requirements are satisfied by one of these lighter-weight ESBs, they are using them."

Players and approaches

Vendors offering ESB technology can be broadly separated into three camps: pure-play ESB companies, application server vendors whose products can be customized to meet ESB requirements, and traditional EAI players that are building support for Web services standards on top of their integration platforms.

Forrester Research analyst Mike Gilpin describes pure-play ESB products from companies such as Sonic Software, Fiorano Software and Cape Clear Software as "lightweight ESBs" that generally can be used off the shelf at a fraction of the price of EAI offerings.

Lightweight is not a pejorative term, Gilpin says. "What we really mean is that it is easy to implement and maintain, as opposed to light in not having good capabilities," he says.

Sonic, which has been shipping an ESB product since 2002, has a Java messaging infrastructure embedded in its ESB, which it markets as an extension to message-oriented middleware to provide services with added business process management.

Gordon Van Huizen, chief technology officer at Sonic, says an ESB must provide support for transforming the format of applications so they can be used by other services.

"That configuration should be handled through metadata so you create better control over what is happening between the services," he says. "You can make some very dramatic changes in how systems interact just by changing the configuration metadata."

Although Cape Clear doesn't have messaging technology in its ESB, it aims to provide ways to coordinate Web services and SOA interactions on top of existing enterprise messaging infrastructure.

IBM and BEA Systems don't offer ESB products today, but both are beefing up their application server product lines to meet the growing enterprise demand for ESB-like functionality.

Last month, IBM announced the availability of WebSphere MQ Version 6, which for the first time merges the MQ messaging stack with the WebSphere stack, the primary plumbing that IBM offers for an ESB.

Gilpin notes that most IBM customers today need a highly customized ESB because they have very high-end and unique requirements. "IBM can implement an ESB using their technology and services, but it ends up being a specific ESB to the particular customer," he adds.

BEA is set to ship an ESB codenamed QuickSilver mid-year. While its WebLogic application server software is well suited for creating and composing Web services, the ESB will provide dynamic service integration, says Kelly Emo, BEA's director of product marketing.

"The new part of it is the SOA and this idea that you're treating the endpoints as shared services and using Web service standards and metadata . . . to create an easy, simple way to connect and manage your services," she says. "With QuickSilver using the configuration model, you can add new services . . . while the other services are connecting and interacting."

Finally, the third camp of vendors marketing products under the ESB umbrella includes traditional EAI vendors like Iona Technologies and Tibco Software, which have built support for Web services standards for specifying integration in XML on top of their existing platforms.

These ESB offerings are best suited for EAI users that want to incrementally add integration using services on top of what they already have, according to Gilpin.

Banking on the ESB

First Command Financial Services is using Sonic Software's ESB to support data transformation and routing needed for a customer-facing portal application it plans to roll out in the norothern hemispher's spring.

First Command, which provides financial services to active and retired military families, wanted to use Web services to automatically fulfill customer requests like changing an address. But because customers often have several accounts, including ones for banking, securities and insurance, these services had to link with multiple back-end databases from a variety of vendors, including IBM, Microsoft and Oracle.

"There weren't many products that allowed you to have open standards and do data transformation seamlessly," says John Quinones, CIO and vice president for IT at First Command. "We needed the ESB to be able to talk to many different databases [and] many different data sources, then take the data, understand business logic of where that data needs to be shared and get it to those locations. It has to not only transport it, it has to translate it into the various formats that are readable by those databases."

In addition, First Command needed technology that would let it apply specific rules. For example, if one member of a family requested an address change, the addresses of other family members would stay the same, Quinones adds.

Using the ESB has helped the company slash its development cycle from eight months to three weeks because developers don't have to customize application programming interfaces to integrate applications.

"It's like plug and play -- you make a change to the application, but not the interface," Quinones says. "We wanted to be able to build applications that we could put on the network knowing they could hook into the ESB and that we could move services across that ESB to provide the needed flexibility and speed of data."