The latest hype technology has numerous software vendors scrambling to become buzzword compliant. Analyst groups from Gartner to IDC hail the enterprise service bus (ESB) as the revolutionary technology that will transform middleware due to the vast benefits of adopting vendor-independent standards-based architectures. According to Gartner, ESBs will replace traditional middleware by 2007. So far, however, this "revolution" has seen only a few sparks.

Though just a handful of users have begun deploying ESBs, reports from early adopters imply that the advantages of putting ESBs into service are real. Financial firms such as the Netherlands-based Rabobank say the revised architecture allows their enterprise to phase away legacy MOM products, thus escaping vendor lock-in. They are now able to efficiently and cheaply migrate new and future applications towards open standards.

So What's So Special About ESBs?
The rationale of ESBs is that they are an interface-independent enabler for service orientation - a not-so-new concept that allows distributed software components to follow the flow of information through the business. Just like service-oriented architectures, ESBs are fundamentally a design pattern, but they were originally rooted in Java technology, a light nibble, a relevant pick-n-mix of some core J2EE components.

What's different from traditional EAI solutions is that connectivity is based on open messaging standards. You can interface to your service, hosted on an ESB, via SOAP/XML, traditional message-oriented middleware such MQSeries or Tibco's messaging, or JMS or a host of other protocols, such as vanilla TCP/IP sockets,FTP, e-mail, etc. ESBs allow organizations to form a universal integration backbone. What is different from traditional EAI solutions is the price. The use of standards means that not only are they cheaper to buy, but the total cost of ownership is far lower because the IT skills required to implement solutions using an ESB are readily available.

Which Types of ESBs Exist?
The ESB space is already getting crowded! If you're convinced ESB is right for your organization, there is a wide range of choice. You can roll your own, and as most of what drives an ESB is readily available in your local J2EE application server, this may be a good place to start.

Traditional EAI vendors, such as IBM, SeeBeyond and webMethods, have or will be deploying ESB offerings themselves, as low-cost entry points to their more traditional solutions. If you are already using EAI products heavily, why change?

Then there are the pure-play ESB vendors who provide lightweight and relatively cheap and nimble products. There are even some good open source implementations, such as Mule, that are joining the fray.

The great thing about ESBs is that because their connectivity is open and pluggable, there is no reason why all these solutions can't run side by side.

So What's the Downside?
ESBs are all about standards, but only from an external point of view.

While they leverage cross-platform standards such as XML, WSDL, and SOAP, their internals, how you access the internal service API for an ESB are still mainly proprietary and are different from vendor to vendor. So while the total cost of ownership may be reduced because ESBs leverage standards-based connectivity, the vendor lock-in trap can still grab the unaware.

What Can You Do?
Choose your ESB vendor carefully. If you are looking for independence and choice, look for vendors who use internal service APIs that are based on already existing connectivity APIs, such as JMS, or the new JSR 208 for Business Process Integration. Assess the connectivity and functional aspects of your vendors: Do they easily separate business logic from the implementation?

Are they manageable, easily deployable, and fault tolerant?

Ultimately, because an ESB is a universal transport bus, which integrates applications with services in a standard way, the cost of replacing one ESB vendor with another solution is going to be relatively cheap!