In your daily work as an integration developer you’re working with different kinds of patterns, even if you’re not aware of it.
Since Mule is based on EIP (Enterprise Integration Patterns) you’re most definitely using patterns when using Mule.
One of those patterns that seems to raise a lot of questions is the “fork and join pattern”. The purpose of the fork and join pattern is to send a request to different targets, in parallel, and wait for a aggregated response from all the targets.
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, which allows you to reduce the outbound traffic towards regularly (and of course cacheable) web resources.
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 this scenario it would be nice to automatically stop delivery for a certain period of time to not exacerbate the situation.
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.
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, even further, your own pattern catalogs.
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.
If you’ve peeked into Mule 3’s source code, you may have noticed that this effort is already on-going. Indeed, each of the newly introduced configuration patterns is backed by a builder class that is used to instantiate it. Read on for a quick demonstration of how this can be used…
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, the rest doesn’t matter.
But sometimes, a strict up-front validation of incoming messages is needed. This is that kind of scenarios that the Validator configuration pattern addresses.
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.
So we’ve built a bridge: it’s time we get over it!
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.
As announced before, Mule 3 will offer pattern-based configuration artifacts that will allow you to perform common configuration tasks with the least amount of XML. This first post opens the series where each of these patterns will be introduced.
The first configuration pattern we’d like to present is called: Simple Service. Its goal is as simple as its name suggests: provide a simple way to expose request-response services. In other terms, it is used to expose some business logic in a synchronous manner over the transport of your choice.