Skip to content

Latest commit

 

History

History
89 lines (62 loc) · 4.42 KB

understanding-configuration-patterns-using-mule.adoc

File metadata and controls

89 lines (62 loc) · 4.42 KB
Raw

Understanding Configuration Patterns Using Mule

Flows and Configuration Patterns

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.

The Configuration Patterns:

There are currently four configuration patterns in Mule. All of them are in the pattern namespace.

Bridge

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,

Simple Service

The simple service pattern is used to expose a component as a request-response service. Several types of components are supported:

  • POJOs

  • JAX-WS services

  • JAX-RS services

  • 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,

Validator 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.

Web Service Proxy

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