New LC Issue: Changes to wsaw:Anonymous

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

New LC Issue: Changes to wsaw:Anonymous

Jonathan Marsh

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




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  ][  [hidden email]  ][  ]