Comparing WS-Policy and Features & Properties

1. Comparing WS-Policy and Features & Properties Glen Daniels Sonic Software October, 2004

2. Overview • Features and Properties • WS-Policy recap • Similarities and differences • The WSDL situation • Possible paths from here • Conclusions

3. The Quickie Version Both WS-Policy and Features and Properties encourage extension writers to name at least user-visible “tweak points” with well-definited identifiers. This enables both expressing sets of requirements and capabilities in metadata in a simple and useful way, and spec composition. The current Web Service user community needs something in WSDL, and though it might not be a 100% complete solution, it does enough to enable a lot, and can be the base for other richer efforts. We have some issues to resolve.

4. F&P : History • The SOAP HTTP binding is natively Request/Response • Request-Response is also something you can do using SOAP extensibility • We needed a way of describing some of the semantics which are provided by protocol bindings, which could also be implemented with headers Client Server <SOAP:Body>...</SOAP:Body> HTTP <SOAP:Header><reply-to...></SOAP:Header><SOAP:Body>...</SOAP:Body> Client Server one-way protocol

5. What’s a Feature? • Arbitrary piece of semantics / functionality • Described in a specification • Named with a URI • We can talk about it / point to it • Other specs can refer to the SAME thing • Could have a “static” wire representation (security) ...a “dynamic” wire representation (time-of-day greeting) ...or no wire representation (ISO9001)

6. Features May Have Properties • Properties are like the “API” of a feature • Named with URIs (used to be Qnames) • Typed with XML schema • Example: • “TrafficLight” feature has “color” property, which is an enum [ red, yellow, green ] • Feature spec says the value of this property should be passed from node to node, but NOT how it should be done

7. Bindings Implement Features • The specification of a binding includes a description of which (if any) features that binding provides • Examples: • The SOAP HTTP binding natively implements the “Request-Response” MEP • A SOAP HTTPS binding might natively implement a “secure-channel” feature

8. Modules Implement Features • Reminder : Modules are semantics / functionality implemented within the SOAP envelope (headers) • A SOAP Module specification indicates which (if any) features that Module provides • Examples: • An encryption Module might implement a “secure-channel” feature • A correlation Module might implement the “Request-Response” MEP

9. Example Diagram Feature: http://secureChannel Properties : NONE Binding : http://https-binding Implements: http://secureChannel Module: http://mySecurityExt Implements: http://secureChannel

10. Example 2 : Properties • Feature : “urn:Encryption” • Property : “urn:cipher” • Spec says sending node MUST ensure the cipher value is available to the receiving node. • When implemented as a Module: • <soap:header> <sec:cipher>BLOWFISH</sec:cipher></soap:header> • When in a Binding: • Cipher could be a protocol header, or simply a fixed value

11. Describing Modules • <soap:header> (WSDL1.1) wasn’t expressive enough • Can’t do state/context dependent headers • <soap:module> lets us say “follow the rules of the Module spec” – much more flexible • Properties can be constrained/given values in WSDL

12. F&P in WSDL 2.0 • Each component in WSDL has features and properties containers • Scoping rules (operations inherit interface properties, etc) • Properties are constrainable using types (nice 80/20, reuse of things like Schema)

13. Naming is Important for Composition • Non-trivial Web Services involve extensions • Extensions need to compose • People implementing them need to know how to share values/configuration where appropriate (unambiguously) • People putting together previously unconnected extensions need the ability to make higher-level assertions about values

14. Naming is Important for Runtime Values • I can write a security module that uses an “authenticated user” property...and then write a notarization module which uses that value • If I represent properties like this with unique identifiers: • I can write clear assertions in higher-level languages like OWL/RDF/Rei – “this userID maps to that clientID” • I can write other specifications which unambiguously use the SAME value as my original one • If I do it in english, I lose the above advantages

15. The Use-Case with F&P Posit we have this schema type available: <schema targetNamespace="http://services.org/"> <simpleType name="tokenConstraint"> <restriction base="string"> <enumeration value="X509"/> <enumeration value="userName"/> </restriction> </simpleType> </schema>

