working on test cases to extract requirements for ws-policy and ws-policy attachment implementations, we (Stefano and me) started thinking how the policy framework could be, thus we would like to do a little brainstorm here to share our thoughts on the issue.
1) First of all, we do need ws-po and ws-poa since we need ws-rm; for this reason the main goal would be to do the minimal work to get a working policy framework that can be used to test the future ws-rm implementation. Thus we will start supporting normal policy form (http://www.w3.org/Submission/WS-Policy/#Normal_Form_Policy_Expression) only as agreed with Thomas;
compact form (http://www.w3.org/Submission/WS-Policy/#Compact_Policy_Expression) will be added later.
For the same reason we think all UDDI related stuff (http://www.w3.org/Submission/WS-PolicyAttachment/#AttachingPoliciesUsingUDDI) could also be added in the future.
2) We nevertheless think that in order to be able to obtain future good interoperability, even now we should at least think about how this upcoming ws-po/ws-poa implementation will interact with ws-rm policy and other implementations of specs depending on policy.
3) We immagine that all the spec implementations based on ws-policy would be only required to provide mechanisms for their own assertions, ws-po/ws-poa implementation instead would provide all we need for alternatives, scope and effective policy selection, policy intersection and so on. This is what is defined in Policy Model and Policy Expression chapters of ws-policy spec:
and in chapter 3 and 4 of ws-policy attachment:
4) We would ofcourse need metadata for ws-policy and these will contain specific metadata of eventual assertions belonging to ws-rm, etc. We think we should be able to go to and from metadata parsing/writing wsdl, with the wstool or may be via annotations that could be defined for assertions.
5) Thomas wrote an initial policy implementation some times ago: this is to be used as a starting point for core ws-policy metadata, since it already contains a policy model implementation. This should be further developed to add scope/effective policy mechanisms.
6) Speaking about how these metadata creation could be plugged into the existing source, we think that we could evaluate something similar to what has been done for other extension implementations like eventing and addressing (MetaDataBuilder creating ExtensibleMetaData objects and so on).
Any comments and/or ideas?