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 inquiries regarding the definition of an ESB, Mike Gilpin, an analyst at Forrester Research Inc., 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 LLC in Waltham, Mass.

"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 PLC. The investment brokerage firm 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 soft ware into its own CORBA-based system, says Martin Kullman, vice president and manager of fixed-income technology at St. Petersburg, Fla.-based 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."

Sidebar

Lightening the integration load

Steve Craggs, president of Saint Consulting Ltd. in Hampshire, England, and vice chairman of the Integration Consortium, recently spoke to Computerworld about the evolving ESB market.

Where did the notion of an ESB come from, and why do companies need it? The ESB came about because integration is expensive and people were saying, "Is there some sort of lightweight integration package that could do a lot of what we want but doesn"t cost as much?" Most companies are really at the stage of wanting a bit of integration with a little bit of transformation, a little bit of routing. They don"t want the huge, complete functionality that some of the other software stacks provide.

What are users doing with ESBs? There are some customers who are just really getting going with integration and are looking at ESBs as a simple way to get in. Quite a lot are looking at using it together with traditional solutions. If you"ve bought integration for critical operations for the business that are essential and now you are looking at integrating in with people who are doing the merchandising analysis . . . their demands aren"t the same.

Traditional integration solutions tend to be hub and spoke with a "brain" in the middle. Between every application component, you have to go through the brain to see if you need to do any routing or things like that. With a bus, you have more intelligence out in the nodes.

There seems to be a lot of confusion between Web services and ESBs. Many companies are saying that Web services were billed as a way to do integration without an integration platform, so why do I need an ESB? What is your take on this? You can use Web services without using an ESB and vice versa. People have assumed you can do your integration just using Web services, and that is a load of rubbish.

Web services tackle some of the connectivity issues and adapter issues. But if you use Web services over HTTP, then you better not be doing anything that requires guaranteed delivery [without an ESB]. If you want to transfer money, you have to know the transfer request has got through and only exactly once.

-- Heather Havenstein

Side bar

What is it?

An enterprise service bus acts as a shared messaging layer for connecting applications and other services throughout an enterprise computing infrastructure. It supplements its core asynchronous messaging backbone with intelligent transformation and routing to ensure that messages are passed reliably. Services participate in the ESB using either Web services messaging standards or the Java Message Service. ESBs are increasingly seen by users and analysts as core components in service-oriented IT infrastructures.

Side bar

Players & 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 Inc. and Cape Clear Software Inc. 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, says Gilpin. "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 Bedford, Mass.-based 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 Waltham, Mass.-based 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 Inc. 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 code-named QuickSilver in the summer. 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, San Jose-based 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 Inc., 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.

-- Heather Havenstein

Side bar

Banking on the ESB

First Command Financial Services Inc. is using Sonic Software Corp."s ESB to support data transformation and routing needed for a customer-facing portal application it plans to roll out this spring.

Fort Worth, Texas-based 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 Corp. and Oracle Corp.

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

-- Heather Havenstein