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
Why 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 the future − Suppose if we want to add more services or applications in the 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.
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 a simple drag-and-drop graphical design.
- Mule ESB is capable of visual data mapping and transformation
- Users 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 a secure Data Gateway for cloud/on-premise connectivity.
- It provides the service registry where all the services exposed to the ESB are published and registered.
- Users can have control through a web-based management console.
- Rapid debugging can be performed using a service flow analyzer.
Sl no. | Error Type and Description |
---|---|
1 | TRANSFORMATION This Error Type indicates an error occurred while transforming a value. The transformation is Mule Runtime internal transformation and not the DataWeave transformations |
2 | EXPRESSION This kind of Error Type indicates an error occurred while evaluating an expression |
3 | VALIDATION This kind of Error Type indicates a validation error occurred. |
4 | DUPLICATE_MESSAGE A kind of validation error which occurs when a message being processed twice. |
5 | REDELIVERY_EXHAUSTED This kind of Error Type occurs when maximum attempts to reprocess a message from a source has been exhausted. |
6 | CONNECTIVITY This Error Type indicates a problem while establishing a connection. |
7 | ROUTING This Error Type indicates an error occurred while routing a message |
8 | SECURITY This Error Type indicates a security error occurred. For example, invalid credentials received. |
9 | STREAM_MAXIMUM_SIZE_EXCEEDED This Error Type occurs when the maximum size allowed for a stream exhausted. |
10 | TIMEOUT It indicates the timeout while processing a message. |
11 | UNKNOWN This Error Type indicates an unexpected error occurred. |
12 | SOURCE It represents the occurrence of an error in the source of the flow. |
13 | SOURCE_RESPONSE It represents the occurrence of an error in the source of the flow while processing a successful response. |
Error Types
Let us understand the Error Types with the help of its characteristics −
- The first characteristic of Mule Error Types are that it consists of both, a namespace and an identifier. This allows us to distinguish the types according to their domain. In the above example, the Error Type is HTTP: UNAUTHORIZED.
- The second and important characteristic is that the Error Type may have a parent type. For example, the Error Type HTTP: UNAUTHORIZED has MULE: CLIENT_SECURITY as the parent which in turn also has a parent named MULE: SECURITY. This characteristic establishes the Error Type as the specification of the more global items.