The ESB: Driving the SOA into the enterprise

The service-oriented architecture is driving fast adoption of new tools that integrate applications.

While the concept of an "enterprise service bus" (ESB) 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.

Network World - While the concept of an "enterprise service bus" (ESB) 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.

ESB and you Before you decide if this application infrastructure software is right for your enterprise . . .
ASK YOURSELF
•	Do you need to integrate a wide range of internal and external application sources?
•	Are you already pushing the limits of your application servers, Web services and portals to perform point-to-point integration?
•	Would your SOA applications benefit from message inspections and other advanced management functions?
ASK YOUR VENDORS
•	What QoS features are standard?
•	How does your ESB enforce security policies?
•	What registry and metadata management features do you offer?
•	Does your ESB support service orchestration natively or as an add-on?
•	In what ways do you let users customize their privacy settings and their view of the dashboard?

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.