16. Use-Case Cont. <service name="myService"> <-- A required abstract Feature, which must be implemented by some module or binding --> <feature uri="http://sampleco.com/reliability“ required="true"/> <property uri="http://sampleco.com/reliability/qos"> <value>EXACTLY-ONCE</value> </property> <!-- continued... -->

17. Use Case Cont. <-- A specific SOAP module --> <soap:module uri="http://sampleco.com/WSSecurity“ required="true"/> <property uri="http://sampleco.com/WSSecurity/token" xmlns:svc="http://services.org/"> <constraint qname="svc:tokenConstraint"/> </property> <property uri="http://sampleco.com/WSSecurity/xpath"> <value>{xpath to header}</value> </property><!-- continued... -->

18. Use Case Cont. <-- Using WSDL extensibility --> <p3p:policyLocation xmlns:p3p="http://sampleco.com/p3p/"> {url to P3P policy document} </p3p:policyLocation> </service>

19. WS-Policy Recap • Policy framework describes expressing/requiring settings using XML vocabularies: • Policy Attachments talks about putting these in WSDL, using a well-known “reference” element: <wsp:Policy xml:base="http://fabrikam123.com/policies“ wsu:Id="AUDIT" > <wssx:Audit wsp:Optional="true" /></wsp:Policy> <wsdl:binding name=“safeBinding”> <wsp:PolicyReference URI=“#AUDIT”/> ...</wsdl:binding>

20. On to the comparison...

21. What’s Similar? • Both use identifiers to represent the activation/configuration of semantics • Both can be expressed in WSDL • Both have scoping rules to determine the complete set of constraints for a given WSDL component • Both allow a WSDL user/agent to decide if a given set of supported/required behaviors is compatible with their environment

22. What’s Different? • <syntax/> • URIs vs. QNames • URIs make RDF easier • QNames make XML serialization easier • Properties are both about user-settable values and runtime state • F&P implies distinguished identifier for a specification itself • WSDL Properties have a richer constraint syntax (schema) • WS-Policy has simple composition operators now • W3C owns F&P now • WS-Policy is explicitly more generic • F&P has explicit abstract requirements (features)

23. Where Do We Want To Be? • Spec writers using best practices to hang identifiers off extension specs • Converged syntax • Ability for partners to determine correctness of an interaction by comparing requirements/capabilities • Well defined failure is really useful! • Eventually, negotiation protocol / reasoning support? • Start small, but keep futures in mind

24. How Can We Get There From Here? • W3C seems like a good place for a Policy WG into the future • Core Web Services technology like SOAP, WSDL, Addr • Relates to Semantic Web at some level • Deep “best practices” + specific syntax/rules • Need some solution now • We love WS-Policy, but... • Can’t refer to WS-Policy directly from WSDL, and current WS-Policy won’t be the end-result of a WG anyway • Clearly we want to converge at some point, how can we make that easier?

25. Resolving the Formal Objections • The WSDL group eagerly awaits input from this workshop • Issues: • OK to wait, or need it now? • Support SOAP extensibility model, or not? • In WSDL core, or not? • Spec writer adoption? • Some ideas follow....

26. Compromise Ideas • If properties were QNames (as they once were), declaring <property> would be almost identical to policy assertions in WS-Policy...

27. Compromise Ideas • If a Policy group spun up with a charter that got a WSDL extension done in time for WSDL 2...

28. Compromise Ideas • If F&P became a standard extension, not core...

29. Potential Pros and Cons of Compromise • PROS • Common vocabulary for assertions/properties • Early WSDL 2.0 users win • Everyone starts using the same techniques for building extensions • Specs can talk about values in terms of either “properties” OR “policies”, but they work the same • CONS • Perhaps two syntaxes for a while • Making sure semantics stay in sync

30. Timing Sucks : Realities • If there was a way for WSDL to normatively reference WS-Policy in an acceptable (RF + available) manner, we might be better able to forge a compromise • But if this isn’t in WSDL 2.0, everyone loses • How do we balance political/industry realities?

31. Conclusions • These technologies are in many ways similar • The SOAP extensibility model is good • We can carry it forward into a Policy-enabled world • Need to figure out most palatable compromises, and resolve WSDL formal objections • These are not easy questions to answer, and any solution is going to have tradeoffs

32. Questions / Comments?