Why use an ESB?
Increasing organizational agility by reducing time to market for new initiatives is one of the most common reasons that companies implement an ESB as the backbone of their IT infrastructure. An ESB architecture facilitates this by providing a simple, well defined, "pluggable" system that scales well. In addition, ESB integration provides a way to leverage your existing systems and expose them to new applications.
Implementation
Let's examine how a simple Bank Loan processing application can be implemented using an ESB architecture. In this example, we'll utilize a canonical messaging format and the Mule product to handle communication and transformation between services.
Our bank loan processing application is a simple SOAP-based Web Service and orchestrates three back end fine-grained services, namely:
- Credit status check: REST - Web Service- A simple service that returns the credit status of a loan applicant.
- Retrieve interest rate: JMS - Legacy service - Another simple service that retrieves the correct interest rate to be applied to a loan application based upon a "daily interest" source.
- Store application to data warehouse: JDBC - Database - Each and every application received by the bank must be cached into the data warehouse database to comply with regulatory requirements. This component performs a simple insert into an existing database.
Integration core principles
While this is a simple example, it does serve to illustrate some basic fundamentals of any integration initiative. Applying our five core integration principles, namely:
| Orchestration | Composing new services by chaining multiple services together. |
|---|---|
| Transformation | Data transformation. |
| Transportation | Transport protocol negotiation. |
| Mediation | Supporting multiple interfaces to a single service for backwards compatibility or alternate data formats & transports |
| Non-functional consistency | Security requirements, monitoring, management, high availability, etc. |
An ESB implementation use case typically involves the following:
| Orchestration | Composing several existing fine grained components into a single higher order composite service. This can be done to achieve appropriate "granularity" of services and promote reuse and manageability of the underlying components. In our loan processing example this includes leveraging existing credit check, interest rate and data warehouse applications to create a new composite service. |
|---|---|
| Data transformation | Transformation between canonical data formats and specific data formats required by each ESB connector. An example of this would be transforming between CSV, Cobol copybook or EDI formats to either SOAP/XML or JSON. Canoncial data formats can greatly simplify the transformation requirements associated with a large ESB implementation where there are many consumers and providers, each with their own data formats and definitions. |
| Transport protocol negotiation | Transport protocol negotiation between multiple formats (such as HTTP, JMS, JDBC). Note: Mule treats databases like another "service" by making JDBC just another transport (or endpoint) where data can be accessed. |
| Mediation | Providing support for multiple interfaces for the purpose of a) supporting multiple versions of a service for backwards compatibility or alternatively, b) to allow for multiple channels to the same underlying component implementation. This second requirement may involve providing multiple interfaces to the same component, one legacy interface (Flat file) and one standards compliant (SOAP/XML) interface. |
| Non-functional consistency | For a typical ESB initiative, this can include consistency around the way security and monitoring policies are applied and implemented. Additionally the goals of scalability and availability can be achieved by using multiple instances of an ESB to provide increased throughput (scalability) and eliminate single-points-of-failure (SPOFs), which is the key objective for highly available systems. |
ESB - Bank Loan application flow
In an ESB implementation this would be one of many similar integration flows. The Bank Loan Application flow illustrated here is a simple ‘Service Orchestration’ pattern comprised of the following steps (see below).
- An Http inbound endpoint & SOAP component receive SOAP/XML ‘Bank Loan Application’ requests,
- Credit status check (REST) service is invoked to retrieve credit status details. This is implemented using an Http outbound endpoint and a message enricher pattern to ‘augment’ this information to the original message payload. A request transformer is also used here (not shown) to convert the data format from its canonical XML representation into JSON.
- Interest rate (JMS) service is invoked to retrieve the current interest rate for this category of loan application. In a similar way to the previous step a message enrichment pattern is used here also.
- Data warehouse - A JDBC Endpoint is used to cache the entire message to the Data Warehouse component. This component enables a transactional ‘INSERT/UPDATE or DELETE’ operation to be invoked on an external database. If required stored procedures and bulk updates can also be utilized.
- Finally a simple ‘Transformer component’ re-formats the message payload to prepare the response message, which is returned to the original consumer.
Summary
Most organizations want to increase agility by reducing time to market for new initiatives. ESB architectures promote this objective by implementing a simple, well defined, "pluggable" system that scales really well. Here at MuleSoft we understand that an ESB architecture is exactly that: an architecture and not simply a product you can buy off the shelf. It encompasses not only infrastructure but application architecture as well (a complete discussion of this is provided by MuleSoft founder Ross Mason here). However, selecting the right product to facilitate this architecture can make a huge impact on the success or failure of the architecture. Mule serves as a great foundation or backbone upon which to build such an architecture.
In our loan application example we've demonstrated the key principles of any ESB implementation: service orchestration, transport protocol negotiation and data transformation utilizing canonical data formats. Using these techniques, organizations can gain a competitive advantage by providing a solid foundation for new initiatives while continuing to leverage their investment in their existing infrastructure.
Want to learn more?
If you are ready to get started, start your free trial of Mule today.