In this guide, learn more about the ESB (an essential component of SOA), the benefits it offers, and how it relates to microservices architecture.
What is an ESB (enterprise service bus)?
An ESB, or enterprise service bus, is a pattern whereby a centralized software component 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. The ESB pattern is typically implemented using a specially designed integration runtime and toolset that ensure the best possible productivity.
ESB and SOA
An ESB is an essential component of SOA, or service-oriented architecture, an architecture that emerged in the late 1990s. SOA defines a way to make software components reusable via service interfaces. These interfaces utilize common communication standards in such a way that they can be rapidly incorporated into new applications without having to perform deep integration each time.
Each service in an SOA embodies the code and data integrations required to execute a complete, discrete business function (e.g. checking a customer’s credit, calculating a monthly loan payment, or processing a mortgage application). The service interfaces provide loose coupling, meaning they can be called with little or no knowledge of how the integration is implemented underneath. The services are exposed using standard network protocols—such as SOAP (simple object access protocol)/HTTP or JSON/HTTP—to send requests to read or change data. The services are published in a way that enables developers to quickly find them and reuse them to assemble new applications.
These services can be built from scratch but are often created by exposing functions from legacy systems of record as service interfaces. This is where the need for an ESB arises. Legacy systems and systems of record typically use old protocols and proprietary data formats that need to be translated and integrated to work with the SOA network protocols. An ESB performs these translations and integrations on the fly. You could implement an SOA without an ESB, but application owners would each have to find their own unique way to expose service interfaces, which is a lot of work (even if the interfaces are eventually reusable) and creates a significant maintenance challenge in the future.
To learn more about SOA and the role of an ESB within it, see “Introduction to SOA (Service-Oriented Architecture).”
In theory, a centralized ESB offers the potential to standardize—and dramatically simplify—communication and integration of services across the enterprise. Hardware and software costs can be shared, provisioning the servers need only be performed once, and a single team of specialists can be tasked (and, if necessary, trained) to develop and maintain the integrations.
Developers can use a single protocol to ‘talk’ to the ESB and issue commands that direct interactions between services and leave it to the ESB to translate the commands, route the messages, and transform the data as required to get the commands executed. This would enable developers to spend dramatically less time integrating and much more time configuring and improving their applications. And the ability to reuse these integrations from one project to the next offered the potential for still greater productivity gains and savings downstream.
But while ESBs were deployed successfully in many organizations, in many other organizations the ESB came to be seen as the bottleneck in the SOA deployment. Making changes or enhancements to one integration often destabilized others. Updates to the ESB middleware often impacted existing integrations. Because the ESB was centrally managed, applications teams soon found themselves waiting in line for their integrations. As the volume of integrations grew, implementing high availability and disaster recovery for the ESB servers became more costly. And as a cross-enterprise project, the ESB proved difficult to fund, making these technical challenges that much more difficult to resolve.
Ultimately the challenges of maintaining, updating, and scaling a centralized ESB proved so overwhelming and expensive that the ESB often delayed the very productivity gains that it, and the SOA, were intended to yield, frustrating line of business teams who anticipated a greater pace of innovation.
For a deeper dive into the rise and fall of the ESB, read “The fate of the ESB.”
ESB vs. microservices
Microservices architecture enables the internals of a single application to be broken up into small pieces that can be independently changed, scaled, and administered. Microservices emerged and gained steam with the rise of virtualization, cloud computing, Agile development practices, and DevOps. In these contexts, microservices offer the following:
- Improved developer agility and productivity by enabling developers to incorporate new technologies into one part of an application without touching or ‘catching up’ the rest of the application.
- Simpler, more cost-effective scalability by enabling any component to be scaled independently of others, for the fastest possible response to workload demands and the most efficient use of computing resources.
- Greater resilience, because the failure of one component does not impact the others, and each microservice can perform to its own availability requirements without staking the other components to a ‘greatest common availability’ requirement.
The same granularity that microservices bring to application design can be brought to integration, with similar benefits. This is the idea behind agile integration, which breaks up the ESB into fine-grained, decentralized integration components, without interdependencies, that individual application teams can own and manage themselves.
For a deeper dive into all things microservices, check out “Microservices: A Complete Guide,” "SOA vs. Microservices: What's the difference?" and watch Dan Bettinger’s video, “What are Microservices?”:
ESB and IBM Cloud
As your company shifts its IT infrastructure toward a hybrid cloud approach, there’s a high likelihood you’ll be transforming a variety of workloads, including those based on SOA and ESB patterns, to more lightweight and flexible deployment models. Such transformations are just one part of application modernization on any organization’s journey to cloud.
Take the next step:
- See how you can leverage, extend, and modernize your middleware investments with the IBM Cloud Pak for Integration.
- Learn how you can connect all your applications and data across multiple private and public clouds for personalized customer experiences by visiting IBM Cloud Integration.
Get started with an IBM Cloud account today.