Difference between Hub, Spoke and ESB

折月煮酒 提交于 2019-12-04 09:36:53

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.

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.

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.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!