Re: WSDL Binding Feedback

Todd Wolff wrote:

> Hi David,
>  
> Thanks for the response.  When viewed from the perspective of the
> receiver, the mechanics of how an implementation would manage
> exchanges delivered to an endpoint whose binding indicates
> wsa:Anonymous='optional' is very clear.
>  
> What my issue attempts to address, however, is how the exchange
> is handled from the sender's point of view.  Lets assume that an
> application generates an abstract message instance, adds content to
> the payload and invokes an In-Out operation on the receiving service
> all using some application specific API.  Life is good.
>  
> Now it is up to the binding to take the abstract message instance,
> convert it into a protocol specific message instance, i.e. SOAP in
> this case, set the relevant ws-addressing headers and submit it via
> HTTP.  My question is this.  How does an implementer determine what
> value to set on the ReplyTo header if the receiver allows you
> the choice of using an anonymous URI or a non-anonymous URI?  And ...
> what use-case necessitates that this decision must exist?

First, the use case is easy.  If I'm providing an operation through an
endpoint, some of my clients might want synchronous replies and some
might want asynchronous (or the same client might want one for one
invocation and the other for another).  In the (now) typical case that
I'm using HTTP, anonymous is always there for free.  If I support
non-anonymous, I automatically support both.  That is, I have the
capability to send a response back on the HTTP response, or through some
other means and all I need is for the sender to tell me which it wants. 
For HTTP, the expected scenarios are "prohibited" and "optional".  The
wsaw:Anonymous just tells the rest of the world which one I'm doing,
that is, whether a sender has the option of using non-anonymous.

As for what the sender does, that depends on the sender, that is, the
sender's tooling.  A sender might simply always use anonymous without
consulting anyone else.  This will produce the usual behavior, and all
the sender has to do is include the appropriate wsaw:Action and hardwire
wsa:ReplyTo to anonymous.  In fact, if wsaw:UsingAddressing isn't
wsa:required, it doesn't even have to do this.

Only if the sender wants an asynchronous response does it have to do
anything special at runtime.  In this case, the tooling will most likely
have to have an extra parameter indicating where to send responses (or
at least, telling it to ensure that there is an endpoint listening for
responses).  Exactly how this happens is up to the tooling and outside
our scope.

Put another way, having wsaw:Anonymous="optional" for an endpoint
doesn't require the sender to do anything more than having
wsaw:Anonymous="required".  The sender /may/ choose to take advantage of
non-anonymous replies with an "optional" endpoint, but it doesn't have
to.  By hardwiring wsa:ReplyTo to anonymous (and either omitting
wsa:FaultTo or hardwiring it the same way), it can pretend that such an
endpoint said "required".

By contrast, if wsaw:Anonymous is "prohibited", the sender will have to
set up a listener if it wants to interact with that endpoint.

>  
>  
> Thanks,
>  
> Todd
>  
>  
> ----- Original Message -----
>
>     *From:* David Hull <mailto:dmh@tibco.com>
>     *To:* Todd Wolff <mailto:twolff@bluestemsoftware.com>
>     *Cc:* Jonathan Marsh <mailto:jmarsh@microsoft.com> ;
>     public-ws-addressing-comments@w3.org
>     <mailto:public-ws-addressing-comments@w3.org>
>     *Sent:* Tuesday, April 04, 2006 2:01 PM
>     *Subject:* 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.
>