Spring-WS 2: WS-Security Using XWSS

In this tutorial we will explore how to add WS-Security using XWSS in an existing Spring-WS application. We will secure our web service using Spring's XwsSecurityInterceptor. In the client-side, we will use soapUI to verify the results.

What is WS-Security?

WS-Security (Web Services Security, short WSS) is a flexible and feature-rich extension to SOAP to apply security to web services. It is a member of the WS-* family of web service specifications and was published by OASIS.

The protocol specifies how integrity and confidentiality can be enforced on messages and allows the communication of various security token formats, such as SAML, Kerberos, and X.509. Its main focus is the use of XML Signature and XML Encryption to provide end-to-end security.

WS-Security describes three main mechanisms:

• How to sign SOAP messages to assure integrity. Signed messages provide also non-repudiation.
• How to encrypt SOAP messages to assure confidentiality.
• How to attach security tokens.

Source: Wikipedia (http://en.wikipedia.org/wiki/WS-Security

)

To view the official specification please visit OASIS Web Services Security (WSS) TC

What is XWSS?

XWSS stands for XML and Web Services Security. This is a SUN's implementation of WS-Security, which is part of the Java Web Services Developer Pack

Source: Spring WS 2.0 Reference (paraphrased due to lack of official definition)

As mentioned earlier, we will be adding security to an existing unsecured web service using Spring's XwsSecurityInterceptor. This web service is available at the following tutorial Spring WS 2 and Spring 3 MVC Integration Tutorial.

What is XwsSecurityInterceptor?

The XwsSecurityInterceptor is an EndpointInterceptor (see Section 5.5.2, “Intercepting requests - the EndpointInterceptor interface”) that is based on SUN's XML and Web Services Security package (XWSS). This WS-Security implementation is part of the Java Web Services Developer Pack (Java WSDP).

Note that XWSS requires both a SUN 1.5 JDK and the SUN SAAJ reference implementation.
Source: Spring WS 2.0 Reference

We will not recreate the whole web service. We'll just focus on what needs to be added to enable an XWSS-based security.

Open the spring-ws.xml file and replace it with the following configuration:

spring-ws.xml

Actually we don't need to replace everything. What we did is add a XwsSecurityInterceptor inside the sws-interceptors element:

Then we declared a bean SimplePasswordValidationCallbackHandler referenced as callbackHandler:

Inside the XwsSecurityInterceptor we referenced a securityPolicy.xml, which is located an the WEB-INF/ folder:

The securityPolicy.xml contains a list of actions to be performed when an incoming message has arrived. This is marked by the RequireXXXXXX elements. The RequireTimestamp and RequireUsernameToken means that the web service expects an Timestamp and UsernameToken from the incoming message. If these don't exist, an exception is thrown.

When the web service replies back, it will add a timestamp and username tokens as well. This is indicated by the elements xwss:Timestamp and xwss:UsernameToken.

Now let's test our web service using soapUI.

What is soapUI?

soapUI is the world's leading Web Service Testware. With over 2 million downloads, it's the de facto tool for SOA testing.

Source: http://www.eviware.com/soapUI/soapui-products-overview.html

It's also mentioned as one of the tools for testing Spring-WS applications:

These tools can help you test your Web service applications.

- soapui is a desktop application for inspecting, invoking and testing (functional and load) of web services over HTTP.
- the WS-I testing tools, which make sure your Web service is interoperable.
- Axis Tcpmon is a monitoring tool which allows you to see the XML as it is sent and received across the wire.

Source: http://static.springsource.org/spring-ws/sites/2.0/resources.html

Follow the steps below to perform a test:
1. Open soapUI.

2. Create a new soapUI project:

3. Open the project and create a new request:

4. On the right side window, you should see a request template. To add a WSS UsernameToken or Timestamp, right-click on the request and select Add WSS UsernameToken or Add WSS Timestamp.

5. To send the message, hit the Submit button (the green arrow).

Using soapUI we send the following SOAP message:

Our web service responds back with the following SOAP message:

If we remove the Timestamp element from the client, the web responds back with an exception:

If we remove the UsernameToken instead, the web service replies:

If the username or password is incorrect, we get the following exception instead:


