Re: Scoping multi-transport / async bindings for WSDL

> The point is to ask if we all agree, however we actually acheive it, 
> that WSDL needs to support patterns like this - a request/response 
> operation where the request and the response might be sent along 
> completely different transport paths (and in fact where the response 
> transport path might be unknown at WSDL time).


I'm probably missing something, but wouldn't the ability to supply a 
reply-to EPR dynamically subsume this as a special case?  Maybe not.  
There look to be several different constructs on the table:

   1. Current WSDL:  An operation is bound to a (single) transport.  The
      server advertises "I accept request/reply operations on this
      transport."
   2. The messages in an operation may be bound statically, but
      separately.  The server advertises "I accept requests on this
      transport and send replies on this one."  IMHO this invites
      combanatorial explosion (or at least a small "bang", since there
      are generally only two dimensions) and seems to be of limited use.
   3. The messages in an operation may be bound dynamically from a given
      set of transports.  The server advertises "I accept requests on
      these transports and send replies on these transports."  (the two
      sets may not be identical).
   4. Outgoing messages may be sent to arbitrary EPRs.  The server
      advertises "I accept requests on these transports and send replies
      wherever you say, as long as I know how to send to the destination
      you give."

I don't see how 3 could work without giving a reply-to EPR, or the moral 
equivalent, in the request message.  That is, 3 requires 4.  The 
question then becomes how best to advertise the set of supported reply 
transports.  This seems more like a server-wide property than a 
per-operation property.

 From thinking it over myself, and then talking it over with my local 
WSDL representative, it seems like the most direct approach is just to 
add some sort of "dynamic reply" element to the binding (e.g., as a 
feature?).  This means "I accept requests as per this binding, and you 
may specify the reply EPR dynamically, from your choice of these 
transports."  On output-first (the old solicit response) it says "I will 
send a request as per this binding.  It will contain a set of possible 
reply EPRs from one of these transports."

The current behavior falls out as a special case.  It's equivalent to a 
supported reply transport list of "anonymous", with a missing reply-to 
defaulted to anonymous.