The difference between ESB and EAI

In most articles, I saw that the main difference between ESB and EAI is the "single error in EAI."

My question is:

At EAI, if the Hub fails, we say that this is the only point of failure. In the ESB also, if the bus fails, we can say that a single point failure. It is right? If not, please briefly explain this.

+6
source share
3 answers

The main difference between ESB and EAI is not a clear mistake.

Having said that, if the ESB Bus fails, yes, that is the point of failure. Ultimately, these are just applications in your infrastructure and whether they are a single point of failure or not, depends on their deployment (for example, clustering), and not on the basic conceptual integration template.

Personally, I would classify ESB (Enterprise Service Bus) as an EAI (Enterprise Application Integration) type. Many companies trying to sell you a product instead of a concept will argue differently.

ESB is just a new template for EAI instead of Hub-Spoke. I would not be too carried away by differences. When you dig into them, they are few and far between.

+6
source

Refer this comment

ESB is a new generation of integration technologies with enterprises that occupy a place where EAI (hub-spoke) does not work.

  • Smarter endpoints : ESB allows you to create architectures that place more emphasis on the point where the application interacts with the outside world. An ESB allows each endpoint to be present as a service using standards such as WSDL, and eliminates the need for a unique interface written for each application. Integration intelligence can be deployed at endpoints (clients and servers). Canonical formats bypass the direct formatting of the payload for the target format. This approach effectively eliminates the significant complexity inherent in EAI products.
  • Distributed architecture . Where EAI is just a hub and conversational approach, ESB is a lightweight distributed architecture. A centralized center makes sense when each interaction between programs is converted to a canonical format. The ESB distributes much more processing logic to endpoints.
  • No integration stacks . Because customers have used EAI products to solve more problems, each added vendor has stacks of proprietary features associated with an EAI product. Over time, these integration stacks are monolithic and require in-depth experience of use. ESBs, by contrast, are a relatively thin layer of software to which other processing levels can be applied using open standards. For example, if an ESB user wants to deploy a specific business process management tool, they can easily integrate with ESB using industry standard interfaces such as BPEL to coordinate business processes.

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

+2
source

We need to avoid becoming a single point of failure with a clustered setup — it could be an HA cluster or an FO cluster.

+1
source

Source: https://habr.com/ru/post/894169/


All Articles