Re: WSDL Binding Feedback

David,

I'm not suggesting that the committee remove the ability to specify an anonymous URI vs. a non-anonymous URI within ReplyTo at runtime.  Standardizing this behavior by formally defining a binding extension is a wonderful thing (see my original message.)

What I am suggesting is that for an HTTP binding, the allowable values for the anonymous element, when wsaw:UsingAddressing is 'required', should be 'required', 'prohibited.'  Binding behavior (from the perspective of the sender) will then be predictable across all implementations. The runtime decision as to whether the reply should be received synchronously or asynchronously could then be deferred to the application (where, IMO, the decision belongs.)


----- Original Message ----- 
  From: David Hull 
  To: Todd Wolff 
  Cc: Jonathan Marsh ; public-ws-addressing-comments@w3.org 
  Sent: Tuesday, April 04, 2006 3:59 PM
  Subject: 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 
      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.