Over the past months, we’ve been regularly blogging about the cool new features that are coming in Mule 3. So far, we’ve presented these features in high level terms. In the coming days, we will start posting more detailed information about all the good stuff Mule 3 will offer and how you will be able to benefit from them.
Obviously, the most visible changes will concern the XML configuration. But, like the tip of the iceberg, that will only be a small part of the whole story. Deeper changes have occurred; and they were all about empowering Mule’s users.
Mule’s internal architecture has gone through a complete overhaul, which mainly aimed at unifying the design of the different internal moving parts (endpoints, transformers, routers…). All these parts are now known internally as message processors. For Mule users, this unification will open the possibility to freely combine these moving parts in a new structure named “flow”. Flow-based configuration will set users free from the rigid structure of Mule 2’s services: out of this freedom, we’re expecting new and unexpected usage patterns to emerge.
This will also allow us to identify and crystallize common message flows as ready-made configuration patterns. Indeed, one of our major goals with Mule 3 was to increase the productivity of its users while drastically reducing the learning curve and making Mule more accessible to everyone. For that matter, we have introduced the notion of pattern-based configuration, which consists in specific artifacts that resolve recurring problems with the least possible amount of XML.
This new architecture will also open the door to progressively roll-out a pure Java-based configuration for Mule, which is required by both XML-averse users and those in need of advanced runtime control on an instance’s configuration.
Beyond the logical flow of messages, Mule 3 will offer a clearer control on time-related concerns. Instead of approaching the problem from a synchrony standpoint only, we’ve redesigned the internal architecture to support the notion of message exchange patterns (MEPs). This will allow us to offer more expressiveness in the interactions that occur between Mule and the external systems that connect to it or it connects to.
Lastly, Mule 3 will bring important improvements to the management of message property payload and properties. The notion of message adapter has been abandoned in favor of a clearer approach that relies on message factories. Moreover, strict scoping will give the user a complete control of what message properties should be carried across, retained in session or simply dropped, as messages travel through Mule.
So get ready for Mule 3 and the new power it’s going to give you! It’s time to get these drum rolls going…
