What is and how does an Enterprise Application Bus(ESB) work?

Question

Some companies that work with containers Java EE say use Application Buses, never worked with such feature and would like to know two things about them:

• what is?
• how they work?

Answer 1

As an introduction, it should first be stressed that ESBs are agnostic in terms of technology, being this a premise and even factor that makes large companies with a heterogeneous park of applications sweeten bus services.

Another thing you quoted in the question is application bus, I personally had never heard this term, even searched and found nothing related. The standard is even bus services, services contained in an application

What is?

Briefly, the explanation of Wikipedia is quite good, ie service bus is a model of software architecture for designing and implementing mutual communication between applications in a heterogeneous environment in which one seeks a service-oriented architecture.

An interesting point we should point out is that busses by themselves do not deliver service-oriented architectures, but in many cases are essential to compose such an architecture.

I would say that buses are the guys who don’t know the semantic meaning of the messages exchanged, but who know much better than any other application the syntax of the most varied types of information exchange, then they worry about being the abstraction for the correct message exchange, without worrying almost always about specific business rules.

How it works?

In a corporate environment it is common to have many applications built on the most diverse platforms, each having (or not) different types of data exchanges. Common examples are file exchanges in file system or FTP, construction of views in databases, message in any messaging service, web services SOAP, end points REST and many other standards and ways to make information available for integration.

Now imagine you have to do the point-to-point integration of each of these applications? If we have 10 applications, which is little in a corporate environment, and each of them has its own integration standard we would have to implement in the nail 100 integrations!!!

It is at this point that the midlewares services bus entry, ie aim to abstract and centralize the heterogeneity found in these corporate environments, providing integration with low coupling and more configurations oriented than coding.

Buses have at least these 4 characteristics, which can be divided into many others:

• Service creation and hosting: exposes services for integration between applications centrally
• Service mediation: protocol adapters, service mapping
• Message routing: deliver messages in the correct location with low coupling
• Data Manipulation: Transform data to deliver it to the standard expected by each application consuming bus services

Very common scenarios in which they are adopted, including also those already mentioned, are these:

• data transformation between systems
• integration between standards and heterogeneous systems
• file exchange between systems
• exchange of messages between queues/topics/etc.
• orchestration of a process between amusement systems: scenario in which a system should integrate with N applications, but which now consumes a single bus service
• data processing and messaging according to business rules
• expose legacy systems through more current standards, such as web services
• exposure of Apis through proxy of heterogeneous services already available
• etc..

Some examples of ESBs are these:

• Apache Synapse Enterprise Service Bus
• Mule ESB
• Red Hat Jboss Fuse
• WSO2 Enterprise Service Bus
• List of Esbs on Wikipedia

This was a summary of what is and what can make a bus, in the documentation of providers listed above you can see many other features and benefits a corporation can get when it adopts a service bus.

Answer 2

Man, I’ll give you a clear answer, better than copying and pasting here like my friend did there.

Come on, imagine you have an app that consumes one service from another. so far so good ?

Now imagine that you have one application that consumes the service of another, and that one consumes the service of another application to give its answer. It’s getting complex, isn’t it? It will take dozens of interfaces for you to do this, imagine now if you have hundreds of middlewares running doing this crazy thing there ? for the maintenance you will go crazy young

That’s where the bus (ESB) comes in, the idea is that it consumes all the services and does the routing and orchestration of it, it’s able to pick up all the wsdls there fill them with more content at runtime (this is called orchestration), out it will give you translation of msgs and other things, all with just one interface (abstraction of layers).