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.)
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
Technorati: WSIT GlassFish Web Services WS-Policy Interoperability