An ESB brings flow-related concepts such as transformation and routing to a Service-Oriented Architecture. In an enterprise architecture making use of an ESB, an application will communicate via the bus, which acts as a message broker between applications. Such an approach has the primary advantage of reducing the number of point-to-point connections required to allow applications to communicate. This, in turn, makes impact analysis for major software changes simpler and more straightforward. By reducing the number of points-of-contact to a particular application, the process of adapting a system to changes in one of its components becomes easier.

When the ESB receives a message, it routes the message to the appropriate application. Often, because that application evolved without the same message-model, the ESB will have to transform the message into a format that the application can interpret. A software “adapter” fulfills the task of effecting these transformations (analogously to a physical adapter).

In addition, an ESB is expected to exhibit the following characteristics:

• general agnosticism to operating-systems and programming-languages; for example, it should enable interoperability between Java and .NET applications
• general use of XML as the standard communication language
• support for web-services standards
• support for various Message Exchange Patterns (for example: synchronous request/response, asynchronous request/response, send-and-forget, publish/subscribe)
• adapters for supporting integration with legacy systems
• a standardized security-model to authorize, authenticate and audit use of the ESB
• facilitation of the transformation of data formats and values, including transformation services (often via XSLT or XQuery) between the formats of the sending application and the receiving application
• validation against schemas for sending and receiving messages
• the ability to apply business rules uniformly
• enriching messages from other sources
• the splitting and combining of multiple messages and the handling of exceptions
• the provision of a unified abstraction across multiple layers
• routing or transforming messages conditionally, based on a non-centralized policy (without the need for a central rules-engine)
• queuing, holding messages if applications temporarily become unavailable

Key benefits

• Faster and cheaper accommodation of existing systems.
• Increased flexibility; easier to change as requirements change.
• Standards-based
• Scales from point-solutions to enterprise-wide deployment (distributed bus).
• Predefined ready-for-use service types.
• More configuration rather than integration coding.
• No central rules-engine, no central broker.
• Incremental patching with zero down-time; enterprise becomes “refactorable”.

Kinds of problems that an ESB helps to solve

• You have a number of protocols you’d like to normalize to a single protocol (e.g. FTP, email, SOAP, XMPP, etc. to a messaging system) e.g. ActiveMQ. This lets you decouple the implementation of services from the protocol.
• You want a consistent way to hook services into this architecture so that they can listen for messages, process messages and generate messages (Message Endpoints, Channel Adapters etc.).
• You may want a managed container to deploy these various components into (e.g. ServiceMix, Mule)
• You may want a number of prebuilt components and adapters into various protocols (e.g. ServiceMix, Mule and Camel have a lot of pre-built components).
• You may require long running workflows. Business Process Management is often something that is provided alongside an ESB (Apache ODE plugs into a number of Open Source ESBs).

Key disadvantages

• Usually requires an Enterprise Message Model, resulting in additional management overhead. Potential difficulties integrating many disparate systems to collaborate via message standards.
• Requires ongoing management of message versions to ensure the intended benefit of loose coupling. Incorrect, insufficient, or incomplete management of message versions can result in tight coupling instead of the intended loose coupling.
• It normally requires more hardware than simple point-to-point messaging.
• Middleware analysis skills needed to configure, manage, and operate an ESB.
• Extra overhead and increased latency caused by messages traversing the extra ESB layer, especially as compared to point-to-point communications. The increased latency also results from additional XML processing (the ESB normally uses XML as the communication language)
• ESB becomes a single point of failure.
• Though ESB systems can require a significant effort to implement, they produce no commercial value without the subsequent development of SOA services for the ESB.

Alternatives to an ESB

The alternatives really depend on the problem that you’re trying to solve.

• To provide distributed services, people often use application servers exposing services via some point to point RPC protocol (like EJBs over RMI or Web Services over HTTP). So, rather than putting a message onto a ‘bus’, a client directly calls a server.
• To respond to specific protocols, you could just build a client that responds to that protocol for example writing an application that listens for emails using JavaMail or one that listens to XMPP using Smack. If your problem is constrained to one or two protocols it may not be worth bringing in a full ESB.

ESB selection checklist

Mule and other ESBs offer real value in scenarios where there are at least a few integration points or at least 3 applications to integrate. They are also well suited to scenarios where loose coupling, scalability and robustness are required.
Here is a quick ESB selection checklist –

1. Are you integrating 3 or more applications/services? If you only need to communicate between 2 applications, using point-to-point integration is going to be easier.
2. Will you really need to plug in more applications in the future? Try and avoid YNNI in your architecture. It’s better to keep things simple re-architect later if needed.
3. Do you need to use more than one type of communication protocol? If you are just using HTTP/Web Services or just JMS, you’re not going to get any of the benefits if cross protocol messaging and transformation that Mule provides.
4. Do you need message routing capabilities such as forking and aggregating message flows, or content-based routing? Many applications do not need these capabilities.
5. Do you need to publish services for consumption by other applications? This is a good fit for Mule as it provides a robust and scalable service container, but in Erik’s use case all they needed was an HTTP client from their front-end Struts application.
6. Do you have more than 10 applications to integrate? Avoid big-bang projects and consider breaking the project down in to smaller parts. Pilot your architecture on just 3 or 4 systems first and iron out any wrinkles before impacting other systems.
7. Do you really need the scalability of an ESB? It’s very easy to over-architect scalability requirements of an application. Mule scales down as well as up making it a popular choice for ‘building in’ scalability. However, there is a price to be paid for this since you are adding a new technology to the architecture.

[via wikipedia and this link]