First, can you give me a clear, fast summary of ESBs?

It’s very difficult to find a clear definition of the term “ESB”. There is not complete agreement on what an ESB is and experts in the field and ESB vendors are notoriously imprecise in their language when defining the term. Misleading phrases like “ESBs use SOAs to…”Footnote 1: I better not tell you where I got this quote from ‘cause the experts who wrote that article and their rather large employer will probably sue us six ways from Sunday. Let’s just say the lead author’s name rhymes with [editor deleted]. imply ESBs are separate from their service-oriented architectures when they are really a part of it. Phrases like “ESBs are a type of SOA…” imply that all parts of the ESB are SOA-based, which isn’t necessarily true either. Phrases such as “SWF seeks ESB for occasional heavy SOAing…” excite and heighten curiosity, but confuse as well.

In its simplest form, an ESB is really just the architectural layer that connects a bunch of software capabilities (referred to as “services”) to high level controlling entities (referred to as “choreographers”) so the capabilities can work in concert to accomplish tasks. This kind of relationship is shown in the example below:

Sample ESB

How does this tie in to those "service oriented architectures" that everyone talks about?

As you can see in this diagram, the enterprise service bus (ESB) is a particular piece of what is usually a service oriented architecture, which means it provides the communication mechanisms for the various software systems inside (or even outside) of a company’s network. In the same way that the bus in a computer acts as a shared communication mechanism between the various circuit boards that plug into it, an enterprise service bus also transports electronic information throughout a corporation and even across corporations. Legacy applications and even databases can also connect to the bus and offer their “services”, although they frequently require some sort of “adapter” or “connector” to do so.

Who are the main ESB players?

Vendors who implement ESBs include IBM, Oracle, BEA, Sonic Software, SeeBeyond, Polar Lake, Cape Clear, Fiorano Software, Iona, Playboy and others (except that last one). Moreover, a number of older technologies can be assembled to act like an ESB (depending on your definition of the term “ESB”). For example, UDDI services, BPEL engines Footnote 2: The BPEL engine itself is in the Enterprise Service Bus layer. , and messaging systems collectively satisfy many of the key requirements for an ESB, although purists frequently argue true ESBs should not be created by assembling old products. In the Process Choreography layer, IBM’s WebSphere Integration Developer, Oracles JDeveloper, Microsoft’s Workflow Foundation, and many other vendors offer business process choreography design tools that allow semi-technical Footnote 3: At least, the vendors tend to claim that process choreography only requires semi-technical users. Turns out those users need to be technical as hell. users to graphically create and alter business flows.

What's the central vision of ESBs?

The typical ESB vision is that everything talks to everything else, transactions are never lost, and the world is happy, birds chirp, and lollipops abound. The most typical ESB diagram is one that shows just about anything you can think of – databases, services, adapters, user interfaces, messaging software, custom applications, legacy applications, external corporations, users, choreography software, etc. - all connected to a bus that spans the enterprise.

However complex and idealistic the vision of ESB is, the core concept can be illustrated with a simple example. Consider a one line batch file (or “shell script” for you UNIX fans) that calls a program and uses the output of that process as input to another process (process A “pipes” information into process B). In this example, we might say that the programs called by the script are the “services”. The shell script itself is a primitive process choreographer. And the operating system, which transfers the information (or “messages”) between the processes, is an Enterprise Service Bus in its simplest form. You may have been using an “Enterprise Service Bus” for the past 40 years and never even knew it Footnote 5: Best ask for a retroactive pay raise. .


That sounds pretty simple. What about all those other features of ESBs the sales guys talk about?

