Implementing Enterprise Integration with Mule ESB

he sum of the Enterprise Service Bus (ESB) is greater than its parts. While you can—often quite easily—implement 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 prices—which 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:

• Endpoints: Endpoints are objects used to connect components from within Mule with external components or to other components within Mule. Endpoints require configuration of the address, connector, filter, transaction, and properties. For example, here is an inbound configuration of an endpoint for capturing console input:

  
  <stdio:inbound-endpoint system="IN"/> 
  

• Transports: Transports represent common enterprise connectivity protocols such as FTP, email, HTTP, SOAP, JDBC, JMS/MQ, CORBA, XMPP, TCP, and UDP. Through built-in transports, Mule supports a total of 30 common enterprise communication transports/protocols.



• Transformers: Transformers are compounds that transform inbound messages into formats required by processing components, or transform results of the processing components into the formats of the outbound messages. Mule ESB supplies transformers for XML, encryption, compression, encoding, and object transformations (including transformations between objects and XML).



• Filters: Filters can be used to express the rules for filtering messages on routers. Mule supplies default filters for payload-type filters, regular expressions, XPath expressions, wildcards, message properties, logic expressions (and, or, etc.), and the so-called OGNL filter—a filter using the expression language for the plain old Java objects.



• Routers: Message routers are used to control how components send and receive events in the system. Mule defines inbound routers that apply to events as they are received and outbound routers that are invoked when an event is being dispatched.

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.

Next Page