So, exactly what does WS-Policy give us? Conceptually, it's pretty simple: a standard XML format for expressing requirements or capabilities (policies) of a system. To be more precise, it just provides a framework for expressing policies. This is an excellent model for flexibility and extensibility because you can add policies of any 'flavour' within this framework.
A policy flavour or 'domain' might be a proprietary policy - for example, a policy relating to a logging. Alternatively, you can express policies relating to pre-canned standard domains such as WS-SecurityPolicy. So this opens a whole new opportunity: so long as communicating systems understand WS-Policy and the same policy domains, they can exchange information about requirements and capabilities in a standard format. Here are some example uses of this:
- A client could configure itself based on a server's configuration (even if the client and server use different proprietary formats for representing their configurations internally)
- In a large, heterogeneous environment, a standard policy configuration for many machines could be held in a central repository
- A service endpoint could advertise its requirements to all its clients in a non-proprietary way
Finally, WS-Policy provides an algorithm (called intersection) for combining 2 policies together to find an acceptable policy for all parties. So if a client has requirements but also needs to conform to the requirements of the service, you can take the two policies, perform intersection and out pops a policy acceptable to both the client and service.
More about ws-policy support in WAS 7 to follow...