Comparison of ESB solutions popular on the CIS market

Part 2: System Characteristics 27.9.2021

We examine the functionality and interfaces of ESB systems popular in the CIS market:

• Talend
• Mule
• Red Hat Fuse
• WSO2

Why an ESB in a Project: the Technical Side of the Question ESB Buses: a Brief Overview of Capabilities, Pros, and Cons Talend Mule Red Hat Fuse WSO2 Summary: How to Choose an ESB System for Your Project

Now let's take a closer look at what each of these systems is, what their interfaces look like, and what their inherent pros and cons are for integration development and support. In addition, we will share our own impressions from implementing each of these systems.

One of the most common objections to using an ESB layer in a company or project architecture is that independent systems can be connected without intermediaries.

It is enough to develop an integration module in one of these systems or use an API, for example.

Let's look at these options in more detail.

The first option is an integration module within one of the systems.

As a rule, its development is delegated to the team that is directly responsible for developing that system.

For such a team, integration development is not a core task and comes with risks, such as introducing hard-to-detect integration errors, spending much more time than planned, or making architectural mistakes.

In addition, the development team will need to build wrappers around the system to monitor integration health. That is a difficult and substantial task.

You need not only to develop an integration that works without failures, but also to give the support team clear procedures for handling the failures that may still occur. And even if the integration works here and now, there is no guarantee that it will work tomorrow. Nor is there any guarantee that the development team will learn about a broken integration before the customer comes to them with a complaint: "My data exchange is not working."

The second option is to transfer data through an API interface or, for example, GraphQL.

There is a nuance here: the API that the system uses to exchange data with the outside world is passive.

A system can only respond to requests by sending data outward or changing it at the initiative of another system. As a result, the two systems being integrated will wait for each other's initiative to transfer information (with API, this is unavoidable).

For the transfer to take place, a third player must be introduced: an active system, i.e. in effect a data bus (ESB). In the ideal case, this setup should be supplemented with webhooks in the master system, that is, the system serving as the data source.

They will trigger data change requests in the target systems as soon as the data changes in the master system.

Perhaps because Talend was a pioneer in its field, it still has a more archaic interface than other buses today.

includes a fairly complex mechanism for creating subroutines.

If you want to split off a part of a job (a small program that performs a specific task) and turn it into a subroutine that you can call from several places in the main job, you will need to spend a lot of time learning the studio, especially if a business analyst with limited programming knowledge (a so-called citizen developer) will work with the system. Git is not included in the free version of Talend, but you can connect it yourself.

The project structure in the system makes things more difficult: a project consists of atomic jobs that are not visually connected to each other, instead of a file tree. Git is built into the paid version, but it runs in the background, so you do not control it.

It is also worth noting that working with Git in the paid version essentially means every change is committed automatically.

The same job cannot be edited from two computers at the same time, only opened read-only.

Add to that the not-so-simple mechanism for creating custom components, and you get a system that is fairly difficult for users, with a high entry barrier to development itself.

At the level of data transfer lines between elements, Talend offers flexible configuration.

This looks like an advantage, but in practice it is also the system's drawback. A business analyst will find it difficult to understand object transformations.

The logic of how lines work is not obvious: to understand the program's behavior, you have to take into account the asynchronous operation of those very lines.

The product is now owned by Salesforce.

The first references to it can be found around 2006: that was when

Mason gained popularity, and he founded MuleSource (MuleSoft since 2009), headquartered in San Francisco.

The product name is explained as follows: Mule, which translates from English as "mule," does the "donkey work" for developers (from the English donkey work).

That is exactly what developers do when they write code for system integration.

Anypoint Platform helps developers by enabling fast setup of interactions between various applications, data, and devices using API. In March 2018, Salesforce bought MuleSoft for $6.5 billion, which was the company's most expensive acquisition at the time

The interface is built on Eclipse and has intuitive elements and components.

Many components that are installed by default during job assembly do not need adjustment.

Anypoint Studio makes it easy and efficient to monitor all APIs in orchestration by key parameters and metrics:

• the initial design of the future API
• access control
• logging
• server statistics

Anypoint Exchange lets you maintain a catalog, search for various artifacts (API, code snippets, templates, examples, connectors, etc.), and share them.

All of these artifacts can be made available publicly or within the organization.

Cloud services are sufficient for creating integrations.

The ESB concept implies deploying the entire infrastructure from scratch on your own servers.

However, many companies today use cloud services.

You can build your infrastructure with iPaaS much faster and better than developing it from scratch.

The entire project can be viewed at the file level, which makes it possible to use Git to manage project changes.

The free Mule trial is valid for 30 days.

If you plan to continue using the bus, you need to purchase a license during this time,

License cost is calculated individually.