1 / 32

Comparing WS-Policy and Features & Properties

Comparing WS-Policy and Features & Properties. Glen Daniels Sonic Software October, 2004. Overview. Features and Properties WS-Policy recap Similarities and differences The WSDL situation Possible paths from here Conclusions. The Quickie Version.

lilia
Télécharger la présentation

Comparing WS-Policy and Features & Properties

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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?

More Related