4

I know theres already a good question on this, but it doesn't really answer what I'm looking for.

From what I understand:

1.both are used as a central focal point between applications
2.both can use routing/mediation/transformation etc. between services/apps

But the only difference i can really see is that hub and spoke typically have many different formats entering the hub(SOAP/REST/XML/JSON...) while ESB typically has a standard format(Usually just SOAP.)

Also I keep reading that hub and spoke introduces a single point of failure compared to an ESB. So is the physical deployment the difference here? Where a hub has every possible endpoint and as ESB has endpoints deployed across multiple hubs? So an ESB is just multiple hubs(for want of better words)?

Can anyone help clear this up for me?

jon lee
  • 887
  • 1
  • 15
  • 32
  • http://soalink.blogspot.in/2009/08/difference-between-esb-and-hub-and.html – Vrashabh Irde May 15 '14 at 12:08
  • You're not correct in the "formats" part. An ESB can support multiple formats and protocols. Actually, this is one of the things an ESB is used for: enabling the clients to use whatever transport/protocol they want, and letting the ESB handle the convertions. – spakendralo man May 19 '14 at 06:23

3 Answers3

4

There is no exact answer here, since you can talk about ESB as a specific design pattern, or as the discourse about the evolution of software integration tools and SOA.

ESB as a design pattern means that you manage communication between different services using a bus where clients can easily plug in and out. This is usually done by forcing them to use standard data formats and protocols, whereas with Hub and Spoke you might use custom connectors and data transformations for each client. This limits the number of problems you may have with running multiple integrations, but you may still have a single point of failure in ESB.

ESB as a discourse (or marketing term) is a more complex issue, where people argue over what is "True ESB". Some people say you need to have a modular architecture where you can select which components you deploy, or you need to be able to distribute the components across different machines to allow scaling and fault tolerance. In the extreme definition you would need to deploy even your data transformers as distributed services.

Anton Kupias
  • 3,945
  • 3
  • 16
  • 20
1

From Here

The ESB is the next generation of enterprise integration technology, taking over where EAI(hub-spoke) leaves off.

  • Smarter Endpoints : The ESB enables architectures in which more intelligence is placed at the point where the application interfaces with the outside world. The ESB allows each endpoint to present itself as a service using standards such as WSDL and obviates the need for a unique interface written for each application. Integration intelligence can be deployed natively on the end-points (clients and servers) themselves. Canonical formats are bypassed in favor of directly formatting the payload to the targeted format. This approach effectively removes much of the complexity inherent in EAI products.
  • Distributed Architecture : Where EAI is a purely hub and spoke approach, ESB is a lightweight distributed architecture. A centralized hub made sense when each interaction among programs had to be converted to a canonical format. An ESB, distributes much more of the processing logic to the end points.
  • No integration stacks : As customers used EAI products to solve more problems, each vendor added stacks of proprietary features wedded to the EAI product. Over time these integration stacks got monolithic and require deep expertise to use. ESBs, in contrast, are a relatively thin layer of software to which other processing layers can be applied using open standards. For example, if an ESB user wants to deploy a particular business process management tool, it can be easily integrated with the ESB using industry standard interfaces such as BPEL for coordinating business processes.

The immediate short-term advantage of the ESB approach is that it achieves the same overall effect as the EAI(hub-spoke) approach, but at a much lower total-cost-of-ownership. These savings are realized not only through reduced hardware and software expenses, but also via labor savings that are realized by using a framework that is distributed and flexible.

craftsmannadeem
  • 2,665
  • 26
  • 22
0

I don't know if you mean this when you say is physical deployment the difference here? but actually the main difference between Hubs and ESP is that, its communication system is in different Layer.

When we talking about an ESP we are reffering to a software architecture model where as a hub is reffering to a strict hardware connecting topology.

Profiously this hardware topology, (a collection of hubs) implements an ESP, but there is a distinct line in communication layers between the two.

apomene
  • 14,282
  • 9
  • 46
  • 72