Mule ESB is great at solving integration problems, whether it’s using a couple of connectors to create a simple flow or a full blown eco-system of integration patterns and flows.
Inevitably when considering integration one has to tackle service orchestration. This is relatively trivial when tying together some APIs via REST but orchestrating SOAP based web services always seems to throw a few curveballs for the uninitiated.
So what are the most effective and expedient ways of using mule to orchestrate these services?
There are several ways of using Mule ESB to consume SOAP based web services:
- CXF JaxWS Client
- CXF Client Proxy
- Web Service Consumer connector
- Web Service Consumer with Data Weave
Each method will be looked at in terms of ease of use and enterprise licensing.
The use cases will provide a RESTful request and response thus protecting the client from anything too soapy.
CXF Client
Ease of Use
With the CXF service client it’s best to generate the client classes from a WSDL. This can be achieved by using the CXF command line tool, the cxf-codegen maven plugin or generating the client from “Generate from WSDL” button from the mule CXF module. (My personal preference is using the POM plugin as I get the source generation repeatable as part of the build with all the control of the command line).
The client class, port and operation then need to be manually entered against the CXF connector.
You will need to ensure the payload prior to the CXF is set to the correct JAXB object and set the HTTP request connector to where the service is actually hosted.
If you prefer to manipulate the request and response as JAXB objects rather than XML then you might like this option.
OK, it’s not hard to do, but there’s still a fair bit of boilerplate code needed just to call my web service. Not rocket science, but neither is brain surgery.
Enterprise Licensing
None.
CXF Client Proxy
Ease of Use
Pretty simple. No client code generation needed. Set the XML payload, a bit more boilerplate configuration before and after the call than I’d like, such as explicitly setting the SOAP action, but all in all it’s ok.
Enterprise Licensing
Nope.
Web Service Consumer
Ease of Use
Easy peasy lemon squeezy. No source code generation, point the web service consumer to the WSDL and bingo, bango, bongo, done. Select the method you want from a convenient drop down and set the payload to the XML of the inner part of a SOAP request.
Less configuration is required to construct the request and response than before. Which is nice.
Enterprise Licensing
Nada.
Web Service Consumer with DataWeave
Ease of Use
Easy like Sunday Morning. Which is easier that lemon squeezy. Unless you have kids, where Sunday morning is much the same as any other. But I digress. Point the web consumer to the WSDL as before. This time add a data-weave transformer before the web service consumer. Using datasense the structured output from the data-weave is already known to be the request message for the web service consumer. It simply then a case of mapping your incoming data, e.g. JSON to the request.
Likewise a data-weave added after a web service consumer has its input set by default to the response data structure of the ws consumer. Mapping the required response becomes a trivial matter.
There’s bugger all boilerplate configuration and it’s soooo clean. Must be all that soap.
Enterprise Licensing
Yes, the use of data-weave is an enterprise feature.
Conclusion
The use case of the CXF client is not compelling enough given the downsides. The cxf proxy doesn’t require boilerplate code and as much configuration but if you want simplicity without enterprise licensing, go for the ws consumer option.
If using the enterprise edition is not an issue, go for ws consumer with data-weave. This is by far the simplest and fastest method. Integration becomes fun – kinda.
