Took a look at Spring-WS and came up with a quick example service to describe its use. I decided to build the not-so-exciting but yet functional ‘echo’ service. Send in a text and it will echo that back with a date and time appended to the text.

After building the application I saw that Spring-WS comes with a sample echo service application. Oh well. Since I put in the effort here is the article on it.

Spring-WS encourages document based web services. As you know there are mainly two types of web services:

• RPC based.
• Document based.

In RPC you think in terms of traditional functional programming. You decide what operations you want and then use the WSDL to describe the operations and then implement them. If you look at any RPC based WSDL you will see in the binding section the various operations.

In the document based approach you no longer think of operations (their parameters and return types). You decide on what XML document you want to send in as input and what XML document you want to return from your web service as a response.

Spring-WS encourages a more practical approach to designing document based web services. Rather than think WSDL, it pushes you to think XSD (or the document schema) and then Spring-WS can auto-generate the WSDL from the schema.

Lets break it up into simpler steps:

1. Create your XML schema (.xsd file). Inside the schema you will create your request messages and response messages. Bring up your favorite schema edit or to create the schema or write sample request and response XML and then reverse-engineer the schema (check if your tool supports it).
2. You have shifted the focus onto the document (or the XML). Now use Spring-WS to point to the XSD and set up a few Spring managed beans and soon you have the web service ready. No WSDL was ever written.

Spring-WS calls this the contract-first approach to building web services.

Lets see the echo service in action. You will notice that I do not create any WSDL document throughout this article.

BusinessCase:

Echo service takes in an XML request document and returns an XML document with a response. The response contains the text that was sent in, appended with a time stamp.
RequestXML Sample:

The schema XSD file for this can be found in the WEB-INF folder of the application (echo.xsd).
ResponseXML Sample:

The schema XSD file for this can be found in the WEB-INF folder of the application (echo.xsd).

If you inspect the SOAP request and response you will see that this XML is whats inside the SOAP body. This is precisely what is document based web services.
EchoService Implementation:

Here is the echo service Java interface and its related implementation. As you can see this is a simple POJO.

Now the Spring-WS stuff:

Here is the web.xml.

Only thing to note in the web.xml is the Spring-WS servlet.

Next is the all important Spring bean configuration XML (spring-ws-servlet.xml).

• Registered the ‘echoService’ implementation bean.
• Registered an endpoint class named ‘echoEndpoint’. The endpoint is the class that receives the incoming web service request.
• The endpoint receives the XML document. You parse the XML data and then call our echo service implementation bean.
• The bean ‘PayloadRootQNameEndpointMapping‘ is what maps the incoming request to the endpoint class. Here we set up one mapping. Anytime we see a ‘EchoRequest’ tag with the specified namespace we direct it to our endpoint class.
• The ‘XsdBasedSoap11Wsdl4jDefinitionBuilder‘class is what does the magic of converting the schema XSD to a WSDL document for outside consumption. Based on simple naming conventions in the schema (like XXRequest and XXResponse) the bean can generate a WSDL. This rounds up the ‘thinking in XSD for document web services’ implementation approach.  Once deployed the WSDL is available at http://localhost:9090/echoservice/echo.wsdl.

Finally here is the endpoint class. This is the class, as previously stated, that gets the request XML and can handle the request from there.

This is a simple class. Important point to note is that it extends ‘AbstractJDomPayloadEndpoint‘. The ‘AbstractJDomPayloadEndpoint‘ class is a helper that gives you the XML payload as a JDom object. There are similar classes built for SAX, Stax and others. Most of the code above is reading the request XML using JDOM API and parsing the data out so that we may provide it to our echo service for consumption.

Finally I build a response XML document to return and thats it.

Download the sample Application:

Click here to download the jar file containing the application. The application is built using Maven. If you do not have Maven please install it. Once Maven is installed run the following commands:

1. mvn package (this will generate the web service war file in the target folder).
2. mvn jetty:run (this will bring up Jetty and you can access the wsdl at http://localhost:9090/echoservice/echo.wsdl.
3. Finally use some web service accessing tool like the eclipse plug-in soapUI to invoke the web service.

As you can see this is relatively simple. Spring-WS supports the WS-I basic profile and WS-Security. I hope to look at the WS-Security support sometime soon. Also interesting to me is the content based routing feature. This lets you configure which object gets the document based on the request XML content. We did the QName based routing in our example but the content based parsing is of greater interest to me.

While I could not find a roadmap for Spring-WS, depending on the features it starts supporting this could become a very suitable candidate for web service integration projects. Sure folks will say where is WS-Transactions and all of that, but tell me how many others implement that. I think if Spring-WS grows to support 90% of what folks need in integration projects then it will suffice.