ESB in its simplest form is a software architecture model which allows multiple application to communicate.
Nothing great about it?
What if those application were developed in different ages using different technologies? Like some in C, C++, Java etc. and nightmare is not over yet what if everyone needs their input data in their own format and produces output in their own format?What if every application resides on different hosts?
That’s where ESB comes in picture.
ESB stands for Enterprise Service Bus. This is software architecture model that allows multiple applications written in various technologies, running in different environments, expecting different data formats and producing different formats to work together. Basically altogether ESB solves integration problem at enterprise level.
An ESB is standard based integration platform that combines messaging, web services, data transformation and intelligent routing to reliably connect and coordinate integration of significant number of diverse application across extended enterprises with transaction integrity
–David Chappell, ESB Theory in practice.
Understanding ESB becomes even easier when we understand the problem it was introduced to solve
How to enable many disparate systems, written in different languages and running on different machines to share information and form an integrated business platform?
Traditionally if Java application producing data in xml wants to share some information with legacy application that works with only flat files it would have to push that info directly to legacy application converting XML data to flat file or we need to write interfacing code for information sharing between Java Application and legacy application. Again if legacy application wants to share data with java application. Again one interface for converting Flat file to xml needs to be written. After some days if third party vendor which sends flat file input to your legacy application says because of its internal migration they will provide pipe delimited files and not flat files. Again one more code needs to be written for just changing pipe delimited file to flat file. Just imagine if number of Application grow and data formats changes how many interfaces needs to be written for sharing data among these applications. Worst nightmare is what if some changes in data format of Legacy application needs to be done we don’t only have to rewrite legacy application’s interface to others but we also need to modify other Applications accordingly and we would end up in jumbled up code.
How ESB will help?
- An ESB aims to simplify this problem of integration
- It acts as Middleware, which sits in the middle of all your applications and facilitates message routing between them.
- Instead of every application interfacing with every other application, each application now just has one interface to the ESB. The ESB is responsible for translating messages to / from a source data format to destination data format and routing them to destinations.
- The major saving in this approach comes if you have to replace any of your applications.
- Instead of writing a whole bunch of new interfaces, you now only have one to worry about (between your application and the ESB).
ESB acts as information highway which connects heterogeneous applications and allows to communicate. These application need not to worry anymore about destination data format ESB will do that for you. Rather than application communicating with each other every application communicates with ESB and ESB will talk to destination providing loosely coupled environment. Its functionality is very much similar to BUS on motherboard to which all other modules connect and every module communicates to each other using the same BUS.
SOA and ESB?
Many times these terms are almost used interchangeably but they are not the same. SOA is design pattern in which applications component are exposed as service via communication protocols over network. These applications work together to solve business problem by using services exposed independent of underlying technologies.
On other hand ESB is model which allows us to design and implement communication between desperate systems .
ESB can be used in implementing backbone of SOA
What is Fuse ESB?
As we know ESB is architecture and one of many implementation of this artchitecture is Redhats Jboss Fuse ESB,
Find out more about it on Fuse Official site