Mule 3: A New Deployment Model

MuleSoft has published the third milestone for Mule ESB 3, an open source Enterprise Service Bus with over 1.5 million downloads to date.  This is one of the most significant milestones for Mule because it constitutes a fundamental change in the way applications are deployed.  This new model will facilitate many new options for running applications in Mule ESB.

First, here is a list of some changes in Mule 3 M3:

• MuleMessageAdapter has been dropped and replaced with MuleMessageFactory.  This change does away with the message adapter model and makes it easier for Mule to work in a configuration where the passage holds a non-serializable payload.  The MuleMessage API will not change.
• There are Lifecycle improvements and fixes, although they may affect only users coding against Mule APIs, like custom transport creators.
• Support for Apache Axis transport is being phased out gradually.  Enterprise customers would still be able to obtain the transport from the portal to ease migration to Mule 3

An early preview is available for the new deployment model for Mule applications.

In Mule ESB 3, product developers are changing architecture that has been around since the beginning of Mule ESB.  Many of MuleSoft's (previously called MuleSource) customers have been trying to nail down exactly what constitutes a Mule application for some time now.  With an early preview of the new application deployment model in Mule ESB 3 Milestone 3, the concept becomes more clear.  Here are the new steps for deploying a Mule 3 application ('foo'):

• Create a directory under: $MULE_HOME/apps/foo
• Jar custom classes (if any), and put them under: $MULE_HOME/apps/foo/lib
• Put the master Mule config file at: $MULE_HOME/apps/foo/mule-config.xml (note that it has to be named: mule-config.xml
• Start your app with: mule -app foo

A nifty feature is the ESB's monitoring of your application's master config file.  This means you can make class changes and modify the configuration (just save or touch mule-config.xml), and Mule will hot-reload the app.

Mule Architecture


The new deployment model opens up a whole new world.  For example, you can now have more than one application isolated and structured under the apps directory.  Applications will be able to have multiple library versions as dependencies even if they would have conflicted before.  There are also clear boundaries for operations people working with a Mule application.  Later milestones will have the ability to run multiple applications in parallel.

MuleSoft is not trying to create an application server with these changes, or chase compliance with every single specification.  They say their focus is more pragmatic, and the new model is not officially enabled by default yet.  To implement the new model you need to enter one line of config change. 

Recently, MuleSoft also launched an enterprise-grade management console for fine-tuning the performance of the ESB's thread pools, CPU utilization, memory, and more.  You can find the Mule Management Console (MMC) at MuleSoft.org.