Do you want an ESB?

Recently, I met an IT project. Because some work has been done in the early stage of the project, the system functions are dispersed into various pre-defined subsystems. Based on this reality, some business processes need to be used in the project, and the ESB must be used to integrate these subsystems.

Must I use ESB?

What is ESB and what development scenarios is it applicable? We have to go back to the initial issue.

What is ESB?

ESB is an architecture model, not a software product. Different software products can form an ESB. In some cases, companies use multiple products in different regions and use specific features to meet their unique needs. These different products can be combined to implement the ESB mode.

In summary, ESB has four main functions:

• Message routing: Sends incoming messages to the destination. The destination is logically determined by hard encoding or dynamically determined by content. Routing is a key feature for enabling Service Virtualization. You can create an intermediate layer between the caller and the service to move the service location without knowing the change.
• Message Conversion: Converts incoming messages from one format to another. For example, you can convert a message separated by commas into soap to transfer data to a web service.
• Protocol intermediary: The incoming messages are sent from the sending location using different protocols. For example, HTTP can be used for incoming messages, while WebSphere MQ can be used for outgoing messages.
• Event Processing: Incoming messages of events are generally distributed to many endpoints through the release and subscription models.

In a given transaction, these advanced functions are usually merged. For example, the incoming message may be a web service call using SOAP/HTTP, And the destination is a legacy system that needs to use the fixed-length message format of WebSphere MQ. The message and coordination protocol must be converted and the message must be routed to the correct location.

The ESB programming usually involves a virtual environment, and the logic is represented as a connection activity stream called a message stream or intermediary stream. These streams are transactional and use a mechanism such as two-phase commit. In this way, you can roll back the entire stream in case of a failure or commit the entire stream in case of a success. These streams are stateless. Normally, a message is passed in. The stream performs various operations on the message and then sends the outgoing message.

Because of the stateless transactions of ESB, high performance is a prerequisite. In large organizations, it is not uncommon for an ESB to process millions of messages per day.

Advantages of ESB

One of the main advantages of ESB is to process messages. Message transmission and transmission may use protocol or format mediation. When these requirements clearly need to process messages, using ESB can provide many advantages, including the ability to process more complex transactions in conversions. When these requirements require the use of basic ESB functions (such as message routing, conversion, or Protocol mediation), the ESB is the best choice.

Another advantage of ESB is performance. The ESB can process a large amount of messages on schedule. For example, if you want to process 200,000 messages a day, the ESB is obviously a good choice.

If the requirement is data-centric, You must select ESB.

Questions to consider

As far as our project is concerned, there is no legacy system, and boundaries and messages between all subsystems can be redefined and designed (there are many unreasonable aspects in the original design ). First, you can reduce the number of subsystems by means of data integration and business re-division. Second, the problem of integration between subsystems is solved by standardizing the information definitions exchanged between subsystems. There is no need to use ESB at all, which is a typical overdesign.