Mule 2.0 Released

• XML Schema - configuring Mule is easier than before, using an XML Schema-based configuration.  This enables auto-complete features in IDE's such as IntelliJ and Eclipse, making configuring simpler.
• A Spring-ier Mule - Spring is the default configuration mechanism, making , as well as allowing Mule to take advantage of Spring AOP, Spring resource loading and Spring modules.
  
• Architectural improvements - multiple architectural improvements have been made, including introducing a MuleContext and Registry; changing the MuleDescriptor to a clearly-separated Service and Component model; endpoint improvements; and improved streaming and transformation improvements.
  

With the architectural work, new XML configuration and package re-organization, how different is Mule 2 from Mule?

The major change is the new XML configuration.  All config elements are well-typed and described.  there are no more class names in the config files (except for you own custom extentsions). Each namespace introduces a module or transport into your configuration. Where transports are concerned a namespace allows user to configure transport specific endpoints for every transport making it much easier to know what must be configured and what other config options you have. Using schema-based config also gives developers code completion and inline documentation in most Xml editors.

Architecturally, there are a couple of changes that are immediately apparent:

1. No More MuleManager. Instead we have split out this monolithic object into manageable pieces that now make it much easier to extend and hook into core server behavior .
2. From the users point of view the objects they deal with are much more well defined. We've look very carefully at all objects in Mule and made sure there definition and roles are well defined.
3. You now have a MuleContext that provides access to Mule resources at runtime (1 per instance).
4. You have the Registry that manages runtime objects.  You can have multiple registries that enables you to overlay configuration on an existing instance of Mule.
5. We have split the notion of Component (your POJO that does your business logic) Service (the configuration that defines how the Component will be managed as a service.  This was an important distinction to help users understand the relationship between Component and Service
6. The core architectural concepts have not changed, this means old Mule users are not bombarded with new terminology or a different way of working.

Is there a recommended upgrade path for existing Mule users?

Right now it's a manual process for users to switch their configuration to Mule 2.0.  The configuration structure is pretty similar to Mule 1.0 but there is much less configuration required for Mule 2.  For our Mule Enterprise customers we will be releasing a Migration tool when we release Mule Enterprise 2.0.

With an impressive list of features, what do you think users will be most thankful for?  What feature are you most proud of?

I am most proud of the core architecture piece since we've made huge improvements internally to mule.  We needed to do this to create a compelling platform for new projects on top of Mule. Unfortunately, most users will never see these changes directly :)

1. We've added an expression evaluator framework that means users can define expressions in xpath, xquery, groovy, jxpath, and use Mule specific handlers such as header, attachment and function expressions. to grab information from the message at runtime.  These expressions can be used to quickly transform the current message, construct new messages and do content based routing. This is pretty powerful stuff since it makes runtime configuration much more dynamic.  It's also very easy to plug in new expression evaluators for things like mvel, ognl, or jruby.
2. The message handling has been revamped and we now support Auto Transformations which will discover existing transformers and apply them to payloads when necessary. It also means users can request the message payload as different types just by doing MuleMessage.getPayload(org.w3c.dom.Document.class) or MuleMessage.getPayload(org.xml.sax.InputSource.class). Users can still explicitly define transformers as before.
3. Message handling is generally more efficient. Streaming is handled by default, there is no need to explicitly define streaming endpoints anymore
4. Transport-specific endpoint configuration is a huge improvement and will eradicate the issues many users had configuring endpoints incorrectly
5. We released a Milestone of Mule IDE at the same time as Mule 2.0.  This is based on Eclipse and includes a preview to the new Visual drag'n drop editing.

Anything else you want to add?

Some architecture changes were also made to allow Mule to be loaded from an OSGi container.  Mule 2.0 does not support OSGi yet, bet we gave a demo of Service hot deployment in Mule at MuleCon in San Francisco earlier this month and everyone there seemed to be very enthusiastic about it.

Mule 2.0 is available now, to see how the new features work check out the overview and download the latest version.