Bobby Woolf, co-author of Enterprise Application Integration Patterns, and WebSphere SOA and J2EE Consultant at IBM, wrote an article that questions the legitimacy of an ESB as the foundation of a Service Oriented Architecture (see note below*).
Clients often want to build only an ESB because that involves a technology challenge without the need for messy business requirements. Building just an ESB becomes an IT field of dreams, where IT builds an ESB and then hopes some SOA will come along and use it. Such an ESB-oriented architecture loses the benefits of SOA. It does not create business value. In fact, it incurs cost without reaping immediate benefit.
Bobby's article is very entertaining. The debate is serious though and has been on going ever since Dave Chappell coined the catchy term. In reference to the contract-first debate, deploying an ESB is like starting your SOA with "Connectivity-First". Bobby argues the ESB-oriented architecture approach
...is inherently flawed in that it builds connectivity no one might ever want to use... Always implement things when you actually need them, never when you just foresee that you need them.
The OASIS SOA Reference Model does not speak about "connectivity" per se, but introduces the notion of a communication infrastructure:
The primary task of any communication infrastructure is to facilitate the exchange of information and the exchange of intent...Especially in the case where the exchanges are across ownership boundaries, a critical issue is the interpretation of the data. This interpretation MUST be consistent between the participants in the service interaction.
Conventional SOA Reference Architectures, including the one of IBM, always show an ESB in a prominent location. Dave Chappell explains an ESB is in essence a service container with a dedicated communication infrastructure to connect services that share the same container.
A service container is the physical manifestation of the abstract endpoint, and provides the implementation of the service interface. A service container is a remote process that can host software components. In that respect, it has some similarities to an application server container, but with the specific goal of hosting integration services.
Beyond, Bobby's great humor, it is important not to loose track of his arguments. Bobby expressed he disagrees with Joe McKendrick or Dave Linthicum that interpreted that ESB's are useless. I have, myself, written many years ago a series of posts on the topic "Jump off the bus, take a cab" where I questioned the need for a common communication mechanism. Yet, service containers combined with a dedicated communication infrastructure (as Dave Chappell's describes them) are extremely useful, because, Ron Ten-Hove, JBI specification Lead, explains:
- Service containers [are] used to adapt a wide variety of IT assets to the ESB
and an ESB:
- has a reliable messaging system, used to allow the service containers to interact.
- provides message transformation services
- provides message routing services
- provides security features to control access to services
- is centrally administered, despite being a distributed system.
- allows incremental changes to services without requiring shutdown or other disturbance to system availability.
These capabilities (and many more) are essential to a large class of service implementations. D. Sprott, from the CBDIForum, lists a series of patterns that would be difficult to implement without an ESB, for instance using the ESB's Routing Mechanisms to implement a Service Versioning strategy.
Of course, the communication infrastructure starts loosing a bit of its appeal with the completion of the WS-* stack (WS-TX is now available and reliable messaging is near completion**), but efficient service containers will remain key to a successful enterprise class Service Oriented Architecture. I would not be surprised if vendors will soon talk more about their "service containers" rather than their "bus". Not suprisingly, you may nest service containers to combine capabilities.
Bobby's article expresses, with humor, the frustration of consultants facing some IT organization which has little or no knowledge about SOA and is pressed to show progress within unreasonable timelines in any way shape or form. Of course, in the end, the consultants get blamed for delivering something that in itself has no business value. I would argue that Bobby's is giving us a helpful warning that I could summarize as "ESBs are considered harmful if used without vision". That's probably true of any technology.
* Bobby added some clarification to his article: "ESBs good; ESB-only projects bad. Orient the architecture around the services, not the bus. Is that clear enough?! :-)"
** as pascal pointed out, the stack is complete as of June 2007 with the release of WS Reliable Messaging as an OASIS standard