how is mulesoft (ESB) different from hub and spoke?

Question

My original intention is to understand the difference between ESB architecture and Hub-Spoke architecture. I'm afraid, I'm not able to understand it clearly no matter how many answers are given.

The following are my understanding - ESB is not a product but an architecture topology - ESB facilitates loosely coupled integration and reduces dependency - Mulesoft ESB and other ESBs in market offer more than just ESB characteristics - Message routing/Web services support

The point I'm trying to understand is - How is it exactly different from a HUB-SPOKE architecture?

• ESB says that the distributed message delivery architecture makes it work in such a way that dependency is reduced and possible reduction in downtime. But how? Is it because 'adapters'/integration layer are in source and destination application? if so, why does Mulesoft or any ESBs in market propose that they provide a huge range of adapters?

• if it is a matter of architecture design, does that mean, I can have adapters in application end and use ESB just for routing? and leave the adapters provided by MUlesoft unused?

• More importantly, how does it different from Hub? Technically, why is it said that 'HUB-SPOKE' does not allow distributed message delivery architecture?

Any help in this would be much appreciated. Thanks in advance.

Answer 1

ESB is a message oriented middleware (MOM) plus services that a typical application container provides.

So ESB helps different enterprise components to integrate seamlessly avoiding point-to-point integration's. A service producer/consumer (component) once integrated with ESB, it can talk to any components which are already integrated, reducing the point-to-point integration costs.

ESB says that the distributed message delivery architecture makes it work in such a way that dependency is reduced and possible reduction in downtime. But how? Is it because 'adapters'/integration layer are in source and destination application?

how does ESB achieve that

1. All components integrating with it should talk in Common data format (Message)

2. Routing and Filtering based on the message header

3. Supporting multiple Communication / Integration patterns

   a) Synchronous vs Asynchronous
   b) Request only (with/without Ack)
   c) Request with Response

What are the additional services does ESB provide ?

1. Application Deployment Service
2. Thread pooling
3. Message Queuing
4. Monitoring and statistics
5. Clustering Support
6. High Availability Support

why does Mulesoft or any ESBs in market propose that they provide a huge range of adapters?

Commonly used Components like DB service, File Services, Rule Engines, mail service , FTP Service are already integrated to ESB/or adapters are already written, so once your component integrate with ESB it can readily use these common services with little or no configuration

if it is a matter of architecture design, does that mean, I can have adapters in application end and use ESB just for routing? and leave the adapters provided by MUlesoft unused?

ESB is not just for routing, but it is one of the most important functionality. You might not use all the pre-supplied components of your ESB provider. You can also publish you service as a ESB component for the community to use.

More importantly, how does it different from Hub? Technically, why is it said that 'HUB-SPOKE' does not allow distributed message delivery architecture?

There is no difference if the architecture implementation provides all the features and services of ESB. But some say with ESB we can distribute the components across different machines to allow scaling and fault tolerance.

Answer 2

The key difference between hub/spoke and bus topology is that for the bus architecture, the integration engine that performs message transformation and routing is distributed to the application adapters rather than centralizing it to a single 'hub'