The integration hub comes in to align the business application along the data flows using most standardised technologies such as SOA and REST web services. Now days called API. For the matter of the latter, the dedicated capability of the hub become separate product to manage APIs and it’ policies.
Many technical systems are better integrated via the native interfaces such as databases, ERP applications and of kind. These are connected to the hub via the dedicated software pipes called adapters. Most integration hubs use the open adapters architecture to plug the multiple adapters when required to connect to the enterprise.
The broker means messages management, it is integrated with the hub via the special module or an adapter. Some brokers although take the responsibility of the integration hub providing the API and adapters on it’ own. Here the diverse integration platforms overlap in it’ functionality.
So, how to go about provisioning of the integration product? The golden rule is that the integration hub is the application while the message broker is middleware. The fundamental objectives are better to approach from the middleware side, while the specific requirements via the hub. For example, the broker better to handle the technical protocols such as MQ or RPC, while the hub will connect EDI, media applications and of a kind.
Broker habitat is on premises next to the traditional technologies such as mainframe and other legacy applications. The hub is the first to move to the cloud connecting the media platforms to the databases as a service, as well as on-premises applications.
In the process of the architecture development one will start with the data flow via the protocols realised by the messaging and event driven functionality. Further integrating with the enterprise applications, the specialised adapters will appear to connect the components via the fine-grained interfaces generated from the business objects.
It may sound that the broker is must and therefore it comes first, and in the nutshell, it should be the case without undermining the integration hub. In the bigger solutions the broker and the hub do often come together. The point is to recognise when the requirements could be addressed by the broker alone and go for it! This architecture will never be locked in and will be always open to changes such as introducing the integration hub with it’ benefits on the later stage.
Clearly, with the requirement for the API management, the integration hub is a must from the start. However, as it was mentioned already, the API management is less considered as an integration hub now days, but as an integration product in it’ own right. By virtue of it’ implementation the API management platform is often based on the integration hub, and with the deal comes an opportunity the customers do not want to miss – acquiring the integration hub as well with all it integration capabilities.
In the conclusion, all three plus API governance come as one unified integration platform for the digital transformation, otherwise known as Enterprise Service Bus. Think of the broker as the foundation with integration hub added to it to enable the adapters to connect the enterprise systems, and API gateway to manage the customer channels.