Our web service has been secured but this doesn't mean it's fool-proof. Security is a serious and complicated matter. There are many numerous variables that needs to be considered. By adding security in our web service we have lessened the risk of being exposed. But remember no matter how small is the risk, it's still a risk.

To access the web service, use the following endpoint in soapUI:

http://localhost:8080/{project name}/krams/ws

where {project name} is either spring-ws (if you're using the sample application from the other tutorial) or spring-ws-xwss (fi you're using the sample application at the end of this tutorial).

The best way to learn further is to try the actual application.

Download the project
You can access the project site at Google's Project Hosting at http://code.google.com/p/spring-ws-2-0-0-rc2-tutorial/

You can download the project as a Maven build. Look for the spring-ws-xwss.zip in the Download sections.

You can run the project directly using an embedded server via Maven.
For Tomcat: mvn tomcat:run
For Jetty: mvn jetty:run

If you want to learn more about Spring MVC and integration with other technologies, feel free to read my other tutorials in the Tutorials section.

For an in-depth look of the XWSS Security Configuration file (including all possible elements) , please visit the following link What is the XWS-Security Framework?

Related OASIS Specification and References:
- WS-Security Core Specification 1.1
- Username Token Profile 1.1
- To see the complete list, visit http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss

---

Share the joy: blogger tutorials Social Bookmarking Blogger Widget I'm reading: Spring-WS 2: WS-Security Using XWSS ~

Subscribe by reader Subscribe by email Share

Spring-WS 2: WS-Security Using WSS4J

In this tutorial we will explore how to add WS-Security using WSS4J in an existing Spring-WS application. We will secure our web service using Spring's Wss4jSecurityInterceptor. In the client-side, we will use soapUI to verify the results.

What is WS-Security?

WS-Security (Web Services Security, short WSS) is a flexible and feature-rich extension to SOAP to apply security to web services. It is a member of the WS-* family of web service specifications and was published by OASIS.

The protocol specifies how integrity and confidentiality can be enforced on messages and allows the communication of various security token formats, such as SAML, Kerberos, and X.509. Its main focus is the use of XML Signature and XML Encryption to provide end-to-end security.

WS-Security describes three main mechanisms:

• How to sign SOAP messages to assure integrity. Signed messages provide also non-repudiation.
• How to encrypt SOAP messages to assure confidentiality.
• How to attach security tokens.

Source: Wikipedia (http://en.wikipedia.org/wiki/WS-Security

)

To view the official specification please visit OASIS Web Services Security (WSS) TC

What is WSS4J?

Apache WSS4J is an implementation of the OASIS Web Services Security (WS-Security) from OASIS Web Services Security TC. WSS4J is primarily a Java library that can be used to sign and verify SOAP Messages with WS-Security information. WSS4J will use Apache Axis and Apache XML-Security projects and will be interoperable with JAX-RPC based server/clients and .NET server/clients.

WSS4J implements:
- Web Services Security: SOAP Message Security 1.1
- Username Token Profile 1.1
- X.509 Certificate Token Profile 1.1

