04 September 2007

Enterprise Service Bus - Features, Usage and Critique

I recently presented some statements about the mysterious concept of ESB, the under-defined enterprise service bus. People seem to expect different things from an ESB, so I'll try to summarize a few points here:

As our industry is not really sure what an ESB really is, I'll give you a few definitions:

Defining ESB
  1. "An ESB provides an abstraction layer on top of an enterprise messaging system which allows integration architects to exploit the value of messaging without writing code." (Abbreviated from Wikipedia).
  2. An ESB, a.k.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" (from David Chappell, who actually invented the term ESB and has written a book on the topic).
  3. The OASIS SOA Reference Model calls the ESB a communication infrastructure and defines: 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. (found on fantastic InfoQ, where ueber-blogger Stefan Tilkov is content-editor for SOA...)

Most likely, you're still uneasy wether to use an ESB or not... read on:

Functions an ESB can (and should) deliver

Again, quoting Wikipedia, an ESB has the following characteristic functions:
  • Support for invoking (remote) services, either sync or async, with a variety of transport protocols.
  • Capabilities to route messages to appropriate destinations (addressing, dynamic-, content- or rule-based routing)
  • Capabilities to transform messages (between protocols, data formats,
  • Service Choreography or Orchestration: Ability to create and execute complex (business) processes based upon existing services.
  • Integration of other service providers, like encryption, signing, authorization, authentication, data transformation, compression.
  • Management of services, like monitoring, logging, administration.

The problem persists: Do you (or your organization) really need that stuff?

ESB values
In his great article "ESB-oriented architecture: The wrong approach to adopting SOA", Bobby Woolfe (co-author of the famous Enterprise-Integration-Patterns book (excerpts of this available here)) argues that an ESB itself does not create value:

An ESB by itself produces no business value. An ESB is a means to an end, not the end itself. An ESB is like the electrical wiring or plumbing of an SOA. Plumbing does not produce value; sinks with water coming out of their faucets do. Wiring does not produce value; lights, especially lights connected to switches, are valuable. A road is not valuable except that it enables you to get from one point to another. An ESB without an SOA is like a road from someplace nobody is located going to other places nobody wants to be. People might eventually want to go to those places, but in the meantime, the road is all cost and no benefit.

He continues:

"Develop an ESB as part of developing the SOA. You will discover services based on business needs. Each service requires not only providers and consumers, but also a channel in the ESB to connect the two. That channel implements the service interface just like a provider (but acting as a proxy), including message formats for service requests and responses that enable remote invocation (such as interprocess communication) of the service. Differences in the consumers’ and providers’ service interfaces, message formats, scope, and qualities of service can be bridged and facilitated by mediations. All of this is the core of ESB design, and none of this can be done without knowing the services the ESB invokes. And knowing those services requires knowing the services in the SOA that will use the ESB.

In this light, connecting the applications is the easy part. Connecting their business functionality is the much greater challenge. That cannot be achieved by building only an ESB.

Potential Disadvantages of ESB

  • * You're stuck to a specific vendor, if your ESB does not adhere to open standards.
  • * Additional translation layer on top of conventional messaging systems - added complexity.
  • * No established industry standards, no clear product scoping, everything is pretty much vendor-centric.
  • * The current state of Open-Source ESB's, September 2007, is not amusing:
    • Both ServiceMix and Mule are pure horror to install and try-out. Both are, from my personal point-of-view, in research-state and not production-ready.
    • Corrected due to comments from Andrew P: I tried the Sept-07 versions of both ServiceMix and Mule, both can be installed without problems. Apart from having improved their install & config process, both now have excellent documentation. Sorry for calling them "research-statte" - my fault.
    • SOPERAs ESB cannot even be downloaded, they promised to snail-mail a DVD (which did not arrive so far, but it's only 6 weeks since I asked.).
    • Haven't tried JBoss and others yet...

Further Resources
Labels: ,