Modules extend Mule’s functionality by providing namespace support for a certain set of message processors. The following table contains some of the modules provided by Mule.
||JSON support, including marshaling, transformation and filtering.
||SOAP support via Apache CXF
||JAX-RS support for publishing RESTful services.
||Support for JSR-223 compliant scripting language, like Groovy or Rhino.
||XML support, including XML marshaling, XPath and XSLT support.
The full list of available modules is available in the official Mule documentation. Additional modules are available on MuleForge.
Use MuleForge.org to locate community-written extensions.
Bridging REST to SOAP
The following demonstrates how the CXF module can be used to bridge a RESTful service to a SOAP service.
The inbound-endpoint accepts HTTP POST requests to http://localhost:8080/service. The POST data is then sent to the SOAP service defined by the CXF jaxws-client.
Routers implement the Enterprise Integration patterns (EIP) and determine how messages are directed in a flow.
The following table contains commonly used routers
||Sends the message to each endpoint.
||Sends the message to the first endpoint that matches.
||Sends the message to all endpoints in the expression evaluated with the given evaluator.
||Each message received by the router is sent to alternating endpoints.
||Sends a copy of the message to the supplied endpoint then passes the original message to the next processor in the chain.
||Sends the message to the first endpoint that doesn’t throw an exception or evaluates the failureExpression to true.
||Will split the current message into parts using an expression or just split elements of a List.
||Will collect related messages and create a message collection.
Transformers modify the message and pass it to the next message in the chain.
The following table contains commonly used transformers.
||Adds and removes properties from a message, optionally specifying their scope.
||Many basic type transformers are included.
||Transforms JAXB objects explicitly.
||Will automatically find the best transformer for a specified type.
||Transforms a message using the given stylesheet.
||Transforms message payloads to and from JSON.
||Compresses and uncompress message payloads using gzip.
||Encrypts and decrypts message payloads.
Endpoints often include their own transformers. JMS for instance, allows transformers to convert message payloads to and from JMS messages automatically.
Components allow business logic to be executed in a flow. Any Java object or script can be used as a component. Components are configured by either identifying the class or providing a reference to a Spring bean for dependency injection.
The following snippet shows how a class called MyService can be configured as a component using a class and via dependency injection via Spring.
Mule will use the type of the payload of the message being processed to determine what method to invoke. It’s often necessary, however, to explicitly specify the method to invoke. Entry point resolvers are used for this purpose. The following table contains a list of available resolvers.
||Resolves the method using the specified name.
||Resolves the method using the specified message property.
||A Java class that implements org.mule.api.model.EntryPointResolver or extends org.mule.model.resolvers. AbstractEntryPointResolver.
The use of entry point resolvers allows you to use POJO’s as components, decoupling your code from Mule. Sometimes, you will want access to the MuleMessage or MuleContext when processing a message. In cases like this, you can implement the org.mule.api.lifecycle.Callable interface. Callable includes a single method, onCall, to implement that provides direct access to the MuleMessage when the method is invoked.
In addition to custom components, Mule provides the following utility components.
||Returns and passes along.
||Helps test message flows (in the test namespace).
Try to avoid implementing Callable to keep your component code decoupled from Mule’s API.
Filters selectively pass messages to the next processor in the chain.
The following table contains commonly used filters.
||Passes messages using any of the expressions languages supported by Mule.
||Decides what messages to pass by applying the supplied regular expression to the message payload.
||Passes messages only of the given type.
||Specifies the class of a custom filter that implements the org.mule.api.routing.filter.Filter interface.
|and-filter, or-filter, not-filter
||Logic filters that work with other filters.
Using Filters with XPath
The following example demonstrates how the xpath-filter can be used to only pass certain XML documents. In this case, only order XML documents containing a certain ZIP code are allowed to pass.
<flow name=”Filter messages using the XPath filter”>