First, so far at least, there is no single definition IBM always uses (nor one the industry agrees on). Here's the definition from our executive's guide:
An ESB enables software applications running on different platforms, written in different programming languages and using different programming models to communicate with each other, without requiring expensive, time-consuming reengineering.
Second, IBM's general company line is this: ESB is not a product, it's a pattern. (By my standards, a very broad pattern; an architecture++ level pattern that spans multiple applications across an enterprise and even between enterprises.) It's more about the goals achieved and the way multiple products work together than any one product. You don't just "install an ESB," take satisfaction, and walk away. It's something you design custom for your enterprise and then implement using the products that provide the features you need. (See flexible infrastructure for end-to-end integration for a list of ESB capabilities and our products that provide them. Keep in mind that you don't need all of the products, just the ones for the capabilities you want your ESB to have.) Having said that, I remember a day when an app server wasn't thought of as a single product anyone agreed on. So I can imagine the day where an ESB might be a single product, or a single core product with several optional add-ons; but the industry isn't there yet.
Third, IBM thinks that ESBs have many different capabilities. I've seen the list expressed different ways, as you'll see in my references. Without getting into enumerating all of those here, let me summarize by saying that we believe many competing (e.g. non-IBM) products that call themselves ESBs do not have the range of capabilities that IBM's products do. Some competitors' views of what an ESB is are more limited than IBM's, a reflection of their products' more limited capabilities. (Hey, I'm not trying to flame anyone, I'm just espousing IBM's basic position here. You be the judge.)
Forth, we think an ESB is a key part of making an SOA work in production (see Services Oriented Architecture and Web services): an ESB enables the SOA providers to make their services available and the SOA consumers to invoke those services. SOA is one of our key approaches to helping you develop what we call an On Demand Business.
So, where can you find out more info?
- WebSphere Software: Enterprise Service Bus
- Benefits of an ESB from IBM
- ESB (from IBM Patterns for e-business)
- Patterns: Implementing an SOA using an Enterprise Service Bus (IBM RedBook)
- SOA and Web Services zone (developerWorks )
- IBM's Enterprise Service Bus (discussion of a Proof of Technology)
- Understand Enterprise Service Bus scenarios and solutions in Service-Oriented Architecture (developerWorks article)
- Enterprise Service Bus Capabilities of WebSphere Business Integration Server Foundation V5.1 (developerWorks article)
- ESB*? (and ESB*?) and The Eight Defining Concepts of an Enterprise Service Bus (and again) (Bob Sutor's blogs)
- ESB vs. Message Bus and What is wrong with UDDI? (my blog)