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.
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?
- Provides the opportunity to integrate applications on an enterprise level
- It is a way to single-source data
- Hardware and software costs can be shared
- A single team of specialists can be tasked with development and maintenance of the integrations
- Developers can use a single protocol to ‘talk’ to the ESB and leave it to the ESB to translate the commands, route the messages and transform data as required
- Developers would have to spend less time integrating and can spend more time on configuring and improving their applications
What are the disadvantages?
- Some organisations found ESB to be the bottleneck in the deployment of their SOA
- Making amendments to the one integration can destabilise others
- Updates to the ESB middleware can impact existing integrations
- When the ESB was centrally managed, application teams soon experienced cues for the implementation of their integrations
- As the number of integrations expand, they require more of the ESB servers, and costs expand as well
- An ESB is generally hosted on-premise which could interfere with the scalability in relation to cloud applications and the longevity of the ESB
- Since the invention of SOA and it’s ESB many developments have taken place towards other types of architectures and applications, some people therefore feel that ESB is somewhat old fashioned
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.
