WS-Addressing defines three global
elements, wsaw:UsingAddressing,
wsaw:UsingAddressingWithAnonymous, wsaw:UsingAddressingWithNonAnonymous that may be used to
indicate that an endpoint conforms to the WS-Addressing specification. Three
different elements specify the granularity of support for using anonymous URIs as addresses in EPRs.
The wsdl:required attribute MAY be used to indicate whether
WS-Addressing Message Addressing Properties are required in messages received
from service requesters. Table
3-1 outlines the requirements on messages sent from an endpoint based on
the contents of any preceding input message and how the use of addressing is
indicated in the WSDL.
|
MAPs in Input message |
An Addressing Extension Element is Present |
An Addressing Extension Element is Not
Present |
|
|
wsdl:required="true" |
wsdl:required="false" |
||
|
Yes, using
SOAP headers with a soap:mustUnderstand value of
"true" |
REQUIRED |
REQUIRED |
REQUIRED or
fault |
|
Yes, using
another protocol or using SOAP headers with a soap:mustUnderstand
value of "false" |
REQUIRED |
REQUIRED |
OPTIONAL |
|
No |
Fault |
OPTIONAL. If
using SOAP, MAP headers MUST NOT have a soap:mustUnderstand
attribute with a value of "true" |
OPTIONAL. If
using SOAP, MAP headers MUST NOT have a soap:mustUnderstand
attribute with a value of "true" |
If WS-A is engaged by using any of these elements, use of the message addressing
properties MUST be fully compliant with this specification; in particular,
senders MUST use all message addressing properties mandated by the Web Services
Addressing 1.0 - Core[WS-Addressing-Core],
applicable WS-Addressing protocol bindings (e.g. Web Services Addressing 1.0 -
SOAP Binding[WS-Addressing-SOAP]),
and this specification, and MUST follow all applicable WS-Addressing normative
requirements.
Any one of these elements
SHOULD appear as a child of the wsdl:binding
element. Alternatively, one of these elements 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, or as a child of an
operation element within a binding element in WSDL 1.1 or WSDL 2.0 when a
specific message exchange intends to indicate with compliance with WS-Addressing.
The inclusion of one of the
elements indicates that the applicable WS-Addressing specifications are
supported and may extend 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.
When included
in a SOAP binding, the extension 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]. The
inclusion of WS-Addressing extension element indicates one of the three
different levels of support for handling anonymous addresses in EPRs that is determined by the QName
of the extension element as follows:
·
wsaw:UsingAddressing: This element indicates that [reply
endpoint] or [fault endpoint] EPR in a request message MAY contain an anonymous
URI as an address.
·
wsaw:UsingAddressingWithAnonymous This element indicates that [reply
endpoint] and [fault endpoint] EPRs in a request
message MUST always use anonymous URI as an address.
If
[reply endpoint] or [fault endpoint] EPR does not contain the anonymous URI as
an address value, then a predefined InvalidAddressingHeader
fault defined in Section 5.4.x.x of Web Services Addressing 1.0 - SOAP Binding[WS-Addressing-SOAP] MUST be
generated (I already raised a CR issue
about this)
·
wsaw:UsingAddressingWithNonAnonymous: This element indicates that [reply
endpoint] and [fault endpoint] EPRs in a request
message MUST NOT use anonymous URI as an address.
If
[reply endpoint] or [fault endpoint] EPR contains the anonymous URI as an address
value, then a predefined InvalidAddressingHeader
fault defined in Section 5.4.x.x of Web Services Addressing 1.0 - SOAP Binding[WS-Addressing-SOAP] MUST be
generated.
Note to reader: This point is
open for discussion.
{Only one of the WS-Addressing
extension elements may appear in a binding, operation within a binding and or endpoint
element. A WSDL document MUST NOT contain different WS-Addressing elements in multiple
attachment points, such as a binding and an endpoint in order to guarantee that
only one definition is in scope for a message exchange. However, specifying
different WS-Addressing elements for each operation in a WSDL binding operation
component is allowed.
If an operation is not covered
by a WS-Addressing element, this means the semantics of the binding is not
extended by WS-Addressing requirements.
}
3.1.2 SOAP 1.1/HTTP Extension Semantics by using one of the
WS-Addressing specified extension elements:
The presence of one of the
WS-Addressing specified elements in the binding or endpoint (port) or binding
operation components of a description extends the semantics of the SOAP
1.1/HTTP binding. In the case of the WSDL SOAP/HTTP synchronous binding for
request-response operations, the presence of such an element may change the
requirement that the response message be sent over the same HTTP channel over
which the request was received depending on the element that is present. In
this case, the wsa:replyTo
header in the request MAY contain an address with a value different from the
anonymous URI depending on the following semantics:
·
The
wsaw:UsingAddressing element
indicates that an extension to SOAP/HTTP binding is used that allows using a
separate connection when needed. The extension allows a SOAP1.1/HTTP binding to
use a separate connection for sending response messages, instead of using the
same HTTP connection. This extension allows SOAP 1.1/HTTP to be used
asynchronously as follows.
The
response message MAY be sent over the same HTTP channel over which the request
was received or by opening a separate connection. When the value of the [reply
endpoint] in the request message contains the anonymous URI as the address, the
response MUST be sent over the same HTTP channel. However, when the value of [reply endpoint]
contains an address that is different than the anonymous URI, this extension
for the SOAP/HTTP binding requires that
·
The
receipt of the request message MUST be acknowledged with a status message (202)
by the receiver using the HTTP connection that generated the request. The
receipt message MUST contain an empty SOAP envelope.
·
The
actual response MUST be sent using a separate connection using the address
value of the response message specified by [reply endpoint].
·
The
wsaw:UsingAddressingWithAnonymous
element indicates that the SOAP1.1/HTTP extension that allows multiple
connections is not in use. In essence, its presence is equivalent to not
extending the semantics of the current SOAP1.1/HTTP bindings. In this case, the
presence of the element does not change the requirement that the response
message be sent over the same HTTP channel over which the request was received.
·
The wsaw:UsingAddressingWithNonAnonymous
element indicates that SOAP1.1/HTTP binding must always use a separate
connection for sending response messages, instead of using the same HTTP
connection. The extension requires SOAP 1.1/HTTP to be used always
asynchronously as described above.
Note: We may consider including a paragraph here as a note to
indicate that SOAP processing rules dictate how responses/errors are generated
and sent to appropriate destinations depending on when the extensions are
processed and engaged.
3.1.3 Examples:
Example 3-1. Indicating use of WS-Addressing using wsaw:UsingAddressing in WSDL 2.0
<binding name="reservationSOAPBinding"
interface="tns:reservationInterface"
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="tns:opCheckAvailability"
wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response"
/>
<fault ref="tns:invalidDataFault" wsoap:code="soap:Sender"
/>
</binding>
Example 3-2. Indicating use of WS-Addressing using wsaw:UsingAddressing in WSDL 1.1
<binding name="StockQuoteSoapBinding"
type="tns:StockQuotePortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http" />
<wsaw:UsingAddressing wsdl:required="true"
/>
<operation name="GetLastTradePrice">
<soap:operation soapaction="http://example.com/GetLastTradePrice"
/>
<input>
<soap:body use="literal" />
</input>
<output>
<soap:body use="literal"
/>
</output>
</operation>
</binding>
Example 3-3. Indicating use of WS-Addressing in a binding that requires synchronous
SOAP 1.1/HTTP binding in WSDL 1.1
<binding name="StockQuoteSoapBinding"
type="tns:StockQuotePortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http" />
<wsaw:UsingAddressingWithAnonymous wsdl:required="true"
/>
<operation name="GetLastTradePrice">
<soap:operation soapaction="http://example.com/GetLastTradePrice"
/>
<input>
<soap:body use="literal" />
</input>
<output>
<soap:body use="literal"
/>
</output>
</operation>
</binding>
Example 3-4.
Indicating use of WS-Addressing in a specific operation that only define
synchronous responses
<binding name="StockQuoteSoapBinding"
type="tns:StockQuotePortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http" />
<operation name="GetLastTradePrice">
<soap:operation soapaction="http://example.com/GetLastTradePrice"
/>
<input>
<soap:body use="literal" />
</input>
<output>
<soap:body use="literal"
/>
</output>
<wsaw:UsingAddressingWithAnonymous wsdl:required=”true”/>
</operation>
<operation name=”OtherOp”>…</operation>…
</binding>