The benefits of an ESB

In my last post on this topic I talked about the concept of an ESB. Here I talk about why you would want one.

There are plenty of whitepapers, analyst reports and vendor statements about the features and functions of the various ESB products. In my experience, the key advantages of using an ESB are less about features and functions and more about how you use it.


One of the primary advantages of an ESB is that it gives you a standardized platform for integration. When everyone is using the same tools you can develop enterprise-wide frameworks, patterns and best practices for building re-usable services. Without a unifying platform, you get a divergence of integration methods which leads to inconsistency and higher cost of management and change. So an ESB platform helps with design-time governance. Note that this is not the same as standardization in the sense of using web-services standards. The important thing is that you use the ESB to support your own enterprise standards. These may be based on external standards – but that may be of secondary importance.

Loose Coupling

The bus architecture of an ESB encourages you toward a loosely coupled architecture.

  • Physically decoupled by making use of message passing mechanisms (e.g. JMS) versus direct network connections (e.g. HTTP).
  • Semantically decoupled by use of message transformation so that services are exposed in a system-neutral format which reduces application lock-in and reduces the cost of change.

Scalability and Reliability

Physical loose-coupling provides scalability advantages such as high-availability, fault-tolerance and load balancing. The messaging layer in the ESB directs messages between service endpoints to the appropriate instance of the endpoint. For example, in the event of a service provider failure, messages will be redirected to a backup provider – thus supporting high availability. In the case of load balancing, messages are distributed between redundant providers (or consumers) to handle high volumes of message traffic. You could say that physical loose-coupling supports change at the “micro” level where short term changes in the system topology can be compensated for via real-time message redirection.

Routing and mediation

Message routing supports scalability and fault tolerance. An ESB can also be used to support business-level routing and mediation. For example content-based routing allows services to be invoked based on the content of a service request. A business example would be routing of a customer enquiry to the branch where that customer account is located. A technical example would be the routing of a service request based on the version of the service being invoked.

Complex message exchange patterns

Traditional HTTP-based services support only one-to-one request-reply MEPs. An ESB supports more complex MEPs such as asynchronous one-way messaging and to multiple subscribers using topic-based messaging. Asynchronous publish and subscribe mechanisms support new ways of intermediating service consumers and subscribers – such as auditing, service monitoring – which are extremely useful for runtime management and governance of your services. Beyond mere governance, higher level business functions such as complex event processing (CEP) and business activity monitoring (BAM) are supported by this ability to “listen in” to service traffic on the ESB.

The benefits of an ESB that I’ve described above stem largely from the architecture of an ESB and in particular from the use of a message bus as the primary underlying transport. But it is important to understand that these benefits don’t automatically come “out of the box”. Your solution architecture (and your architects) must recognise and utilise the architectural principles underlying the ESB.


#1 Sue Massey on 01.31.08 at 8:26 am

I found your site on google blog search and read a few of your other posts. Keep up the good work. Just added your RSS feed to my feed reader. Look forward to reading more from you.

– Sue.

#2 johnny on 12.31.08 at 3:42 am

qpeTPx Thanks for good post

#3 jjettervu69 on 01.04.09 at 10:15 pm

I also agree..

#4 biorneferndale on 01.04.09 at 10:43 pm

Thanks for all you ideas! I sure will be back to visit your site again so i can learn more.

#5 Kashif on 01.28.09 at 12:37 am

Precise and to the point….it has cleared few of my confusions about ESB

#6 Jeff on 04.21.10 at 7:17 am

Changes are inevitable and when a schema is changed, the ESB needs to be updated as well as or instead of the client(s) consuming the XML. What’s the difference, a code change is a code change, we’re just doing it in a different place now.

I can go on and on, but the other “benefits” can also be strategically implemented without the use of an ESB. The ESB simply introduces another middleware component that can be difficult to diagnose during failure and/or introduce issues during deployment. It is a good example of code bloat and should be seriously reconsidered prior to implementing in your enterprise.

#7 Saul on 04.21.10 at 11:51 am

@Jeff, thanks for your comment. I agree that change is always difficult but a code change can have different degrees of impact depending on the architecture of your system. My point is that a Service Bus architecture helps promote architectural practices such as loose-coupling which minimise the cost of change.

I also agree that architects should carefully consider the benefits and costs of adopting an ESB architecture. There is complexity which needs to be offset by benefits. But benefits can be realised in the right circumstances – one man’s bloat is another man’s infrastructure.

There are other point-mechanisms for addressing each of the benefits I describe. My experience is that these other mechanisms eventually add up to just another middleware layer in the end. I’d be happy for you to expand on your experience if it is different!

#8 Vishal The Sharma on 04.11.12 at 12:06 am


#9 You mined 26 946 US dollars. Gо tо withdrаwаl >> on 02.15.24 at 3:51 pm


#10 You mined 15 757 USD. Gо tо withdrаwаl >>> on 02.18.24 at 11:22 am


#11 Transfer 41 730 Dollars. Gо tо withdrаwаl => on 03.09.24 at 12:05 am


Leave a Comment