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!

The post Understanding the Traditional Application Integration Models appeared first on Sandhata.

DevOps is a software development method that stresses communication, collaboration, integration, automation and measurement cooperation between software developers and information technology professions – That’s what Wikipedia has to say about DevOps. Now let us keep this simple, derive the definition from the word, Development + Operations = DevOps. DevOps bridges the gap between development team and operation team for faster delivery, more stable operating environments, faster resolution problems and continuous software delivery to make life simple. Now where does this virtual service actually fit in? As many companies have some form of SOA implementation, the architecture becomes complicated and most of them will be struggling with the dependencies and constantly changing interfaces. This is where service virtualization and virtual services comes into play.

How does service virtualization solve these problems and help in the process? Why is it the new buzz word in the market? Imagine you are driving a bike which is not properly tested. You will dare not to touch that bike until every part of it is thoroughly tested. Anything in the market should be well tested before it is released. A similar notion applies to software applications. Applications have become so huge and complex that the development process is time consuming and testing of the application piles up to later stages. So testers have to wait until everything else is developed and ready, which leaves them very less time for them before delivery.

Service virtualization will help to create a new virtual service that replicates the live service. The requests and responses from virtual service will simulate the live service. This will help testing teams to test early in the development life and they need not wait till the application development is complete. Different project teams will work on different components and assemble to integrate them into one. This is a slow process; testers can’t perform end-to-end testing.

With service virtualization:

• Remove the dependency between developers and testers, allowing them to work independently in parallel to each other. This helps teams in faster delivery of applications.
• Reduce testing life cycles and cut costs that will help in ROI for a project.
• The environment will be stabilized and defects can be identified in earlier stages of process, which will lead towards a higher quality outcome.

I have covered only the basics of service virtualization and its importance in DevOps. In my upcoming blogs I will drill down into each individual topic and discuss them in detail.

The post Service virtualization – The new trend in DevOps appeared first on Sandhata.