Re: WSDL Binding Feedback

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?


Thanks,

Todd


----- Original Message ----- 
  From: David Hull 
  To: Todd Wolff 
  Cc: Jonathan Marsh ; 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" 
    a.. 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.

    b.. 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.