nce upon a not-long-ago, Web services were the future killer application that you just had to have a grasp on. While they are a very important part of most architectures nowadays, they aren’t actually a magic bullet that helps you integrate your applications or even expose your applications to the rest of the world. The reasons for this are many, including, but not limited to, security, performance, and flexibility.

The next wave in the evolution of the service-oriented architecture or application is the enterprise service bus. It is not a product, nor is it, strictly speaking, a technology. The enterprise service bus is a ‘way of doing things’?a ‘design pattern’ to continue the evolution of standardizing application integration.

The enterprise service bus is all about allowing different components or applications to communicate through a common messaging bus, usually implemented using JMS, MQ, or other messaging server. It allows traffic of all types to traverse it and has adaptors to allow servers of different message types to communicate seamlessly across the bus. For example, if you have an application that needs to raise an alarm based on some condition, and the action of that alarm is to send an email or an instant message to the administrator, the module that raises the alarm should not need to ‘understand’ SMTP or SIP (Session Initiation Protocol); it should just put the message on the bus and have the bus and the intended recipient handle it as they see fit.

So how does the enterprise service bus get used in the real world? A typical business process that would usually require a lot of custom programming is an ordering system. Generally a document enters the ordering system in the form of a purchase order. This document then has to be processed and passed to a billing system (taking part of its content), an inventory system (to see if the requested item is available), and finally a shipping system (to take the item out of stock and send it to the customer). In many cases this is a paper trail with manual entry; if it’s an automated system, it will have many lines of custom code.

An enterprise service bus allows you to automate much of this, and the only custom code required (if any) is that which drives your business logic. A well-designed enterprise service bus, like the one in the system described here, can achieve business automation without any custom code. Say the purchase order in this example comes in via an e-mail and is formatted as an XML document: The enterprise service bus will pick up this XML document and each module (billing, inventory and shipping) will have the choice to use an XPATH query to pull the nodes that they each require. They could also append to the document as they see fit.

There are many varied implementations of software that promise this functionality, from the commercial Microsoft BizTalk, BEA WebLogic, and IBM WebSphere products with relevant add-ons to open source offerings such as the WDI Business Integration Engine or the Mule framework. It is the latter of these, Mule, that you’ll be drilling down into in the rest of this article.

Mule is a lightweight messaging framework and an object broker that handles the interactions between your applications across JMS, e-mail, HTTP, and even XML-RPC. It is designed to be highly scalable and it manages all the interactions between the components regardless of their location and their implementation.

Getting Started with Mule
Mule is available at wiki.muleumo.org/display/MULEPROJ/Home. For this article I used version 0.9.3, which was the latest at time of writing. Download the ZIP file called mule-0.9.3-dist.zip (or whatever the equivalent version is), and unzip it to the C:MULE directory on your hard drive. You should see a file and directory structure like that in Figure 1.

Figure 1. Mule Installation Directory: This is what you should see when you unpack the Zip file into a C:MULE directory on your hard drive.

One thing you’ll have to make sure of before running Mule is to have a valid J2SE SDK installed and that the JAVA_HOME environment variable is correctly set up. In addition, you should make sure that the CLASSPATH environment variable contains a reference to C:Mulelib and C:Muledist (or whatever directory you installed to). Once all that is set up you are ready to start playing with your brand new enterprise bus.

The Hello World Example
Perhaps the most appropriate place to start is with a ‘Hello World’ application. This Hello World, though, is actually a lot more complicated than it appears: It demonstrates the input pipeline?which includes some nodes that process the document that is input to the pipeline?as well as an output pipeline that sends the new information back to the user. While this is very simplistic, it demonstrates some of the principles of the bus and provides a peek at some of the functionality and how it is handled by Mule, the messaging broker.

You can find this sample in the samples/hello directory of Mule. Start it by running START.BAT from the command line (see Figure 2). Entering your name will trigger the process to run (see Figure 3).

Figure 2. Hello MULE: This is what you should see when you run the ‘Hello World’ application from START.BAT.

Figure 3. Hello, You: Here is the Hello World application in action.

Figure 4. Mule Train: The document flow across the enterprise service bus in the ‘Hello World’ Application is shown.

The order in which the bus flows the message is determined by a combination of the configuration XML for the process and the internal logic within the individual nodes. However, to get the bus started, you have to specify the input to the process and this can be seen in the configuration XML file (conf/hello-mule-config.xml), some snippets of which are shown in Listing 1.

With that, you’ve just jumped into the deep end of configuration and flow, to show what should be a very simple process. So you might be a bit confused at this point, but that’s perfectly acceptable. You have the basics now in order to see the big picture of everything going on in this application. Understanding will come shortly.

Referring to Listing 1 and Figure 4, you will see that the SystemStreamConnector is defined as the connector for this application and that GreeterUMO is the main ‘object’ that starts the processing for this application (in the mule-descriptor tag).

The SystemStreamConnector takes in a string but the application knows (via the receiveEndPoint attribute of the mule-descriptor) that it is to transform that string into an object that will move along the bus. The transformation is done by the StringToNameString application, which is implemented as a Java class in the snippet below. The full source code is available in the Mule download.

public class StringToNameString extends DefaultTransformer{    public StringToNameString()    {        super();        this.registerSourceType(String.class);    }    public Object doTransform(Object src) throws TransformerException    {        String name = (String)src;        int i = name.indexOf("
");        if(i > -1) name = name.substring(0, i);        return new NameString(name);    }}

StringToNameString converts the incoming string containing your name (or whatever you typed in) into an object of NameString class (source also included) for use by the GreeterUMO. The GreeterUMO is implemented using the Greeter class (specified in the mule-descriptor using the ‘implementation’ attribute). This class then operates on the document and when finished the framework sends it onto the next node, specified by the sendEndPoint attribute. In this case the next node is the chitchatter.

The chitchatter node is described using the for ChitChatUMO (Listing 1). In a similar vein as the greeter, chitchatter uses a transform to convert the incoming document from a NameString to a Chatstring. This is achieved using the NameStringToChatString class (also in the download). The output of this class (again specified in the ) is the ChatStringToString transformer, which takes the Document (now a ChatString object) and converts it into a string. This string is eventually passed to the StreamConnector, which writes it back out to the console, providing a ‘hello world’ implementation.

By starting the Mule server application and specifying this configuration, you have implemented this service bus to handle the following process:

• taking the input from the SystemStreamConnector (which handles the keyboard)
• converting the input document to the document formats that the various nodes in the process understand
• acting on these documents as specified
• and converting the documents back to the format that the Stream Connector understands for output.

The final effect of this process is very simple: Input ‘Bill Gates’ to get an output of ‘Hello, Bill Gates, How are you’.

To start up the server with this configuration issue the following command:

java -classpath "%MULE_PATH%" org.mule.MuleServer 

Where %MULE_PATH% is the path to the mule JARS, and is the location of your configuration file specifying how the ESB is set up (as seen in Listing 1).

Next Steps
This example was very simple in functionality but it demonstrated many of the principles of how an enterprise service bus works. And it should help you get started in configuring and extending the Mule enterprise service bus.

Mule is an enormous and very flexible framework that allows you to build such applications. If you are looking to build an agile business, and don’t want to spend the heavy dollars that something like BizTalk would cost, it is well worth a look.