Re: WSDL Binding Feedback -- possible solution

Hi David,

Your last paragraph summed it up pretty well for me.  Now I feel comfortable that you and the rest of the committee understand the issue/non-issue.  My concern is based more on intuition than on any concrete example demonstrating interoperability.  You are right in saying that on the wire, there is no ambiguity.  The ambiguity exists instead within the sender's binding. 

Again, I'm just happy we now, at long last, have a standard for async messaging over HTTP using an In-Out MEP.  It's a huge improvement over having to declare 'callback' operations on a separate interface.

The committee is doing a great job.  Thanks for all the hard work.


Todd


----- Original Message ----- 
  From: David Hull 
  To: Todd Wolff 
  Sent: Thursday, April 06, 2006 12:18 PM
  Subject: Re: WSDL Binding Feedback -- possible solution


  Todd,

  First, thanks for your input.  It's always good to have a fresh set of eyes in order to check our assumptions and be sure we haven't missed the obvious (or not-so-obvious).  Also, thanks for your patience in explaining your viewpoint.  I'm pretty sure I understand it now, but only now that I've tried to reply to your latest message explaining why there is no issue :-).  I also understand your need to bow out.  Fortunately, I think I can now explain why the WG has acted as it has.  I no longer feel I'm missing something basic, which I did at the start of f this thread.  I hope that what follows will be enough to close out the issue.

  I was going to say that, if the business logic makes a synchronous call to the binding API, i.e., it says something like result=getResponse(endpoint, request), then the binding will know to use anonymous, and conversely if the business logic makes an async call, i.e. getResponse(endpoint, request, callback), the binding will know to use non-anonymous.

  But while that certainly seems like a natural way to do things, it's still a heuristic.  The binding could instead decide to use a listener with the sync call (and block until the listening thread completes) or it could use anonymous with an async call (and call the callback when the response comes back).  The type of call used does not say unambiguously which way to go, and neither does anything else.  Each binding implementation will have to decide on its own how to make the decision for "optional" endpoints.

  If that's the issue, I can appreciate it, but I'm very sure that the WG does not see this as a problem and will be comfortable closing the issue with no action.

  First, there is no interoperability problem on the wire.  The endpoint has advertised that it can handle either option, so it doesn't need clients to behave uniformly, any more than it needs all clients to send the same request message.  The endpoint will behave differently depending on what the sender sends; In particular, it will use a second message exchange to deliver the response in the async case.  Again, there is no interop problem.  The service endpoint is obligated to follow the sender's instructions.  If the sender includes a non-anonymous response endpoint, the service endpoint does not have the option to send the response back on the HTTP response instead.  If it did have such an option, there would indeed be an interop problem, since some service endpoints might do this and some might not.

  If there were some third party expecting the endpoint always to send a response on the HTTP response or always to use a second message exchange, then that party would not know which to expect based on the WSDL alone.   It would also have to look at the request.  If you can name such a party, then I believe you would have an interesting issue.  But this party would have access to the WSDL (that's what's confusing it) and the network traffic with the endpoint (that's what it has expectations about), so it's difficult to see how it wouldn't have enough information to know what was going to happen.

  If there's no interop problem on the wire, then the remaining problem is that bindings don't know what to do.  I believe the WG sees this as flexibility, not ambiguity.  A naive binding can simply choose always (or never) to use anonymous and everything will interop just fine.  More sophisticated bindings can compete on how well they choose when to go sync and when to go async.  Again everything will be fine.  Those bindings don't have to interop with each other, only with the service endpoints, and the service endpoints have advertised that they're fine either way.

  Todd Wolff wrote: 
    Hi David,

    My point is that there should be NO heuristic involved when determining whether to invoke an operation synchronously or asynchronously from the perspective of the sender. If the 'optional' value is removed, then the binding's job is straightforward.  If the value is 'required', an anonymous URI is set on ReplyTo.  If it's 'prohibited', a non-anonymous URI is set on ReplyTo.  

    IMO, a SOAP/HTTP binding where wsa:UsingAddressing is 'required' should behave similarly across all implementations (which, after all, is one of the objectives behind the ws-i basic profile.)

    Thanks for all your replies.  I'm going to 'bow out' of the conversation for now and concentrate on my 'paid work' :-)  Hopefully the committee has enough information to discuss this issue further, if it so desires.


    Thanks again,

    Todd
      ----- Original Message ----- 
      From: David Hull 
      To: Todd Wolff 
      Cc: Jonathan Marsh ; public-ws-addressing-comments@w3.org 
      Sent: Wednesday, April 05, 2006 3:23 PM
      Subject: Re: WSDL Binding Feedback -- possible solution


      I think I may finally understand the issue.  If I understand correctly, it's not about what policies or processes a sender might use to decide whether it wants sync or async behavior, but that a WSDL endpoint description with wsaw:Anonymous="optional" does not by itself provide enough information to determine whether the operation with be sync or async.

      If this is the point, then it's correct as far as it goes.  To know whether a particular operation is sync or async you look at the response endpoints, not the WSDL description.  That's by design and highly unlikely to change.  If you want to know what modes an endpoint supports, you can look in the WSDL.  If an endpoint can support both, it will say so by having wsaw:Anonymous optional.  This is also by design and highly unlikely to change.

      However, neither the WSDL endpoint description nor the response endpoints is what the sender is likely to be looking at when it sends a message.  It will likely see an EPR, that is, an endpoint reference.  Such a reference can carry anything at all in its metadata.  In particular, it can contain a flag saying which mode to use.  E.g. if ServerEndpoint is an EPR,

<ServerEndpoint>
  <wsa:Address>http://www.example.com/AnEndpoint</wsa:Address>
  <wsa:Metadata>
    <ns:Mode>sync</ns:mode><!-- must use anonymous -->
  </wsa:Metadata>
</ServerEndpoint>could indicate synchronous operation while

<ServerEndpoint>
  <wsa:Address>http://www.example.com/AnEndpoint</wsa:Address>
  <wsa:Metadata>
    <ns:Mode>async</ns:mode><!-- must not use anonymous -->
  </wsa:Metadata>
</ServerEndpoint>could indicate async.  If the mode marker is missing, you'll have to know some other way, perhaps because the WSDL for the endpoint says "required" or "prohibited".

      One interesting candidate for the mode marker would be wsaw:Anonymous.  For example, if you want to use an "optional" endpoint synchronously, you refer to it by an endpoint with wsaw:Anonymous="required" in its metadata.  Effectively, the value provided in the metadata overrides the WSDL.  This overriding is only sensible if the WSDL says "optional" or if the WSDL and metadata say the same thing.

      I believe we've deliberately shied away from defining a general rule for this sort of thing, and I can't find anything in section 2 either to support or prohibit this overriding semantic.

      Personally, I'm still not convinced this is necessary, but perhaps it addresses the problem at hand.


      Todd Wolff wrote: 
        David,

        (My Comments are In Line )

        Unless I've missed something, the runtime decision as to whether the reply should be received sync or async can be deferred to the application even if wsaw:Anonymous is "optional".  I don't think I (or the rest of the committee) understand what case breaks if Anonymous is "optional".

        Comment: By 'application layer' I mean business logic, which works at the abstract level, and has no visibility/notion of binding related artifacts, which includes ws-addressing message headers. Using BPEL as an example, the only way a BPEL application, i.e. process, can influence the manner in which a service is invoked is via endpoint assignment.  If anonymous is 'optional' and only one endpoint is supplied, the application has no control over the sync vs. async decision. The decision is instead up to the binding or as you call it, the 'tooling.'

        If you define two separate endpoints, one "required" and one "prohibited", then the sender can select sync or async behavior by choosing which endpoint to send to.  But it seems much easier just to define one optional, and let the sender select based on how it sets the response endpoints as opposed to which endpoint it sends to and how it sets the response endpoints.

        Comment: I agree that it is easier to gen the wsdl, if only one binding and endpoint is required, but the logic within the binding layer, i.e. the tooling is more complicated. If anonymous is 'optional' every vendor must come up with their own algorithm to determine when to set an anon ReplyTo URI vs. a non-anon ReplyTo URI within request.  I am arguing that bindings across all implementations should behave predictably.  If each vendor uses their own algorithm this will not be the case.

        Suppose I have two endpoints defined or an operation: endpoint R is required and endpoint P is prohibited.  If I want sync behavior, I tell my tooling I'm sending to endpoint R and it has to know to set the response endpoints to anonymous.  If I want async behavior, I send to endpoint P and the tooling has to know not to use anonymous (and it either has to establish a listener or get one from me).  In general, I'll want to use one API call to send to R and a different one to send to P.

        Comment: this is exactly what I am proposing. The application, i.e. business logic, via some application specific API indicates to the tooling which behavior it wants by selecting endpoint R or endpoint P.  The tooling then has no decision to make, it is made by the application.  If anonymous='optional'i.e. only a single endpoint O exists, then this isn't possible.

        On the other hand, with a single endpoint, O optional, I say I'm sending to that endpoint and say whether I want sync or async behavior, and the tooling sets the endpoints based on that.  If I want sync, I use the sync API call to send to O.  If I want async, I use the Async call to send to O.

        Comment: when you say API at this level, you mean the tooling API, i.e. something that isn't accessible from application logic.  Again, this implies that the binding, i.e. tooling must make the sync vs. async decision which will be different for every implementation.

        The exact same information is being conveyed in either case, just in different ways.

        We're also being a bit loose here with the term "application level".  If "application level" means "business logic", then the question of whether the behavior on the wire is sync or async is orthogonal.  If the wire is async and the business logic wants sync, spawn a thread to send the request while the main thread sleeps and have the response listener wake the main thread when the response arrives (I'll also want to set a timeout in case it doesn't arrive in time).  On the other hand, if the wire is sync and the business logic wants async, send the request, block for the response and send the response to the business logic's listener.

        Comment: I understand.  The application shouldn't be concerned with the underlying transmission protocol. The application either decides to block for a response, or not to block, and the tooling can emulate either, regardless of whether it's HTTP, JMS, etc ... I think this still remains true, the difference being that we no longer need this 'mess' under the covers to emulate async behavior over a synchronous transmission protocol, i.e. HTTP. When the application decides to block for a response, it selects endpoint R otherwise it selects endpoint P.  No emulation on behalf of the tooling is required.

        The point being that the "application level" that would be selecting whether to use anonymous or not (whether by selecting between two endpoints or just using one) is most likely going to be an intermediate layer of tooling sitting between the business logic and the wire.  This level of tooling shouldn't be bothered by having to know about things like anonymous addresses.

        Comment:  I agree.  The application shouldn't be concerned with ws-addressing at all, including anon URI's.  This is binding related logic, i.e. the tooling's responsibility.  The application is, however, as is the case with BPEL, capable of understanding and manipulating endpoints.

        If none of this seems to apply to your situation, maybe we should try working through an an example with hypothetical API calls and wire messages.

        Comment:  I think we are both on the same page as far as the mechanics are concerned.  Where we differ is, where the sync vs. async invocation decision is made.  I contend that if anonymous is 'optional' and the decision is made by the tooling using some proprietary algorithm, then every implementation will behave differently.  

        Shouldn't a SOAP/HTTP binding behave similarly across all implementations? And if it doesn't, will application portability be a problem?  If the answer to both questions is 'no', then this is a non-issue.  If the answer to either question is a 'maybe' then it should be addressed.


        Todd