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

Asynchronous Binding action item.

From: David Orchard <dorchard@bea.com>
Date: Tue, 11 May 2004 18:23:43 -0700
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF07651B6C@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:
<binding>
<operation ref="xs:QName" >
      <documentation />?

      <wsoap:operation mep="xs:anyURI"?
                       webMethod="xs:string"? 
                       action="xs:anyURI"? 
                       mediaType="xs:string"?/>?

      <input messageLabel="xs:NCName"? >
        <documentation />?
        <wsoap:header element="xs:QName" 
                      mustUnderstand="xs:boolean"?
                      role="xs:anyURI"?
                      relay="xs:boolean"? 
                      reinsert="xs:boolean"? />*
      </input>*

      <output messageLabel="xs:NCName"? >
        <documentation />?
        <wsoap:header ... />*
      </output>*
</operation>

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 split into 2 with the mep retained as an operation extension and the rest of the attributes be moved inside input and optionally output.  

<operation ref="xs:QName" >
      <documentation />?

      <wsoap:mep="xs:anyURI"/>?
      <input messageLabel="xs:NCName"? >
         <documentation />?
         <wsoap:operation webMethod="xs:string"? 
                          action="xs:anyURI"? 
                          mediaType="xs:string"?/>?
         <wsoap:header element="xs:QName" 
                      mustUnderstand="xs:boolean"?
                      role="xs:anyURI"?
                      relay="xs:boolean"? 
                      reinsert="xs:boolean"? />*
      </input>*

      <output messageLabel="xs:NCName"? >
        <documentation />?
        <wsoap:operation webMethod="xs:string"? 
                          action="xs:anyURI"? 
                          mediaType="xs:string"?/>?
        <wsoap:header ... />*
      </output>*
</operation>

The endpoint is split into two for the service.  An endpoint MAY have an asynch address element.  In this case, the referenced binding must have an operation with output with an operation extension element (ie operation/output/wsoap:operation).  The asynchaddress may be an an "unknown" address which indicates that the address is dynamic.

<endpoint name="xs:NCName" binding="xs:QName" >
      <documentation />?
      <wsoap:address location="xs:anyURI" />
      <wsoap:asynchaddress location="xs:anyURI" />
<endpoint>

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, 11 May 2004 21:23:55 GMT

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