You might have read Dan Diephouse’s post last month announcing the release of Mule 3.6, and if you haven’t – go read it! And then come back to this. Seriously.
Ok, so now that you’ve read about the new HTTP connector in Mule 3.6 and seen the cool demo that Dan put together it’s my turn to drill down into some of the more interesting details – why we built the new connector, how we went about it and how we ensured that it’s performant.
We’ve just released Mule ESB 3.3 into the wild. This is a big release for us and and marks a huge step forward in the ease of use of Mule and what you should expect from an integration platfrom. Not only has Mule Studio been significantly improved and the brand new DataMapper added, but Mule itself has also undergone a number of significant improvements.
With the flexibility and power of Mule Flows introduced in Mule ESB 3.0 along with Mule Studio including DataMapper and the improvements to Mule itself in this new release, Mule ESB 3.3 really is “Mule 3 Reloaded”. Read the recent whole product release announcement for an overview of everything that is being released with Mule ESB 3.3, then continue reading this post to get the low down on some of the most important new feature in Mule.
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:
Last month we released Mule 3.3 M1, our first milestone on the way to Mule 3.3. While for production you should use Mule 3.2.1, we hope these milestones are a great way to play around with the latest and greatest features. This is a great opportunity to provide feedback and have an impact on what we are doing for the Mule 3.3 release.
A couple of months back we released Mule 3.2, which is the version we recommend for all Mule users. The latest release of Mule 3.2 is Mule 3.2.1 which can be found on the download page.
We haven’t stopped though. Since releasing Mule 3.2.1, we’ve been busy working on Mule 3.3 M1. This is the first of a number of monthly milestones we will be making available to the community on the road towards Mule 3.3. In this blog post I’ll not only go over what’s new in M1, but also give you an idea of what we have planned for Mule 3.3.
In previous posts explaining the enterprise integration patterns with example Mule configuration I have covered Content-Enricher and Content-based Routing patterns, today I’ll talking about the “Message Filter” pattern.
Message Filter
How can a component avoid receiving uninteresting messages?
Use a special kind of Message Router, a Message Filter, to eliminate undesired messages from a channel based on a set of criteria.
The implementation of the Enterprise Integration Patterns, first documented by Gregor Hohpe, is an important aspect of Mule.
These patterns are accepted solutions to recurring problems within a given context and as such provide both a framework for both designing and building messaging and integration systems as well as a common language for teams to use when architecting solutions.
The fact that Mule implements these patterns greatly reduces the effort required when building integrations, you design your solution using these well-known patterns and then simply configure and use these same patterns in Mule.
In this “Integration Patterns” series of blog posts I’ll introduce the fundamental patterns people use when building Mule applications, noting anything specific to Mule and providing configuration examples. I’ll cover one pattern per post, let me know if there is anything specific you’d like me to cover. My first post covered the Content Enricher Pattern, today we’ll look at Content-based Routing.
One of the enterprise integration patterns that Mule hasn’t explicitly supported up until now is the “Content Enricher”. Enrichment has of course been possible but it hasn’t been as easy as it should have been. That’s changing for Mule 3.1 as we introduce support for message enrichment. Read on to learn what you can do with the new enricher and see some examples..
Mule 3 underwent some significant architectural improvements, I talked about this back when Mule 3.0 was released in my “Mule 3 Architecture: Back to Basics” blog post. These improvements enable a much simpler way of configuring Mule that is more powerful while at the same time much more intuitive. As we release Mule 3.1 I really want to encourage everyone to “Go with the Flow!!”
In this post we’ll cover the basics of “Mule Flow”; what it is, when to use it and how to integrate with it.
Mule 3.1 introduces a very useful new <logger> element that makes it easy to inspect the content and properties of your messages in Mule while building or debugging a flow. It’s also perfect for logging errors, info messages etc. Mule has always supported logging with the <log-component> but while working with the new orchestration capabilities of Mule 3 flows, we found a real need for fine grained logging. With the new message processor architecture, this was a snap and we were able to put together the new functionality in an afternoon. In this blog post I’ll take you on a quick tour of what you can do with it with some examples.
Sign up for our newsletter
