RE: Revised Asynch Binding

Isn't a messageID also required to correlate the request and the
response, since they cannot be correlated by being on the same channel?
Both WS-Address and WS-MD have the capability of carrying such an ID,
but the two concepts are orthogonal and other addressing mechanism might
not include a messageID capability.

Ugo

> -----Original Message-----
> From: www-ws-desc-request@w3.org 
> [mailto:www-ws-desc-request@w3.org] On Behalf Of Sanjiva Weerawarana
> Sent: Sunday, July 04, 2004 9:16 AM
> To: www-ws-desc@w3.org
> Subject: Re: Revised Asynch Binding
> 
> 
> 
> This feels all too complicated to me.
> 
> The problem we want to address is to enable an asynchronous 
> SOAP/HTTP binding right? IMO trying to make all bindings 
> asynch aware is beyond the scope of what we need at this time.
> 
> So if its just SOAP/HTTP I propose the following simple solution:
> 
>     - Presently we require the user to set the 
> /binding/@wsoap:protocol
>       attribute to http://www.w3.org/2003/05/soap/bindings/HTTP/
>       to indicate that they wish to have the XMLP defined 
> SOAP-over-HTTP
>       protocol. That protocol assumes that the response of a request/
>       response will always come back in the response channel of the
>       HTTP request.
> 
>     - We define a new URI: 
> http://www.w3.org/@@@@/@@/wsdl/soap/asynch/http
> 
>     - By assigning the above value to 
> /binding/@wsoap:protocol attr, the
>       user is indicating that they will follow all the rules 
> of SOAP/HTTP
>       protocol, but for one: the response MAY get sent back 
> via another
>       transport/connection and not necessarily via the 
> response path of
>       the HTTP request.
> 
>     - How does the requester indicate how the response should be sent?
>       To avoid political problems, we say that how that is 
> done MUST be
>       indicated in the WSDL thru extensibility (or F&P; which 
> is of course
>       a special form of extensibility). So, if I want to 
> allow the use of
>       WS-Addressing's <ReplyTo> to indicate where the 
> response should go,
>       I need to assign the above URI to the SOAP protocol 
> attribute, put
>       some indication in the WSDL that I can handle WS-Addressing and
>       that's it.
> 
>     - We can also state that if the above URI is assigned to 
> @wsoap:protocol
>       and if no reply address has been defined in some other 
> manner, then
>       the old approach of sending the response via the HTTP 
> response will
>       hold.
> 
> That's it. Its very simple and it allows me to do full async 
> stuff very cleanly.
> 
> Sanjiva.
> 
> ----- Original Message ----- 
> From: "David Orchard" <dorchard@bea.com>
> To: <www-ws-desc@w3.org>
> Sent: Wednesday, June 30, 2004 12:47 AM
> Subject: Revised Asynch Binding
> 
> 
> >
> > In order to do an Asynchronous binding, that is binding an 
> abstractly
> synchronous operation to 2 synchronous operations in the 
> binding, it means that most of the binding operation 
> constructs that are expected on the input side must also be 
> available for the output.  The way that a wsoap:operation 
> extends the binding operation must be available for the 
> output as well as
> the input.   Further, the service must have a way of 
> specifying what the
> address of the "callback" is.
> >
> > The current model is:
> > <definitions >
> >   <binding name="xs:NCName" interface="xs:QName"? type="xs:anyURI"
> >            wsoap:protocol="xs:anyURI"
> >            wsoap:mepDefault="xs:anyURI"? >
> >
> >     <operation ref="xs:QName"
> >                wsoap:mep="xs:anyURI"?
> >                wsoap:action="xs:anyURI"? >
> >
> >     <input messageLabel="xs:NCName"? >
> >     </input>*
> >     <output messageLabel="xs:NCName"? >
> >
> >     </output>*
> >     </operation>
> >   </binding>
> >
> > This causes us problems because we want to retain the
> operation/input|output model.  The part of wsoap:operation 
> that is useful to both input and output is the mep.  
> Therefore, I propose that the wsoap:operation be modified.  
> The operation information - namely the protocol, mep and 
> action - apply to the input or output in 2 ways: When the mep 
> and action are only on the operation, then the implication is 
> that the protocol operation binds directly to the 
> input/output.  For example, an input binds to http request 
> and the output binds to http response.  This can be 
> overridden in the input or output to enable a 2nd protocol 
> operation to be controled.  The protocol may be overridden to 
> specify a different protocol for the second message.  In the 
> case of wsdl in/out?, then the output may contain protocol, 
> mep and/or action attributes.  In the case of wsdl out/in?, 
> the input may contain protocol, mep and/or action attribugtes.
> >
> > <definitions >
> >   <binding name="xs:NCName" interface="xs:QName"? type="xs:anyURI"
> >            wsoap:protocol="xs:anyURI"
> >            wsoap:mepDefault="xs:anyURI"? >
> >
> >     <operation ref="xs:QName"
> >                wsoap:mep="xs:anyURI"?
> >                wsoap:action="xs:anyURI"? >
> >
> >     <input messageLabel="xs:NCName"? wsoap:protocol="xs:anyURI"
> >            wsoap:mep="xs:anyURI"? wsoap:action="xs:anyURI"? >
> >     </input>*
> >     <output messageLabel="xs:NCName"? wsoap:protocol="xs:anyURI"
> >            wsoap:mep="xs:anyURI"? wsoap:action="xs:anyURI"? >
> >
> >     </output>*
> >     </operation>
> >   </binding>
> >
> > The endpoint has an additional optional asynch address attribute.  
> > This
> attribute specifies a location of the 2nd message if the 
> interface operation is bound to 2 protocol messages.
> >
> > <service name="xs:NCName" interface="xs:QName"
> >     <endpoint name="xs:NCName" binding="xs:QName" 
> location="xs:anyURI"
> asynchLocation="xs:anyURI"?>
> >     </endpoint>*
> >   </service>*
> >
> >
> > When a WSDL document is exchanged, the location of an 
> endpoint may not 
> > be
> known to the WSDL publisher.   Some examples of this scenario are
> asynchronous message exchanges with callbacks and 
> non-addressible software. WSDL defines a URI for specifying 
> these "unknown" locations
> >
> > http://www.w3.org/2004/wsdl/part3/unknown
> >
> > It is expected that messages that are sent to the unknown location 
> > will
> use some other mechanism, such as runtime soap headers, for 
> exchanging the location.
> >
> > Cheers,
> > Dave
> 
>

Received on Monday, 5 July 2004 18:06:44 UTC