Greg recently posted an interesting article on what’s ahead of us in terms of really using policies in conjunction with Web services. I agree with him that the interesting question is not in “features and properties” versus WS-Policy. Whether you use one, the other, or a combination of the two you’ve still barely scratched the surface. I also agree that policies should not be tied with WSDL descriptions (a problem of F&P). But a key thing I would add to Greg’s list of what people need to be able to do with policies is define more precisely what “components” of the architecture policies are attached to. Yes, the “service” component is not sufficient as policies can be attached to more granular or less granular levels. But what are these levels? Who defines them? How do we come to agreement on them?
WSDM MUWS 1.0 Part 1 (coming in December) will define such basic components as “property”, “operation” and “event” that can have policies attached to them. These are components that are more granular than a “service” or an “endpoint”. Then you have relationships (defined in MUWS Part 2) that can also have attached policies. And you can have policies applied at a higher granularity level than the service, for example at the level of a business process made up of several services. Who will define these components?
Once we have these policy-capable components defined, we can go back to Greg’s question about attaching policies to them. “Multiple methods of association”, as he suggests, is one possible approach. Another way is to make more daring (shall we say) usage of existing addressing methods. For example the way WS-Management does it in its section 3. But this comes at the cost of throwing down the drain the benefits associated with opaque reference properties in WS-Addressing. Is it worth it? Any other alternative?