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 Sunday, 4 July 2004 23:27:17 UTC