Currently, IT organizations are facing the challenge of integrating various applications, and other technologies into a single umbrella. In a multibillion-dollar company, it's the responsibility of the company to satisfy their customers to keep their reputation up. At the same time, to do this it needs to handle various modules and sections to accomplish a goal. To keep a lucid structure of development, the preferred way is to have SOA
. Enterprise Service Bus (ESB) works on the principle of SOA.
Let's look at the root of the enterprise service bus. The concept of enterprise service bus came from the concept of 'BUS' in hardware architecture. If we look at the Computer Hardware Bus
, it is a subsystem that transfers data from one working module to another working module which is loosely coupled. Now, let's try to apply the same concept of computing bus here in ESB architecture.
It tries to connect various independent loosely coupled modules. It helps to share data generated by one module with another. Here comes the concept of SOA discussed before.
So for the time let's say, ESB is a black box that helps to integrate the system modules which are loosely coupled but are used by other systems.
The content we had seen till now is just overviewed. We will discuss in-depth ESB & Mule ESB in a few moments.
|Do you want to master Mulesoft? Then enrol in "MuleSoft Training" This course will help you to master Mulesoft
Point To Point Connection
S1, S2, S3 & S4 are say 4 services (module) of the system which are interacting with each other by direct contact as shown in fig. This is the most basic communication architecture with a simple design.
But it has major disadvantages:
- If the system is complex with 'n' number of modules interacting with each other, in that case, it fails. It makes more hardware connectivity.
- This (primary model) will not support asynchronous communication.
- To handle asynchronous communication, service implementation have to have the logic build for asynchronous support. (Queuing, synchronizing etc)
- If all systems are on a different platform and support different protocol, that case P2P won't be an efficient way of communication.
So basically, ESB is used to overcome drawbacks of various communication architecture, none less, it depends upon the complexity of the system.
So, to focus on ESB, ESB acts as middleware.
Let's look at the detailed diagram of ESB architecture.
In an organization, the ESB architecture will look like as shown in the figure.
There are various modules, handling different functionality like mail, database, etc. These individual modules are working as a service. Each service or client can ask for another service and asked service will act as a service provider.
Now, one could say, one service is working on some protocol, and another service is unknown about such protocol.
Such kind of scenarios is considered in ESB architecture.
Capabilities of ESB:
- Routing of services
- Message Transformation
- Service orchestration
- Transaction management
- Protocol transmission
- Message processing
- Message enhancement
- Process choreography
- Service Mapping