WS-Security without Spring and without WS-Policy

[otinanism]

My client suggests that implementing a web service using WS-Policy entries inside the WSDL might cause incompatibility issues with clients that call the web service. My first question is can this be true? If not how can I prove to my client that it is not? I could not find anything on the subject.

If compatibility issues can indeed occur, I need to find a different way to implement WS-Security requirements (like signing parts etc.) without Spring, using JavaEE APIs. I could not find anything on that subject either. The only thing I could find is when the web service is implemented as a standalone application but I do not want that, I want a web application.

Any help will be appreciated.

[zcc39r]

1. I have no idea which compatibility issues could be encountered when using WS-Policy inside the WSDL. This suggestion sounds interesting. May be your client could provide some examples of such incompatibilities.

2. I solved similar problem recently. WS-Policy entries inside the WSDL was not an issue. But it was required to use custom algorithm suite for signing. Consequently I got stuck on undesirable Spring dependency when tried to provide Apache CXF with custom AlgorithmSuite. So I abandoned this way and made the following workaround:

a. Got rid of WS-Policy entries inside the WSDL and left my web service WSS-unaware.

b. Made another servlet (in form of REST service) which acts as a signing proxy for the web service. It does two things: patches original WSDL with the actual location when WSDL is requested and signs original application responses. Signature validation for incoming application requests is optional in my case.