Dose this question intrigue you? Do you want to know how communication/data transfer happens between different applications of an enterprise? If so, read through this post & let’s try to understand the same thing.
In today's enterprise infrastructure, system and application integration is becoming increasingly important. The important question is, how will this happen or what will help in achieving this goal of inter-application communication? This is where Enterprise Application Integration or EAI comes into picture. Now, what is EAI you ask, let’s try to understand about it in this article.
What is Enterprise Application Integration (EAI)?
EAI is a continuous process of translation of data & commands between two incompatible systems. It is an approach of providing interoperability between multiple (incompatible) systems within an enterprise.
Putting this in simple terms, consider EAI as a person who knows many different languages (language translator). In a situation where, there are two or more people from separate places knowing different languages who want to communicate to each other can take help from this language translator to bridge the communication gap between themselves.
EAI design approach can be of point-to-point type, or it can be of a message broker type, or it can be a service bus type. Depending on the organization/enterprise need, application integration approach can be decided.
Types of EAI:
1. Point-to Point:
- This is the simplest way to design the integration to achieve the goal of interoperability.
- This can be a good approach when the enterprise is having a smaller number of applications to integrate & communicate with each other.
- As the name says, this approach will design a point-to-point communication link between each available application.
- The pros for this approach are that it is easy & can be delivered quickly as only a common connection string needs to be established from application A to application B. If there is another Application C that wants to connect to application B, then a new communication string needs to be developed.
- This starts becoming difficult when the applications available in an enterprise is more, as the maintenance of this will take more time & also the developer working on maintenance part must know all the details about each involved end system.
- This approach is only suitable for enterprises with small number of end system with low to zero scope of change.
- As explained in above figure, the number of interfaces start growing fast as we start adding a greater number of applications. This will add development cost with every added system/application to the enterprise.
- Another trade-off with this design patter is the complexity that will be added to the complete enterprise applications architecture will also grow & at some point the maintenance of the same will become a tedious job.
2. Message broker:
- In this approach, there is a message broker/communication facilitator application which sits in between all the applications that are to be connected to each other.
- This message broker is responsible for all the required message translations/transformations, application of business orchestrations if any or any other policy applications to the transactions flowing through.
- This adds the factor of system scalability, as the newly joining system just must take care of connecting their system to this message broker & the rest is already established.
- Also, there is a capability of adding logging over the transaction flow.
- The drawbacks of this approach could be listed as the message broker can become a single point of failure for the complete network & also it can act as a bottleneck for the entire communication channel during high load periods. Apart from this there is a constant need of an expert to work on the message broker development & maintenance.
- This design pattern overcomes the shortcomings of previous design pattern. As in the number of interfaces will always stay equal to the number of applications. This makes the maintenance job easy.
- At the same time, trade-off for this pattern will be that it may act bottleneck during the time of high network traffic & there may be chances of message loss as well.
- Another point to consider is that will it adds a single point of failure for the complete application network. If the message broker goes down for some reason none of the application in that enterprise will not be able to communicate to each other.
3. Enterprise Service Bus (Event Bus):
- This is the easiest & most scalable approach to implement application integration throughout the enterprise.
- In this approach, a universal data communication channel is created which makes the data available to all the applications connected to this event bus at all times.
- This makes connectivity easy for the new systems in an enterprise, as the data is already available, they only must select the appropriate section out of it.
- This approach is most suitable to enterprises which are in constant growing phase as the scope of applications is not predefined & new systems may get added to the enterprise on the go.
- The inter-application communication becomes easy here, but the drawback is that of availability of an expert on the event bus coding.
- As this patter is the newest offering, it tries to overcome the drawbacks of previously mentioned design patterns, but a system cannot be perfect all the time. This system also adds a single point of failure in case of ESB service being unavailable at a point of time again disrupting the complete application network.
There are multiple tools available in market that help in achieving this interoperability goal & each of them has their own pros & cons. Post research & requirement analysis of the enterprise needs an EAI provisioning solution can be finalized.
Resources:
www.investopedia.com
www.mulesoft.com
If this post helped you in understanding a new concept today, then share it with your network & let someone get help from it. Also comment down below a topic from integration world that you want me to write about. For now, the next topic I’ll be posting about will talk about ESB design pattern in detail. I’ll be posting similar posts to explain things from the world of integrations.
SOCIAL SHARE CARD GENERATOR