1. CONNECT EVERYTHING. ACHIEVE ANYTHING. ™ Comparing WS-Policy and Features & Properties Glen Daniels Sonic Software October, 2004

2. 2© 2003 Sonic Software Corporation Overview Features and Properties WS-Policy recap Similarities and differences The WSDL situation Possible paths from here Conclusions

3. 3© 2003 Sonic Software Corporation 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. 4© 2003 Sonic Software Corporation 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 ClientServer ClientServer HTTP one-way protocol...

5. 5© 2003 Sonic Software Corporation 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. 6© 2003 Sonic Software Corporation 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. 7© 2003 Sonic Software Corporation 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. 8© 2003 Sonic Software Corporation 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. 9© 2003 Sonic Software Corporation Example Diagram Feature: http://secureChannel Properties : NONE Binding : http://https-binding Implements: http://secureChannel Module: http://mySecurityExt Implements: http://secureChannel

10. 10© 2003 Sonic Software Corporation 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: – BLOWFISH When in a Binding: –Cipher could be a protocol header, or simply a fixed value

11. 11© 2003 Sonic Software Corporation Describing Modules (WSDL1.1) wasn’t expressive enough –Can’t do state/context dependent headers lets us say “follow the rules of the Module spec” – much more flexible Properties can be constrained/given values in WSDL

12. 12© 2003 Sonic Software Corporation 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. 13© 2003 Sonic Software Corporation 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. 14© 2003 Sonic Software Corporation 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. 15© 2003 Sonic Software Corporation The Use-Case with F&P Posit we have this schema type available:

16. 16© 2003 Sonic Software Corporation Use-Case Cont. <-- A required abstract Feature, which must be implemented by some module or binding --> <feature uri="http://sampleco.com/reliability“ required="true"/> EXACTLY-ONCE

17. 17© 2003 Sonic Software Corporation Use Case Cont. <property uri="http://sampleco.com/WSSecurity/token" xmlns:svc="http://services.org/"> <property uri="http://sampleco.com/WSSecurity/xpath"> {xpath to header}

18. 18© 2003 Sonic Software Corporation Use Case Cont. {url to P3P policy document}

19. 19© 2003 Sonic Software Corporation 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:...

20. 20© 2003 Sonic Software Corporation On to the comparison...

21. 21© 2003 Sonic Software Corporation 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. 22© 2003 Sonic Software Corporation What’s Different? 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. 23© 2003 Sonic Software Corporation 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. 24© 2003 Sonic Software Corporation 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. 25© 2003 Sonic Software Corporation Resolving the Formal Objections The WSDL group eagerly awaits input from this workshop Issues: 1.OK to wait, or need it now? 2.Support SOAP extensibility model, or not? 3.In WSDL core, or not? 4.Spec writer adoption? Some ideas follow....

26. 26© 2003 Sonic Software Corporation Compromise Ideas If properties were QNames (as they once were), declaring would be almost identical to policy assertions in WS-Policy...

27. 27© 2003 Sonic Software Corporation Compromise Ideas If a Policy group spun up with a charter that got a WSDL extension done in time for WSDL 2...

28. 28© 2003 Sonic Software Corporation Compromise Ideas If F&P became a standard extension, not core...

29. 29© 2003 Sonic Software Corporation 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. 30© 2003 Sonic Software Corporation 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. 31© 2003 Sonic Software Corporation 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. 32© 2003 Sonic Software Corporation Questions / Comments?