CONNECT EVERYTHING ACHIEVE ANYTHING Comparing WSPolicy and Features

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

Overview 2 n Features and Properties n WS-Policy recap n Similarities and differences n The WSDL situation n Possible paths from here n Conclusions © 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. 3 © 2003 Sonic Software Corporation

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

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

Features May Have Properties 6 n Properties are like the “API” of a feature n Named with URIs (used to be Qnames) n Typed with XML schema n Example: – “Traffic. Light” 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 © 2003 Sonic Software Corporation

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

Modules Implement Features 8 n Reminder : Modules are semantics / functionality implemented within the SOAP envelope (headers) n A SOAP Module specification indicates which (if any) features that Module provides n Examples: – An encryption Module might implement a “securechannel” feature – A correlation Module might implement the “Request. Response” MEP © 2003 Sonic Software Corporation

Example Diagram Feature: http: //secure. Channel Properties : NONE 9 Binding : http: //https-binding Module: http: //my. Security. Ext Implements: http: //secure. Channel © 2003 Sonic Software Corporation

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

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

F&P in WSDL 2. 0 12 n Each component in WSDL has features and properties containers n Scoping rules (operations inherit interface properties, etc) n Properties are constrainable using types (nice 80/20, reuse of things like Schema) © 2003 Sonic Software Corporation

Naming is Important for Composition n Non-trivial Web Services involve extensions n 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 13 © 2003 Sonic Software Corporation

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

The Use-Case with F&P Posit we have this schema type available: <schema target. Namespace="http: //services. org/"> <simple. Type name="token. Constraint"> <restriction base="string"> <enumeration value="X 509"/> <enumeration value="user. Name"/> </restriction> </simple. Type> </schema> 15 © 2003 Sonic Software Corporation

Use-Case Cont. <service name="my. Service"> <-- 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. . . --> 16 © 2003 Sonic Software Corporation

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: token. Constraint"/> </property> <property uri="http: //sampleco. com/WSSecurity/xpath"> <value>{xpath to header}</value> </property> <!-- continued. . . --> 17 © 2003 Sonic Software Corporation

Use Case Cont. <-- Using WSDL extensibility --> <p 3 p: policy. Location xmlns: p 3 p="http: //sampleco. com/p 3 p/"> {url to P 3 P policy document} </p 3 p: policy. Location> </service> 18 © 2003 Sonic Software Corporation

WS-Policy Recap n Policy framework describes expressing/requiring settings using XML vocabularies: <wsp: Policy xml: base="http: //fabrikam 123. com/policies“ wsu: Id="AUDIT" > <wssx: Audit wsp: Optional="true" /> </wsp: Policy> n Policy Attachments talks about putting these in WSDL, using a well-known “reference” element: <wsdl: binding name=“safe. Binding”> <wsp: Policy. Reference URI=“#AUDIT”/>. . . </wsdl: binding> 19 © 2003 Sonic Software Corporation

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

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

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

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

How Can We Get There From Here? n W 3 C 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 n 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? 24 © 2003 Sonic Software Corporation

Resolving the Formal Objections n The WSDL group eagerly awaits input from this workshop n Issues: 1. 2. 3. 4. n 25 OK to wait, or need it now? Support SOAP extensibility model, or not? In WSDL core, or not? Spec writer adoption? Some ideas follow. . © 2003 Sonic Software Corporation

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

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

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

Potential Pros and Cons of Compromise n PROS – Common vocabulary for assertions/properties – Early WSDL 2. 0 users win – Everyone starts using the same techniques for building extensions n n 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 29 © 2003 Sonic Software Corporation

Timing Sucks : Realities 30 n 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 n But if this isn’t in WSDL 2. 0, everyone loses n How do we balance political/industry realities? © 2003 Sonic Software Corporation

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

Questions / Comments? 32 © 2003 Sonic Software Corporation