Reading Time: 8 minutes

I wrote a post a while back, To ESB or not to ESB, about when to use an ESB and when not to.  It got a fair bit of pick up, and I’ve had a lot of people reach out to me about it with specific use cases.  It got me thinking it’s time to revisit the topic and provide more practical information about your options for integration.

This is a multi-part post where I’m going to start by defining what an ESB really is, offering up alternatives for the integration landscape and then finish off with how Mule fits into this landscape.

Previous Posts:

ESB is an Architecture

latest report
Learn why we are the Leaders in API management and iPaaS
Read reports

ESB is fundamentally an architecture; It is a set of rules and principals for integrating numerous applications together over a bus-like infrastructure.  ESB products enable users to build this type of architecture but vary wildly in the way that they do it and the capabilities that they offer.

The concept of the ESB architecture is that you integrate different applications by putting a communication bus between them and then enable each application to talk to the bus. This decouples systems from each other, allowing them to communicate without having a dependency or knowledge of other systems on the bus. The concept of ESB was born out of the need to move away from point-to-point integration, which becomes brittle and hard to manage over time. Commonly, the ESB is often drawn as follows:

The ESB diagram above is technically overly simplistic. Let’s take a look a the tenets of an ESB architecture to highlight what is missing from this picture.

  • The ‘bus’ concept decouples applications from each other, this is usually achieved using a messaging server like JMS or AMQP.
  • The data that travels on the bus is a canonical format and is almost always XML
  • There is an ‘Adapter’ between the application and the bus that marshals data between the two
  • The adapter is responsible for talking to the back-end application and transforming data from the application format to the bus format. The adapter can also perform a host of other activities such as message routing transaction management, security, monitoring, error handling, etc.
  • ESBs are generally stateless; the state is embedded in the messages passing through the bus.
  • The canonical message format is the contract between systems.  If you speak the canonical format, you can communicate with other applications.

The ESB diagram above has no mention of messaging servers or adapters between applications, to be more accurate we can add the next level of detail:

Where is the Bus?

I find that the ‘B’ in ESB confuses people since there is no actual bus, at least not in the way people think about a bus. In reality, there is a messaging server such as JMS, AMQP, Tibco RV or WebsphereMQ used as the communication channel.  The messaging server is responsible for delivering the messages between application adapters. So in truth, the Bus is real as the set of the queue through which data can be sent and received.  These act like well-defined addresses for the Adapters to communicate with each other. Typically an application adapter will have an inbound and outbound queue to receive and send messages.

To build on our previous example the ESB architecture looks something like this:

The ESB Adapter is really where a lot of the magic happens. This is where data marshaling, transformation, security, transaction management and mediation is handled.  There are usually another set of capabilities that an ESB product provides for managing to monitor and governing the implementation.

ESB is just one architecture

We see a number of different architectures that people build to solve their integration needs.  These range from very simple requirements to full-blown strategic architectures for integration. In part 2 of this post, I will explore other architectures used for integration such as Hub and Spoke, Grid, Pipeline, Enterprise Service Network and simply embedding integration inside a WebApp. I will provide some context of the pros and cons of each approach.

In the meantime, I hope this has helped put some clarity around what an ESB architecture is as well as the principals behind it.

Read on about the next part of this series ESB or not to ESB revisited – Part 2.

Follow: @rossmason, @mulesoft