On Defining "ESB"
Thursday, December 15, 2005
What is an enterprise service bus? Various ESB vendors provide their own “definitive” answer to this question, including Sonic Software
, and others. Unsurprisingly, each vendor’s definition matches only its own offerings. This is exactly what we should expect, since a vendor’s job is to sell its products, not to define clear terminology.
Yet customers crave a clear sense of what the term means. When a vendor tells you that you need an ESB, what are they saying? When an analyst firm predicts that we’ll all be using ESBs soon, what do they mean? Without a common definition, we can’t answer these questions.
But there isn’t a common definition, and there probably won’t be for some time. Whenever a representative from any vendor in this market uses the term “ESB”, what he or she really means is “my product”. When any of them talk about the characteristics an ESB must have, they’re always describing what their product offers and the problems it addresses.
Most products sold under the ESB label do have a few things in common. They all provide some kind of mediation between clients and services, for example, and they all support at least some web services standards. Like the term “application server” ten years ago, however, there’s not much commonality beyond the basics.
Assuming the ESB moniker survives, which seems likely, a few vendors will wind up dominating this market. Once this happens, those products (which will by then all be quite similar) will in effect supply a definition for the term. Until then, don’t expect much clarity.
And just to be clear: I’m not the David Chappell who works for Sonic and is the author of the book Enterprise Service Bus
. Our naming collision
is a remarkable coincidence, but please don’t confuse my views with his. I certainly respect his work and his perspective, but we don’t always see things in exactly the same way.