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.