Bob Sutor has a great blog posting, The Eight Defining Concepts of an Enterprise Service Bus: Universality, heterogeneity, interoperability, incremental integration, qualities of service, substitution, event orientation, and service orientation. (That's eight; you can count them.) In ESB vs. Message Bus, I've pointed out two qualities that Web services have that services in an ESB need: the services should be self-describing and discoverable. I've even said that an ESB is like a network of roadways: custom and evolving.
OK, that's all great. But what does an ESB actually do for you? What features can an application using an ESB, or applications integrated by an ESB, or parts of an SOA integrated by an ESB--what features does an ESB have that those app(s) (parts) can make use of?
I believe an ESB provides apps with four main capabilities:
- Synchronous service invocation -- Like how SOAP over HTTP, JAX-RPC-style Web services work
- Asynchronous service invocation -- Messaging, like how JMS request-reply works when the request is a command message
- Data transport -- One-way transportation of a data structure from one process to another; see document message
- Event notification -- One-way transportation of an event notification from the process where the event occurred to other processes that are interested; see observer, publish/subscribe channel, and event message
So with an ESB, applications can invoke services synchronously and asynchronously, transport data, and perform event notification.
Also check out IBM Info on ESBs and What is wrong with UDDI?.