Insights into Enterprise Service Bus (ESB)

Why Enterprise Service Bus (ESB)

Let’s take the case of a hypothetical scenario where one single application (App A) is used to control the business. As the business expands, ‘App A’ might be required to be scaled up or a new Application ‘App B’ that provides a solution to particular business problems needs to be developed. As there are only two apps, communication should not be an issue.

As more applications (or software blocks) are added; component integration becomes challenging, and scaling up becomes difficult as it will involve massive customizations to a number of applications.

To summarize, integrating heterogeneous systems by following the above approach is neither scalable nor maintainable. This is where Enterprise Service Bus (ESB), architecture (or a middleware tool) that provides the distribution of work between different connected components in an application can be used.

What is Enterprise Service Bus (ESB)

Enterprise Service Bus, ESB is an architecture that provides heterogeneous integration of applications and business services in an enterprise. It also provides messaging communication, transformation and routing to different complex applications.

Instead of communicating point to point, applications connect independently and messages can be routed to any application based on the routing criteria. Applications can accept or exchange messages with different transport protocols. Different connectors (or adapters) can be easily plugged in as there is loose coupling between the different application components.

Importance of Enterprise Service Bus (ESB)

Below are some of the primary reasons why ESB is important:

• Reduces the effort spent in the maintenance of applications as addition or removal of components (or modules) in ESB is easy.
• Applications can talk to each other using a standard protocol as ESB acts as a service layer between those applications.
• If the primary service provider is not able to process the incoming request (or is not available), an alternate service provider is called. Switch back to the primary service provider is done once it is available. This is termed as dynamic failover.

When do you need an Enterprise Service Bus (ESB)

Enterprise Service Bus (ESB) may not be required in projects where there are fewer modules (or integrated applications) e.g. less than four in number and a common protocol is used for data exchange between the applications. It is also not required in scenarios where a data exchange and messaging communication is done through a standardized mechanism such as web services.

This is not a thumb rule but also depends on the volume of data that is exchanged between different applications. ESB is ideally used for the integration of heterogeneous applications and might not be required for a homogeneous or lightweight integration ecosystem.

Decoupling applications, Messages Routing, transformation, enrichment, orchestration, integration (simple and complex), and security are some of the important features of ESB.

Core functionalities of Enterprise Service Bus (ESB)

Below are some of the primary duties of ESB:

• Message Transformation – If messages exchanged between different components in the application are of different formats (e.g. XML, JSON, etc.) or if different technologies are used for communication between different applications, then message transformation is required. Message transformation is done by the ESB so that a standardized format of messaging is used across different applications.
• Message Enhancement – ESB lets you add or modify the information within a message as per the requirements of the service provider. An example of message enhancement is adding date, time, or any other field to the message.
• Protocol Transformation – Messages in ESB are sent using a common standard protocol.
• Application (or Service) orchestration – ESB provides a layer of abstraction at the software infrastructure level. Every service provider in the enterprise application interacts with ESB which is the single point (or port) of connectivity.

Consumers of the services on the bus need not know the underlying implementation and deployment details of the requested service. ESB also abstracts the business services (or business logic) from the low-level implementation of the services.

• Message Routing (or Processing) – ESB is responsible for routing the client request to the appropriate service provider based on the routing criteria
• Decoupled applications – One of the core benefits of ESB is totally decoupled architecture. As there is loose coupling between different applications (or systems), any change in the platform or technology requires minimal change as the clients are decoupled from the service providers.
• Security – The services in ESB are protected from any unauthorized access. Security server is an integral part of the ESB architecture as it provides services for encryption, message validation, security-token management, and other aspects related to the security of the services.
• Message Throttling – ESB ensures that messages of high priority are always processed first so that that there is no delay in processing them.
• Load Balancing – Static routing in ESB can lead to low throughput on the service side and low satisfaction on the consumer service as a particular request is sent to the same service irrespective of the service status.

  With load balancing, multiple service endpoints are listed for every endpoint of a logical service provider. Redundant service implementations are called alternately for every incoming request depending on the message priority or load dependency.

• Endpoint Failover – If the primary service provider is not available (or unable to process the request), the request is sent to an alternate service provider for processing.

Popular ESB Implementations

There are many popular open-source, as well as, commercial ESB products to choose from.