Comparing WS-Policy and Features

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
FP 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
ltSOAPBodygt...lt/SOAPBodygt
HTTP
ltSOAPHeadergt ltreply-to...gtlt/SOAPHeadergtltSOA
PBodygt...lt/SOAPBodygt
Client
Server
one-way protocol
5
Whats 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 urnEncryption
• Property urncipher
• Spec says sending node MUST ensure the cipher
  value is available to the receiving node.
• When implemented as a Module
• ltsoapheadergt ltsecciphergtBLOWFISHlt/secciphergt
  lt/soapheadergt
• When in a Binding
• Cipher could be a protocol header, or simply a
  fixed value

11
Describing Modules

• ltsoapheadergt (WSDL1.1) wasnt expressive enough
• Cant do state/context dependent headers
• ltsoapmodulegt lets us say follow the rules of
  the Module spec much more flexible
• Properties can be constrained/given values in WSDL

12
FP 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 FP

• Posit we have this schema type available
• ltschema targetNamespace"http//services.org/"gt
• ltsimpleType name"tokenConstraint"gt
• ltrestriction base"string"gt
• ltenumeration value"X509"/gt
• ltenumeration value"userName"/gt
• lt/restrictiongt
• lt/simpleTypegt
• lt/schemagt

16
Use-Case Cont.

• ltservice name"myService"gt
• lt-- A required abstract Feature, which must be
  
• implemented by some module or binding --gt
• ltfeature uri"http//sampleco.com/reliability
• required"true"/gt
• ltproperty uri"http//sampleco.com/reliab
  ility/qos"gt
• ltvaluegtEXACTLY-ONCElt/valuegt
• lt/propertygt
• lt!-- continued... --gt

17
Use Case Cont.

• lt-- A specific SOAP module --gt
• ltsoapmodule uri"http//sampleco.com/WSSecurity
  required"true"/gt
• ltproperty
• uri"http//sampleco.com/WSSecurity/token
  "
• xmlnssvc"http//services.org/"gt
• ltconstraint qname"svctokenConstraint"/gt
• lt/propertygt
• ltproperty
• uri"http//sampleco.com/WSSecurity/xpath
  "gt
• ltvaluegtxpath to headerlt/valuegt
• lt/propertygtlt!-- continued... --gt

18
Use Case Cont.

• lt-- Using WSDL extensibility --gt
• ltp3ppolicyLocation xmlnsp3p"http//sampleco.c
  om/p3p/"gt
• url to P3P policy document
• lt/p3ppolicyLocationgt
• lt/servicegt

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

ltwspPolicy xmlbase"http//fabrikam123.com/polic
ies wsuId"AUDIT" gt ltwssxAudit
wspOptional"true" /gtlt/wspPolicygt
ltwsdlbinding namesafeBindinggt
ltwspPolicyReference URIAUDIT/gt
...lt/wsdlbindinggt
20
On to the comparison...
21
Whats 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
Whats Different?

• ltsyntax/gt
• URIs vs. QNames
• URIs make RDF easier
• QNames make XML serialization easier
• Properties are both about user-settable values
  and runtime state
• FP implies distinguished identifier for a
  specification itself
• WSDL Properties have a richer constraint syntax
  (schema)
• WS-Policy has simple composition operators now
• W3C owns FP now
• WS-Policy is explicitly more generic
• FP 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/capabilit
  ies
• 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...
• Cant refer to WS-Policy directly from WSDL, and
  current WS-Policy wont 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 ltpropertygt 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 FP 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 isnt 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?