Mule 2.0 Released

Posted by Ian Roughley on Apr 24, 2008

Sections

Development,

Enterprise Architecture

Topics

SOA Platforms ,

Java ,

SOA ,

ESB ,

SOA Appliance

Tags

Mule

Mule, a lightweight and highly scalable ESB, has just release Mule 2.0.  New features in the 2.0 release include:

• 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.
  

InfoQ spoke with Ross Mason, CTO and co-founder of MuleSource, about the new release.

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.

1. Back to top

   OSGi and Flex

   by Christopher Brind

   Great news about OSGi and I look forward to full support. Would be very useful to be able to drop Mule in to my existing container to get an instant ESB for my bundles, especially being able to auto-magically expose my services registered with the OSGi container as Web-Services.
   
   Also, has there been any thoughts towards supporting AMF as a transport protocol? Flex is gaining popularity and we're already using Flex with OSGi.
   
   I can see Mule being very useful for wiring the communications between distributed OSGi containers and Flex clients, but I'll be waiting for official OSGi support before I try it.
   
   Good job though. =)

   Reply

2. Back to top

   Re: OSGi and Flex - check out Newton

   by richard nicholson

   Christopher,
   
   If you are interested in Mule / OSGi - check out the Mule4Newton project mule4newton.codecauldron.org/
   
   In addition to Mule in an OSGi container - you also get all the dynamic distributed benefits of Newton.
   
   Regards
   
   Richard

   Reply

3. Back to top

   Re: OSGi and Flex

   by alexis richardson

   You can also use AMQP as a message based transport using RabbitMQ which now has a Mule adaptor - thanks to Ross, and to Neil Ellis from the Newton/Paremus team - and a Flex client thanks to Ben Hood. Neil Bartlett has released some OSGi support for the RabbitMQ Java client as well. For a demo of Mule working with RabbitMQ and Newton all at the same time, either as a package or as a runnable virtual server, please contact me, or Neil Ellis. Cheers, alexis

   Reply

• Older >