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,
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.
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.
Configuring Mule involves XML, and though using a decent XML editor can help a lot (thanks to the contextual help it provides from Mule’s schemas), there is still a enough angle brackets to warrant a coffee break as projects get more complicated.
As the number of services in a Mule project increases, so does the amount of noise in its configuration files, making it harder to understand and maintain them. We recommend splitting service configuration files,