By ritzmann on Feb 22, 2007
With WSIT milestone 3, we are now shipping a complete WS-Policy implementation. WSIT provides an open-source and fully compliant implementation of WS-Policy 1.2 and WS-PolicyAttachment 1.2. We have lately been able to solely focus on fixing bugs and polishing the code and documentation and we currently have only very few open bugs . This seems like a good time to examine how WSIT supports WS-Policy more closely. And if you are wondering now what WS-Policy is in the first place, take a look at Marek Potociar's blog .
WSIT is an extension of JAX-WS and part of the GlassFish community. JAX-WS supports quite a number of approaches to develop and configure a web service. You can start with plain Java code and use annotations. If you need maximum flexibility, you would implement the Provider interface. If you have a WSDL document, you may want to start by having JAX-WS generate a service endpoint interface. There may be some deployment descriptors that allow you to configure your web service, see e.g. JSR 109. And on the client, you can use WebServiceFeatures.
Generally, the WS-Policy support in WSIT distinguishes between whether you develop your service starting from Java or WSDL. If you provide a WSDL document with your service, WSIT uses it and the contained policies to configure the system. The WSDL document is published almost unaltered. I am saying almost because this WSDL may contain policy assertions that are considered private. You can e.g. specify the password of a certificate store with a policy assertion. This and similar elements are automatically removed from the WSDL document before it is published.
When a service is developed from Java without any WSDL, WSIT relies on a separate configuration file. The file format is almost valid WSDL 1.1 and the actual configuration settings are contained as policies. That makes it very easy when JAX-WS generates a WSDL document for the service to attach the given policies to the generated WSDL document. As is the case when you develop your service from WSDL, private policy assertions are removed before the final WSDL is published.
Web service clients retrieve the WSDL of the service that they want to talk to. If that WSDL document contains policies, the client configures itself automatically to comply with the requirements of the service. Note that a client usually retrieves the service WSDL at run-time, i.e. the client configures itself at run-time as well. That makes it very easy to e.g. tighten the configuration of a web service in production without having to change or redeploy any client. (There is one exception to that rule, namely if you are using WS-AtomicTransaction, but then you have to adapt your code to deal with transactions anyway.)
The WSIT client can additionally read a separate configuration file. That configuration file serves two purposes. It allows to configure client-only settings, e.g. the certificate store of the client. And in case the service WSDL does not have any policies or the service has no retrievable WSDL at all, the service policies can be added to the client configuration instead. The client configuration file has the same format as the service configuration file, i.e. it is almost valid WSDL 1.1.