Enterprise Integration Zone is brought to you in partnership with:

Steve Daskam is currently a Senior Java Developer and Tech Lead at hotels.com Steve has posted 1 posts at DZone. You can read more from them at their website. View Full User Profile

Web Services with Mule, CXF, and Spring

  • submit to reddit


In order to get our service to run under Mule, we need to create two configuration files:
1) the Spring config file
2) the Mule config file

The Spring Configuration File

The config file for Spring is shown below. We declare our service implementation bean that will be loaded by the Spring container. We'll save this to a file called catalogContext.xml.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"

<bean id="productCatalogService"



The Mule Configuration File

Using the configuration shown below, we first tell Mule the name of our Spring config file. The Mule integration with Spring is excellent.

Next, we setup our service. We declare that the inbound endpoint uses CXF and we define the URL for the service address. We also declare that our Spring-loaded bean is the component that will handle the requests for this service.

We'll save this to a file called catalogservice-config.xml.

<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns="http://www.mulesource.org/schema/mule/core/2.0"
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://www.mulesource.org/schema/mule/core/2.0 http://www.mulesource.org/schema/mule/core/2.0/mule.xsd
http://www.mulesource.org/schema/mule/soap/2.0 http://www.mulesource.org/schema/mule/soap/2.0/mule-soap.xsd
http://www.mulesource.org/schema/mule/cxf/2.0 http://www.mulesource.org/schema/mule/cxf/2.0/mule-cxf.xsd">

<spring:import resource="catalogContext.xml"/>

<model name="services">
<service name="ProductCatalogService">
<cxf:inbound-endpoint address="http://localhost:65082/services/ProductCatalogService" />
<spring-object bean="productCatalogService" />



Build and Deployment

Now that we have our classes and config files created, the next step is to compile the classes and package them up into a jar file. This jar file will then be deployed to the lib/user directory of your Mule installation (i.e. MULE_HOME/lib/user).

Starting the service

To run the service in Mule, you will need to execute the following via command prompt or script:
In Windows: MULE_HOME/bin/mule.bat -config <path-to-config-file>\catalogservice-config.xml
In Unix: MULE_HOME/bin/mule start -config <path-to-config-file>\catalogservice-config.xml

To ensure that the service is running, open up your web browser and go to the following URL:

You should see the WSDL file that has been generated for our service.

Testing the service with SoapUI

Once Mule is up and running with the service, you can easily test it with the free open-source web services testing tool, soapUI. This can be downloaded at:

After launching soapUI, you can create a new project by selecting "New WSDL Project" from the File menu. You will get the following dialog, where you can enter the Project Name and Initial WSDL URL.

Once the project is created, expand the tree, and you should see something like this:


From here, you can double-click on the "Request 1" item under listProducts to open the Request Editor for this operation. Next, just click on the green arrow to call the service. You should see the results as shown below:

You can make the call to the getProductDetail operation in a similar manner. After you open the Request Editor for that operation, just replace the question mark within the <productId> tag with a valid product Id such as SW123. Next, click the green arrow to make the call, and you should get back the SOAP response containing the Product attributes in XML format.

Wrap Up

Using the Mule, CXF, and Spring frameworks, you can quickly get web services up and running. These frameworks give you a lot of flexibility and offer a whole lot more functionality than was covered here. But hopefully this will give a good starting point for further research.


Article Resources: 
Published at DZone with permission of its author, Steve Daskam.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Jason Whaley replied on Fri, 2008/07/04 - 4:28pm

Decent article. I work day to day with a suite of web services implemented with the exact same stack (but using a wsdl first approach).  It, for the most part, gets the job done, although there was more legwork involved than what you've described due to the fact a wsdl first approach was selected.

However, I think this article lacks in showing the real strength of the mule esb, which is applying transformations, multiple/chainable routing, and abstracting the protocol away from the implementation (e.g. seamlessly going from a web service call over HTTP to a JMS queue, yet your code never knows that's happening), and in general sitting in front or behind the web service doing such work and not being solely there for containing the web service.

Richard Yang replied on Thu, 2008/09/18 - 11:28am

Excellent article. The author covered everything what he said at the beginning and mentioned that there were more to explore at the conclusion.  Will someone cover the advanced/other features?

Hat off to Steve Haskam.


Balu Gulla replied on Sun, 2009/10/18 - 10:35pm


I'm learing mule, I impressed with your blog, If you any mule related blogs please let me know. 



Jammy Chen replied on Mon, 2012/12/03 - 10:24am

Really nice article. Recently I am learning that use CXF and Spring to publish web service. I just want to share another same excellent article  http://www.asjava.com/web-services/cxf-spring-support/ 

Ga Sita replied on Thu, 2011/05/12 - 9:14pm

Nice article, Anyone has any experience for consuming a SAP webservice and transforming it to different form to another endpoint in mule? thanks.

David Mccullough replied on Wed, 2013/11/06 - 11:13am

I have a couple of questions (new to mule)

Is the  catalogservice-config.xml a separate file from the *.mflow?

Is there an easy way to test this in studio?

David Mccullough replied on Wed, 2013/11/06 - 11:15am

I have a couple of questions (new to mule)

Is the  catalogservice-config.xml a separate file from the *.mflow?

Is there an easy way to test this in studio?

I am having problems with the following in my *.mflow file compiling in Mulestudio.

<spring:beans><spring:import resource="catalogContext.xml"/></spring:beans>

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.