RE: Revised Asynch Binding

Sanjiva,

I do like the idea of making things simple, but this makes it too simple.  Clever use of protocol too.

I already argued the point about SOAP HTTP binding of interface operations.  How is my or even Paul's proposed use of asynch violating the XMLP defined SOAP HTTP binding?  That binding roughly says that the HTTP request and response contain a SOAP body.  It says nothing about how a WSDL operation is sent on the wire.  In particular, it does NOT say that a wsdl operation response must come over the HTTP response.  I find it ironic that people keep talking about interfaces being abstract, but then they almost invariably think that an interface operation binds directly to a protocol operation.   My proposal takes 1 interface operation and maps it to 2 HTTP protocol operations.

Your proposal removes the ability for the WSDL to specify the soap information for the callback, such as soap action, in the binding of the interface operation.  In your proposal, I have to have 2 interface operations to do the callback, whereas mine allows for a single interface operation.  

The working group needs to decide whether an interface operation is abstract from the protocol operation or not, and whether 2 interface operations versus 1 are required to do a callback.  I argue that for the 80/20 case, a single interface operation is the right way to go.

I do like and support the idea that any asynch binding must specify through some mechanism how to succesfully perform the callback.

Cheers,
Dave 

> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
> Behalf Of Sanjiva Weerawarana
> Sent: Monday, July 05, 2004 8:26 AM
> To: paul.downey@bt.com; www-ws-desc@w3.org
> Subject: Re: Revised Asynch Binding
> 
> 
> 
> Hi Paul,
> 
> No, that's not enough because using WS-Addressing's ReplyTo (for
> example) with a non-anonymous URI will mean we are not compliant
> with the SOAP HTTP binding (the one the XMLP guys defined, not us).
> Thus, you need to use a different URI for the protocol binding as
> this is indeed a different way to do SOAP request-response MEPs
> over SOAP.
> 
> Sanjiva.
> 
> ----- Original Message ----- 
> From: <paul.downey@bt.com>
> To: <sanjiva@watson.ibm.com>; <www-ws-desc@w3.org>
> Sent: Monday, July 05, 2004 8:25 PM
> Subject: RE: Revised Asynch Binding
> 
> 
> >
> > Sanjiva
> >
> > i like the simplicity of this approach, but do wonder why it has
> > to be flagged via the protocol attribute; couldn't the same effect
> > be achieved by a wsdl:async="true" flag on binding/operation?
> >
> > A generic attribute would make this mechanism useable for other
> > bindings without doubling the number of protocol URIs which need to
> > be published.
> >
> > Paul
> >
> >
> > -----Original Message-----
> > From: www-ws-desc-request@w3.org 
> [mailto:www-ws-desc-request@w3.org]On
> > Behalf Of Sanjiva Weerawarana
> > Sent: 04 July 2004 17:16
> > 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 15:33:41 UTC