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) |
|