W3C home > Mailing lists > Public > www-ws-desc@w3.org > June 2004

Revised Asynch Binding

From: David Orchard <dorchard@bea.com>
Date: Tue, 29 Jun 2004 11:47:26 -0700
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF08957E60@ussjex01.amer.bea.com>
To: <www-ws-desc@w3.org>

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 Tuesday, 29 June 2004 14:47:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:31 GMT