What is Enterprise Service Bus (ESB)? – Rapid Blog

Integration. That’s one big chore that keeps the IT and application development teams busy throughout the day. In a growing enterprise, new business requirements and increasing reliance on third-party systems are a standard norm. Therefore, integrating different systems and applications is a never-ending challenge for these teams. Enterprise Service Bus (ESB) represents one of the earlier approaches devised to solve this problem. 

This blog post is a short treatise on the concept of ESB, covering its motivations, applications, use cases, and its pros and cons.  

What is an Enterprise Service Bus (ESB)?

Several architectural patterns have emerged over the last few decades to ease the pain of integrating disparate systems within an enterprise. Client-Server Architecture (CSA) was one of the earliest approaches. It was simple but lacked scalability. It was followed by Service Oriented Architecture (SOA), which split the business logic into well-defined, cooperating services.  ESB was conceived as a middleware layer within SOA for facilitating this cooperation.

The design of ESB mimics a hardware bus in computer hardware architecture that acts as a communication bridge between multiple peripheral devices. To put things into perspective, ESB serves as a stable communications bus between services. It is not a standard or a tangible product but an architectural and communication pattern. It provides a conceptual blueprint with a set of guidelines for orchestration and mediation between software components representing business services by ensuring adequate de-coupling.

Use Cases of ESB

ESB was envisaged as an internal component of SOA. Therefore for the end-user, it is an invisible black box. The only personas that interact with ESB are the application developers and IT engineers.

Application developers are responsible for defining the interfaces of the services that they develop. These interfaces become the service access points for other services to communicate with them via the ESB. The IT engineers are responsible for deploying, maintaining, and monitoring the ESB infrastructure to ensure peak performance with the growing number of services attached to it.

If you look at an IT deployment of a small company with a handful of services and applications, a client-server or peer-to-peer communication model serves the purpose. However, in a large enterprise, things get too complex too soon. ESB’s virtues come to the fore in such occasions to handle complexities related to:

1. Integrating multiple services:

   When multiple services on an application are integrated, there is a high dependency. Mirroring that dependence at a code implementation level leads to severe problems, such as entanglement of business logic or spaghetti code. ESB solves this problem by streamlining the integrations, providing reliable, secure, and often instant connections.

2. Integration with external services

   : Where there is a requirement for interfacing with an external service, ESB provides a reliable connection while managing and controlling service level commitments to minimize the impact of adjustments to your service agreements. 

3. Protocol and message transformations

   : 

   ESBs are especially good at transforming multiple protocols into one, such as FTP and HTTP into SOAP or weaving together SMTP, IIOP, MQ/JMS. Similarly, message transformation is one of the most important features of an ESB. It is used to convert messages from one format to another using standards such as XPath and XSLT.

4. Integrating legacy applications

   : ESBs are useful in integrating legacy applications. They include a variety of pre-built adapters to integrate legacy applications with modern apps and services.

Alternatives to ESB and Completing Technologies

The challenges of providing seamless communication between two or more applications are not new. Many standards have been proposed, and proprietary applications and protocols built over the years. The evolution of ESB aligns with the SOA-based enterprise application deployment trends that go back nearly to the dawn of the World Wide Web. Therefore it predates the current cloud era technologies.

While EBS may be perceived as outdated, it is still relevant to IT integration and digital transformation. However, with the advent of newer generation technologies, it is essential to draw parallels to clarify the virtues and limitations of ESB.

ESB vs. Service Mesh – Service mesh is more relevant to the current trend in microservices architecture (MSA), which uses containers to define more fine-grained service orchestration using cloud-native technologies. At a high level, ESB achieves the same functions as a service mesh. However, it was predominantly built as a monolithic set of application components. Over the last few years, hybrid models of deployment have emerged that leverage the cloud. Therefore the lines between ESB and service mesh are now blurred. 

ESB vs. Integration Platform as a Service (iPaaS): iPaaS is a suite of cloud services enabling development, execution, and governance of integration flows connecting any combination of on-premises and cloud-based processes, services, applications, and data within individual or across multiple organizations. It is a platform for building and deploying integrations within the cloud and between the cloud and enterprise. Functionally both ESB and iPaaS offer the same solution. iPaaS is less expensive and more flexible to scale compared to monolithic ESB. ESB is preferred in some scenarios, such as supporting the legacy, process-heavy software systems that underpin the safe management of sensitive company data.

