Re: WSDL Binding Feedback

Comments inline.

Todd Wolff wrote:

>Jonathan,
>
>So that we can better understand one another, I assume 'programming model'
>implies the mechanics by which message exchanges are handled within the
>'application layer.'  If this is the case, then I understand
>that the value of the 'anonymous' element, which is a binding artifact,
>cannot be used, as it is currently designed, to indicate the programming
>model employed, i.e. sync or async.  This, I believe, is exactly the
>problem.
>
>Allow me to explain. Lets assume that only a single binding is provided for
>a service, i.e. a soap/http binding and the binding binds an interface with
>a single 'In-Out' operation named 'echo'.  If the value of the anonymous
>element defined on the binding is 'optional', how/where is the decision made
>to insert an anonymous URI vs. a non-anonymous URI into the wsa:ReplyTo
>header of a request sent to this operation?
>
>It would appear to me, that this decision should be made within the
>application layer.  The only way that this would be possible is if:
>
>1.  The 'optional' value were removed from the spec, or
>2.  The 'anonymous' element were removed and a new binding type created,
>i.e. 'soap/http non-anon.'
>
>Either solution would allow the WSDL author to create two soap/http
>bindings. One that requires that all requests sent to the 'echo' operation
>contain an anonymous ReplyTo URI and one that prohibits all requests sent to
>the 'echo' operation from using an anonymous ReplyTo URI. The decision then
>COULD be made within the application layer via endpoint assignment, i.e. by
>selecting either the SoapHttpAnon endpoint or by selecting the
>SoapHttpNonAnon endpoint.
>  
>
If you want to define an endpoint that requires anonymous (i.e., doesn't
support "async" responses), use wsaw:Anonymous="required".  If you want
to define an endpoint that prohibits anonymous (i.e. /only/ supports
"async" responses), use wsaw:Anonymous="prohibited".  Otherwise, by
default or by explicitly using wsaw:Anonymous="optional" the WSDL
advertises that the endpoint will accept either form.

The existing SOAP 1.1/HTTP binding, together with the very brief note
describing the use of status 202, supports this as-is. XMLP is currently
hammering out the analogous case for SOAP 1.2, but the results for HTTP
will be essentially the same.  For example, with wsaw:Anonymous="optional"

    * If the request has wsa:ReplyTo anonymous, the reply will come back
      as usual with a 200 status.  Similarly, if wsa:FaultTo is
      anonymous (or missing and ReplyTo is), a fault will come back as
      usual with a 5xx (or was it 4xx?) status.
    * If the request has wsaw:ReplyTo non-anonymous, the HTTP response
      will have a 202 response code.  The sender then knows to expect a
      response elsewhere.  More precisely, the sender will /already/
      know what to expect unless it included an anonymous wsaw:ReplyTo
      and a non-anonymous wsaw:FaultTo or vice-versa.  In this "split"
      case, the response code will disambiguate.  In the more common
      case, it will confirm what the sender already knows and
      distinguish replies from faults as usual.

Knowing this, the sender can use anonymous endpoints or not as it sees
fit, according to its own circumstances.

In general, the WSDL describes what the receiver will accept and what it
will do in response to a message, in terms of the facilities defined in
the core and the SOAP binding (or whatever other binding is relevant). 
The sender may do with that information what it likes.

In the case of anonymous optional, the receiver is saying "[from the
WSDL binding] You may send me messages with any mix of anonymous and
non-anonymous response endpoints. [from the core and SOAP binding] If I
use an anonymous endpoint for a fault or response, that fault or
response will be sent via the HTTP response.  Otherwise, it will be sent
according to the relevant binding."

If the sender wants to receive responses via the HTTP response, it
should use anonymous.  If not, it should use something else.  There is
no way for the receiver's WSDL to signal what the sender should do. This
is completely up to the sender.

This is really no different from the case with "none", except that none
is always available and so doesn't need to be mentioned in the WSDL at
all.  The receiver MUST support none (as per the Core).  The sender can
use it or not as it sees fit.

Hope this helps.

>Perhaps a non-normative example presenting a use-case which rationalizes the
>need for an 'optional' value is warranted - specifically one that explains
>how/where within an implementation the decision to populate the ReplyTo
>header in a request with an anonymous vs. a non-anonymous URI is made.
>
>  
>
See above.  This decision is out of our scope.  That said, non-normative
use cases might well make things clearer.