For the past few months we’ve been busy working hard on the next version of Mule, release 3.3. This release candidate includes all the new features and improvements from Milestone 1 and Milestone 2, as well as those that we have introduced since.
As you’ll see, we didn’t slow down as we neared feature-complete, but continued to make high-impact improvements. In a nutshell, this release includes:
- Mule Expression Language – a concise way to work with any payload, message headers and attachments.
- HTTP Response builder – a new element that makes it easy to work with HTTP responses for REST or general resource calls.
- HTTP Proxy – a new pattern that allows you to front any HTTP resource with routing, filtering and caching.
- Transformations – improved implicit transformation capabilities, enforcement and lookups, which make it easier to work with different data types and content types.
- Syntax Sugar – a couple of new elements have been added to make it easier to work with variables and the payload and to make flows more concise and easier to read.
Mule Expression Language
Mule introduced expression evaluators back in Mule 2.2 in 2009, which significantly simplified basic filtering, transformation and routing using a single expression. Since then, expression support has been added in many other areas other of Mule, including dynamic endpoints and the choice router among others. We have evolved the existing support into a single comprehensive expression language.
We’re positive you’ll love the new Expression Language, but in case you want to use the old expression evaluators or don’t have time to switch, don’t worry, all existing traditional “expression evaluator” expressions will continue to work and are backward compatible.
Basic filtering
In the choice router above you can see how easy it is to combine environment information, application context and message content in a natural, easy to use expression with a single syntax.
Message Enrichment
Message enrichment using the <enricher> element now uses the Mule Expression Language so there is no need for using header or variable expression enrichers. Enriching the payload itself is now simple and natural.
We’re hoping this is a significant advancement in the power and usability of expressions in Mule and can’t wait to get feedback on this! We’re still working on the new documentation for this, but it will be ready for 3.3.0. For those eager to give this a go, there is some information in the feature spec. If you have any questions, just give me a shout via our forum.
HTTP Improvements
As you’d expect, HTTP is one of the most used transports in Mule and often provides the foundation for the implementation or consumption ofREST services and APIs.
HTTP Response Builder
The HTTP Response Builder simplifies setting the response code, content type and any other cookies or headers on a response.
The example above shows a simple flow that creates an Order. The HTTP Response Builder is used to set the correct status code and location header as well as create a simple confirmation message that is returned.
HTTP Proxy Pattern
This new pattern will come handy when remote web resources need to be accessed in a controlled manner.
This pattern is very much like its cousin, the Web Service Proxy. The HTTP Proxy sits in the middle between a caller application and a target web resource and propagates HTTP requests and responses, including their headers.
Typical use cases for this configuration pattern include:
- exposing a remote web resource as one being hosted behind a corporate firewall
- adding or removing HTTP headers
- dynamically dispatching to different remote resources
- content caching of regularly accessed resource
As you can see in the following examples, configuring the HTTP Proxy is trivial:
Transformation improvements
There were a number of improvements in the transformation of messages, which can be separated into three groups:
Transformation Enforcement
In previous Mule versions, transformers that did not match the expected source data type were just ignored. Depending on the data type of the message, we could not say what data type of the transformed message would be. With the enforcement, there are now three possible outputs from a transformation: (a) you get a message of the expected type, (b) you get a message with a NullPayload or (c) you get an exception.
Implicit Message Conversions
Nobody likes converting data types. In the past, Mule users have peppered their configuration files with ‘x-to-string’ transformers. Now Mule can figure out what conversions are needed for you. This means that if your Mule configuration uses a transformer B->C and your payload is of type A, then we try to find a transformer from A->B to apply instead of failing.
Extended Transformer Lookup
Mule provides a transformer lookup mechanism that helps to convert a given payload to a different type. The old lookup mechanism worked by finding direct transformations from the current type to the expected one. The new lookup method extends the current behavior and enables the search of composed transformations.
All of these features are enabled by default. Since there is a possibility that they might break backwards compatibility, there is a new configuration flag to disable them and obtain the old transformation behavior.
Syntax Sugar
Most of the following tasks could be performed using previous versions of Mule. We’ve added these features to further simplify these common tasks.
Dealing with Variables and Message Properties
Message attachments can also be managed in the same way.
Updating the payload
The <set-payload> element is used in the same way as the <logger> and replaces the payload while the <parse-template> element loads a file from the filesystem and parses embedded expressions before setting the payload with the response.
Download Mule 3.3.0 RC today and take it for a test drive!
As usual, if you have any questions feel free to use our forum. All feedback is welcome! And should you find any bugs, let us know at JIRA.
