This blog tries to give you an understanding of what an Enterprise
Service Bus is and what are the typical functionalities of an ESB. What
scenarios that it can be utilized, for what purpose, and how it will help you
to solve similar problems you’re having in a consistent, standardized
way. Also incorporating a wealth of knowledge from real life production
deployments. That’s important. If you have something which can solve
world hunger or claim to be the world’s best at something and if it’s
not used in real life production scenarios, it’s good as dead. Those
stuff tend to make great folk stories, like bed time stories that you
tell your geek younglings of how, once upon a time this great and complex
thing was built over a weekend with some pizza and mountain dew ;-)
Let’s forget about ES part in ESB and concentrate about the B. The bus.
This is not something new. You probably have learned about busses when
you read about PC architecture. If you look at how data is being
transferred from CPU to memory and also how data is received from
keyboard, mouse and other peripheral devices plugged into a PC they all
use a bus. Why? Main reason being, it eleminate point to point links
between those systems. In todays world, where there are thousands of
different peripherals that can be plugged into a computer, imagine
the mess it would create if all of them need point-to-point links
to the CPU, memory etc… So you have a single bus that everything
connects to. That will take care of transferring information back and
forth between connected peripherals.
Companies tend to use a lot of software for their day to day activities.
This will only increase with time, not decrease. Also, things that were
done using manual labour or hardware also tend to be converted to software
as this excellent blog explains.
Using software is great you can increase the efficiency of business
operations. Even this is true, there are instances where you want the
data in one system to be fed into or do some form of consolidation to
have a unified overview of what’s going on. Otherwise there’s little
to no advantage of having disconnected systems. Then you have to some
kind of manual intervention for keeping data in sync among all these
Collection of services
Because of sheer tediousness all these enterprise software systems
started exposing their functionalities as web services. Now you have easier
ways of connecting one system to the other. Importing data and exporting
to another system is just a matter of writing some glue code to call
several web services. Just like that your data synchornization issues between
two systems can be solved.
When the number of systems gets increased then you have to maintain point
to point links with different glue code that connects these systems.
Again, it gets error prone and tedious when you have more than a handful
of systems in place. It’s not going to be a scalable solution to the
As you can see from the above image, it gets very complex and hard to
maintain when the number of systems are increased. Add to the complexity,
each and every system or the service that’s exposed might be operating
on their own message format. Which you have to map from one message format
to the other through your glue code when connecting different systems.
This is where a bus architecture is useful again. A service bus. Since
it’s connecting all enterprise systems, enterprise service bus. Although
I have no idea how the name came probably something along those lines :-)
As you can see, this simplifies the process a LOT. Now you can move all
the “glue code” logic you had to the ESB.
Functions of an ESB
When you’re integrating different systems with some glue code that should
have certain functions which can be different from one system to another,
you need to take all those into account when you’re selecting an ESB.
An ESB should allow you to do all those things. Let’s see what they are.
An ESB as the name says, a service bus. It should have the ability to
expose services. For example, taking the above diagram as an example,
it should connect the CRM and expose CRM’s connectivity as a service
to other systems. CRMService may be. That service we call it as a
proxy service because it proxies request for the actual CRM service.
Since the message format one system accepts can be different from
another, an ESB should allow you to transform one message format to
another. This can typically be transforming from one XML format to
another XML format. XML -> JSON, JSON -> XML, Binary -> XML and so on.
There are instances where systems expose their service through different
protocols. HTTP, HTTPS, JMS, FIX, FTP, SFTP, WebDAV etc… So an ESB
should support accepting messages from one protocal and sending it in
a different protocol.
This is another commonly used function of an ESB. You receive a message
and based on certain values in the message you want to route the message
to different systems/services. So ESB should allow you to traverse through
the content of the message and filter on any attribute that’s there in
Another useful functionality is being able to clone an incoming message
and send it to one, two or several services that accept the same message
format, all at the same time. Also, splitting a message before sending
and aggregating messages that comes from different services.
There are many such forms of communications and different ways of
processing messages. Based on this knowledge of systems and different
ways of connecting and message processing, you can identify certain
patterns from these integrations.
Enterprise integration patterns
This fortunately has been documented in the excellent Enterprise Integration Patterns book.
The book has a pattern catalog that’s has been developed or extracted
from by looking at different real life integration scenarios in the
industry. Now an ESB should be able to support or fascilitate implementing
these patterns. When you see how different patterns can be implemented
through an ESB with the configuration, it becomes easy to understand how
the pattern is to be implemented as well as if you need alterations to match
it to your specific use case, then you can do so very easily.
Here’s all the configurations how an ESB can be use to implement these enterpise integration patterns.