Mule overview
Background
Mule was founded by Ross Mason in 2005 as a result of his enterprise integration frustration while using the heavyweight and costly closed source products from the typical integration vendors. He created a lightweight integration framework that's making use of a lot of other open source projects and that's very flexible. In 2008 Mule 2.0 was launched, and this version includes foremost a more powerful configuration language utilizing Spring 2.0 features. Support for Mule is available via MuleSource. There are currently two versions of Mule 2 available, the community edition and the enterprise edition. The community edition is fully open source and available for free. The enterprise edition adds a couple of features and is available as part of a support contract with MuleSource.
Architecture
The basics of Mule are quite easy to understand when you are familiar with the core building blocks. Mule supports a large number of transports, such as JMS, File, SMTP etc, which can receive and send messages. When a message is received by such a transport it's processed by a so-called Mule service. A Mule service is a vehicle that you define within a Mule configuration. A Mule service consists of an inbound router, a component and an outbound router. An inbound router consists of an endpoint definition which configures which transport is used and how it's received, for example a JMS queue. A component is a piece of logic that processes the incoming message. This can be a Java component but also a piece of scripting for example in Groovy. The response of the component is eventually processed by the outbound router to its target endpoint. The following figure summarizes the Mule architecture and its building blocks.
Configuration language
Mule supports both a XML configuration language as well as other configuration languages including Groovy. The common choice for implementing integration solutions in Mule is the XML configuration language. You can learn a lot of this configuration language while reading through the Mule examples, but a short introduction is good to get started. Mule 2 uses different XML Schema definitions for every transport and other features, such as XML support. An example of the use of such an XML Schema definition in a Mule configuration is the file transport.
These xsd's, such as the mule-file.xsd, can be found in the sources provided in the src directory in your Mule distribution. Next you'll find a simple example showing a Mule service definition
This example shows a simple integration flow, which includes logic to move a file to another directory, the out directory. It also shows the typical XML elements of a Mule configuration. Here we have defined one service, but a model can contain more service definitions. We also see the use of a transformer. The file-to-string transformer transforms the java.io.File class instance to a String, which contains the content of the incoming file message. Here you can see that Mule is exposing Java classes to you as an integration developer. The String instance is forwarded to the SimpleComponent class as an input parameter. So we'd expect the SimpleComponent class to have one method that accepts a String input parameter. Mule also supports other types of so-called entry point resolvers, see the documentation on the Mule website. The return value of the invoked method in the SimpleComponent class is then forwarded to the outbound router. This router simply writes the result to a file in the out directory.
