Mule ESB is undergoing its next mutation with the upcoming version 3.0. Mule ESB has always been one of the easiest ESB's to setup and work with. The intelligent combination of Spring and other open source technologies gives outstanding results.
An example of a unique feature, is the JUnit-based framework that comes with Mule. It is enormously convenient to be able to create a complete test case and run the entire Mule server from a single JUnit class! When I work with other ESB's I really miss this one.
Another example is the Spring-based configuration system. It is difficult to grasp all the power that you get from this. By contrast, ESB's that use proprietary DSL's for their configurations are limited to the features they build. With Spring, you can pretty much inject anything into you Mule configuration and reference that from anywhere else in the configuration.
A third example is the leveraging of Maven in various areas. Build management of course but also providing partners with Maven archetypes to help them bootstrap their transports and modules developments. That's so much better than documentation and samples.
These features alone could explain why Mule has become so popular.
Inevitably though, as larger companies and organizations started using it, demand for entreprise-class features has increased. Message flows that users needed to describe to Mule have become more complex. The limitations of the "endpoint/transformer/service" buiding blocs became apparent (Behaviors such as "Remote Sync" are still pretty obscure to me).
Mule 3.0 is introducing a new "flow" concept that should allow description of complete pipelines. I haven't played much with that yet but really looking forward to.
When you deploy large number of services in a single server instance, the class loading mechanism comes under stress. Typical problems are the need to share libraries and multiple versions of libraries having to coexist.
You don't solve problems like these without some major overhaul. Mule 3.0 is introducing a completely new deployment mechanism with features such as hot deployment.
Because there are major architectural changes, Mule 3.0 is not backward compatible. This might sound like an heresy to Mainframe people but remember how IBM CICS went from macro-level API to command-level APIs.
The reality is that you can't deal with core architectural issues without fundamental refactoring.
The good news is that the migration process is not that painful and is well documented. It took me only a few days of work to migrate the LegStar for Mule transport.
In the mainframe world, version 3 was usually the most complete and stable version. Looking at Mule 3.0 feature set, it could very well be the case for Mule too.
