Re: Description of scenarios

Glen,

This looks pretty good.  I like the description of how a feature as a whole is required.  I do have some questions, though.

1) Suppose that a feature contains a number of properties, and the WSDL author wants to express the fact that a certain property is required?  There is no coordination showing here between the feature element and the propertyValue element.  That's fine, but isn't it possible to require a property?

2) Is it possible to show propertyConstraint as well as propertyValue?

3) In general, I'd really like to see the whole proposed syntax, and then the examples of use.

Amy!
On Wed, 26 Feb 2003 11:54:55 -0500
Glen Daniels <gdaniels@macromedia.com> wrote:

> 
> 
> Here are descriptions/quick notes of the scenarios we decided to introduce on Monday at the F2F.  If folks could take these and perhaps expand on them a bit, that would be great.  The syntax proposed is simply meant to be illustrative.
> 
> I. Security feature
> 
> This example illustrates an "on/off" feature which has no explicit properties.  We simply want to indicate that security (either in binding form or via a SOAP module) is either required or offered.
> 
> A simple way to do this for a required feature might be as follows:
> 
> <wsdl:feature uri="http://example.com/secure-channel/" required="true"/>
> 
> This abstractly states "the secure-channel feature must be engaged".  It could live in a <portType>, a particular <operation>, a <service>, or even an <input>/<output>.
> 
> It is up to the software doing the actual interaction to determine how such an abstract feature requirement will be met.  As an example, if the SOAP underlying transport binding in use is HTTPS, the binding specification may specify that it natively provides the "secure-channel" feature.  The software would know this (since one would assume they implemented the binding from the spec), and realize the requirement was met.  Alternately, the service may indicate that a SOAP module is available via something like this:
> 
> <soap:module uri="http://example.com/modules/SOAPSecureChannel"/>
> 
> Again, if the software at the client had an implementation of this module around, it would know that the module implemented the desired feature and realize the requirement was satisfied.
> 
> II. WebMethod feature
> 
> This is an almost trivial example of setting a property associated with a feature.  We use the SOAP 1.2 WebMethod feature, and probably specify the value for the "Method" property like this:
> 
> <propertyValue uri="http://www.w3.org/2002/12/soap/features/web-method/Method">
>   GET
> </propertyValue>
> 
> This could be in the <portType>, in an <operation>, or inside a <service> or <binding>.  The SOAP HTTP binding automatically provides the WebMethod feature, and would use the value described above to determine what method to send down the wire.
> 
> A SOAP-specific version of this might look like this:
> 
> <soap:binding>
>   <soap:webMethod>GET</soap:webMethod>
>   ...
> 
> One of the bonuses to doing it with explicit features/properties outside the SOAP binding is that other WSDL bindings (i.e. the WSDL HTTP binding) could use the same property to indicate which HTTP method should be used.  Along those same lines, expressing it as a property in a standard "bag" of URI-tagged values allows any other feature/extension to refer to the value in a standard way, without needing to know the specific WSDL binding (i.e. <soap:webMethod>).  As feature specs proliferate, it is better to have one way to refer to the properties (which incidentally matches the way they are defined in the specs, by URI) than a separate WSDL extensibility element for each new spec.
> 
> How's that for starters?
> 
> --Glen
> 


-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Wednesday, 26 February 2003 14:53:44 UTC