ESB stands for Enterprise Service Bus which is basically a middleware tool for integrating various applications together over a bus-like infrastructure. Fundamentally, it is an architecture designed to provide a uniform means of moving work among integrated applications. In this way, with the help of ESB architecture we can connect different applications through a communication bus and enable them to communicate without depending on one another.

Implementing ESB

The main focus of ESB architecture is to decouple the systems from each other and allow them to communicate in a steady and controllable way. ESB’s implementation can be done with the help of ‘Bus’ and ‘Adapter’ in the following way −

• The concept of “bus”, which is achieved through a messaging server like JMS or AMQP, is used to decouple different applications from one another.

• The concept of “adapter”, responsible for communicating with backend application and transforming data from application format to bus format, is used between applications and bus.

The data or message passing from one application to another through the bus is in a canonical format which means there would be one consistent message format.

The adapter can also perform other activities like security, monitoring, error handling and message routing management.

ESB’s Guiding Principles

We can call these principles as core integration principles. They are as follows −

• Orchestration − Integration of two or more services to achieve synchronization between data and process.

• Transformation − Transforming data from canonical format to application specific format.

• Transportation − Handling protocol negotiation between formats like FTP, HTTP, JMS, etc.

• Mediation − Providing multiple interfaces to support multiple versions of a service.

• Non-functional consistency − Providing mechanism for managing transactions and security also.

Need of ESB

ESB architecture enables us to integrate different applications where each application can communicate through it. Following are some guidelines on when to use ESB −

• Integrating two or more applications − Use of ESB architecture is beneficial when there is a need to integrate two or more services or applications.

• Integration of more applications in future − Suppose if we want to add more services or applications in future, then it can be easily done with the help of ESB architecture.

• Using multiple protocols − In case if we need to use multiple protocols like HTTP, FTP, JMS etc., ESB is the right option.

• Message routing − We can use ESB in case if we require message routing based on message content and other similar parameters.

• Composition and consumption − ESB can be used if we need to publish services for composition and consumption.

P2P integration vs. ESB integration

With the increase in number of applications, a big question in front of developers was how to connect different applications? The situation was handled by hand-coding a connection between various application. This is called point-to-point integration.

Rigidity is the most obvious drawback of point-to-point integration. The complexity increases with the increased number of connections and interfaces. The disadvantages of P-2-P integration leads us to ESB integration.

ESB is a more flexible approach to application integration. It encapsulates and exposes each application functionality as a set of discrete reusable capabilities. No application directly integrates with other, instead they integrate through an ESB as shown below −

For managing the integration, ESB has the following two components −

• Service Registry − Mule ESB has Service Registry/Repository where all the services exposed into the ESB are published and registered. It acts as a point of discovery from where one can consume the services and capabilities of other applications.

• Centralized Administration − As the name implies, it provides a view of transactional flows of performance of interactions occurring inside the ESB.

ESB Functionality − VETRO abbreviation is generally used to summarize the functionality of ESB. It is as follows −

• V(Validate) − As the name implies, it validates the schema validation. It requires a validating parser and up-to-date schema. One example is an XML document confirming to an up-to-date schema.

• E(Enrich) − It adds additional data to a message. The purpose is to make message more meaningful and useful to a target service.

• T(Transform) − It converts the data structure to a canonical format or from a canonical format. Examples are conversion of date/time, currency, etc.

• R(Routing) − It will route the message and act as a gatekeeper of the endpoint of a service.

• O(Operate) − The main job of this function is to invoke the target service or interacts with the target app. They run at the backend.

VETRO pattern provides overall flexibility to the integration and ensures that only consistent and validated data will be routed throughout the ESB.

What is Mule ESB?

Mule ESB is a lightweight and highly scalable Java-based enterprise service bus (ESB) and integration platform provided by MuleSoft. Mule ESB allows the developer to connect applications easily and quickly. Regardless of various technologies used by applications, Mule ESB enables easy integration of applications, enabling them to exchange data. Mule ESB has the following two editions −

• Community Edition
• Enterprise Edition

An advantage of Mule ESB is that we can easily upgrade from Mule ESB community to Mule ESB enterprise because both the editions are built on a common code base.

Features & Capabilities of Mule ESB

Following features are possessed by Mule ESB −

• It has simple drag-and-drop graphical design.
• Mule ESB is capable of visual data mapping and transformation.
• User can get the facility of 100s of pre-built certified connectors.
• Centralized monitoring and administration.
• It provides robust enterprise security enforcement capabilities.
• It provides the facility of API management.
• There is secure Data Gateway for cloud/on-premise connectivity.
• It provides the service registry where all the services exposed into the ESB are published and registered.
• Users can have control through a web-based management console.
• Rapid debugging can be performed using service flow analyzer.