Hub-and-Spoke Architecture

Message Brokers allow the information flow between applications. Following this type of middleware, we advance to an integration architecture that is based on message brokers.
As the applications universe grows and the Point-to-Point architecture is no long a viable option, the necessity of middleware is obvious. One of the possible architectures to implement the middleware is the Hub-and-Spoke.
Hub-and-Spoke is a MOM that uses a central message broker. The communication is not made between pairs of applications, but between each application (spoke) and the central hub [1]. The broker functionalities include routing and messages transformation to the receiver spoke. This architecture allows content based routing, which performs based on information in the message header or in some element defined in the message body. The hub can apply rules to the content of the message and determine the receiver spokes [2].
 
hub_spoke

Figure 1. Hub-and-Spoke

 
As communication can be synchronous or asynchronous, this architecture can ensure the persistence of messages storing them in databases or files. Other functionality supported by this model is the ability to create flows with defined logic for forwarding messages. For example, if you set a field with the value “X”, it forwards to destination “A”, otherwise forwards it to the destination “B” or even to both [1].
It exist several benefits of the hub-and-spoke architecture, as the detaching between applications. It is possible to add a new application to communicate with the broker without affecting other applications. It is also possible to change the broker subscriber rules without the necessity to change the connected applications [1].
Since the broker is a central point of communication that manages all the messages between applications, under heavy load it can be a bottleneck or compromising the organization’s operation if it becomes unavailable.
As mentioned, a hub-and-spoke solution based on MOM still does not answer all the requirements of an integration platform. Another architecture that can meet the integration needs is SOA.

Ricardo Santos

EAI Consultant and IoT Evangelist at Polarising
 
References

  1. Bussler, C.: B2B Integration: Concepts and Architecture. Springer Science & Business Media, California (2013)
  2. Ramanathan, R.: Service-Driven Approaches to Architecture and Enterprise Integration. IGI Global (2013)

 

Leave a Comment

Your email address will not be published. Required fields are marked *