Skip to main content

Hub & Spoke Vs WCF Routing

Hub & Spoke architecture style – When it comes to integration in heterogeneous environment, hub & spoke architecture style is the best and proven option. This architecture style can be realized through queues, messages & some routines. The different apps of an enterprise can communicate with each other through message exchanges.

Sometimes, the same architecture style is also used for just content based message routing. Some people call it as ‘message based integration’. Messages will have different values in headers indicating their type & other details. Based on the content in the header, each message will be routed through different paths. Message processing will be taken care by routines or batch processes.

With the availability of the options like WCF Router in .Net 4.0, it has now become a must to find when exactly to use hub & spoke. Using it in simple places like content based routing will make things complex. While options like WCF Routing is available, hub & spoke should not be employed unless there is a definite need.

Let us see the candidate scenarios where hub & spoke could be the best solution:

  1. When there is a need for asynchronous, content based routing. Here, queues will be used to persist the messages so that they can be processed later by the routines asynchronously
  2. When reliability & transaction takes high priority, then obviously message based solution scores higher no. of points (by saying that I does not mean that WCF Routing is unreliable)

WCF Routing scores high when it comes to synchronous content based routing. Why? Because it is simple when it comes to effort required for implementing a solution. Also, it makes things easy when to compared to hub & spoke.

When it comes to implementation, following are the building blocks that will be used in hub & spoke:

Queue –It will be used as a place for persisting messages temporarily; MSMQ, MQ Series etc.

Messages – XML messages in pre-defined formats; Header attributes will indicate what the
message is meant for ; say like invoice, order, delivery note etc.

Routines / Listeners – Windows services which will be configured to watch various queues and process the messages based on the header values. Say invoice processing windows service will look for the messages with “Invoice” in the “Transaction” attribute in the header and process it

In some cases, even databases are used instead of queues as they also offer the same benefits as what queues offers in terms of transaction, security, durability etc.

Even though hub & spoke architecture style enables heterogeneous integration with loose coupling, using of components like queues & windows services will make implementation more complex. Also, as no of transaction types increase, routines are to be developed and deployed to do processing.  

Even though WCF Router does not have any persistent capability, it can also attribute to reliability to certain extent through its support for increasing fault tolerance by routing traffic away from unavailable services.

You can think why I am comparing Apple with an Orange! I had compared here a technology option with an architecture style. But I had done it from the perspective of the problem – “content based routing”.


Popular posts from this blog

Lambda Architecture on Microsoft Azure

Gone are those days when Enterprises will wait for hours and days to look at the dashboards based on the old, stale data. In this fast world of BYOD, fitness gears and flooding of other devices, it is becoming super important  to derive out “actionable” information from huge volume of data / noise that is generated from these devices or any other data sources and act proactively on them  in real-time, to stay competitive. At the same time, the need for having dashboards and other analytical capabilities based on the quality, cleansed, processed data still very much exists. With the emergence of more data types and need to handle huge volume, shift is happening from the conventional data warehouse practice to cloud based data processing & management capabilities where high volume batch processing is possible at the optimized cost. Business scenarios demanding the need to process the data in real-time    More  

Heterogeneous Cloud Integration

Heterogeneous integration is common scenario in the Enterprises where their IT portfolio is based on heterogeneous platforms. Various solution approaches such as message broker, messaging middleware, SOA – service based integration were employed to address heterogeneous integration challenges.   These solution approaches were good when the integration happens on premise, with in the data centers of an Enterprise. Problem here is non-availability of “elasticity”.   With the Enterprises started leveraging cloud platforms extensively for various solution aspects such as elastic computing, storage, it opens new capabilities that can be leveraged for heterogeneous integration. Also, similar to existing on premise scenario, Enterprises are also leveraging multiple cloud platforms to address their business needs. This scenario will pose same integration challenges as those that were faced within on premise datacenters   Within datacenters / on premise, integration product

Blockchain for a "Secured" AADHAAR

AADHAAR  is gradually becoming the “Most Important” digital identity (like a social security number in US) for the citizens of India. It is considered to be more important than any other identities such as Passport, Driving License, PAN card etc. as it is being recognized as the “Mandatory” proof for the authenticity of an Indian citizen, for all the Govt. as well as private transactions, starting from availing the subsidized residential gas benefits  to operating a trading account or even getting a Passport. Because of this, the secured accessibility & immutability of that digital identity is very critical. The AADHAR card once issued to a citizen should not be subjected to change especially in terms of AADHAAR number, name of the person etc.; Any compromise on AADHAR can lead to problems related to mistaken identity. Storing AADHAAR information in a Blockchain platform is a natural choice , as Blockchain offers "Cryptographically" secured decentralized storage and