Mule is an ESB (Enterprise service bus), now that’s an acronym
, in this article I’ll build on a simple example to show a tiny part of its power.
As an example, Mule will be configured to monitor a folder, and move the contents to a different location on the file system, this example is inspired heavily by this article on the MuleUMO wiki. in another article, we’ll work on a more “enterprisy” application. This example will show how Mule can simplify matters.
What I’ll try to achieve can be done in plain Java, but the idea is not to reinvent the wheel; there is no need to build a fragile event driven framework, or bother with reading and writing files, not to mention the configurability aspect of the system, like changing the source and destination folder.
By using Mule you can add nifty things like recieiving a notification email when a file arrives or even uploading the files to an ftp folder, all these without programing, but simply by configuring Mule.
The installation of Mule is straight forward, go to the official site and download the latest distribution, unzip it, set the MULE_HOME environment variable, you may also add MULE_HOME\bin to your path.
To configure Mule, a configuration file must be created, the Mule container can then be run by invoking the following command: %MULE_HOME%\bin\mule.bat -config=configuration.xml (Yes I am on windows
)
Instructing Mule to monitor a folder:
To be able to interact with the filesystem, the FileConnector needs to be configured, by setting some properties:
autoDelete: delete the moved file?
binary: has the file transfer to be in binary mode?
outputPattern: what will be the name of the moved file, this can be set to be the original filename, the date and many others which can be combined.
pollingFrequency: the polling frequency of the folder
Configuring the source and destination folders:
The input and output here can be abstracted as endpoints, a specific channel through which two parties can communicate (RTFM). only the endpoint address matters here, which are naturally the full path to the source and destination directories.
Configuring events are routed into and out of the system:
This is the role of the inbound-router and the outbound-router respectively.
Transformers:
they are used to convert data to an object required by the next element in the processing chain. In our simple example we don’t need those, but because the current Mule version (1.3.3) is afflicted with a bug, we still need to invoke a special filter on the inbound-router, a noActionTransformer, which will basically do what it suggests, no transformation, that is. The current FileConnector has a default transformer activated.
So basically the flow is:
- Files are in the source directory
- Mule moves them from one directory to the other
- Files arrive in the destination directory
In a future article, we’ll build a very simple r-sync clone (well nearly)
Download the mule configuration file here.