Enterprise Middleware and Integration
In the yesteryears, organizations used to leverage monolithic applications, fulfilling the entire business requirement using a single software solution. However, organizations today follow a modular approach where they prefer to have separate solutions for different aspects of their business. As a consequence, organizations face the challenge of integrating their legacy systems with newly developed on-premise solutions, SaaS based offerings, and other new data sources. To provide interoperability between these multiple applications a middleware solution is required which can ensure seamless connectivity between all these applications.
Types of Application Integrations
When organizations started facing the challenge of integrating multiple applications running on different software stacks, several approaches for application integration started evolving. One of the earliest and very common integration approaches is Point-to-Point integration.
Point-to-Point: This is one of the quickest approaches to integrate applications in which you develop connectors for each pair of applications. These connectors will have the data transformation logic and ensure seamless interaction between the applications. This model becomes complex for an ecosystem consisting of large number of applications, as the number of connectors grow exponentially with the increase of applications. For e.g. in an ecosystem comprising of three applications only three connectors are required, but if you add two more applications, then number of connectors required will be 10. This leads to increase in design complexity as well as creates a new challenge of maintaining these connectors.
1. Quick Implementation.
2 Fast and Efficient.
1. Integration complexity increases with addition of new application.
2. Tight coupling between the applications.
Hub and Spoke: In this model there is a central integration engine called Hub/Broker. All the applications in the ecosystem communicate through this hub. Spokes are the connectors that connect these applications to the Hub and perform the message transformations in a format which the Hub understands, and vice versa.
1. This model reduces the complexity of integration. One can add an application in the ecosystem by simply connecting it to the hub.
1. The limitation with this model is the scalability, as there is a single hub to process the messages. When message load over the hub increases, the hardware needs to be scaled up and hence becomes a bottleneck for the complete integration design.
2. The failure of the hub at any point of time can bring the whole system to stand still.
Bus Architecture: Due to the bottleneck in the hub and spoke design, owing to a single centralized broker system, the bus architecture evolved. This model uses a central messaging backbone (bus) for message propagation. Unlike hub and spoke design, message transformation and routing in this architecture is distributed to respective application adapters, making this integration more scalable.
Today we have several integration solutions available in the market based on the Bus Architecture. Apart from a messaging backbone these solutions provide additional functionalities like security, transaction processing, logging, monitoring, error handling and many more. These complete packaged solutions are well known as Enterprise Service Bus or ESB.
2. Ease of adding new applications
1. Overhead for simple integrations involving two or three applications.
2. Improper implementation could lead to a more complex architecture
Some of the leading commercial ESB products available in the market are Oracle Service Bus, IBM Integration Bus, Microsoft BizTalk, and MuleSoft's Mule ESB.
ESB products available under open source category are JBoss ESB, Apache ServiceMix, Apache Synapse, WSO2 ESB, and Talend.
With technology shifting towards APIs and Service Oriented Architecture, one will always find a need of integration to ensure that all the applications in the ecosystem can interact with each other, including the legacy system which still has the core components of the business. To use any of the integration architecture/solutions discussed, it is important to evaluate them against parameters like number of applications they want to integrate, number of applications that may be added in future, different type of communication protocols involved in integration, and scalability of the system.