Mitch Pronschinske 
Mule 3: A New Deployment Model
Email
The Enterprise Integration Zone is presented by DZone and FuseSource. Check out the EI Zone for real world integration scenarios to help you learn which technology will give you the most elegant solution. For open source systems based on Apache Camel, ActiveMQ, or ServiceMix, look into FuseSource's training and technology.
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:
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'):
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.
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.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Enterprise Integration is a huge problem space for developers, and with so many different technologies to choose from, finding the most elegant solution can be tricky. The Enterprise Integration Zone is a place for enterprise developers of all backgrounds to share design patterns and technology solutions that make integration easier for various scenarios. FuseSource proudly supports the EI Zone and provides its own gamut of training, services, and tools based on Apache Camel, ActiveMQ, CXF, and ServiceMix.
