What is an ESB?

ESB products are touted by vendors as key infrastructure component of an SOA. ESB product selection is a great challenge because ESB as a product category is still very new. Unlike in JEE application server space, there are no standards that define ESB capabilities. So vendors are free to use ESB moniker for, essentially, any integration middleware that has some Web services support.

I’ve looked at several ESB products trying to understand exactly what these products are about and what the key features that characterize an ESB are. Here is the list of these features:

• Data transformation. Supports bi-directional transformation for XML and non-XML formats, such as CSV, EDI, COBOL copybooks. XML-to-XML transformation is done with the help of XSLT or XQuery; non-XML transformation is implemented using various proprietary mechanisms. Multiple transformations can be “chained” together to implement a complex transformation logic.
• Message routing and service orchestration flows. This facility allows ESB to create a flow that supports transformations, branching (“if” logic), and services invocation. Some vendors use BPEL for routing and orchestration (CapeClear, IBM ProcessServer), some use proprietary mechanisms (BEA, IBM Message Broker) and some use both (Fiorano).
• Support for multiple protocols. Almost all vendors support HTTP, JMS, FTP and email.
• GUI tools (typically, Eclipse-based) for developing data transformation and service orchestration flows. All vendors promote ESBs as a way to improve “agility ” of IT, in other words, allowing IT respond to business requirements quicker. Easy-to-use tools are the key piece of this vision; in theory they should allow for designing flows and transformations in a visual manner with minimal or no programming (I have to admit that I’m somewhat skeptical of this view).

This pretty much describes “core” ESB capabilities. Of course, many (if not all) ESB products go above and beyond this basic feature set and implement many other features, such as service management, security, additional WS-* specs (such as WS-ReliableMessaging), services registry, connectors to enterprise applications (SAP, etc.) and others. But I would argue that all these extra amenities are not really what ESBs are about. They can be supported either with other product categories (such as SOA management tools) or by application servers, especially since many ESB products run on top of existing application servers (e.g., BEA, CapeClear).

So when selecting an ESB for your project, focus on the core capabilities and move non-core stuff down the list. By the way, ESB roundup conducted by Network computing magazine provide a good starting point for ESB selection (although their review is a bit too superficial in my opinion).