Re: Issue 59 proposal

I'm with Dave on protocol-independent MEPs, though as I've tried to make
clear, I have a bett^H^H^H^Hdifferent approach to them.  As to empty
elements, if I were 100% convinced those elements would always be empty
going forward, I'd be much more comfortable with the list-valued
attribute approach.  As it is, it seems quite plausible that an <async
*binding="..."> element could usefully have something inside it.

FWIW, I'd be fine with a list-valued attribute /defined/ as a shorthand
for the appropriate sequence of elements, but would strongly prefer the
fully-extensible syntax be defined from the get-go.  This is a major
reason why I prefer the whole "list of possible response bindings"
approach, even if to start with we only define what this means for one
particular binding.  The "list of response bindings" syntax can exactly
describe everything the plain always/never/full markup can, but not vice
versa.

Finally, I'll reiterate that as far as I can tell, the issue of how to
describe the semantics of async is largely independent of the issue of
how to mark it up.  I do believe that the "list of response bindings"
markup maps more naturally to the various proposed semantics, and I
consider that another mark in its favor.

David Orchard wrote:

>Hi Marc,
>
>Perhaps the biggest difference is the one I've been talking about for a
>while, which is specifying the relationship between wsdl meps and the
>bindings.  In my proposal, I say specifically how a wsdl req-resp maps
>to a protocol independent mep.  That way, I can write the
>wsaw:UsingAddressing and async extension in a protocol independent
>manner.  While 95% of the SOAP req-resp mep doesn't help us -
>particularly the state machine, the soap mandatoriness and the mandatory
>response - at least having a protocol independent mep is a good thing.
>
>I believe that such a layering is critical and is the thing I'm prepared
>to be strident about.  
>
>QNames would work instead of URIs, though I guess I'm a URI bigot :-)
>It's not a showstopper, as long as it's either qname or URI (qname AND
>URI is the worst of all worlds).
>
>I'm not particularly jazzed about lists of elements with qnames in them,
>seems like a convoluted design to me.  Might be easier to have the
>qnames as element names instead of element values.
>
>But, I tell ya what, if you could live with an abstract MEP, I could
>live with qnames and elements :-)
>
>Dave
>
>
>
>  
>
>>-----Original Message-----
>>From: Marc.Hadley@Sun.COM [mailto:Marc.Hadley@Sun.COM]
>>Sent: Friday, November 04, 2005 2:45 PM
>>To: David Orchard
>>Cc: public-ws-addressing@w3.org
>>Subject: 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.
>>
>>    
>>
>
>
>
>  
>