Mule 3 Embraces Simplicity and Next-Gen Technologies

After thousands of user suggestions and many months of development, MuleSoft's open source Mule ESB has been transformed to handle a new set of modern challenges like cloud deployment, simplifying configuration, and operational flexibility.  DZone talked about the new release with MuleSoft founder and CTO Ross Mason.

ESBs are no longer reserved mainly for the large organizations.  People are trying to do more integrations in the cloud and outside the firewall.  “In this major community release, we are extending the power of Mule ESB out from behind the firewall to enable seamless integration with the next generation of applications, including cloud, SaaS, mobile, and dynamic browser-based web applications," said Mason. "In addition, we’ve taken feedback from the community to drive the next level of configuration simplicity with Mule.”

Mason went through each of the highlights in this release:

Mule Cloud Connect

• Cloud connectors – out-of-the-box connectors for popular cloud, SaaS, and Web 2.0 providers (e.g., Amazon Web Services, Salesforce.com, Facebook), as well as an easy way for users to create their own cloud connectors.  These custom connectors are easy to build.
• Native REST support – Mule had REST support since 2007.  Now it's baked into the core.  It also has support for JSON data bindings and mapping, JAX-RS, and OAuth out of box.
• AJAX/JavaScript integration – enables developers to access enterprise data directly from a browser-based application without heavyweight server-side infrastructure.  jQuery, YUI, Dojo, GWT, ExtJS, etc can subscribe to events in the ESB and publish events directly.  This feature removes the intermediate step of having to go through the application server.

Configuration simplicity

• Flow-based configuration –a new powerful way of configuring Mule that simplifies the creation of message flows.
• Pattern-based configuration – out-of-the-box building blocks for common configuration patterns (transactional bridge, web service proxy etc.), drastically reducing the learning curve for new users.  Patterns can be dragged and dropped as elements into Mule configuration flows.  Users can create their own custom patterns as well.

Operational flexibility and uptime

• New deployment model – provides an easy, well-defined path for developers to work with Mule.  It supports many deployment models such as app servers, embedded, and standalone.  Mule 3's model allows developers to package Mule services applications as an archive, and then manage that lifecycle over time.
• Automatic hot deployment –  reduces friction and provides immediate feedback during the development process.  Hot deployment enables dynamic application and service provisioning to running Mule servers.  
• Service and application isolation – allows services in production time to be commissioned and decommissioned at runtime without impacting other services.   Much like the OSGi model, services and applications are secured and separated.  This way you can't mess up someone else's services.
• Dynamic endpoints – enables users to configure endpoint destinations at runtime based on message content and/or properties.  Publishing to dynamic clients was previously a difficult task in ESBs.  Now you know exactly where you're publishing to.  You also have the flexibility to publish in virtual or mobile environments.

Mule 3 has a rewritten web services infrastructure so users have more options for building services.  This is the main hurtle for backwards compatibility, but a review of Mule 3's documentation should help you reconcile older Mule assets.  

The next version of the Mule Management Console will follow close behind today's release with the ability to manage server instances and deploy to groups of servers using the new deployment model.  This will give users full auditing and rollback support.

Originally, MuleSoft wanted to modularize Mule 3, but they ultimately decided against it.  "There's no easy way for vendors to shield end users from the complexity of OSGi without adding a lot of extra abstraction on top of it," said Mason.  They even converted everything in Mule to OSGi bundles and had a demo one year ago.  Unfortunately, developers would have had to manage the bundles explicitly and the deployment model would not have been as simple as it is today.  "We haven't written it off, because there are some new things happening around OSGi," but right now, Mason says OSGi is not a good technology for the average end user.



Graphical Eclipse-based tooling will be available for Mule next year.