120 likes | 130 Views
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
E N D
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 Feature: http://secureChannel Properties : 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> 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)