Overview

If you need reliable SOAP web services that behave like grown ups and not like Tuesday morning production incidents then this guide walks through a contract first approach with Spring. You will see how to go from an XSD to Java models and then to a live WSDL that clients can actually consume. Keywords to flex during standups include SOAP, Spring WS, WSDL, XML, marshalling, Endpoint and SoapUI.

What this covers

• Project setup and dependencies to add with Maven or Gradle
• Designing an XSD and generating Java classes with JAXB or XJC
• Wiring Spring WS beans so the WSDL shows up
• Implementing @Endpoint handlers and keeping business logic out of the way
• Configuring marshalling with Jaxb2Marshaller or message converters
• Testing with SoapUI and adding simple security ideas like HTTPS and WS Security headers

Project setup

Create a Spring Boot project and add your Spring Web Services dependency along with a JAXB or Jackson XML binding library. Let Maven or Gradle manage the drama. You do not need magic plugins to get started, just the usual dependency entries and a main application class.

Dependencies and build

Include Spring WS support and an XML binding tool. Common choices are Jaxb2 or Jackson XML. They will let you marshal and unmarshal XML payloads so your endpoint can speak both human and machine.

Design the XSD and generate models

Start with an XML schema that describes request and response messages. This is contract first territory which prevents future arguments about who promised what. Use JAXB or XJC to generate Java classes from the XSD. Generated classes reduce hand typed errors and keep runtime validation simple.

Configure Spring WS beans

Register a MessageDispatcherServlet so SOAP messages reach Spring WS. Declare a DefaultWsdl11Definition bean and wire an XsdSchema bean that points to your schema file. That combination will expose a WSDL based on your XSD at a predictable URL for client discovery. Think of it as publishing a map before sending people into the jungle.

Implement endpoints and services

Annotate your handler class with @Endpoint and map handler methods with @PayloadRoot. Keep the endpoint thin and focused on translating requests to service calls. Put the actual business logic in a separate service class so unit tests are mercifully easy to write.

Handler responsibilities

• Unwrap the request object
• Call the service layer for business rules
• Wrap and return the response object

Configure marshalling and WSDL generation

Provide a Jaxb2Marshaller bean or configure a message converter and point it at the generated package that contains your JAXB classes. DefaultWsdl11Definition will use the XSD and schema location settings to create a WSDL. Consumers can retrieve the WSDL and use it to generate client stubs in their favorite language or their least favorite legacy framework.

Test and secure the service

Run the application and exercise the SOAP operations with SoapUI or a simple Java client. Validate incoming XML against the schema to catch nonsense payloads early. For production think about transport level security with HTTPS and message level protections such as WS Security headers if you need authentication or message integrity.

Quick checklist

• Create XSD and generate JAXB models
• Wire MessageDispatcherServlet and DefaultWsdl11Definition
• Expose XsdSchema so the WSDL is generated
• Implement @Endpoint handlers and keep services testable
• Configure Jaxb2Marshaller or equivalent
• Test with SoapUI and add HTTPS or WS Security for production

Final words

This approach gives you a maintainable contract first SOAP service powered by Spring. You get schema driven models, predictable WSDL generation and endpoints that do their job without pretending to be application servers. Now go make the clients happy or at least less likely to yell at you on Slack.