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.
In Mule 3 we are now able to clearly define a chain of message processing steps and see exactly what is being applied and in which order. This was unfortunately not the case in previous versions of Mule where transformers and filters were defined as attributes on the endpoint or the router.
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.
Following the general availability of Mule 3.0.0 Community Edition, I’m happy to announce the release of the following MuleForge projects, which have been upgraded to work with Mule 3:
* JCR Transport – A transport that reads from, writes to and observes JCR 1.0 containers.
* Erlang Transport – A transport that can send and receive messages to and from Erlang nodes.
* Common Retry Policies –
As you may have heard, Mule 3 has undergone a streamlining of its internal architecture. It’s now my job to explain what’s changed, why and what this means to you. I can’t promise it will be as exciting as a children’s movie but I will attempt to explain things as clearly as possible so that everyone can understand the concepts which in turn will help you use Mule 3 to its fullest.
The Mule IDE does not natively support Mule 3’s new application structure yet, but not to worry, with the new 2.1 release of the Mule IDE you can still keep it hot when working in the IDE. Just follow a few simple steps and your apps will be doing the tango with Mule 3 while you code away in Eclipse.
MuleSoft will be at Oracle OpenWorld at booth #1833 (Moscone South) again this year. Come join us to experience firsthand the simplicity of Tcat Server and how it makes running Tomcat in production painless. We will also preview exciting new features of Tcat Server including dashboards, monitoring, alerting and fine-grained security permissions.
ActiveMQ in Action, an upcoming book from Manning Publications, may well end up being the perfect companion book for Mule In Action.
Happily Ever After…
Thanks to Mule ESB’s native support for Apache ActiveMQ and the capacity to transparently use Spring for advanced configuration needs, Mule has long been the ESB of choice to tap into ActiveMQ’s JMS goodness.