Hub and spoke vs bus type

, , ,
1

Hi Guys
Could some body tell me what is the difference between
hub-spoke archtecture and bus-based archtecture. What are the pros and cons of each in EAI.

Thanks In Advance
Sreekanth Babu

2

Hi Srikanth,
In hub-spoke approach, all integrated applications connect through a central server. Thus, a new system or application only needs to be connected with the hub to be automatically integrated with other applications that also are connected with the hub. The integration server acts as a message broker to control communication, data translation, and process interaction among the connected systems.

The bus provides the medium for messages to reach their destinations. The physical implementation of this approach involves placing adapters within each integrated system or application, which then uses the bus backbone for interacting with the integration server and the other interconnected systems.
Compared with the hub-and-spoke model, the bus model scales better and potentially offers better performance. However, implementation of the bus model is more complex and more difficult to administer as the environment grows.
hub-and-spoke architectures are better for companies with limited IT resources and environments that involve a handful of systems and moderate transaction volumes. Bus architectures are more difficult to manage for resource-strapped IT groups, but they’re better-suited for large-scale environments

3

  1. The big drawback that EAI architects point out with respect to hub and spoke model is the central point of failure. Since all the messages are going via a central hub server, HA of this server becomes extremely critical.

  2. A webMethods based bus-type architecture with integration servers, brokers and territories/gateways can be easily drawn on a piece of a paper, but can add an additional layer of complexity (as Johnson mentioned). In this diagram, the bus essentialy is a pseudo-communication channel involving messaging between various brokers (using gateways and territories). Each Integration server (that can host multiple adapters) communicate with a single broker.

  3. Some of the bus implementations (from other EAI vendors) that are out there depend on selective multicasting of messages over the network. This can potenitally cause network related issues and may require higher degree of maintenance.

4

Hi guys
Thanks alot. It is a very useful info.
My understanding of the above is:

  1. In the hub and spoke architecture all the adapters and connectivity packages installed in the central server.
  2. Where as in the bus type architecture all the adapters/connectivity will be part of the applications. And the bus implementation provides routing, transformation and etc… features.

Is it correct.

Regards
Sreekanth

5

Not quite.

  1. In hub and spoke, the adapters and connectivity packages to not necessarily need to be installed on the central server. They connect and communicate to the central server but generally can be installed on any machine (e.g. out on the spokes).

  2. For a bus architecture, it is generally true that adapters will be on the same machine as the resource they connect to but that’s not a requirement. It depends on how the adapter connects to the resource. For example, a DB adapter can use a DB client package to connect to a DB instance that resides on another machine.

Lastly, these architectures refer to the connectivity/communication characteristics only. Things like transformation, workflow, etc. are not part of this. These features are usually performed by one of the end-points (be it a spoke or a node on a bus).