In the early days of EAI, the applications needed to interact with each other in various formats, which may include communicating some information or exchanging data. To facilitate this exchange, the organizations came up with a hub and spoke model for EAI.

In this hub and spoke model, there's a router-based middleware component and a concept of events. Whenever there was some change in the state of one of the applications, the application used to generate an event. The other applications subscribed to the event stream they were interested in.

Now, whenever a new event was generated, the router was responsible for the delivery of the event to the interested applications handling the conversion of data from one format into another, so that the applications could communicate with each other. In this kind of approach, the router became the central point of facilitating the integration between the different applications.

The router provided a lot of features, such as the following:

• Adapters and SDK: For the applications to communicate with the router to raise events, they need to have some kind of glue that facilitates the connection between the application and router. The adapters provided by the router middleware used to provide this necessary glue layer. In case there was no supported adapter for an application, the router middleware provided an SDK to facilitate the development of an adapter.
• Message transformation: When a new event has been generated, the router, based on a set of some pre-defined rules, used to translate the messages associated with an event into a format that can then be consumed by another application. This kind of functionality was important to facilitate communication between two different applications, each of which have their own data storage formats and communications styles.
• Intelligent routing: For the applications to work seamlessly with each other, there needs to be a guarantee that the correct event is reaching the correct target audience. The router middleware used to implement intelligent routing based on which application generated the event and which applications are interested in listening to that event, so that the messages generated as a part of an event are delivered to the correct recipients.

This kind of approach provided a nice mechanism to remove the unneeded complexity from the enterprise infrastructure that would have been developed if every application had to communicate with other applications directly, managing their own connector, and handling data consistency. Whereas, with this approach, the router facilitates the communication between the different applications.

But, as good as this approach was with all of the benefits, it suffered from some of the following serious drawbacks:

• Single point of failure: The broker model to the EAI proved to be a single point of failure. In case the router middleware goes down, all communication between the different applications will come to a halt.
• Centralized logic: The logic for the transformation of the data, along with the routing of the data, was all centrally located inside a single router. This caused the broker to become a complex component making the operations and maintenance of the broker a difficult task.
• Poor scalability: When the load on the router increases, the handling of the messages by the router can take a hit. This results in an inconsistent state of data between the different applications. Also, having a single, centrally located router becomes a hurdle in the geographical scalability of the router if the applications that are trying to connect to each other are located in the different geographies around the world.
• Proprietary solutions: In the earlier days, when the router-based hub and spoke approach of integrating enterprise applications was there, most of the solutions used to be proprietary in nature and supporting only a subset of vendors. To get some application from an unsupported vendor integration, it was a huge problem for the developers, who would then need to write and maintain their own adapters based on the provided SDK.

All of these issues called for a better approach to be implemented that does not suffer the same issues as the router-based approach had. Eventually, the enterprises started to shift to a service oriented architecture (SOA) model and introduced the use of an Enterprise Service Bus (ESB) for integrating these different services inside the SOA. So, let's take a look at how the ESB changed the way EAI happens.