Adding Clarity to the Enterprise Service Bus: An ESB Reference Architecture
by David A. Chappell
Sonic Software introduced the concept of the ESB to the world in March of 2002 when we shipped the first ESB product. At the same time we started socializing the concepts and the terminology with the analyst community (Gartner, Giga, META, IDC, Forrester, etc), the journalist community, and the IT community at large in order to establish a common understanding of what an ESB is.
Our efforts appear to have worked :) The ESB product category has become so well known that you would be hard pressed to find a vendor offering SOA infrastructure today that doesn't brand itself as an ESB. Even vendors such as IBM and BEA have announced their intentions to build one. The reason was successful in establishing this new technology category is that these analysts, journalists, and IT end users knew we were onto something very valuable.
We initially set the bar relatively low with regard to the definition of an ESB, in order to allow the quick uptake and the rapid adoption of the terminology and architectural characteristics of the ESB by as many vendors as possible. In those early days the initial definition of ESB was simply infrastructure that combined 1) Message Oriented Middleware, 2) Web Services, 3) Data Transformation, and 4) Intelligent routing based on content. Even though we always knew exactly what that meant, and what the architectural implications of that are, the side affect of this loose definition is the category has become somewhat broad and diluted as vendors have started adopting the terminology and trying to retrofit it onto their existing hub-and-spoke EAI broker, WS-toolkit, or application server architecture. There have so far been fairly good but imprecise definitions from the analyst community about what an ESB might include and what its purpose is. However there has not been any formal definition that an architect could look at, understand, and begin a fruitful comparative analysis.
As part of our unwavering effort to continue to provide thought leadership and education on what it means to be an ESB, Sonic Software has announced a more formal and detailed definition. The "Sonic ESB: An Architecture and Lifecycle Definition" is a technical explanation of the major architectural components of an Enterprise Service Bus. It happens to be based on the Sonic ESB architecture, but it is generically described such that it may be used as a reference model of others to study and gain an understanding of what makes an ESB unique from other approaches to SOA infrastructure. It is comprehensive and includes more than twenty UML class and object diagrams depicting the structure and examples of how this important new type of infrastructure fits together to support the design, configuration, and deployment lifecycle of an SOA. The text describes the detailed descriptions of inner workings of the ESB, and for completeness a complete class diagram and 100 term glossary are included.
The complete whitepaper, executive summary, and glossary can be found at
Shouldn't the ESB reference architecture include Rules Based Routing and Streaming API support?