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