Re: New LC Issue: Changes to wsaw:Anonymous

Jonathan,

 > Because there is no way to say, “I’m using addressing, but making no
 > design-time claims /here/ as to support for anonymous addresses”,
 > wsaw:UsingAddressing is unsuitable as a universal mechanism for
 > engaging addressing.

Is this an issue with the default value of wsaw:Anonymous being 
'optional'. I.e. does the concern go away if we say that there is no 
default value (i.e. unknown)?

-Anish
--

Jonathan Marsh wrote:
> Section 3.2: Anonymous Element.
> 
>  
> 
> wsaw:Anonymous does not correspond well with the features of WCF.  
> Instead of providing a single SOAP binding that can be parameterized at 
> will to accept anonymous URIs, our implementation provides separate SOAP 
> bindings for anonymous and non-anonymous cases.  This makes direct 
> support for the “optional” value impractical for us to support during 
> the CR testing phase.  For this reason we’d like to see wsaw:Anonymous 
> functionality deferred so it doesn’t hold up the rest of the 
> specification.  However, the current design also places undesirable 
> limits on the evolution of anonymous handling in the future.
> 
>  
> 
> In general we are currently tending towards favoring sets of composable 
> assertions rather than a monolithic, though parameterized, assertion or 
> extension.  In WS-Policy generally, multiple assertions with distinct 
> QNames are preferably to a single assertion that uses attributes and/or 
> content to distinguish different cases. For example, given two possible 
> assertion designs;
> 
>  
> 
> 1.         <A1/>
> 
> <A2/>
> 
> <A3/>
> 
>  
> 
> 2.         <A Parameter='1' />
> 
> <A Parameter='2' />
> 
> <A Parameter='3' />
> 
>  
> 
> then design 1 would generally be preferred because it allows the policy 
> matching logic to provide more accurate matches between policies.  
> Anonymous handling currently feels more like design 2.
> 
>  
> 
> This results in a suboptimal expression of anonymous handling when 
> UsingAddressing appears as a policy assertion.  The lack of a 
> “ws-addressing engaged” primitive assertion prevents UsingAddressing 
> (used as a policy expression, a WSDL extension, or through the soap 
> module synonym) from composing well with other primitive (or composite) 
> extensions or assertions that govern the handling of anonymous.
> 
>  
> 
> For instance, we plan to develop and deploy policy assertions which 
> represent composite functionality, one aspect of which may be 
> constraints upon anonymous handling.  As far as WS-Addressing is 
> concerned, this represents out-of-band specification of 
> wsaw:Anonymous-like capability.  Unfortunately, the value space of 
> wsaw:Anonymous is not extensible, and forces one to make claims as to 
> the treatment of anonymous addresses.  Other assertions may contradict 
> the claims made in wsaw:Anonymous, impeding consistent and accurate 
> description and therefore interoperability.  Another bad effect of only 
> providing a composite design is that anonymous address handling cannot 
> be separately negotiated at runtime through trial and fault.
> 
>  
> 
> Because there is no way to say, “I’m using addressing, but making no 
> design-time claims /here/ as to support for anonymous addresses”, 
> wsaw:UsingAddressing is unsuitable as a universal mechanism for engaging 
> addressing.  Rather than a composite assertion covering both engagement 
> of WS-Addressing and anonymous handling, we’d prefer to have composable 
> primitives representing this orthogonal functionality.
> 
>  
> 
> We also note that some members of the WG have stated their desire to use 
> wsaw:Anonymous as a hint for code generation (sync, async).  We don’t 
> think overloading anonymous is a good way to hint as to how a 
> programming model should be built, and would not support the retention 
> of wsaw:Anonymous solely for this purpose.
> 
>  
> 
> We therefore propose that wsaw:Anonymous be removed from this spec and 
> features to constrain anonymous or hint at programming models be 
> deferred to future specs.
> 
>  
> 
> Failing that, we ask that “unspecified” be added as a value for 
> wsaw:Anonymous, and that this value be treated as the default when no 
> wsaw:Anonymous element appears.  The addition of an “unspecified” value 
> enables the wsaw:UsingAddressing extension/assertion to act dually as a 
> primitive and composite assertion, and compose with other mechanisms of 
> indicating the handling of asynchronous messages as they are developed. 
> 
>  
> 
> ** [  **Jonathan Marsh ** ][ ** jmarsh@microsoft.com 
> <mailto:jmarsh@microsoft.com> ** ][ 
> ** http://spaces.msn.com/auburnmarshes**  ]**
> 
>  
>

Received on Friday, 7 April 2006 19:31:13 UTC