Expand Authors Top

If you have a few years of experience in the Java ecosystem and you’d like to share that with the community, have a look at our Contribution Guidelines.

Expanded Audience – Frontegg – Security (partner)
announcement - icon User management is very complex, when implemented properly. No surprise here.

Not having to roll all of that out manually, but instead integrating a mature, fully-fledged solution - yeah, that makes a lot of sense.
That's basically what Frontegg is - User Management for your application. It's focused on making your app scalable, secure and enjoyable for your users.
From signup to authentication, it supports simple scenarios all the way to complex and custom application logic.

Have a look:

>> Elegant User Management, Tailor-made for B2B SaaS

NPI – Spring Top – Temp – Non-Geo (Lightrun)

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

NPI – Lightrun – Spring (partner)

We rely on other people’s code in our own work. Every day. It might be the language you’re writing in, the framework you’re building on, or some esoteric piece of software that does one thing so well you never found the need to implement it yourself.

The problem is, of course, when things fall apart in production - debugging the implementation of a 3rd party library you have no intimate knowledge of is, to say the least, tricky. It’s difficult to understand what talks to what and, specifically, which part of the underlying library is at fault.

Lightrun is a new kind of debugger.

It's one geared specifically towards real-life production environments. Using Lightrun, you can drill down into running applications, including 3rd party dependencies, with real-time logs, snapshots, and metrics. No hotfixes, redeployments, or restarts required.

Learn more in this quick, 5-minute Lightrun tutorial:

>> The Essential List of Spring Boot Annotations and Their Use Cases

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.

In invoking a SOAP web service in Java, we did the same 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 do a quick recap of how we'd done that.

Following the contract-first approach, we first wrote an XML schema file defining the domain. We then 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

Here, we're going to build a Spring client to invoke and test the above web service.

Now, let's see step-by-step what all we need to do in order to create a client.

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:

  • Country.java and Currency.java – POJOs representing the data model
  • GetCountryRequest.java – the request type
  • GetCountryResponse.java – the response type

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

3.2. CountryClient

Next, we need to 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 take care 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 were able to extract the information we needed for our assertions using the generated data model POJOs, Country, and Currency.

5. Conclusion

In this tutorial, we saw the basics of how to invoke a SOAP web service using Spring WS.

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

As always, source code is available over on GitHub.

Spring bottom

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

Generic footer banner
Comments are closed on this article!