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.

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.

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.

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.

If you are ready to get started, start your free trial of Mule today.