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

As an introduction, it is first necessary to point out that ESB s are agnostic in terms of technology, this being a premise and even a factor that makes large companies with a heterogeneous array of applications adduce service busses .

Another thing you mentioned in the question is application bus , I had particularly never heard of this term, I even searched and found nothing related. The standard is even the service bus, these services are contained in an application

What is it?

In summary, the explanation of Wikipedia is quite good, that is, service bus is an architecture model of software for the design and implementation of mutual communication between applications in a heterogeneous environment in which a service oriented architecture is sought.

An interesting point to note is that buses alone do not deliver service-oriented architectures, but in many cases they are essential to compose such architecture.

I would say that the buses are the guys who do not know the semantic meaning of the exchanged messages but who know the syntax of the most varied types of information exchange much better than any other application, so they worry about being the abstraction for the correct messaging, without ever worrying about specific business rules.

How does it work?

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

Now imagine you having 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 have its own integration standard, we would have to implement 100 integrations in the nail !!! It is at this point that service bus midlewares enter, that is, they aim to abstract and centralize the heterogeneity found in these corporate environments, providing integration with low coupling and more oriented to configurations than coding .

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

• Services creation and hosting: exposes services for integration between applications centrally
• Service mediation: protocol adapters, service mapping
• Message routing: Deliver messages to the correct location with low coupling
• Data manipulation: transform data to deliver it to the expected pattern for each application that consumes bus services

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

• Data transformation between systems
• integration between heterogeneous patterns and systems
• inter-system file sharing
• 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 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
• Exposing APIs through proxy of heterogeneous services already available
• etc.

Some examples of ESB s 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 a bus is and what a bus can do in the providers documentation listed above you can see many other features and benefits a corporation can get when it adopts a service bus .

    

Dude, I'll give you a clear answer, rather than copy and paste here as your friend did.

Come on, imagine that you have one application that consumes a service from another. That's alright so far?

Now imagine that you have one application that consumes the service of another, and that other one consumes the service of another application to give its answer. It's getting complex, right? 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 maintenance you're going to go crazy young

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