Features, Properties and Bindings Glen Daniels, Macromedia November 15th, 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

What's 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

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> isn't expressive enough Can't do state/context dependent headers <soap:module> lets us say "follow the rules of the Module spec" Properties can be constrained/given values in WSDL

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

Describing Features,cont. <soap:binding>   <soap:feature uri="http://correlation-feature"                 soap:required="true"/>   <soap:property uri="http://myProperty">Value</>   <soap:property uri="http://property2"                  type="myNS:restrictedType"/>   <soap:module uri="http://CorrelationModule"/> </soap:binding>

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)