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

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

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

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

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: Properties : NONE Binding : Implements: Module: Implements:

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

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

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

Describing Features,cont. <soap:feature uri= soap:required=true/> Value <soap:property uri= type=myNS:restrictedType/>

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)