Re: Revised Asynch Binding

s/^over SOAP\./over HTTP./

Duh.

Sanjiva.

----- Original Message ----- 
From: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>
To: <paul.downey@bt.com>; <www-ws-desc@w3.org>
Sent: Monday, July 05, 2004 9:25 PM
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 12:40:34 UTC