connect everything. achieve anything. ™ comparing ws-policy and features & properties glen...

CONNECT EVERYTHING. ACHIEVE ANYTHING.™

Comparing WS-Policy and Features & Properties

Glen Daniels

Sonic Software

October, 2004

2 © 2003 Sonic Software Corporation

Overview

Features and Properties

WS-Policy recap

Similarities and differences

The WSDL situation

Possible paths from here

Conclusions


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.


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

Client Server

HTTP

one-way protocol

<SOAP:Header> <reply-to...></SOAP:Header><SOAP:Body>...</SOAP:Body>

<SOAP:Body>...</SOAP:Body>


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)


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


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


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


Example Diagram

Feature: http://secureChannelProperties : NONE

Binding : http://https-binding

Implements:http://secureChannel

Module: http://mySecurityExt

Implements:http://secureChannel


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


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


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)


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


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


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>

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>

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>


Use Case Cont.

<-- Using WSDL extensibility -->

<p3p:policyLocation xmlns:p3p="http://sampleco.com/p3p/">

{url to P3P policy document}

</p3p:policyLocation>

</service>


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:

<wsdl:binding name=“safeBinding”> <wsp:PolicyReference URI=“#AUDIT”/> ...</wsdl:binding>

<wsp:Policy xml:base="http://fabrikam123.com/policies“ wsu:Id="AUDIT" > <wssx:Audit wsp:Optional="true" /></wsp:Policy>


On to the comparison...


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


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)


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


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?


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....


Compromise Ideas

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


Compromise Ideas

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


Compromise Ideas

If F&P became a standard extension, not core...


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


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?


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


Questions / Comments?

connect everything. achieve anything. ™ comparing ws-policy and features & properties glen...

Documents