In this blog I’d like to take a look at Application Integration Models and their traditional approach. So, what in the world does that mean? Well, back in the days when I was fresh out of college and got recruited, I received training on Application Integration or Middleware. At that point I didn’t realise quite how vast the topic of Middleware was. No wonder it always seemed confusing to me!
As I remember how challenging it all was to understand, I will aim to put things as simply as possible for you in this post.
For the purpose of simplicity, I am going to stick to the basics of Application Integration/EAI and its different models with their respective problems. Having worked in EAI and ESB (Enterprise Service Bus) for a long time, I often wonder how I can explain its complexities to someone who is new to it. It’s like an ocean; vast and impossible to define in one simple statement. As difficult as it may be to describe, I will do my best.
The Traditional Approach to Integration
Enterprise Application Integration (EAI) is the sharing of business models, processes, application services and big data between multiple systems in an enterprise.
To understand EAI and why it exists, we need to backtrack to where it all started: The 2000s. At the time, people used to maintain each application independently. Whether it was a program, database, SAP or web, the essential concept was that it should run freely, using point-to-point connections.
To visualise this, imagine that there is an application named “Ozone” which needs to communicate with two external applications and two internal applications as the below graph shows.
Here, we can see the number of connections made for every application to communicate with each other. To get the recipe right, we can use a formula.
- If we have n applications, then we can get the number of associations required by calculating n(n-1)/2.
- In the above diagram, we have 5 applications (n) including Ozone. This would give us the following formula: 5(4)/2 – which equals 10 connections.
- Imagine now that we have 10 applications, which all need to communicate with each other. The formula would be 10(9)/2, i.e. 45 connections.
We can all see that with all these potential connections, making changes to the existing landscape became extremely difficult. To introduce a new application or replace an old one, you had to change all the existing point-to-point applications. The industry clearly needed a different approach to manage this agonising issue.
This is where EAI came into the picture.
By applying different design models, EAI was able to offer a simpler solution to the issue by introducing the concept of autonomous applications to sit in the middle, interpreting the various connections between the applications around it.
Now, I’d like to introduce you to two EAI design models:
1. The Broker Model
The Broker Model, also known as the Hub and Spoke Model, works by setting up a centralised server from where all the data gets passed on to multiple applications. This means there is no need for separate connections between applications.
Using the same example from above, the Broker Model would use the following system:
In this example, a centralised message broker takes requests from each application, via Spokes. The Hub then requests a response from the corresponding application. This integration model dramatically reduces the number of connections required.
One drawback of the Broker model is the vulnerability of having a central Hub. If the Hub fails, every one of the application connections are then also lost. It is possible to have a fault tolerance setup for it, but this has its own disadvantages. In addition, the performance of the Hub would decrease if hundreds of applications were expected to interact with each other at the same time.
For these reasons, many projects using the Broker model would typically fail. This led to the introduction of a new integration model: The Bus architecture.
2. The Enterprise Service Bus Model
The Bus Model is a larger framework, which uses a bus architecture for integrating multiple applications and software across multiple platforms. The model allows each application to talk to others independently, using messaging systems via the Bus.
Using the same example, a Bus Model could look as follows:
In this example, Ozone is placed in the bus architecture without disturbing any other applications. All the message interactions happen within the bus. This model gives us the flexibility of having a “loosely coupled” system, where any new applications can be added to the bus without disturbing the existing ones.
Despite all its advantages, the Bus framework does have its own drawbacks. It is costly to maintain – and it becomes more complex as you add multiple systems.
People often get confused by the various terms, for example thinking that EAI and ESB are the same. Hopefully this blog post goes some way towards helping you understand the distinctions, and seeing the key benefits and disadvantages of these EAI application integration models.
In future blogs, I will aim to go into more detail around other ESB and SOA models.
Stay tuned!
Learn more
We’re happy to discuss your requirements and help guide you make the right middleware decisions. With the help of our specialised consultancy services, you can start implementing an integration strategy that suits the unique needs of your business.
Contact us to have a conversation with one of our integration experts today!
Saai Prasan K
Latest posts by Saai Prasan K (see all)
- Understanding the Traditional Application Integration Models - 10th February 2017
- Service virtualization – The new trend in DevOps - 7th April 2015