Source: Apache WSS4J (http://ws.apache.org/wss4j/)

What is Wss4jSecurityInterceptor?

The Wss4jSecurityInterceptor is an EndpointInterceptor that is based on Apache's WSS4J.

Source: Spring WS 2.0 Reference

We will not recreate the whole web service. We'll just focus on what needs to be added to enable an WSS4J-based security.

Open the spring-ws.xml file and replace it with the following configuration:

spring-ws.xml

Actually we don't need to replace everything. What we did is add a Wss4jSecurityInterceptor inside the sws-interceptors element:

The validationActions is a list of actions composed of space-separated strings. When a client sends a message, the validationActions will be executed. In our example, it will check if there's a Timestamp element in the incoming message. It also checks if the Timestamp hasn't expired. It also checks if there's a UsernameToken present in the message.

The securementActions is a list of actions composed of space-separated strings. These actions will be performed when the web service is replying back to the client. In this example, the web service is returning a Timestamp element and UsernameToken. Both can be customized. timestampPrecisionInMilliseconds declares the precision of the time. The securementUsername and securementPassword declares the actual username and password values, as well as the type of password PasswordText. The outgoing message also include a Nonce and the date Created.

To authenticate the credentials from the incoming message, we declared a bean callbackHandler that references a SimplePasswordValidationCallbackHandler bean:

Watch the package name! There's also an equivalent SimplePasswordValidationCallbackHandler for XWSS! Unlike the XWSS implementation, we don't need to declare an extra securityPolicy.xml here. Everything is contained within this configuration.

What is soapUI?

soapUI is the world's leading Web Service Testware. With over 2 million downloads, it's the de facto tool for SOA testing.

Source: http://www.eviware.com/soapUI/soapui-products-overview.html

It's also mentioned as one of the tools for testing Spring-WS applications:

These tools can help you test your Web service applications.

- soapui is a desktop application for inspecting, invoking and testing (functional and load) of web services over HTTP.
- the WS-I testing tools, which make sure your Web service is interoperable.
- Axis Tcpmon is a monitoring tool which allows you to see the XML as it is sent and received across the wire.

Source: http://static.springsource.org/spring-ws/sites/2.0/resources.html

Follow the steps below to perform a test:
1. Open soapUI.

2. Create a new soapUI project:

3. Open the project and create a new request:

4. On the right side window, you should see a request template. To add a WSS UsernameToken or Timestamp, right-click on the request and select Add WSS UsernameToken or Add WSS Timestamp.

5. To send the message, hit the Submit button (the green arrow).

Using soapUI we send the following SOAP message:

Our web service responds back with the following SOAP message:

If we remove the Timestamp element from the client, the web responds back with an exception:

If the Timestamp is expired, we get the following:

If we remove the UsernameToken instead, the web service replies:

If the username or password is incorrect, we get the following exception instead:


Our web service has been secured but this doesn't mean it's fool-proof. Security is a serious and complicated matter. There are many numerous variables that needs to be considered. By adding security in our web service we have lessened the risk of being exposed. But remember no matter how small is the risk, it's still a risk.

To access the web service, use the following endpoint in soapUI:

http://localhost:8080/{project name}/krams/ws

where {project name} is either spring-ws (if you're using the sample application from the other tutorial) or spring-ws-wss4j (fi you're using the sample application at the end of this tutorial).

The best way to learn further is to try the actual application.

Download the project
You can access the project site at Google's Project Hosting at http://code.google.com/p/spring-ws-2-0-0-rc2-tutorial/

You can download the project as a Maven build. Look for the spring-ws-wss4j.zip in the Download sections.

You can run the project directly using an embedded server via Maven.
For Tomcat: mvn tomcat:run
For Jetty: mvn jetty:run

If you want to learn more about Spring MVC and integration with other technologies, feel free to read my other tutorials in the Tutorials section.

Related OASIS Specification and References:
- WS-Security Core Specification 1.1
- Username Token Profile 1.1
- To see the complete list, visit http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss

---

Share the joy: blogger tutorials Social Bookmarking Blogger Widget I'm reading: Spring-WS 2: WS-Security Using WSS4J ~

Subscribe by reader Subscribe by email Share

Spring WS 2 and Spring 3 MVC Integration Tutorial

In this tutorial we will integrate Spring WS 2 and Spring 3 MVC. We will develop a Spring WS web service that follows a Contract-First development. We will also take advantage of the latest Spring WS 2.0.0 RC2 features and use marshalling techniques to efficiently manipulate XML requests. We will use Spring 3 MVC to display our list of subscribers. It's highly recommended to read first the Spring WS: A Tutorial Using the Latest 2.0.0 RC2 Build because that's the foundation of this tutorial.

What is Spring Web Services (WS)?

Spring Web Services (Spring-WS) is a product of the Spring community focused on creating document-driven Web services. Spring Web Services aims to facilitate contract-first SOAP service development, allowing for the creation of flexible web services using one of the many ways to manipulate XML payloads. The product is based on Spring itself, which means you can use the Spring concepts such as dependency injection as an integral part of your Web service.

Source: Spring WS Reference 2.0

What is Contract-First development?

When creating Web services, there are two development styles: Contract Last and Contract First. When using a contract-last approach, you start with the Java code, and let the Web service contract (WSDL, see sidebar) be generated from that. When using contract-first, you start with the WSDL contract, and use Java to implement said contract.

Source: Spring WS Reference 2.0

For an in-depth look of Spring WS, I suggest my readers to visit the Spring WS Reference 2.0 and the Spring WS API 2.0.0.RC2

We begin by defining our requirements. We have a magazine business. Our business partner has clients that needs to subscribe with our magazine. To expose this feature, we decided to use a web service. Our contract is that the clients will send the following information:

subscription code
name
email

Our web service will send a reply if the subscription is successful or not. The reply will contain the following elements:

status code
description

Since all web services are ultimately XML message, we need to define the format of our messages. We will create an XSD file. If you're not familiar with XSD, please see the excellent XSD tutorial w3schools.com XML Schema Tutorial.

Here's our XSD document:

subscription.xsd

This XSD is comprised of simple and complex element types. Each simple element has been assigned with restriction. In this way we can filter data even before it comes to our service. It's also a good way to validate XML data. Spring WS will handle the validation based on these restrictions.

When the client sends a request, we receive an XML document. Using Java's object-oriented approach and XML approach is not really convenient when manipulating information. Therefore we will use marshalling techniques to map the XML document with a corresponding Java object.

First let's see the actual XML document that is sent to us by the client:

Take note that this XML format is not arbitrary! The client has to honor the format that we declared in the XSD document.

Let's map this document to a SubscriptionRequest class:

SubscriptionRequest

For every request sent by the client, we send a response. We declare a SubscriptionResponse object:

Our marshaller will automatically convert this class into an XML document. If you look at the XSD file, we have declared a subscriptionResponse element.


This has been declared so that the client who is reading our WSDL will see what kind of response he will receive. Hence, the Contract-First development.

When the client receives a response, this is what he actually gets:

Our class has been automatically converted to XML.

To convert Java objects to XML and vice-versa we use Castor as our marshaller/unmarshaller implementation. For more info about Castor, check the reference guide Castor XML Mapping. There are other marshallers available, such as JAXB and JiBX. Check the Spring WS Reference Guide Chapter 8. Marshalling XML using O/X Mapper for more info.

To use Castor we need to declare a mapping file:

castor-mapping.xml

We're done with our contract. We now start the actual development!

The programming model of Spring WS 2 is similar with the programming model of Spring 3 MVC. Keep that in mind. In Spring MVC, to declare a controller, we mark the name of the class with @Controller and @RequestMapping. For example:

In Spring WS, we have a corresponding controller as well. Actually, it's called an endpoint. To declare an endpoint, we mark it with @Endpoint. For example:

In Spring MVC, to expose a method for a particular request, we add the @RequestMapping annotation and the associated URI template value and the type of method. For example:

In Spring WS, to expose a method for a particular service request, we add the @PayloadRoot annotation and the associated localPart and namespace values. For example:

The method is also annotated with @ResponsePayload, indicating that the return value ( SubscriptionResponse) is used as the payload of the response message. The method takes a SubscriptionRequest as a parameter, annotated with @RequestPayload. This means that the payload of the message is passed on this method as a DOM element. If you have omitted these two annotations, you will encounter a "java.lang.IllegalStateException: No adapter for endpoint".

Let's now declare our SubscriptionEndpoint class:

SubscriptionEndpoint

This endpoint has one method named processSubscription. It takes a SubscriptionRequest and delegates the processing to a SubscriptionService. If the subscription is successful a SUCCESS response is sent. If it failed, a FAILURE response is sent.

Here's the SubscriptionService:

SubscriptionService

We're done with the Spring WS part. We now start the Spring MVC development.

What we're adding here are just basically a single controller and single JSP file to display our subscribers. Here's a screenshot of our subscribers list:

Here's the controller:

MainController

This controller declares a single mapping:

/main/subscribers

This mapping delegates the call to the SubscriptionService. This is the same service that's utilized by Spring WS earlier!

Here's the JSP file:

We're done will all our classes. What's left are the XML configurations. We start by declaring the web.xml file:

web.xml

All request are handled by Spring MVC's DispatcherServlet. In a stand-alone Spring WS, we use the MessageDispatcherServlet instead. But since we're now integrating both, we need a way to resolve our dispatchers hierarchy.

As an alternative to the MessageDispatcherServlet, you can wire up a MessageDispatcher in a standard, Spring-Web MVC DispatcherServlet. By default, the DispatcherServlet can only delegate to Controllers, but we can instruct it to delegate to a MessageDispatcher by adding a WebServiceMessageReceiverHandlerAdapter to the servlet's web application context:

Spring WS 2 Reference 5.3.2. Wiring up Spring-WS in a DispatcherServlet

I suggest to read the Spring WS 2 reference for a thorough description of this integration.

If you examine carefully the servlet element, we've declared an init-param. This is required to dynamically convert WSDLs regardless where you deploy it. There's no need to manually set the URL of your WSDL anymore, though you still can.

In the web.xml we declared a servlet-name spring. By convention, we must declare a spring-servlet.xml as well.

spring-servlet.xml

By convention, we must declare an applicationContext.xml as well.

applicationContext.xml

These beans activate Spring's annotation support for Spring 3 MVC. At the bottom portion we import an external configuration file spring-ws.xml. This contains all the Spring WS specific configuration. In a normal Spring project, it's typical to have multiple XML configs. To lessen the XML hell experience, it's advisable we group related configurations in their owned XML file.

Here's spring-ws.xml:

spring-ws.xml

This configuration uses the latest Spring WS 2.0.0 RC2 features (unlike if you're still using 1.5.9).

What's new with Spring WS 2.0.0 RC2?

The most important new feature in this release is the update of the Spring-WS XML namespace, which now contains <sws:annotation-driven/> and <sws:interceptors/> elements (similar to the Spring-MVC namespace), and <sws:static-wsdl/> and <sws:dynamic-wsdl/> for exporting your WSDLs.

Source: SpringSource Forum: Spring Web Services 2.0.0 RC2 released

It's worth mentioning in the spring-ws.xml, we're using a pluggable endpoint adapter

DefaultMethodEndpointAdapter

and a marshalling method processor

MarshallingPayloadMethodProcessor

If you visit some of the popular Spring WS tutorials, they still use the old GenericMarshallingMethodEndpointAdapter. However, this is already deprecated in favor of a pluggable adapter.

Class GenericMarshallingMethodEndpointAdapter

Deprecated. as of Spring Web Services 2.0, in favor of DefaultMethodEndpointAdapter and MarshallingPayloadMethodProcessor.

See Spring WS API 2.0.0 GenericMarshallingMethodEndpointAdapter

That concludes our Spring WS development. We've managed to setup a simple Spring 3 WS application using the latest Spring WS 2.0.0.RC2 build. We've utilized the latest annotation features. We've also leveraged Spring 3 MVC's programming model.

To test the application, you will need to deploy it in a server, like Tomcat. For the client, unless you know how to develop a Web Service client, I advise my readers to use Soap UI for testing. They have a free version at http://soapui.org/. It's also one of the recommended tools at the official Spring Web Services site at http://static.springsource.org/spring-ws/sites/2.0/resources.html.

Here's a sample screenshot using SOAP UI to test the application:

To access the service endpoint, use the following URL:

http://localhost:8080/spring-ws/krams/ws

To access the WSDL, use the following URL (you can use Firefox to check this out):

http://localhost:8080/spring-ws/krams/ws/subscription.wsdl

To access the subscribers page, use the following URL:

http://localhost:8080/spring-ws/krams/main/subscribers

The best way to learn further is to try the actual application.

Download the project
You can access the project site at Google's Project Hosting at http://code.google.com/p/spring-ws-2-0-0-rc2-tutorial/

You can download the project as a Maven build. Look for the spring-ws.zip in the Download sections.

You can run the project directly using an embedded server via Maven.
For Tomcat: mvn tomcat:run
For Jetty: mvn jetty:run

If you want to learn more about Spring MVC and integration with other technologies, feel free to read my other tutorials in the Tutorials section.

---

Share the joy: blogger tutorials Social Bookmarking Blogger Widget I'm reading: Spring WS 2 and Spring 3 MVC Integration Tutorial ~

Subscribe by reader Subscribe by email Share

Spring WS: A Tutorial Using the Latest 2.0.0 RC2 Build

In this tutorial we will develop a simple Spring WS that follows a Contract-First development. We will also take advantage of the latest Spring WS 2.0.0 RC2 features. We will also use marshalling techniques to efficiently manipulate XML requests. This will also be our basis for the next tutorial: Spring WS and Spring MVC Integration.

What is Spring Web Services (WS)?

Spring Web Services (Spring-WS) is a product of the Spring community focused on creating document-driven Web services. Spring Web Services aims to facilitate contract-first SOAP service development, allowing for the creation of flexible web services using one of the many ways to manipulate XML payloads. The product is based on Spring itself, which means you can use the Spring concepts such as dependency injection as an integral part of your Web service.

Source: Spring WS Reference 2.0

What is Contract-First development?

When creating Web services, there are two development styles: Contract Last and Contract First. When using a contract-last approach, you start with the Java code, and let the Web service contract (WSDL, see sidebar) be generated from that. When using contract-first, you start with the WSDL contract, and use Java to implement said contract.

Source: Spring WS Reference 2.0

For an in-depth look of Spring WS, I suggest my readers to visit the Spring WS Reference 2.0 and the Spring WS API 2.0.0.RC2

Unlike with my previous tutorials, there's no Spring MVC here. However, we will still use some of the convenient tools from Spring MVC like the @Service annotation.

We begin by defining our requirements. We have a magazine business. Our business partner has clients that needs to subscribe with our magazine. To expose this feature, we decided to use a web service. Our contract is that the clients will send the following information:

subscription code
name
email

Our web service will send a reply if the subscription is successful or not. The reply will contain the following elements:

status code
description

Since all web services are ultimately XML message, we need to define the format of our messages. We will create an XSD file. If you're not familiar with XSD, please see the excellent XSD tutorial w3schools.com XML Schema Tutorial.

Here's our XSD document:

subscription.xsd

This XSD is composed of simple and complex element types. Each simple element has been assigned with restriction. In this way we can filter data even before it comes to our service. It's also a good way to validate XML data. Spring WS will handle the validation based on these restrictions.

When the client sends a request, we receive an XML document. Using Java's object-oriented approach and XML approach is not really convenient when manipulating information. Therefore we will use marshalling techniques to map the XML document with a corresponding Java object.

First let's see the actual XML document that is sent to us by the client:

Take note that this XML format is not arbitrary! The client has to honor the format that we declared in the XSD document.

Let's map this document to a SubscriptionRequest class:

SubscriptionRequest

For every request sent by the client, we send a response. We declare a SubscriptionResponse object:

Our marshaller will automatically convert this class into an XML document. If you look at the XSD file, we have declared a subscriptionResponse element.


This has been declared so that the client who is reading our WSDL will see what kind of response he will receive. Hence, the Contract-First development.

When the client receives a response, this is what he actually gets:

Our class has been automatically converted to XML.

To convert Java objects to XML and vice-versa we use Castor as our marshaller/unmarshaller implementation. For more info about Castor, check the reference guide Castor XML Mapping. There are other marshallers available, such as JAXB and JiBX. Check the Spring WS Reference Guide Chapter 8. Marshalling XML using O/X Mapper for more info.

To use Castor we need to declare a mapping file:

castor-mapping.xml

We're done with our contract. We now start the actual development!

The programming model of Spring WS 2 is similar with the programming model of Spring 3 MVC. Keep that in mind. In Spring MVC, to declare a controller, we mark the name of the class with @Controller and @RequestMapping. For example:

In Spring WS, we have a corresponding controller as well. Actually, it's called an endpoint. To declare an endpoint, we mark it with @Endpoint. For example:

In Spring MVC, to expose a method for a particular request, we add the @RequestMapping annotation and the associated URI template value and the type of method. For example:

In Spring WS, to expose a method for a particular service request, we add the @PayloadRoot annotation and the associated localPart and namespace values. For example:

The method is also annotated with @ResponsePayload, indicating that the return value ( SubscriptionResponse) is used as the payload of the response message. The method takes a SubscriptionRequest as a parameter, annotated with @RequestPayload. This means that the payload of the message is passed on this method as a DOM element. If you have omitted these two annotations, you will encounter a "java.lang.IllegalStateException: No adapter for endpoint".

Let's now declare our SubscriptionEndpoint class:

SubscriptionEndpoint

This endpoint has one method named processSubscription. It takes a SubscriptionRequest and delegates the processing to a SubscriptionService. If the subscription is successful a SUCCESS response is sent. If it failed, a FAILURE response is sent.

Here's the SubscriptionService:

SubscriptionService

We're done will all our classes. What's left are the XML configurations. We start by declaring the web.xml file:

In a normal Spring MVC application, we dispatch all request to a DispatcherServlet. With Spring WS, we use the MessageDispatcherServlet instead. If you examine carefully the servlet element, we've declared an init-param. This is required to dynamically convert WSDLs regardless where you deploy it. There's no need to manually set the URL of your WSDL anymore, though you still can.

In the web.xml we declared a servlet-name spring. By convention, we must declare a spring-servlet.xml as well.

spring-servlet.xml

These beans activate Spring's annotation support and some of Spring 3 MVC's convenient annotations like @Service. At the bottom portion we import an external configuration file spring-ws.xml. This contains all the Spring WS specific configuration. In a normal Spring project, it's typical to have multiple XML configs. To lessen the XML hell experience, it's advisable we group related configurations in their owned XML file.

Here's spring-ws.xml:

spring-ws.xml

This configuration uses the latest Spring WS 2.0.0 RC2 features (unlike if you're still using 1.5.9).

What's new with Spring WS 2.0.0 RC2?

The most important new feature in this release is the update of the Spring-WS XML namespace, which now contains <sws:annotation-driven/> and <sws:interceptors/> elements (similar to the Spring-MVC namespace), and <sws:static-wsdl/> and <sws:dynamic-wsdl/> for exporting your WSDLs.

Source: SpringSource Forum: Spring Web Services 2.0.0 RC2 released

It's worth mentioning in the spring-ws.xml, we're using a pluggable endpoint adapter

DefaultMethodEndpointAdapter

and a marshalling method processor

MarshallingPayloadMethodProcessor

If you visit some of the popular Spring WS tutorials, they still use the old GenericMarshallingMethodEndpointAdapter. However, this is already deprecated in favor of a pluggable adapter.

Class GenericMarshallingMethodEndpointAdapter

Deprecated. as of Spring Web Services 2.0, in favor of DefaultMethodEndpointAdapter and MarshallingPayloadMethodProcessor.

See Spring WS API 2.0.0 GenericMarshallingMethodEndpointAdapter

That concludes our Spring WS development. We've managed to setup a simple Spring 3 WS application using the latest Spring WS 2.0.0.RC2 build. We've utilized the latest annotation features. We've also leveraged Spring 3 MVC's programming model.

To test the application, you will need to deploy it in a server, like Tomcat. For the client, unless you know how to develop a Web Service client, I advise my readers to use Soap UI for testing. They have a free version at http://soapui.org/. It's also one of the recommended tools at the official Spring Web Services site at http://static.springsource.org/spring-ws/sites/2.0/resources.html.

Here's a sample screenshot using SOAP UI to test the application:

To access the service endpoint, use the following URL:

http://localhost:8080/spring-ws-standalone/krams/ws

To access the WSDL, use the following URL (you can use Firefox to check this out):

http://localhost:8080/spring-ws-standalone/krams/ws/subscription.wsdl

The best way to learn further is to try the actual application.

Download the project
You can access the project site at Google's Project Hosting at http://code.google.com/p/spring-ws-2-0-0-rc2-tutorial/

You can download the project as a Maven build. Look for the spring-ws-standalone.zip in the Download sections.

You can run the project directly using an embedded server via Maven.
For Tomcat: mvn tomcat:run
For Jetty: mvn jetty:run

If you want to learn more about Spring MVC and integration with other technologies, feel free to read my other tutorials in the Tutorials section.

---

Share the joy: blogger tutorials Social Bookmarking Blogger Widget I'm reading: Spring WS: A Tutorial Using the Latest 2.0.0 RC2 Build ~

Subscribe by reader Subscribe by email Share