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:
- 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.
Business Scenario: Order-Processing Service
I have found that many organizations often prefer to leverage simple and widely established technical methods for the implementation of business processes rather than complex and sophisticated methods. Channels such as very simple form-based web submissions or e-mail channels are often the methods of choice for the implementation of important business functions.
This article presents the implementation of one such business function: submitting orders via e-mail into a RESTful web service and verifying the order quantities against a corporate warehouse before the order is submitted. It uses Mule to wire up these processes using mostly built-in Mule components with very little custom coding. This implementation will demonstrate how Mule ESB can save time and simplify the implementation of business functions, as well as add significant value.
To implement the order-processing service on Mule ESB, you first need to define the service itself using Mule’s service definition syntax:
... Orders are received as pre-formatted e-mails. Each line is prefixed with a label for the data it contains: name, address 1, address 2, city, state, zip, phone, comment, and item.
name: John Doeaddress 1: 123 Some Streetaddress 2:city: Townvillestate: DZzip: 98765phone: 012 345 6789comment: please expediteitem: automatic blenderitem: rotary circuit For Mule ESB to pick up these messages, you first need to configure the POP3 transport and the transformer that will translate the messages into the appropriate format. The following XML shows the Mule ESB configuration for the POP3 transport and for the custom translator that translates the incoming plain text messages into an XML message that will be submitted into a backend web services:
Notice how the POP3 configuration is defined. Many defaults, such as POP3 port number, are omitted. Refer to POP3 adapter messages on the public forums for more details on other options and defaults.
Transformation
Transformation is a chained process. In other words, transformers can be chained to each other, similar to how pipes in UNIX/Linux allow a process to take inputs from another process and pass outputs to another.
To transform the e-mail message into XML that will work with a back-end service, this example uses two transformers:
- EmailMessageToString: a transformer supplied by Mule ESB
- orderprocessing.OrderSubmissionsMailtoXMLTransformer: a custom transformer
In order to be recognized as a custom transformer, orderprocessing.OrderSubmissionsMailtoXMLTransformer has to be implemented as an extension of the Mule ESB AbstractMessageAwareTransformer transformer (org.mule.transformers.AbstractMessageAwareTransformer). It also requires the implementation of the abstract method abstract Object transform(MuleMessage message, String outputEncoding).
The custom object simply parses each e-mail message line by line and produces the following XML:
John Doe 123 Some Street Townville DZ 98765 012 345 6789 -
automatic blender 1 -
rotary circuit 1 > Quantity Check
Now, the order-processing service has to check availability against the inventory for each line item. To do so, it uses the nested router concept, which is a new router type in Mule 2.0. A nested router is Mule’s way of calling an orthogonal validation, which the order-processing service uses to call an order quantity service.
The custom validator object orderprocessing.OrderQuantityValidator implements the common custom interface orderprocessing.Validator. This interface implementation, a practice of dynamic Dependency Injection adopted from the Spring Framework (which is the technical basis for Mule), is mandatory in Mule 2.0. Here is the validator interface:
public interface QuantityValidator{ public void validate(Order order) throws ValidationException;} Here is the implementing class and a snippet of Mule’s XML configuration for order processing, whichshows the nested router embedded into an OrderProcessing service:
public class QuantityValidator{ public void validate(Order order) throws ValidationException{ Items items = order.getItems(); if ( items == null ){ throw new ValidationException( "No items in order"); }//end if for (items : item ){ if ( item.getQuantity() <= 0 ){ throw new ValidationException( item " has invalid quantity " + item.getQuantity() ); }//end if }//end for }//end method}//end classFinally, if quantities are confirmed and in order, the order-processing service will post the XML representing the submitted order to a back end RESTful web service:
... Some Homework Required
Mule ESB is a mature product with increasingly sophisticated tooling support (Eclipse-based IDE), available toolkits (e.g., REST pack), and a very active user and developer community. Above all, it is professionally supported through MuleSource. These attributes make Mule worth a look when evaluating enterprise service buses. However, before adopting it, you need to understand the requirements of implementing integration scenarios using Mule.
To effectively use Mule, you have to be prepared to learn the Mule framework, its component model, and its XML scripting model. Although this sounds like a comprehensive task, the learning curve is not very steep because Mule is relatively straightforward and consistent. Most of the work on the Mule ESB is done in the configuration files. All the components are configured in an identical, very predictable fashion with minimal exceptions and with the most commonly used values (e.g., default methods for REST (GET), ports for POP3, SMTP, etc.) set as defaults. These practices significantly simplify what the user should expectation from the tool, and they eliminate surprises and special cases that would require additional learning.
When adopting Mule, you should also have a good working knowledge of Spring and Java. Custom components, as shown in the examples here, are often required, albeit they are usually no more than 10 percent of the overall implementation scope. However, when you need them for your Mule ESB scenarios, you need to know core Java programming.
All in all, I believe Mule ESB belongs in any discussion of enterprise service buses with other commercial and open source ESB products.
