Understanding Configuration Patterns Using Mule
In Mule 3, you have two choices for creating a message-processing flow:
Flows, new in Mule 3, are the most powerful and flexible choice. You can choose from all of the message processors Mule provides, including filters, transformers, routers, components, and others, as well as creating your own, and combine them however you like to implement exactly the logic you need.
Configuration patterns, which are, by design, not as powerful as either of the others. They have instead been designed for ease of use. The four configuration patterns that exist today make things that people do all the time simple, understandable, and fast to create.
In short, if one of the configuration patterns solves your problem, use it. It’s like using a library class that solves a programming problem instead of coding a new one that duplicates it. If your problem doesn’t match one of the configuration patterns, use a flow.
There are currently four configuration patterns in Mule. All of them are in the pattern namespace.
The bridge pattern is used to bridge an inbound and outbound endpoint. Here’s an example that bridges an http and vm endpoint:
<pattern:bridge name="request-response-bridge" inboundAddress="http://localhost:8080/orderService" outboundAddress="jms://orderQueue" />
This example illustrates the goal of minimal configuration: nothing needs to be configured except what is absolutely required. To learn more about the capabilities of the bridge pattern, see Bridge Pattern,
The simple service pattern is used to expose a component as a request-response service. Several types of components are supported:
JAXB and XPath processing components
Here’s a simple example that, once again, shows minimal configuration, in this case to expose a POJO as a service:
<pattern:simple-service name="maths-service" address="vm://maths.in" component-class="org.mule.tck.services.SimpleMathsComponent" />
To learn more about the capabilities of the simple service pattern, see Simple Service Pattern,
The job of the Validator pattern is to ensure that a message is well-formed before sending it to be processed. This pattern demonstrates not only minimal configuration but separation of concerns: different configuration objects are responsible for
Validating the input
Defining the positive and negative status messages returned to the caller
Declaring where well-formed messages are sent.
Here’s a simple example that illustrates all of those:
<pattern:validator name="integer-validator" inboundAddress="vm://validator.in" ackExpression="#[string:GOOD:#[message:payload]@#[context:serviceName]]" nackExpression="#[string:BAD:#[message:payload]@#[context:serviceName]]" outboundAddress="vm://test-service.in"> <payload-type-filter expectedType="java.lang.Integer"/> </pattern:validator>
The filter validates that the message is an Integer, the ack and nack expressions define the positive and negative status messages, and the address declares where a valid message is sent. To learn more about the capabilities of the validator pattern, see Validator Pattern.
The Web Service Proxy pattern creates a proxy for a web service at an endpoint serviced by Mule. This endpoint will advertise WSDL for the service, with the service’s address rewritten to point to the proxy. Here’s a simple example:
<pattern:proxy name="weather-forecast-ws-proxy" inboundAddress="http://localhost:8090/weather-forecast" outboundAddress="http://ws.acme.com:6090/weather-forecast" />
The WSDL which can be fetched from
http:/ /localhost:8090/weather-forecast?wsdl will make the service appaer to be at
http:/ /localhost:8090/weather-forecast. To learn more about the capabilities of the web service proxy pattern, see Web Service Proxy Pattern