ESB vs. Pub/Sub: Pub/Sub is a generic concept. It is an abstract communication pattern for building Internet-scale applications that need a de-coupled messaging middleware. It can be considered a subsystem of ESB since ESB also needs a de-coupled messaging layer between services. However, Pub/Sub is a theoretical notion, unlike ESB.

ESB vs. Apache Kafka – Apache Kafka is a real product. Originally conceived within Linkedin, it has garnered immense popularity in the past decade due to its unique ways of handling inter-system messaging with scale. You can consider Apache Kafka as a real-world implementation of the abstract Pub/Sub pattern. Compared to ESB, Apache Kafka has a smaller scope of responsibility limited to message exchange only.

ESB vs. ETL: ETL (Extract, Transform, Load) is a data pipeline primarily used as part of data pre-preprocessing stages of a machine learning model execution.  It is mostly a linear process where data is fed from one side and retrieved from the other. Therefore it is an entirely different concept than ESB. 

Components of ESB

Due to the lack of any standardization, a uniform architecture of ESB is not available. Different vendors have their ways of segregating an ESB system into its subsystems. Therefore, it isn’t easy to piece together a standard set of components to present a consistent architecture across vendors.

Considering the capabilities envisaged by the proponents of SOA, the following are the critical components of ESB.

1. Broker

   : Like any orchestration layer, ESB follows a hub and spoke model of communication. A central component acts as a hub. The spokes comprise of service producers and consumers. Depending upon the scalability requirements, a multi-tiered hub model is also possible. However, note that this is merely a logical hierarchy of communication. It is not the same as a star topology where multiple spokes connect to a central hub physically. The main function of the broker is to manage subscriptions and message routing between participating services.

2. Messaging Service

   :

   ESB relies on a messaging system. It transports the published messages and works by emulating a hardware bus in the form of a queue. The messaging component creates multiple incoming and outgoing queues and follows a polling mechanism to exchange messages across the queues to pass them around until they reach their destined endpoint.

    

3. Mediator

   :

   ESB is designed to interoperate with multiple services, including in-house and third-party applications. Therefore, ensuring the sanctity of all the participating services is of paramount importance. The mediation component achieves this via a set of pre-defined checks to authenticate and authorize the services and service subscriptions. Multiple mediator components may be present within an ESB to handle additional audit responsibilities and manage the overall security aspects of ESB. 

    

4. Adapter

   :

   As described earlier, protocol and message transformation are key requirements for ESB to interface with external services. Adaptors provide this functionality. Multiple software-based adaptor components perform specific functions, such as message format transformation to and from ESB, using a consistent format, such as XML.

The future of ESB 

Being a part of the older generation technologies, ESB’s role has largely been superseded by newer architectural frameworks. However, legacy applications are running on the SOA model, where ESB still serves well. As long as these applications do not undergo a tech refresh, ESB will play a key role.

While it is fair to say that ESB will witness a sunset in the coming years, its influence in shaping the newer architectural models for distributed computing cannot be ignored. The concepts and mechanisms proposed as part of ESB for handling inter-service communication continue to hold good in the present cloud era. Therefore, it won’t be wrong to say that current generation concepts such as service mesh and iPaaS are standing on the shoulders of a giant named ESB.

What is Enterprise Service Bus?

An enterprise service bus is a software middleware used to orchestrate the interactions between multiple services. It was initially conceived as a component within Service Oriented Architecture (SOA) which splits an application into well-defined services.

How does Enterprise Service Bus work?

Enterprise service bus has an internal subsystem comprising of one or more brokers, a messaging server, and a group of mediators and adapters. The broker is the primary subsystem responsible for orchestration and routing. Messaging server performs the function of message transporting. Mediators take care of service authentication and authorization. Finally, adapters perform the job of protocol and message transformation.

Is Enterprise Service Bus dead?

Enterprise service bus is mostly considered a legacy technology since it was part of SOA. The world has moved away from SOA into a more modern interpretation built atop microservices with finer-grained services hosted on containers. However, enterprise service bus is still used for supporting legacy applications and will continue to serve for the next few years.

4/5 – (2 votes)