1. Features, Properties and Bindings Glen Daniels, Macromedia November 15 th, 2002

2. A Brief History of Features SOAP HTTP binding is natively req-resp Req-resp is also something you can do over other protocols by using SOAP extensibility SOAP 1.2 needed a way of describing the semantics which are provided by protocol bindings, and which could also be implemented with headers

3. Whats a Feature? Arbitrary piece of semantics / functionality Abstractly described in a spec Named with a URI We can talk about it / point to it Other specs can refer to the SAME thing

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

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

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

7. Example Diagram Feature: http://secureChannel Properties : NONE Binding : http://https-binding Implements: http://secureChannel Module: http://mySecurityExt Implements: http://secureChannel

8. 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: BLOWFISH When in a Binding: Cipher could be a protocol header, or simply a fixed value

9. Describing Modules isnt expressive enough Cant do state/context dependent headers lets us say follow the rules of the Module spec Properties can be constrained/given values in WSDL

10. Describing Features has been proposed, but features can be more than just SOAP is better Can describe abstract features / requirements / policies in the interface

11. Describing Features,cont. <soap:feature uri=http://correlation-featurehttp://correlation-feature soap:required=true/> Value <soap:property uri=http://property2 type=myNS:restrictedType/>

12. Proposal This extensibility / composability framework is architectural, and gets used by both SOAP & WSDL It should move out of SOAP More research is needed (scenarios)