he sum of the Enterprise Service Bus (ESB) is greater than its parts. While you canoften quite easilyimplement your own adapters for enterprise services, a pre-packaged product that comes with a tested, documented, and standardized set of adapters for almost any common enterprise service is often a better solution. When time to market and future adaptability are the priorities, an ESB is the way to go.
However, commercial ESB products can often be quite expensive, particularly when adapters are sold separately at very high priceswhich often is the case. Enter Mule ESB, an open source alternative. Not only is Mule ESB well implemented, thoroughly tested, and decently documented, but it also comes with a number of adapters for HTTP, POP3, SOAP, JDBC, FTP, AS 400, TCP, UDP, and many others. You can get support for Mule ESB through either public forums or professional services from the patron company MuleSource.
In addition to its accessible price tag, Mule ESB supports RESTful web services out of the box, which I find the most straightforward and implementation-friendly style of web services for both enterprise and consumer web integration.
This article practically demonstrates how to use Mule ESB to implement a common business scenario: integrating an email-based ordering front end (POP3) with a service-oriented (RESTful), relational order-processing back end.
Mule ESB Architecture
Mule ESB is an application-independent platform composed of message-oriented processing and routing components for enterprise integration. Mule is implemented in Java, but most of the work required to connect to enterprise resources, processes, filters, and route messages happens in XML configuration files.
To use Mule ESB for common service-integration tasks such as the example described in this article, you first need to be familiarize yourself with the following core components. Most of the tasks for the example will be accomplished using combinations of some or all of these:
All these components are internally implemented as Java objects, which you can simply engage and configure through XML or pragmatically in Java without any custom programming. If a task requires custom implementation, you can easily extend native Mule ESB components by adding custom code to the Mule runtime in a predefined, well-controlled manner and by configuring the Mule runtime following the same method as with native Mule ESB components.