New LC Issue: Changes to wsaw:Anonymous

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
<http://spaces.msn.com/auburnmarshes>   ]