Enterprise Integration and ESB

What is ESB?

ESB is an enterprise-level message system that relies mainly on XML message exchange. Such messages are then intelligently routed and converted through a non-centralized architecture.

Open-Source ESB?

Mule, ServiceMix, Apache synapse, JBoss ESB, sun's openesb and Apache camel.

What is the relationship between ESB and SOA?

The reason is that these two words contain too many connotations and cannot be clearly stated in one or two sentences. In addition, they have different meanings in different places. SOA-a service-oriented architecture, in fact, emphasizes a software architecture, a relatively stable structure that supports software operation, and the surface meaning is as follows, in fact, SOA is an idea that solves System Integration through service integration. Not a specific technology, it is essentially a strategy and idea. ESB-An enterprise service bus, like a "smart" pipeline, used to connect various "stupid" nodes. To integrate services of different systems and protocols, ESB implements message conversion interpretation and routing to interconnect different services. Currently, the concept of ESB and SOA still does not exist. However, it can be clearly stated that SOA is a service integration idea, and its implementation methods may vary greatly. Currently, the most common implementation methods of SOA are SCA and jbi.

ESB history?

It is derived from enterprise integrated applications (EAI. Let's see what Mom is.

Mom refers to the use of an efficient and reliable message transmission mechanism for platform-independent data exchange and integration of Distributed Systems Based on Data Communication.

Message-oriented middleware uses message delivery providers to coordinate message transmission operations. The basic elements of the mom system are clients, messages, and mom providers, which include APIs and management tools. The mom provider uses different architectures to route and send messages: it can use a centralized Message Server or distribute routing and transmission functions on each client. Some mom products combine these two methods.

With the mom system, the client can call APIs to send messages to the destination managed by the provider. This call will call the Provider Service to route and send messages. After a message is sent, the client continues to execute other tasks and is sure that the provider keeps the message until the receiver client retrieves the message. The message-based model is coupled with the provider, making it possible to create a loosely coupled component system. Such a system can continue to work reliably without stopping even when some components or connections fail.

Another advantage of coordinating message transmission between clients by the message delivery provider is that the performance can be monitored and adjusted through the addition management interface. In this way, client applications do not have to worry about any issues other than sending, receiving, and processing messages. For problems such as interoperability, reliability, security, scalability, and performance, the administrator should implement the mom system by coding.

So far, we have introduced many advantages of using message-oriented middleware to connect distributed components. The following describes its shortcomings. One drawback is loose coupling. In the RPC system, the called function can be returned only after the called function completes the task. In an asynchronous system, the caller's client continues to load work for the receiver until the resources required to handle the loading work are exhausted and the called component fails. Of course, these situations can be minimized or avoided by monitoring performance and adjusting the message stream, but this is not required for RPC systems. It is important to understand the advantages and disadvantages of each system. Each system has different tasks. Sometimes, you need to combine the two systems to fully obtain the desired behavior.

Take a look at the structure

The biggest advantage of using this structure is that it is not centralized.

Extend it and change the integration mediation to a service adapter, so that the function can fully implement the ESB.

What are the core functions of ESB?

Service-Oriented Architecture-distributed applications consist of reusable services and a message-oriented architecture-a message-driven architecture between applications that send and receive message events through ESB-asynchronous real estate between applications and message receiving protocols adaptation, message transmission, intelligent routing, message conversion, task/Timer, monitoring, and scalable APIs.

What are the application scenarios of ESB?

Servitization, Service Virtualization, asynchronous communication, and Protocol bridging. Servitization: service applications. For example, if a system does not provide external service interfaces or provide unsatisfactory services, you can consider using an ESB. Service Virtualization: the example of a phone call can be used to illustrate the problem. Generally, you only need to dial the phone number without knowing the actual location of the other party. The number is a virtual service, the actual application is managed in the background. Asynchronous Communication: Processes asynchronous messages or asynchronous requests. Protocol bridging: conversion between multiple protocols.

Use Apache SYNAPSE

What functions does Apache synapse have?

1. protocol adapter 2, message-oriented middleware, which can be configured to interact with any JMS-compatible message system. 3. XML-based reliable message delivery. 4. Smart routing and distribution, you can implement multiple filtering methods 5, message conversion service 6, task/timer, and support complex and fine schedule 7 like cron in Unix/Linux, service quality provision and web intermediary services can achieve load balancing, rule logic of failover, message-level Division 8, monitoring and management, and JMX monitoring support 9, scalable APIs