While the concept of an "enterprise service bus" has been floating around for years, it has suddenly become the must-have foundation for service-oriented architecture environments - if you believe the buzz, that is.
This infrastructure software is used to integrate enterprise IT resources. It provides a platform for transforming and routing messages between applications, services and systems.
In function an ESB is similar to enterprise application integration (EAI) technology. But EAI platforms adhere to a hub-and-spoke model in which all messages feed through a proprietary hub. ESBs typically espouse a more distributed model: Applications can pass messages to each other over a shared network. In addition, ESBs use standard Web services interfaces and are generally operating system- and programming language-agnostic.
While an ESB isn't a prerequisite for building an SOA, companies are considering the two constructs simultaneously, especially as they ready enterprise SOA deployments.
The basic ESB and beyond
"People have gone from talk and experimentation to fairly serious development on SOA. They need a message-based backbone that speaks Web services to be their connection mechanism for SOA applications," says Roy Schulte, a Gartner analyst. "The more people get into SOA, they start to get why they need an ESB."
Gartner predicts more than half of all large enterprises will have at least the core of an ESB running by year-end. But implementations will vary because the definition of an ESB is not set in stone.
Schulte says ESB technology should do five things:
* Implement program-to-program communication.
* Support basic Web and Web services standards.
* Support SOA service binding, working in conjunction with a registry to enable discovery of service names and interface specifications.
* Support typed messages so enterprises can make use of message schema information contained in metadata stores.
* Via an intermediary-based architecture, let enterprises apply additional functions, such as message inspections, to the message flow without disrupting the message source or destination.
Some vendors, such as Cape Clear Software, Fiorano Software, IBM and Progress Software, add to these core functions, Schulte says. IBM's WebSphere ESB contains a general-purpose application server, for example, and Cape Clear includes a business process engine in its ESB product. Others add features such as load-balancing QoS so IT staff can make sure that high-priority applications have access to the services they need ahead of lower-priority ones. Vendors also provide varying degrees of built-in security features to let administrators control access to services.
An ESB as software - or hardware
Most ESB vendors offer a software platform. But for some, an ESB is a hardware play.
Automotive financing joint venture RouteOne favors the hardware approach - it is revamping its enterprise architecture around XML network appliances from IBM subsidiary DataPower. It built an SOA that uses XML Web services to mediate between proprietary dealer systems and third-party banking systems.
RouteOne always has used DataPower appliances to secure XML transactions. Now it sees a more central role for the DataPower XI50 integration appliances, says T.N. Subramaniam, director of technology and chief architect at RouteOne in Farmington Hills, Mich.
"We did an exhaustive search of ESBs and settled on an appliance-oriented architecture," Subramaniam says. The XI50 device can do "all the standard SOA stuff for us - it will do the transformation, the mapping, the routing, and it will make Web service calls. And it's got some tremendous transaction rates."
There's no reason why a device such as the XI50 can't be considered as an ESB, Subramaniam says. "It just requires a slightly different mind-set."
More in keeping with the software orientation is the District of Columbia's ESB deployment. The district deployed ESB technology from Sonic Software, an operating unit of Progress Software, to run DCStat, a program aimed at exposing and providing access to data that traditionally isn't shared among systems and agencies. For example, the ESB provides the messaging platform for a Web-based application that culls data from previously unrelated data sets, such as crime incidents, housing-code inspections, business licenses and registered vacant properties.
"We liberate the data from the tyranny of the applications," says Dan Thomas, DCStat director.
ESB and the information model
For Thomas, one of the most crucial elements of the infrastructure is its adherence to an information model. The city's information model tackles the semantic meaning of data and the format of business objects, for example, so that a consuming application understands the context of the data it's accessing.
"Once you start moving information around in this way, there's a great deal of structure that needs to be erected around the data to keep it useful," Thomas says. "All these types of things that we take for granted when we're dealing with a small, closed application come to the forefront."
Many companies downplay the importance of the information model, but it is critical to making an ESB architecture work, he says. "My fear is that when we get past the hype, a number of ESB-enabled SOAs will fail, because people didn't pay enough attention to the information model," he says. "The structure that's in all those tightly coupled systems has to go somewhere, and it belongs in the information model."
Over time, IT staff will get better at addressing issues such as message schemas and metadata management in a structured way. Likewise, some of the ambiguities about what exactly an ESB is will subside, Schulte says. "The market will crystallize," he says. "Within 12 months, the confusion will disappear."
Learn more about this topicSOA platform vendors will own ESB market
2/13/06D.C. boards enterprise service bus
9/4/06The SOA generation gap: Enterprise Service Bus products