SOAP Web Services using CXF with Spring

In this tutorial we are going to see how to implement SOAP Web Services using Spring Framework. In this example we’ll use a Contract-First approach. This approach encourages you to think of the service contract first, in terms of XML, using XML schema (.xsd) and WSDL. In this approach, you design the request and response messages for your service first. The messages are designed with XML, which is very good at representing complex data structures in a platform-and language-independent way. The next step is to implement this contract in a particular platform and programming language, in this case Java.

There are two possible ways to develop a SOAP web service: application servers incorporating or stand-alone web application. In the first case a SOAP Engine or JAX-WS Runtime (like Axis, CXF or Metro) needs to be installed in the Application Server. A stand-alone application instead it’s not Application Server dependent and it can be deployed in a Servlet Container like Tomcat. Tomcat doesn’t support JAX-WS by itself, so we need to help it by embedding a JAX-WS runtime.

What we will see is a stand-alone web application that expose a SOAP web service that calculate the sum of a list of integer.


  • Spring 3.1.1
  • CXF 2.2.3

1. WSDL file

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<wsdl:definitions xmlns:soap="" xmlns:tns="" xmlns:wsdl="" xmlns:xsd="" name="MyService" targetNamespace="">
    <xsd:schema targetNamespace="">
      <xsd:element name="SumRequest">
            <xsd:element name="addend" type="xsd:int" minOccurs="2" maxOccurs="unbounded"/>
      <xsd:element name="SumResponse">
            <xsd:element name="sum" type="xsd:int"/>
  <wsdl:message name="SumIn">
    <wsdl:part element="tns:SumRequest" name="parameters"/>
  <wsdl:message name="SumOut">
    <wsdl:part element="tns:SumResponse" name="parameters"/>
  <wsdl:portType name="MyService">
    <wsdl:operation name="Sum">
      <wsdl:input message="tns:SumIn"/>
      <wsdl:output message="tns:SumOut"/>
  <wsdl:binding name="MyServiceSOAP" type="tns:MyService">
    <soap:binding style="document" transport=""/>
    <wsdl:operation name="Sum">
      <soap:operation soapAction=""/>
        <soap:body use="literal"/>
        <soap:body use="literal"/>
  <wsdl:service name="MyService">
    <wsdl:port binding="tns:MyServiceSOAP" name="MyServiceSOAP">
      <soap:address location=""/>

2. The POM file

<project xmlns="" xmlns:xsi=""
	<name>Spring SOAP</name>


		<!-- Spring framework -->
		<dependency> <!-- Used for REST -->

		<!-- Web Service runtime -->


3. Generate the classes

Now, let’s execute the command mvn generate-sources in the project directory. The cxf-codegen-plugin will generate the Web Service interface, with the JAX-WS annotations. Will be also generated a JAXB2 annotated classes for every type defined in the WSDL file (in this case SumRequest and SumResponse). All those files will be placed under /target/generated.

Below the code of the generated classes.

package org.madbit.myservice;

import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebResult;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.jws.soap.SOAPBinding.ParameterStyle;
import javax.xml.bind.annotation.XmlSeeAlso;

@WebService(targetNamespace = "", name = "MyService")
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
public interface MyService {

