Integration of a set of heterogeneous systems and applications in any organization plays a pivotal role in sharing and communicating useful data across systems and applications in order to perform different business tasks and to better utilize all the information by converting raw data into useful information. Integration area has seen a lot of evolution with time by introduction of new architectural styles to better utilize available technologies and to address any shortcomings in existing integration architecture.

In this post, I will explain Point to Point vs Hub Spoke vs ESB integration architectures and explain how P2P Integration, Hub/Spoke and Bus Architecture (ESB) integration models work and what’s the difference between Point to Point, Hub/Spoke and ESB based architectures.

Point to Point (P2P) Integration

In Point to Point Integration architecture, Every System/Application is integrated directly with any other application or system for enabling their communication to share any data between the integrated parties. With this Integration model, If an application A has to integrate with “n” other applications, application A is responsible to have all the integration logic implemented with respect to all n applications including protocol conversions, data transformations, data transfer etc. which makes it extremely complex resulting in a messy spaghetti architecture as shown in the below diagram:

 

Drawbacks of Point to Point Integration Architecture

* With Point to Point Integration, It becomes a hassle to integrate any new application or system as integration logic needs to be written in all integrated systems for enabling this new application’s integration.

* Such a scheme of point to point integration isn’t scalable and end-systems become really fat with all the integration logic being added up. With too much Integration logic being implemented in End-Systems or applications, performance becomes a serious concern as ideally end-systems need to be more focused towards actual business implementation rather than all the hooks and crooks related to integration.

* With Integration logic implemented in different applications/end-systems, ensuring a standardized integration or following any standard design patterns become difficult as such integration logic is implemented by different teams not necessarily integration area experts.

Hub & Spoke Architecture Based Integration

To address the shortcomings and cons of P2P Integration, industry evolved and opted Hub & Spoke Architecture to get rid of spaghetti mesh. In Hub/Spoke Architecture, all applications are integrated using a Centralized Hub with Spokes (Adapters). In Hub & Spoke Architecture, It is responsibility of Central Broker (Hub) to route all traffic towards integrated systems/applications. In Hub/Spoke Architecture, Hub acts as a MOM (Message Oriented Middleware) and Hub can perform any type of translations, transformations and routing decisions.

Below diagram shows how Hub & Spoke Integration Architecture works with a centralized broker and connected spokes where each spoke connects to hub eliminating any direct point to point interaction:

While Hub & Spoke Integration Architecture rightly addresses the issues of point to point communication, It yet adds some new concerns which also needs due considerations.

Drawbacks of Hub/Spoke Integration Architecture

* With centralized Broker (Hub), we end up with a single point of failure where all integrated systems are affected with any issues on central hub.

* With addition of new integrated parties or with a growth of messages data being transferred, performance become an issue and Hub turns into a bottleneck.

Although we can still mitigate above issues or concerns with use of federated Hubs or by tuning Hub with more sophisticated and increased Hardware & Software resources, such a model is not considered scalable and efficient in a complex and highly critical integration environments.

ESB (Enterprise Service Bus) Integration Architecture

Enterprise Service Bus architecture is based on SOA principles which uses Bus model for integrating multiple systems and applications with a messaging bus acting as a pipeline. ESB acts as a messaging backbone and this architecture rightly glues multiple systems where each integrating system/application is equipped with an adapter and integration engine. These adapters transform messages into a canonical model and all data in the service bus travels in that canonical format. Adapters at the destination system then convert data from canonical format to the supported/desired format of the destination application. ESB architecture is more distributed in nature with smart endpoints and it is also considered as lightweight in nature. Lightweight ESB architecture allows organizations to horizontally scale more conveniently as per organizational needs.

A key difference between hub/spoke and bus topology is that for the bus architecture, the integration engine that performs message transformation and routing is distributed to the application adapters. The bus architecture requires an application adapter on each integrated application. Bus architecture is more scalable and it completely decouples all integrated applications and you can plug/un-plug any integrated applications seamlessly.

In ESB based integrations, applications publish messages to the bus in order to make them available to the destination applications who have subscribed for those message types.

If you want to learn and explore more about different Integration schemes and architectures, watch the video below on our Youtube channel and don’t forget to subscribe for more videos.

Video: Point to Point Vs Hub/Spoke Vs ESB Integration Models