BT

Mule 2.0 Released

by Ian Roughley on Apr 24, 2008 |
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.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

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. =)

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

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

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT