RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Implementing Enterprise Integration with Mule ESB : Page 3

See how Mule ESB, a powerful open-source enterprise service bus, simplifies the implementation of enterprise integration scenarios.

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, which shows 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 class

Finally, 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:

<mule-descriptor name="RESTServiceWrapper"
        <property name="serviceUrl" value="http://myserver.com/OrderProcessing/AddOrder"/>
        <property name="httpMethod" value="POST"/>

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.

Edmon Begoli a software architect with 14 years of professional experience on large commercial and federal software projects. He is a member of the R&D staff at Oak Ridge National Laboratory.
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date