    @WebResult(name = "SumResponse", targetNamespace = "", partName = "parameters")
    @WebMethod(operationName = "Sum", action = "")
    public SumResponse sum(
        @WebParam(partName = "parameters", name = "SumRequest", targetNamespace = "")
        SumRequest parameters

package org.madbit.myservice;

import java.util.ArrayList;
import java.util.List;
import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlRootElement;
import javax.xml.bind.annotation.XmlType;

@XmlType(name = "", propOrder = {
@XmlRootElement(name = "SumRequest")
public class SumRequest {

    @XmlElement(type = Integer.class)
    protected List<Integer> addend;

    public List<Integer> getAddend() {
        if (addend == null) {
            addend = new ArrayList<Integer>();
        return this.addend;

package org.madbit.myservice;

import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlRootElement;
import javax.xml.bind.annotation.XmlType;

@XmlType(name = "", propOrder = {
@XmlRootElement(name = "SumResponse")
public class SumResponse {

    protected int sum;

    public int getSum() {
        return sum;

    public void setSum(int value) {
        this.sum = value;

4. Implement the Web Service endpoint

Now we it’s time to create the Web Service implementation, that is the class which contains the business logic of the service. Let’s call this class It implements the MyService interface previously generated as following:

package org.madbit.soap;

import org.madbit.myservice.MyService;
import org.madbit.myservice.SumRequest;
import org.madbit.myservice.SumResponse;

public class MyServiceImpl implements MyService {

	public SumResponse sum(SumRequest parameters) {
		int sum = 0;
		for(Integer i: parameters.getAddend()){
			sum += i;
		SumResponse response = new SumResponse();
		return response;

5. Exposing a Web Service Using CXF

Exposing a stand-alone SOAP endpoint using the SimpleJaxWsServiceExporter or the support for JAX-WS in a Java EE container in conjunction with Spring is simple, but these solutions ignore the largest cross-section of developers—people developing on Tomcat. Here again, we have plenty of options.
Tomcat doesn’t support JAX-WS by itself, so we needto help it by embedding a JAX-WS runtime. There are many choices, and you’re free to take your pick. Two popular choices are Axis2 and CXF, both of which are Apache projects. CXF represents the consolidation of the Celtix and XFire projects, which each had useful SOAP support. For our example, we’ll embed CXF since it’s robust, fairly well tested, and provides support for other important standards like JAX-RS, the API for REST-ful endpoints. Setup is fairly straightforward. You’ll need to include the CXFdependencies on your classpath, as well as the Spring dependencies.
Let’s walk through the moving pieces for configuration. A good place to start is the web.xml file. In our simple example, web.xml looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="" xmlns:xsi=""

	<display-name>AppStore Gateway</display-name>


	<!-- Servlet for SOAP -->

This web.xml file will look pretty much as all Spring MVC applications do. The only exception here is that we’ve also configured a CXFServlet, which handles a lot of the heavy lifting required to expose our service. In the Spring MVC configuration file, weather-servlet.xml, we’ll declare a bean for the weather service implementation and export it as a web service by using the Spring namespace support that CXF provides for configuring services (as well as clients, which we’ll soon see).
The Spring context file is underwhelming; most of it is boilerplate XML namespace and Spring context file imports. The only two salient stanzas are below, where we first configure the service itself as usual. Finally, we use the CXF jaxws:endpointnamespace to configure our endpoint.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns=""
	xmlns:xsi="" xmlns:aop=""
	xmlns:jaxrs="" xmlns:simple=""
	xmlns:soap="" xmlns:jaxws=""
	<import resource="classpath:META-INF/cxf/cxf-servlet.xml" />
	<import resource="classpath:META-INF/cxf/cxf.xml" />
	<import resource="classpath:META-INF/cxf/cxf-extension-soap.xml" />
	<bean id="myServiceImpl" class="org.madbit.soap.MyServiceImpl" />
	<jaxws:endpoint implementor="#myServiceImpl"
			<soap:soapBinding style="document" use="literal" version="1.1" />

We tell the jaxws:endpointfactory to use our Spring bean as the implementation. We tell it at what address to publish the service using the address element. Note that we’ve found that using a forward slash at the beginning of the address is the only way toget the endpoint to work reliably across both Jetty and Tomcat; your mileage may vary. We also specify some extra niceties like what binding style to use.
You don’t need to, of course. This is mainly for illustration. The Java code stays the same as before, with the javax.jws.WebServicemethod and javax.jws.WebMethodannotations in place. Launch the application and your web container, and then bring upthe application in your browser. In this example, the application is deployed at the root context (/), so the SOAP endpoint is available at http://localhost:8080/spring-soap/soap/MyService. If you bring upthe page at http://localhost:8080/, you’ll see a directory of the available services and their operations. Click the linkfor the service’s WSDL—or simply append ?wsdlto the service endpoint—to see the WSDL for the service. WSDL describes the messages and endpoint to clients. You can use it to infer a client to the service on most platforms.

Invoking a Web Service Using CXF

Let’s now use CXF to define a web service client. We’ll want one to work with our new weather service, after all! Our client is the same as in previous recipes, and there is no special Java configuration or coding to be done. We simply need the interface of the service on the classpath. Once that’s done, you can use CXF’s namespace support to create a client.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns=""
xsi:schemaLocation=" ?
	<import resource="classpath:META-INF/cxf/cxf-extension-soap.xml"/>
	<import resource="classpath:META-INF/cxf/cxf.xml"/>
	<import resource="classpath:META-INF/cxf/cxf-servlet.xml"/>
	<jaxws:client serviceClass="org.madbit.soap.MyService" address="http://localhost:8080/spring-soap/soap/MyService" id="myService"/>
	<bean class="org.madbit.soap.MyServiceClient" id="client">
		<property name="myService" ref="myService"/>

We use the jaxws:clientnamespace support to define to which interface the proxy should be bound, and the endpoint of the service itself. That is all that’s required. Our examples from previous recipes works otherwise unchanged: here we inject the client into the MyServiceClient and invoke it.

If you want to learn more retro games news, read our magazine and subscribe to our newsletter.