- From: David Hull <dmh@tibco.com>
- Date: Fri, 04 Nov 2005 19:25:24 -0500
- To: Marc Hadley <Marc.Hadley@Sun.COM>
- Cc: David Orchard <dorchard@bea.com>, public-ws-addressing@w3.org
- Message-id: <436BFBF4.4030805@tibco.com>
It might do to have both available, as an attribute of the async
element. E.g.
<async protocolBinding="{anyUri}"/>
for the simple case or
<async wsdlBinding="{qname}"/>
for the fully general case. FWIW, I tend to agree with Marc about
attributes with list values.
Marc Hadley wrote:
> 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.
>
>
Received on Saturday, 5 November 2005 00:25:50 UTC