2

I read a lot of integration literature that talk about the evolution of integration architecture from Point-to-Point to Hub-Spoke to ESB. But for the life of me I am struggling to understand the difference between Hub-Spoke and ESB. Hub and Spoke is usually depicted as the following -

Hub as one big circle (Hub) with multiple smaller circles around connected to the hub via spokes

Hub and Spoke with Hub as a circle

But the same can redrawn as you would depict an ESB right?

enter image description here

So I am not sure why ESB and Hub-Spoke architectures are represented differently in pictures even though the idea seems to be the same.

Let's look at a practical example -

A proxy service in my Oracle Service Bus reads a CSV file from a file server, Splits the file into multiple rows, converts each row to XML and finally updates an ERP with this XML, how is this any differently handled in Hub-Spoke?

A Hub-Spoke is typically tagged as a Single Point of Failure. But in my above example if my ESB fails wouldn't the entire process fall apart?

I am looking for practical examples that show how a specific integration is handled differently in Hub-Spoke and ESB but none of the books/documents I read provide specific practical examples.

cubsnlinux
  • 365
  • 3
  • 15

2 Answers2

2

Speaking strictly of the architectural patterns-

In Hub And Spoke the HUB is an intelligent entity with all the logic to route a particular message to a particular system. The Hub will Push the message to the intended recipient.

In a BUS there is no central entity with all the routing logic. It is just a place where one would publish a message. The recipient will have to monitor the BUS for the arrival of any message intended for itself and whenever it finds such a message it will have to Pull it off the BUS.

Although both depictions as you mentioned look the same, the difference is in where the routing logic lies.

Parag Patil
  • 156
  • 7
1

I cannot speak for all service bus implementations but I am going to assume most (that I know of in the .NET world) are actually distributed service bus implementations. My service bus is called Shuttle ESB but NServiceBus, MassTransit, and Rebus are all distributed as far as I am aware.

Some integration engines call themselves a service bus making it one of those tricky terms to nail down.

The thing with a hub-and-spoke approach is that there is usually a central server through which all messages are routed. If that central machine fails then the mechanism fails. With some engines the central machine can be federated but it is still very much central. If the sender of a message does not queue the outgoing message somehow then the failure is going to be more apparent.

With a distributed service bus such as Shuttle ESB each endpoint forms part of the service bus. There is no central server through which all messages are routed. Each endpoint routes messages to the relevant consumer. Messages may also be queued on send/publish so that even a failure at the recipient will not stop that sending. once the recipient comes back up the processing simply continues.

Although logically, as depicted in your images, the two approaches are identical, the actual implementation is quite different.

Eben Roux
  • 12,983
  • 2
  • 27
  • 48
  • Not sure I understand. In a ESB implementation such as Oracle Service Bus isn't there a central server (WL server on which OSB services are running)? So if this WL server or server cluster goes down doesn't the ESB layer as a whole goes down? – cubsnlinux Apr 25 '16 at 01:01
  • Any centralised service bus implementation will go down as a whole should it fail. A distributed approach has some tolerance in that various endpoints will remain operational. A distributed endpoint failure is further mitigated by an "outgoing" queue on the local machine where any dispatched message go into a store-and-forward mechanism. – Eben Roux Apr 25 '16 at 06:43