RE: Scoping multi-transport / async bindings for WSDL

<snip>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).</snip>

Hi Glen,

I definitely agree that this is the question we have to answer before we
go to details about how to make it work. 

Actually, there is another important question I tried to illustrate with
the expenseReport example - Should we support patterns where operations
of a single interface may be bound to different binding types (for
example, one for soap/http, one for plain http, etc)? If the answer if
no, then your proposal is a combination of my option 1 and option 4.

Best Regards,
Kevin

>From: public-ws-async-tf-request@w3.org 
>[mailto:public-ws-async-tf-request@w3.org] 
>Sent: Tuesday, Feb 08, 2005 11:44 AM
>To: public-ws-async-tf@w3.org
>Subject: Scoping multi-transport / async bindings for WSDL
>
>
>
>
>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.
>
>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 Tuesday, 8 February 2005 22:30:32 UTC