How does Web Services Policy work?
WS-Policy specification defines these key concepts:
- assertion – which is a construct that defines a single requirement or description of a single property of the web service behavior
- policy alternative – represented by a set of assertions. Each policy alternative describes single communication contracts a client needs to meet in order to communicate with a service.
- policy expression – defined as a set of policy alternatives.
- operations – such as merge and intersection of policy expressions play a major role in automated policy expression processing.
The mere fact that policy expression is a set of policy alternatives is one of the key factors that makes policy really powerful. This means that a web service may define more than one communication contract, for example to meet different capabilities of different clients. Client does not need to support every contract that web service defines. In order to successfully communicate with a service, a client just needs (using intersection and merge operations) to pick one policy alternative that describes communication requirements the client is able or willing to meet. This was maybe most obvious example how to exploit the concept of multiple policy alternatives. There are many more use cases of course. Multiple policy alternatives may be used for example to support web service versioning, client request routing etc. We do not even need to stay in the field of web services and SOA – this concept may be applied in other IT domains as well.Sun has it’s own implementation of a web service stack that supports WS-Policy processing. It is developed as a part of project WSIT also known as the “Project Tango”. Anybody who ever tried to develop a client that communicates with a secured web service would agree that it is a quite painful process one needs to go through to get all the information about security aspects of the web service to be able to manually setup the secured communication channel between the service and the client. Well, with WSIT it is no longer an issue. As part of the automated policy processing client application automatically configures the communication channel according to the policies attached to the service. And this works even if the policy on the service is changed – there is no need to change implementation or configuration of the client application anymore. In case you want to know more, Fabian has a cool blog that explains some more details about WSIT. Technorati: