CONNECT EVERYTHING ACHIEVE ANYTHING Comparing WS-Policy and

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

Overview n n WS-Policy recap n Similarities and differences n The WSDL situation n Possible paths from here n 2 Features and Properties 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 . . . one-way protocol . . . 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 n n Named with URIs (used to be Qnames) n Typed with XML schema n 6 Properties are like the “API” of a feature 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 n n A SOAP Module specification indicates which (if any) features that Module provides n 8 Reminder : Modules are semantics / functionality implemented within the SOAP envelope (headers) 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 Binding : http: //https-binding Implements: http: //secure. Channel 9 Module: http: //my. Security. Ext Implements: http: //secure. Channel © 2003 Sonic Software Corporation

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

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

F&P in WSDL 2. 0 n n Scoping rules (operations inherit interface properties, etc) n 12 Each component in WSDL has features and properties containers 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: 15 © 2003 Sonic Software Corporation

<-- A required abstract Feature, which must be implemented" src="https://present5.com/presentation/0538dc870a48e9fbed486e727be177b6/image-16.jpg" alt="Use-Case Cont. <-- A required abstract Feature, which must be implemented" /> Use-Case Cont. <-- A required abstract Feature, which must be implemented by some module or binding --> EXACTLY-ONCE 16 © 2003 Sonic Software Corporation

Use Case Cont. <-- A specific SOAP module --> {xpath to header} 17 © 2003 Sonic Software Corporation

Use Case Cont. <-- Using WSDL extensibility -->

{url to P 3 P policy document}

WS-Policy Recap n Policy framework describes expressing/requiring settings using XML vocabularies: n Policy Attachments talks about putting these in WSDL, using a well-known “reference” element: . . . 19 © 2003 Sonic Software Corporation

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

What’s Similar? n 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 21 Both use identifiers to represent the activation/configuration of semantics 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? n 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 22 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 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 n n But if this isn’t in WSDL 2. 0, everyone loses n 30 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 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 n n 31 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 © 2003 Sonic Software Corporation

Questions / Comments? 32 © 2003 Sonic Software Corporation