lustratus LiteBytes

Steve raises some good issues when he challenges (again) the assumption that any SOA implementation must have an ESB.

In fact ESBs provide only some of the function required for a SOA, which begs the question why?

To start by summarizing Steve’s argument:

You can build an SOA without an ESB. What an SOA DOES need is a number of integration functions in the SOA ecosystem, namely communications, mediation services and adapters/gateways. … ESBs provide much of this function, and have other benefits when combined with SOA principles such as being standards-based. … But they are not REQUIRED. For example, a traditional message broker could provide the same functionality.

The Enterprise Servie Bus as a concept and products claiming to be ESBs have been around for 4 years and was originally saddled with quite a minimalist definition: reliable messaging, routing, web services support, limited message transformation (Gartner’s original definition actually included this bizarre qualifier – clearly if the transformation capabilities was too good it couldn’t be an ESB).  Over the years ESB vendors have added features to their product set to make it a better fit to the range of SOA integration requirements – features such as ‘proper’ transformation and business process orchestration.  While some definitions of an ESB reflect this evolution and have become much richer (wikipedias for instance ), in many people’s minds an ESB remains this stunted half-product. Redhat’s announcement of its ESB proves this point – it is little more than a basic back-bone into which even messaging must be plugged.  Yes – you can get many of the ‘bits’ from redhat but they are not part of what it calls an ESB.

All of which means that it is more essential than ever to understand the capabilities required in an SOA ecosystem and measure any vendor’s offerings against it.  And yes, an ESB can be part of that ecosystem but be warned: all ESBs are not created equal.

Ronan