What is ESB?

Where does ESB stand for? It is an abbreviation for Enterprise Service Bus

ESB in the architectural concept context

SOA (Service-Oriented Architecture) is an architectural style, created in the ‘90s, where communication is done through services. This concept was implemented in various products called ESB’s. ESB is a central way to configure and run these services.
Normally, an application calls one of these services, for example to get some data. The services then call other services or applications and return a reply to the original caller.

How does ESB work

ESB, the integration product based on the SOA architectural concept

Enterprise Service Bus – or ESB – is an architectural software construction (pattern) product that simplifies the communication between the user of services and the service providers. A centralised Bus performs integrations to backend systems and translations of data models, deep connectivity, routing and requests and makes those integrations and translations available as service interfaces for reuse by new applications.

ESB is a solution for connecting multiple endpoints without having to create a lot of custom code for integration and communication purposes.

It is possible for the user of a service to communicate with the ESB very differently than how the it communicates with the provider. The ESB translates the message to the right format and sends it to the right recipient.

What is the position of an ESB product in your application landscape?

ESB is a communication system between mutually interacting software applications in a service-oriented architecture – SOA. The SOA is aimed to make software components reusable via service interfaces. These interfaces can be rapidly incorporated into new applications thanks to the common communication standards they use.
If your system is a SOA, an architecture that started emerging in the ‘90s, the ESB is a logical product to enable the desired communication and translations.

ESB supports communication with legacy systems and systems of record (systems with proprietary data formats). These systems generally use old protocols and/or proprietary data formats that need translation and integration to be used in the SOA.
If a developer would have to write something for each application, that would be a lot of work and create a maintenance challenge for the future.

What are the advantages?

What are the disadvantages?

Why use an ESB?

An ESB provides a great solution for integration challenges on an enterprise level. Thanks to the ‘Bus’, different applications can communicate with each other, providing the user with the desired experience within the application or service they use. ESB is generally seen as an architecture and not simply a product you implement. And, when you are in search of a more agile and scalable solution, you should probably look towards other solutions.

What is the value of ESB today?

ESB originated from hub and spoke integration, based on the centralised repository but with more evolved communication and translation capabilities. Since the introduction from ESB we have seen Middleware and Microservices resolve integration issues in on premise landscapes. With the rise of cloud solutions we see that ESB and EAI (Enterprise Application Integration) come together in what we call iPaaS; integration Platform as a Service. And evolution still continues.

On the side

Is ESB the same as Integration Runtime?

Over time people started using the terms Integration Runtime and ESB as one and the same. However there is – or used to be – a difference. The ESB pattern often includes both integration runtime and the exposure gateway and in some cases solely the gateway.

What is enterprise service bus in the cloud?

ESB in the cloud as such does not exist. However, people refer to iPaaS solutions as ESB in the cloud. There are also products available that can be used both on-premise and in the cloud.

Is Dovetail an ESB?

We prefer to call Dovetail a no code/low code integration Platform as a Service – iPaaS. Dovetail is a platform that supports your data flow integrations. It is cloud based and you interact with it through no code/low code depending on your skill set or the complexity of the integration you are building. Learn more about the Dovetail Product here.

Related resources

Automated processing of all sales order related flows

As a sales organisation, you aim for a streamli...

Challenges with entering data in multiple systems

What challenges or pain points do you face? And...

The impact of human error rates in manual data entry across multiple systems

How does human error in data entry effect your ...

Digitising document flow

How can you digitise your document flow when PD...