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 11:26:28 UTC