Comparison of Popular ESB Solutions on the Russian Market

The winner in the business competition is the one who can quickly scale and implement partner projects, as well as invest as little as possible in the expansion. The traditional approach to integrations is diametrically opposed to these priorities. The timing and cost of implementation are unclear, the outcomes are unpredictable and instead of expected advantages there is absolute uncertainty.

The low-code paradigm is much closer to business priorities. Software that works in this paradigm allows speeding up the development and implementation of new systems, integrations and features in times.

One of the products operating in the low-code paradigm is the ESB system (stands for "enterprise service bus"). ESB is a software suite that works as a single hub for the exchange of messages between information systems and applications. The service bus allows you to easily configure the message routing, stores the messages history, and maintains the message tracking log.

ESB does not require complex and lengthy development every time you need to connect systems that are not originally designed for the joint operation. Moreover, most of the work is performed with the visual development tools. During the integration, the main focus is on the business analysis rather than on technical aspects of this integration.

ESB is not a monolithic system, but a layer in the company's IT infrastructure that consists of several products. Each product takes over one or several functions of the service bus. In this article, we will decompose the ESB layer by functions and tell you how these functions are implemented in popular products.

ESB can be roughly divided into five components or functions: studio, message broker, logging, monitoring, hosting.

Studio is a graphical environment for developing fast integrations. The systems, parameters, and actions are visualized and made as transparent as possible. The studio's functionality is sufficient to implement most of the actions, such as transmitting and receiving information, converting and collecting attributes across data flows. Here you can also set the parameters that the ESB bus should monitor or consider an error of integration etc. If a unique action is required as part of the integration, you can write it with a couple of lines in a traditional (for example, Java) or a specific language.

Without the Studio and, accordingly, without the visualization of integrations, ESB cannot be considered a low-code solution.

A message broker is used to exchange messages between systems . This is an active component that "takes" and "gives" messages, observes the message sequence and levels the load on the systems that generate or receive messages (the so-called producer and consumer). Developers often make a mistake as they call a sole message broker, for example, Apache Kafka or RabbitMQ, an ESB system.

Logging is the practice of recording events that occur to a message. Which system it is generated by, how it is processed, where it finally goes (or does not go). Logging provides a clear understanding of whether a message flows through the set route and at what stage and for what reason the problem has occurred.

Important events that occur to messages and queues must be monitored and processed in time by way of responding to them. The monitoring component allows selecting the events that need a response and reporting them to the technical support.

Each ESB solution has several placement options to choose from. For example, some systems provide a possibility of publishing integrations in a private Kubernetes, OpenShift, or Amazon cloud without any configuration at all. An architect's help is required for publications within a unique cluster of yours.

In this article, we will analyze how ESB components are implemented in the most wide-spread solutions on the Russian market: Talend, Mule, WSO2, Red Hat Fuse. Sometimes developers also add Apache Kafka (plus Kafka Connect) and RabbitMQ message brokers to the list, but these two solutions are not the ESB and it's quite impractical to include them in the present analysis.

+ – Studio is included as the out-of-box feature.

± — Studio is available, but it's more difficult to configure and requires constant developers engagement, which goes against the low-code paradigm.

None of the systems has internal message brokers. Nevertheless, the out-of-box software provides the connectors supporting a simple integration of external message brokers. The connectors are systematized and included in the manuals.

As you can see, the internal logging procedure for various ESB systems is almost identical – with minor specific features in case of each product.

In addition to that, there is an option of logging in external systems that are connected via connectors. A business analyst must record the key events within the integration framework so that the messages about these events get into the log records.

Logging in an external system allows for greater ESB flexibility. Most likely, an enterprise-scale business already has a logging component in its IT architecture, and the systems' functions will not duplicate each other.

Event monitoring is carried out in external systems via a universal component. the monitoring system can be selected based on the operation department preferences: it can be Checkmk, Prometheus, Zabbix, etc. The business, together with the developers, needs to create a manual describing the metrics that are to be monitored, acceptable and unacceptable deviations, as well as the necessary corrective actions in case of emergency.

Talend, Mule, WSO2 allow solving problems of the integrations development speed and conform to the low-code principles.

Red Hat Fuse features are similar to the above three products, but it cannot be considered a low-code solution. With Red Hat Fuse you need a developer even for standard operations. However, it follows the self-documentability principle.

Apache Kafka and RabbitMQ are not ESB systems as such, but message brokers. They cannot form a substantial ESB layer by themselves and they do not provide any advantages in terms of simplifying integrations and scaling, but they can become part of the ESB layer.

It is clear that each implementation case is individual and is performed with regard to the business, product, and IT strategy specifics. But if you compare all the solutions available, it's the low-code that allows the fastest digital transformation, scaling, and partner integration. Therefore, we recommend low-code solutions, such as ESB, BPMS, CRM, to companies that are interested in rapid business growth accompanied by the optimization of development costs.

Also, we should emphasize that the low-code ESB implementation is not instantaneous. Like any large-scale integration, it takes time and resources, including, for example, costs for the development team, for servers (if necessary) etc. In this respect the low-code solutions are no different from the usual ones. The savings on the development are possible no sooner than they're implemented.