Re: Issue 59 proposal

I think it may be insufficient to identify the response binding using  
the transport/protocol URI, bindings are potentially much more  
complex than that. In my proposal[1] I used a QName to identify an  
actual binding instance in the WSDL and I think that offers more  
capability.

As a personal preference I'm also not too jazzed with attributes that  
contain lists - that's why I chose a child element instead.

Other than the above our proposals seem pretty much in-line, did I  
miss something radically different ?

Marc.

[1] http://www.w3.org/mid/D1503191-88CA-4537-A20A-1F891F43606D@Sun.COM

On Nov 4, 2005, at 10:22 AM, David Orchard wrote:

> I propose a wsaw:UsingAddressing element with a wsaw:Async and  
> wsaw:ResponseBinding attributes that uses an abstract protocol (aka  
> uber) MEP to show the relationship between wsdl request-response  
> and protocol level request-response without mentioning a specific  
> protocol.  There are 9 examples including protocol switch and  
> reverse bindings, so everybody should be happy.3.1 UsingAddressing  
> Extension Element
> WS-Addressing defines an empty global element,  
> wsaw:UsingAddressing, that may be used to indicate that an endpoint  
> conforms to the WS-Addressing specification. The wsdl:required  
> attribute MAY be used to indicate whether WS-Addressing Message  
> Addressing Properties are required in messages received from  
> service requesters.
>
> A wsaw:UsingAddressing element with a wsdl:required attribute whose  
> value is "true" indicates that messages exchanged with the endpoint  
> MUST contain WS-Addressing Message Addressing Properties. A  
> wsaw:UsingAddressing element with a wsdl:required attribute whose  
> value is "false" indicates that the endpoint will accept input  
> messages with or without WS-Addressing header blocks, and MAY  
> generate output messages containing WS-Addressing headers. If a  
> SOAP binding is used and WS-Addressing header blocks are not  
> present in an input message then WS-Addressing header blocks  
> encoded in the corresponding output message MUST NOT be required to  
> be understood using the SOAP mustUnderstand mechanism.
>
> The wsaw:UsingAddressing element SHOULD appear as a child of the  
> wsdl:binding element. Alternatively, the wsaw:UsingAddressing  
> element MAY instead be included as a child of the wsdl20:endpoint  
> (or wsdl11:port) when an endpoint intends to indicate compliance  
> with WS-Addressing for a specific endpoint only.
>
> The inclusion of the wsaw:UsingAddressing element indicates that  
> the applicable WS-Addressing specifications are supported within  
> the constraints of the WSDL binding being used. That is, uses of  
> the WS-Addressing specifications that may violate or are  
> inconsistent with the semantics of the endpoint's WSDL binding are  
> not supported unless explicitly stated by some other mechanism.
>
> Specifically, when included in a SOAP binding, the  
> wsaw:UsingAddressing marker identifies the use of Web Services  
> Addressing 1.0 bound to SOAP as defined by Web Services Addressing  
> 1.0 - SOAP Binding[WS-Addressing-SOAP].
>
> (Note to reader: Up to this point, this is exactly the same text  
> from the current editor’s draft.  It does need a titch of updating  
> as it isn't an empty global element.
>
> 3.1.1 wsaw:Async attribute
> WS-Addressing defines an attribute, wsaw:Async, that may be used in  
> conjunction with wsaw:UsingAddressing element.  This attribute MAY  
> be used only when wsaw:UsingAddressing element is present.
>
> The wsaw:Async attribute may have three distinct values, “full”,  
> “never” and “always”. If the wsaw:Async attribute is not present,  
> then a value of "full" is the default.
>
> ·        The “full” value indicates that either one or two protocol  
> message exchange pattern (proposed in [1] request-optional-response  
> MEP or in [2] as SOAP-request MEP) instances is used to transmit  
> the request and response.  When wsaw:Async attribute has this  
> value, then the response message MAY be the response part (aka  
> http://www.w3.org/2004/12/ws-addr/mep/ResponseMessage or http:// 
> www.w3.org/2003/05/soap/mep/InboundMessage) of a request-optional- 
> response or request-response MEP or the response message MAY be the  
> request part (aka http://www.w3.org/2004/12/ws-addr/mep/ 
> RequestMessage or http://www.w3.org/2003/05/soap/mep/ 
> OutboundMessage) of a separate request-optional response or request  
> MEP. When the value of the [reply endpoint] in the request message  
> contains the anonymous URI as the address, the response MUST be  
> sent as the response part of the request-optional-response MEP.   
> When the value of [reply endpoint] contains an address that is  
> different than the anonymous URI, the response MUST the request  
> part of a separate request-optional response MEP with a binding  
> using the destination address value specified by [reply endpoint].
>
> ·        The “never” value indicates that a single protocol MEP is  
> in use.  When wsaw:Async attribute has this value, [reply endpoint]/ 
> [fault endpoint] EPRs in the request MUST NOT contain an address  
> with a value different from the anonymous URI. If [reply endpoint]/ 
> [fault endpoint] EPRs do not contain the anonymous address value,  
> then a predefined InvalidAddressingHeader fault defined in Section  
> 5.4.1.7 of defined by Web Services Addressing 1.0 - SOAP Binding[WS- 
> Addressing-SOAP] MUST be generated  (See Section 3 B for the  
> definition of this new fault).
>
> ·        The “always” value of the wsaw:Async attribute indicates  
> that a separate request-optional-response MEP for sending response  
> messages. When wsaw:Async attribute has this value, [reply  
> endpoint]/[fault endpoint] EPR in the request MUST NOT contain an  
> address with a value that is the same as the anonymous URI.
>
> 3.1.2 wsaw:ResponseBinding attribute
> WS-Addressing defines an attribute, wsaw:ResponseBinding, that may  
> be used in conjunction with wsaw:UsingAddressing element.  This  
> attribute MAY be used only when wsaw:UsingAddressing element is  
> present.
>
> The wsaw:ResponseBinding attribute is a list of URIs of bindings  
> that may be specified for any asynchronous response.  If the  
> wsaw:ResponseBinding is not present, and the wsaw:Async attribute  
> is not "never", then the default value is the value of the binding  
> within which the wsaw:UsingAddressing element appears.  It is an  
> error if the ResponseBinding contains a value and if the wsaw:Async  
> attribute is "never".
>
> A sender of a request message SHOULD use the ResponseBinding value  
> when creating [reply endpoint] values.
>
> 3.1.3 SOAP HTTP Binding extensions
> The wsaw:UsingAddressing inside soap:binding elements extends the  
> SOAP/HTTP Bindings in a few specific ways.
>
> Case: WSDL in-out (or request-response) and SOAP 1.1 and non- 
> anonymous [reply endpoint] is specified.
>
> The first HTTP connection MUST have a status code of 202 and the  
> response message MUST contain an empty SOAP body.  The actual  
> response MUST be sent using a separate HTTP connection using the  
> address value of the response message specified by [reply endpoint].
>
> Case: WSDL in-out (or request-response) and SOAP 1.2 and non- 
> anonymous [reply endpoint] is specified.
>
> Each of the two request-optional-response MEPs be sent using a  
> separate instance of the @@TBD SOAP 1.2 one-way binding@@.
>
> 3.1.4 Examples
>
>
> These examples are an update to the async scenarios listed in [3].   
> As described therein, the identifier for the mythical one-way  
> protocol is "http://www.openuri.org/mythical-oneway/soap/"
>
>
>
> Example 3-1. Indicating Sync or Async in WS-Addressing using  
> wsaw:UsingAddressing in WSDL 2.0
>
> <binding name="ServiceBinding"
>
>     interface="s0:ServiceInterface"
>
>     type="http://www.w3.org/2005/08/wsdl/soap12"
>
>     wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP">
>
>   <wsaw:UsingAddressing wsdl:required="true" />
>
>   <operation ref="s0:EchoString"
>
>       wsoap:mep="http://www.w3.org/2003/05/soap/mep/request- 
> response" />
>
> </binding>
>
> Example 3-2. Indicating Sync or Async in WS-Addressing using  
> wsaw:UsingAddressing in WSDL 1.1
>
> <binding name="ServiceBinding" type="s0:ServicePortType">
>
>   <soap:binding style="document" transport="http:// 
> schemas.xmlsoap.org/soap/http" />
>
>   <wsaw:UsingAddressing wsdl:required="true" />
>
>   <operation name="EchoString">
>
>     <soap:operation soapaction="EchoString" />
>
>     <input>
>
>       <soap:body use="literal" />
>
>     </input>
>
>     <output>
>
>       <soap:body use="literal" />
>
>     </output>
>
>   </operation>
>
> </binding>
>
> Example 3-3. Indicating Sync in WS-Addressing using  
> wsaw:UsingAddressing in WSDL 2.0
>
> <binding name="ServiceBinding"
>
>     interface="s0:ServiceInterface"
>
>     type="http://www.w3.org/2005/08/wsdl/soap12"
>
>     wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP">
>
>   <wsaw:UsingAddressing wsaw:Async="never" wsdl:required="true" />
>
>   <operation ref="s0:EchoString"
>
>       wsoap:mep="http://www.w3.org/2003/05/soap/mep/request- 
> response" />
>
> </binding>
>
>
>
> Example 3-4. Indicating Async in WS-Addressing using  
> wsaw:UsingAddressing in WSDL 2.0
>
> <binding name="ServiceBinding"
>
>     interface="s0:ServiceInterface"
>
>     type="http://www.w3.org/2005/08/wsdl/soap12"
>
>     wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP">
>
>   <wsaw:UsingAddressing wsaw:Async="always" wsdl:required="true" />
>
>   <operation ref="s0:EchoString"
>
>       wsoap:mep="http://www.w3.org/2003/05/soap/mep/request- 
> response" />
>
> </binding>
>
>
>
> Example 3-5. Indicating Async with Mythical Oneway Binding in WS- 
> Addressing using wsaw:UsingAddressing in WSDL 2.0
>
> <binding name="ServiceBinding"
>
>     interface="s0:ServiceInterface"
>
>     type="http://www.w3.org/2005/08/wsdl/soap12"
>
>     wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP">
>
>   <wsaw:UsingAddressing wsaw:Async="always" wsdl:required="true"
>
>       ResponseBinding="http://www.openuri.org/mythical-oneway/ 
> soap/" />
>
>   <operation ref="s0:EchoString"
>
>       wsoap:mep="http://www.w3.org/2003/05/soap/mep/request- 
> response" />
>
> </binding>
>
>
>
>
>
> Example 3-6. Indicating Async with HTTP or Mythical Binding in WS- 
> Addressing using wsaw:UsingAddressing in WSDL 2.0
>
> <binding name="ServiceBinding"
>
>     interface="s0:ServiceInterface"
>
>     type="http://www.w3.org/2005/08/wsdl/soap12"
>
>     wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP">
>
>   <wsaw:UsingAddressing wsaw:Async="always" wsdl:required="true"
>
>        ResponseBinding="http://www.w3.org/2003/05/soap/bindings/ 
> HTTP http://www.openuri.org/mythical-oneway/soap/" />
>
>   <operation ref="s0:EchoString"
>
>       wsoap:mep="http://www.w3.org/2003/05/soap/mep/request- 
> response" />
>
> </binding>
>
>
>
> Example 3-7. Indicating Sync or Async with HTTP or Mythical Binding  
> in WS-Addressing using wsaw:UsingAddressing in WSDL 2.0
>
> <binding name="ServiceBinding"
>
>     interface="s0:ServiceInterface"
>
>     type="http://www.w3.org/2005/08/wsdl/soap12"
>
>     wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP">
>
>   <wsaw:UsingAddressing wsaw:Async="full" wsdl:required="true"
>
>        ResponseBinding="http://www.w3.org/2003/05/soap/bindings/ 
> HTTP http://www.openuri.org/mythical-oneway/soap/" />
>
>   <operation ref="s0:EchoString"
>
>       wsoap:mep="http://www.w3.org/2003/05/soap/mep/request- 
> response" />
>
> </binding>
>
>
>
> Example 3-8. Indicating Async in Interface in WS-Addressing using  
> wsaw:UsingAddressing in WSDL 2.0
>
> <interface name="ServiceInterface">
>
>   <wsaw:UsingAddressing wsaw:Async="always" wsdl:required="true" />
>
>   <operation name="EchoString" pattern="http://www.w3.org/@@@@/@@/ 
> wsdl/in-out">
>
>     <input element="s0:EchoStringMessageIn"/>
>
>     <output element="s0:EchoStringMessageOut"/>
>
>   </operation>
>
> </interface>
>
>
>
> The above is only a possibility.  It would require updating the  
> usingAddressing to say what it means if a child of interface, and  
> it would require changes to disallowResponseBindings.   
> Alternatively, the async attribute could be made an element for  
> inclusion as a child of interface.
>
>
>
> Example 3-9. Indicating PAOS Async in WS-Addressing using  
> wsaw:UsingAddressing in WSDL 2.0
>
> <binding name="ServiceBinding"
>
>     interface="s0:ServiceInterface"
>
>     type="http://www.w3.org/2005/08/wsdl/soap12"
>
>     wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP">
>
>   <wsaw:UsingAddressing wsaw:Async="always" wsdl:required="true" />
>
>   <paos:reverseBinding wsdl:required="true"/>
>
>   <operation ref="s0:EchoString"
>
>       wsoap:mep="http://www.w3.org/2003/05/soap/mep/request- 
> response" />
>
> </binding>
>
>
>
> The paos:reverseBinding would have to say something akin to :
>
>
>
> "In the first protocol MEP, put the paos:Get value in the Action  
> MAP and generate a full paos Get request including other MAPs.  The  
> first protocol MEP response must contain the binding operation's  
> request.  The response may have a [reply endpoint].  The second  
> protocol MEP request must contain the binding operation's response  
> and be sent to any [reply endpoint]. "
>
>
>
> Cheers,
>
> Dave
>
>
>
> [1] http://lists.w3.org/Archives/Public/public-ws-addressing/ 
> 2005Jul/att-0010/ws-addr-soapadjuncts-simplemeps_httpbinding.html
>
> [2] http://lists.w3.org/Archives/Public/public-ws-addressing/ 
> 2004Dec/att-0159/WS-Addressing-SOAP-Adjuncts.html
>
> [3] http://www.pacificspirit.com/Authoring/async/async-scenarios.html
>
>
>
>

---
Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.