Used software: Mule ESB 3

In Mule ESB 3 they introduced the concept of Configuration Patterns. These patterns helps you simplify some specific but common integration scenarios.

In a previous article I showed how you can use Mule ESB to build a WS-SOAP proxy. As I stated there this is a common integration scenario and as such Mule ESB provides a pattern for it. This pattern is called Web Service Proxy Pattern.

To start with you need to define the pattern namespace. This is done by adding http://www.mulesoft.org/schema/mule/pattern with schema location http://www.mulesoft.org/schema/mule/pattern/current/mule-pattern.xsd. The example below is NOT a complete example you will have a lot more namespaces defined in your mule config file.

1
2
3
4
5

<mule xmlns:pattern="http://www.mulesoft.org/schema/mule/pattern" ... 
xsi:schemaLocation="
...
http://www.mulesoft.org/schema/mule/pattern http://www.mulesoft.org/schema/mule/pattern/current/mule-pattern.xsd
...">

The pattern tag is defined on the same level as a flow. You could say that a pattern is a flow it it self. In your mule configuration file you only have to add the following and you have a WS-SOAP proxy.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

   	<pattern:web-service-proxy name="SOAP2SOAPFlow3" doc:name="SOAP2SOAP proxy using pattern"
   		inboundAddress="http://localhost:8083/GreeterResponderService"
   		outboundAddress="http://localhost:8088/mockEchoBinding" 
   		wsdlFile="schemas/interactions/GreeterInteraction/GreeterInteraction_1.0.wsdl"
   		transformer-refs="proxy-transformer"
   		responseTransformer-refs="proxy-transformer"
   		/>   
   	<!-- Transformers used by the web-service-proxy pattern above -->
  	<mulexml:xslt-transformer name="proxy-transformer" maxIdleTransformers="2" maxActiveTransformers="5" 
        	outputEncoding="UTF-8" 
                doc:name="Transform from outer to inner and back again, used by the pattern flow" 
        	xsl-file="transform-pattern.xslt" encoding="UTF-8" returnClass="java.lang.String"/>

The inboundAddress attribute on the web-service-proxy element defines the inbound endpoint Mule will listen on and the outboundAddress defines the outbound endpoint to which Mule will proxy the request. In this case the inner service is a SoapUI mockservice.

Since I want the proxy to provide a external WSDL I also have the wsdlFile attribute that specified the WSDL for the external interface. Now calling http://localhost:8083/GreeterResponderService will serve up that WSDL file.

I found was that I had to add a path part to the inboundAddress. Without a path portion the retrieving WSDL from the proxy does not seem to work.

Since we want to transform the request to the inner format and the response to the outer format I add the transformer-refs and responseTransformer-refs. In this case I use the same transformer since my XSLT file is written so it handles both transformations.

One disappointing finding is that when the proxy serves up the WSDL it runs it through the response transformer which in some cases might not be what we want. However a well written XSLT will fix this.

Another finding is that the WSDL the proxy serves up does not allow us to fetch XSD files that are imported as is allowed when using a CXF component. This makes the WSDL useless when using external XSD files in you WSDL.

So to sum up. As described in the documentations the configuration patterns implement “very specific integration patterns” and they will simplify your configuration if and when you are implementing these specific patterns. However if you need to do something that is not in these patterns you will have to roll your own flow. Which to be honest is not that hard.

Full code example is available at github.