The configuration patterns series continues with this new installment!
We’re happy to announce that a new configuration pattern made its way into Mule 3.3. This new pattern, named HTTP Proxy, will come in handy when remote web resources need to be accessed in a controlled manner, for example when it is not desirable to have numerous internal applications depend directly on external services.
It also supports caching,
One of my favorite patterns from Michael Nygard’s excellent Release It! is the Circuit Breaker. A circuit breaker is an automatic switch that stops the flow of electricity in the event of a failure. This sort of behavior is also useful when integrating with remote systems.
We might want to stop message delivery on an outbound-endpoint after a certain exception is thrown. A remote system under load or the target of a denial-of-service attach is a good example.
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.
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,
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..
If you follow this blog or what’s happening in Mule 3, you’ve heard about the newly introduced configuration mechanism based on patterns. In the coming releases of Mule, we will keep adding new patterns based on users feedback and requests.
But this doesn’t mean your experience with configuration patterns will be limited to the ones that come with Mule distributions: we have made it easy for you to create your own patterns and,
True to our goal of simplifying the configuration of Mule, we will be adding the capacity to programmatically configure Mule 3 in the coming releases.
With configuration patterns aiming at reducing the amount of XML configuration and a new IDE in the works for graphically configuring Mule, the third angle we wanted to take on simplification was the creation of an API fluent enough that it becomes possible to configure Mule with your favorite JVM language.
The pattern-based configuration series continues! After a first set of fairly generic patterns, this new addition will demonstrate how highly specialized patterns can provide value too.
When processing messages, a certain format is always assumed to have been respected so that the required data can be retrieved. It is possible and oftentimes desirable to be very liberal with the data representation used by incoming messages: as long as you can find the needed pieces of information,
Web Service Proxy was the last configuration pattern presented in this blog. Time for a new one!
Connecting systems together is one of the most essential task of integration. Mule ESB offers the necessary building blocks for achieving such connections. One of these building blocks allows establishing bridges between message sources and destinations. Known as the messaging bridge pattern, this building block is available in Mule 3 as the newly introduced Bridge configuration element.
After the introduction of Simple Service, the configuration patterns series continues!
The second pattern we would like to introduce is Web Service Proxy. Proxying web services is a very common practice used for different reasons like security or auditing. This pattern allows a short and easy configuration of such a proxy.