Re: Scoping multi-transport / async bindings for WSDL

Glen Daniels wrote:
> 
> Hi folks:
> 
> On last week's async TF call, we discussed a number of questions which
> the TF will need to answer.  I mentioned that I thought the "high order
> bit" here was related to the granularity of WSDL bindings for
> operations.
> 
> As Kevin points out in [1], binding different operations in an interface
> is an important and interesting use-case to consider, and in fact that's
> very similar to what I was talking about, except I wanted to
> specifically discuss the level of operation messages.
> 
> I'm wondering if it's OK for us to bind the different messages (inputs,
> outputs, faults) inside a given operation in different ways - and even
> to leave the actual bindings for some of these messages "floating", to
> be resolved at runtime.
> 

By floating do you mean completely undefined or something like a choice 
between N bindings (perhaps with a default)?

Regardless, if we do go down this path then I assume that we would then 
have a requirement on the EPR (such as the value of ReplyTo for in-out) 
that it contain information about the binding that is selected.

> An example might look something like this (syntax is not meant as a real
> proposal, and I'm explicitly NOT dealing with things like SOAP in one
> direction and plain HTTP in the other, so the difference is at the SOAP
> underlying protocol level, not the WSDL binding level):
> 
> <interface name="store">
>  <operation name="buySomething">
>   <input element="tns:PO"/>
>   <output element="tns:Invoice"/>
>  </operation>
> </interface>
> 
> <binding interface="tns:store" type="wsdl:soap">
>  <!-- this lets protocol be defined by each msg -->
>  <soap:enableMultiProtocol/> 
> 
>  <operation name="buySomething">
>   <input>
>    <!-- input gets sent via HTTP -->
>    <protocol>http</protocol>
>   <output>
>    <!-- no <protocol> here, so it's left "unbound" -->
>    <!-- These are the options for someone sending me a ReplyTo... -->
>    <availableProtocols>http,smtp</availableProtocols>
>  </operation>
> </binding>
> 
> This is something a little like Kevin's option 4.  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).
> 
> What do you think?
> 
> --Glen
> 
> [1]
> http://lists.w3.org/Archives/Public/public-ws-async-tf/2005Feb/0022.html
> 
>

Received on Wednesday, 9 February 2005 19:18:37 UTC