This simple batch file example really does capture the essence of an ESB, but you can’t sell 10 million dollars worth of software by keeping things simple and no one ever charged $400/hr consulting fees to train companies their operating systems were elementary examples of enterprise service buses. Consequently, the IT industry and especially ESB vendors are working hard to add in additional constraints on the term “ESB”. Depending on your source, Enterprise Service Buses are commonly said to include some or all of the following ESB requirements:

  • Routing – ESBs usually intelligently determine the appropriate destination for messages when more than one service provider is available. They may also be able to split one message so that it can be sent to more than one destination or it may be able to merge multiple messages into a single message.
  • Content-based Routing – ESBs may examine the content of messages and determine the appropriate destination for that particular kind of message.
  • Protocol Conversion – ESBs may convert protocols between the service requestor and the service provider. One provider may be a queue, another may be implemented with a web service.
  • Transformation – ESBs may transform a message in one format into the expect format of the message recipient (Fahrenheit to Celsius conversion, for example).
  • Event Handling – ESBs may respond to events received from a given service and respond appropriately - even without having to contact some other remote service.
  • Open Standard Communication – Open standards may be used to communicate with the bus (like XML) and to define the service interface (like WSDL).
  • Open Standard Implementation – Open standards may be used to implement the bus (like Java). Nobody is actually reading this list, are they?
  • Highly Distributable – ESBs may span multiple machines and internal networks. Some authors contend that ESBs must span corporate boundaries. Does anyone know if “distributable” is a real word?
  • High Availability – ESBs may provide redundancy and failover mechanisms.
  • Reliable Message Delivery – ESBs may provide mechanisms to guarantee message delivery.
  • Monitoring and Administration – Administration tools may be provided for bus traffic analysis and remote network configuration and management.
  • Adapters – ESBs may provide adapters to connect widely used software packages to the bus.
  • Support for State – ESBs may provide mechanisms to manage and maintain state as a single transaction traverses across multiple services.
  • Presentation Support – ESBs may provide support to make services available on, for example, a web page in the form of portlets.
  • Security – ESBs appropriately guard the content of the information it transports.
  • Reliability – Producers and consumers of ESB information on one portion of the bus should be protected from problems on another part of the bus.
  • Service Discovery – Consumers can find service providers.
  • Load Balancing – ESBs may provide a mechanism to distribute load over several equivalent service providers. Whew.

Vendors and authors tend to assert, at least in tone, that their set of ESB requirements constitutes the one true correct set of requirements. While there is no standards body that guards the requirements for ESBs, the industry really is coming to expect ESBs to possess many of the properties listed above. But the list continues to evolve and rapidly grow. Moreover, authors and ESB vendors frequently mix requirements for the process choreography and service layers into the requirements for the ESB layer itself, further blurring the responsibilities of the ESB.

There seems to be two main types of ESBs out there. Tell me about them quickly.

Ultimately ESBs tend to be implemented with either message-oriented middleware (MOM) or with J2EE application servers. ESBs implemented with J2EE usually do not use proprietary protocols for communication. MOM ESBs frequently do use proprietary protocols, which can cause complications when crossing firewall boundaries. Firewalls can be configured to let MOM messages pass through, but configuring firewalls can be tricky and you can’t change the firewalls of remote companies.

How do ESBs tie into business process management?

Enterprise Service Buses provide the infrastructure for higher level business process modeling and execution tools. Without an ESB, a BPEL engine could not communicate with the various web services it needs to talk to. Note that the ESB may provide a number of capabilities that overlap with a BPEL engine’s capabilities. The bus may be able to route messages, for example, while the BPEL engine may also provide the ability to route messages. This overlap makes the distinction between the bus and the BPEL engine blurryFootnote 6: So blurry that “I can barely see my own cataracts.” -C. Montgomery Burns.


What are the common mistakes companies make time after time?

The trick to understanding ESBs is to cling to the simple core concepts and try to filter out all the flim-flam marketing hype that comes in your average ESB brochure or sales presentation.  There are about six key weaknesses of ESBs, but there’s so much hype surrounding ESB technologies that it’s hard to find people who have encountered these issues time after time, but who also are not unfairly critical of the technology.  As you may have guessed from the book excerpt above, ESBs can provide enormous benefits to an organization, but only if certain common mistakes are avoided.  Get the whole picture in the rest of the book - not only for ESBs but for all of the other technologies we cover as well.  The career you save may be your own.