Partner – Microsoft – NPI (cat= Spring)
announcement - icon

Azure Spring Apps is a fully managed service from Microsoft (built in collaboration with VMware), focused on building and deploying Spring Boot applications on Azure Cloud without worrying about Kubernetes.

And, the Enterprise plan comes with some interesting features, such as commercial Spring runtime support, a 99.95% SLA and some deep discounts (up to 47%) when you are ready for production.

>> Learn more and deploy your first Spring Boot app to Azure.

You can also ask questions and leave feedback on the Azure Spring Apps GitHub page.

1. Overview

Previously, we saw how to create a SOAP web service with Spring.

In this tutorial, we’ll learn how to create a Spring-based client to consume this web service.

We did the same in invoking a SOAP web service in Java using JAX-WS RI.

2. The Spring SOAP Web Service – a Quick Recap

Earlier, we had created a web service in Spring to fetch a country’s data, given its name. Before delving into the client implementation, let’s quickly recap how we’ve done that.

Following the contract-first approach, we wrote an XML schema file defining the domain. We used this XSD to generate classes for the request, response, and data model using the jaxb2-maven-plugin.

After that, we coded four classes:

Finally, we tested it via cURL by sending a SOAP request.

Now let’s start the server by running the above Boot app and move on to the next step.

3. The Client

We will build a Spring client to invoke and test the web service above.

Now, let’s see what we need to do to create a client step-by-step.

3.1. Generate Client Code

First, we’ll generate a few classes using the WSDL available at http://localhost:8080/ws/countries.wsdl. We’ll download and save this in our src/main/resources folder.

To generate code using Maven, we’ll add the maven-jaxb2-plugin to our pom.xml:


Notably, in the plugin configuration, we defined:

  • generateDirectory – the folder where the generated artifacts will be saved
  • generatePackage – the package name that the artifacts will use
  • schemaDirectory and schemaIncludes – the directory and file name for the WSDL

To carry out the JAXB generation process, we’ll execute this plugin by simply building the project:

mvn compile

Interestingly, the artifacts generated here are the same as those generated for the service.

Let’s list down the ones we’ll be using:

  • and – POJOs representing the data model
  • – the request type
  • – the response type

The service might be deployed anywhere in the world, and with just its WSDL, we could generate the same classes at the client end as the server!

3.2. CountryClient

Next, we must extend Spring’s WebServiceGatewaySupport to interact with the web service.

We’ll call this class CountryClient:

public class CountryClient extends WebServiceGatewaySupport {

    public GetCountryResponse getCountry(String country) {
        GetCountryRequest request = new GetCountryRequest();

        GetCountryResponse response = (GetCountryResponse) getWebServiceTemplate()
        return response;

Here, we defined a single method getCountry, corresponding to the operation that the web service had exposed. In the method, we created a GetCountryRequest instance and invoked the web service to get a GetCountryResponse. In other words, here’s where we performed the SOAP exchange.

As we can see, Spring made the invocation pretty straightforward with its WebServiceTemplate. We used the template’s method marshalSendAndReceive to perform the SOAP exchange.

The XML conversions are handled here via a plugged-in Marshaller.

Now let’s look at the configuration where this Marshaller is coming from.

3.3. CountryClientConfig

All we need to configure our Spring WS client are two beans.

First, a Jaxb2Marshaller to convert messages to and from XML, and second, our CountryClient, which will wire in the marshaller bean:

public class CountryClientConfig {

    public Jaxb2Marshaller marshaller() {
        Jaxb2Marshaller marshaller = new Jaxb2Marshaller();
        return marshaller;
    public CountryClient countryClient(Jaxb2Marshaller marshaller) {
        CountryClient client = new CountryClient();
        return client;

Here, we need to ensure that the marshaller’s context path is the same as generatePackage specified in the plugin configuration of our pom.xml.

Please also notice the default URI for the client here. It’s set as the soap:address location specified in the WSDL.

4. Testing the Client

Next, we’ll write a JUnit test to verify that our client is functioning as expected:

@ContextConfiguration(classes = CountryClientConfig.class, loader = AnnotationConfigContextLoader.class)
public class ClientLiveTest {

    CountryClient client;

    public void givenCountryService_whenCountryPoland_thenCapitalIsWarsaw() {
        GetCountryResponse response = client.getCountry("Poland");
        assertEquals("Warsaw", response.getCountry().getCapital());

    public void givenCountryService_whenCountrySpain_thenCurrencyEUR() {
        GetCountryResponse response = client.getCountry("Spain");
        assertEquals(Currency.EUR, response.getCountry().getCurrency());

As we can see, we wired in the CountryClient bean defined in our CountryClientConfig. Then, we used its getCountry to invoke the remote service as described earlier.

Moreover, we could extract the information we needed for our assertions using the generated data model POJOs, Country, and Currency.

5. Conclusion

In this tutorial, we learned how to invoke a SOAP web service using Spring WS.

We merely scratched the surface of what Spring offers in the SOAP web services area; there’s lots to explore.

As always, the source code is available on GitHub.

Course – LS (cat=Spring)

Get started with Spring and Spring Boot, through the Learn Spring course:

res – REST with Spring (eBook) (everywhere)
Comments are open for 30 days after publishing a post. For any issues past this date, use the Contact form on the site.