Hub-and-Spoke architecture
Lots of nice articles have been published on the net on Hub and Spoke architecture. To start this topic, I am putting together information which I found very useful, some of this information has come from other blogs, company websites (JBOSS, IBM, Cape Clear, BEA, Microsoft etc.). I have practically worked on this architecture and found it’s fulfilling all the latest requirements.
Very rapidly we are experiencing advancements in hardware and software technologies, so somehow its overcoming Hub and Spoke architecture downsides. Though I believe this could be considered as a base of modern EAI systems.
When it was required to transfer data between applications, then Point to point architecture was introduced, but with the increasing complexity of applications, more and more point to point interconnections were produced. This lead to a nightmare IT landscape which nobody could understand, to solve this problem hub-and-spoke architecture was proposed.
The Hub-and-Spoke architecture, was the first dominant integration architecture that broke with the interconnected point-to-point application integration model, this is often referred to as “message broker.” i.e. it provides service brokering capabilities between systems. It follows pub-sub integration pattern.
Hub-and-spoke architectures consist of a centralized hub that accepts requests from multiple applications that are connected to the centralized hub as spokes. The spokes are connected with the central hub through lightweight connectors, which are constructed and deployed on top of existing systems and applications. One of the key goals of the hub-and-spoke architecture with connectors is to leave the current systems untouched and unchanged as much as possible.
Inside the hub there are capabilities for requirements such as message transformation, validation, routing, and asynchronous message delivery. Furthermore, most hub-and-spoke-based EAI solutions provide process management functionality to orchestrate inter-application message exchanges, and an administration console to monitor and track the workings of the hub.
Despite its indisputable advantages and merits, hub-and-spoke models are not as popular as they used to be. One major problem is that the centralized hub presents a single point of failure in the overall architecture. If the central hub goes down, not a single message can still be sent or received. Attempts to overcome this problem by clustering multiple implementations of the hub are often stranded on the complexity of the architecture and on the overhead in administration. As explained the hub has a critical role. ISVs or developers used to create lot of safety mechanisms around it. Commonly for messaging layer you see Fault Tolerance setup while for process hub you have either Fault Tolerance or Load Balance. These settings are generally done on software level with extra software and/or hardware configuration.
It provides a central point for applications and reduces the links between applications from n² links to n links, for a network of n nodes, only n – 1 routes are necessary to connect all nodes; that is, the upper bound is n – 1, and the complexity is O(n). This compares favourably to the (n(n – 1))/2 routes, or O(n2), that would be required to connect each node to every other node in a point-to-point network.
The hub provides a layer of insulation and functionality between the spokes, thus enabling spoke applications to be removed and replaced without other spokes being disrupted in any way, because of this simplification of connecting applications, the model offers lower total cost of ownership.
references:
http://www.time-tripper.com/uipatterns/Hub_and_Spoke
http://en.wikipedia.org/wiki/Hub-and-spoke