Enterprise Service Bus (ESB), once an acclaimed solution to the complexity of the Service Oriented Architecture protocol. But are the days of centralizing the integration of applications numbered? And will the rise of API Gateways and Microservices be sufficient to handle all possible use cases for enterprise integrations? Let’s take a look at API Gateway vs ESB.
What is an API Gateway and what is ESB?
What is an API Gateway?
An API Gateway is a server that handles the requests coming for APIs (Application Programming Interface). An API Gateway is a proxy provided for the client. API Gateway gives the client a consistent interface regardless of any changes within the internal system. It allows the internal system to change without affecting the client. The API Gateway can also provide consistent cross-cutting concerns such as security logging, reporting and API analytics
What is an ESB?
Like an API Gateway, an ESB (Enterprise Service Bus) is an approach to connecting services. It’s an architectural pattern whereby a centralized software component performs integrations between applications. It transforms data models, handles connectivity, performs message routing, and converts communication protocols. an ESB provides a means for service-to-service communication.
What functionalities do API Gateways and ESBs have?
When comparing ESB vs API Gateway it’s important to look at both their functionalities. And in particular what they both do well, in order to figure out where they differ from each other. Here we explain the functionalities apparent in both API Gateways and ESBs.
Routing
What is routing? An incoming request will be read by your server and distributed to the designated API based on the given parameter at URL level.
Authentication
What is authentication? Authentication discerns whether a user or a particular system is valid to be accepted.
Authorization
What is authorization? The functionality of authorization is concerned with whether a particular system or a user is allowed to perform a particular operation. For example a certain user belongs to a certain group. And only that group is authorized to create or update data.
Policy Management
What is Policy Management? Policy Management defines how a web service should be accessed. And furthermore which parts of a web service should be accessed and in which way by the user.
Payload Transform
What is Payload Transform? Messages come into your server in all different sizes and formats. Payload is basically the container format of the message. So Payload Transform is concerned with converting the format of the incoming message so that it matches with whatever your web service can read. For example, a request comes in on your API Gateway or ESB in an XML format and your web service is based on JSON format. As soon as the request comes in, your API Gateway or ESB transforms that XML message into a JSON format.
Common Protocol
What is Common Protocol? Common Protocol means the communication between different heterogeneous systems as well as homogenous systems. So the Common Protocol could be that all systems are for instance in HTTP, TFTP, or SMTP.
Validation & Enrichment of Payload
What is Validation and Enrichment of Payload? Let’s first look at validation of payload. There are two kinds of validations happening: 1. Format Validation and 2. Content validation. Format validation discovers whether the request structure is right or wrong as defined by the Policy Management. Content Validation means whether the format contains valid value, or not. Both kinds of validation you can do at API Gateway level, as well as ESB. The term Enrichment means that when a request comes in you are able to add additional value, maybe in the body, maybe in the header section.
| Functionality | API | ESB |
| Routing | ✓ | ✓ |
| Authentication | ✓ | ✓ |
| Authorization | ✓ | ✓ |
| Policy Management | ✓ | ✓ |
| Payload Transform | ✓ | ✓ |
| Common Protocol | ✓ | ✓ |
| Validation & Enrichment of Payload | ✓ | ✓ |
When to use ESB and when to use API Gateway?
Looking at the table above, you could argue that they both execute the same functionalities of handling integrations. Therefore, why change to a more modern approach with API Gateways?
The last three functionalities – Payload Transform, Common Protocol, and Validation & Enrichment of Payload – are mostly concerned with change of the Business Logic. Business Logic is the set of custom rules or algorithms that handle the exchange of information between a database and user interface. These are much more suited to a centralized component (ESB) as opposed to an API Gateway.
Why should you not put Business Logic in the API Gateway? The moment you add business logic to the gateway, it starts acting as an ESB. Meaning centralized data aggregation and business transformation that require manually written code to be deployed in the gateway. Each piece of code incurs CPU cycles. Therefore impacting performance, puts stress on cross-team communication, and brings additional maintenance and support issues.
On the other hand, there are a number of drawbacks with an ESB. It is heavy in terms of resource utilization. It’s not as fast or as scalable – especially when using Microservices. And the main issue is that ESBs have a single point of failure (SPOF), so you need multiple ESBs adding complexity and infrastructure. That ultimately results in bigger teams and rising costs.
So when comparing API Gateway vs ESB, ideally you want to lead with an API Gateway, but that doesn’t allow for utilizing the full functionalities of the server. Or would there be another solution?
Concluding: ESB, API Gateway or a combination for your integration solution?
The easy route would be to think that a combination of ESB and API Gateway is the way forward. Doing the routing, authorization, authentication and policy management in the API Gateway and the remaining three on the ESB. Except, you would then (partly) have to build a centralized architecture, but Microservices and APIs prefer to run in distributed architectures.
The solution? You can create a microservice as Smart Endpoint, mimicking the functionality of an ESB and utilizing the tasks of Payload Transform, Common Protocol, and Validation & Enrichment of Payload. You can then have the Business Logic in that smart endpoint. In this particular architecture setup you’re looking at two different kinds of microservice: Composite Microservice and Base Microservice. The composite microservice acts as the ESB and the base microservice does what microservices are supposed to do. Your setup then has all the functionalities that you require of a server and because it’s within an API Gateway you will be fully prepared for an API-first digital transformation.
If you want to learn more about API Gateways and what the right setup for your enterprise is: Get in touch with our team. And find out how Yenlo’s integration-Platform-as-a-Service ‘Connext Platform’ and Integration-as-a-Service solution ‘Connext Go!’ can help you lead the way in your industry.
Yenlo is the leading, global, multi-technology integration specialist in the field of API-management, Integration technology and Identity Management. Known for our strong focus on best-of-breed hybrid and cloud-based iPaaS technologies. Yenlo is the product leader and multi-award winner in WSO2, Boomi, MuleSoft and Microsoft Azure technologies and offers best-of-breed solutions from multiple leading integration vendors.
