ID | Chapter | Section | Description | Required | Dependency | Implementation Specific | Defined by | Status | Testable |
WSAMD:SPEC:2000 | 2 | 1 |
An EPR's metadata section can contain a reference to WSDL metadata.
| true |
| false | technology | active | true |
WSAMD:SPEC:2000.1 | 2 | 1 |
An EPR's metadata section can include embedded WSDL metadata.
| true |
| false | technology | active | true |
WSAMD:SPEC:2000.2 | 2 | 1 |
An EPR's metadata section can contain both a reference to WSDL metadata and it can include embedded WSDL metadata.
| true |
| false | technology | active | true |
WSAMD:SPEC:2001 | 2 | 1 |
The WSDL binding of Web Services Addressing introduces the following element and attribute information items for referencing WSDL metadata from an EPR's metadata section. These element information items are used in an EPR's metadata section.
| true |
| false | technology | active | true |
WSAMD:SPEC:2001.1 | 2 | 1 |
wsam:InterfaceName (0..1)
A QName identifying a description of the sequences of messages that a service sends and/or receives. This corresponds to, for backwards compatibility, a WSDL 1.1 port type.
| true |
| false | technology | active | true |
WSAMD:SPEC:2001.2 | 2 | 1 |
wsam:ServiceName (0..1)
A QName that identifies the set of endpoints at which a particular Web service is deployed. The set of endpoints is represented by, for backwards compatibility, a WSDL 1.1 service.
| true |
| false | technology | active | true |
WSAMD:SPEC:2001.3 | 2 | 1 |
wsam:ServiceName/@EndpointName (0..1)
An NCName that identifies one endpoint amongst the set identified by the service name above. An endpoint is represented by, for backwards compatibility, a port in WSDL 1.1.
| true |
| false | technology | active | true |
WSAMD:SPEC:2002 | 2 | 2 |
For backwards compatibility, 1.1 definitions can be embedded in the metadata section of an EPR to provide a consuming application with WSDL information that applies to the referenced endpoint.
| true |
| false | technology | active | true |
WSAMD:SPEC:2002.1 | 2 | 2 |
To do so, the creator of an EPR MAY include a WSDL 1.1 definitions element in the metadata property of the EPR. The semantics of the embedded WSDL is as defined by the WSDL 1.1 specification.
| false |
| false | technology | active | false |
WSAMD:SPEC:2002.2 | 2 | 2 |
In particular, embedding a WSDL service component description MAY be used by EPR issuers to indicate the presence of alternative addresses and protocol bindings to access the referenced endpoint. In the case of WSDL 1.1, additional ports can be conveyed by the WSDL 1.1 service definition.
| false |
| false | technology | active | false |
WSAMD:SPEC:2002.3 | 2 | 2 |
In the case of WSDL 1.1, additional ports can be conveyed by the WSDL 1.1 service definition.
| true |
| false | technology | active | true |
WSAMD:SPEC:2002.4 | 2 | 2 |
If the ServiceName element appears in the EPRs [metadata] and an embedded WSDL service component is also provided inside a descriptions or definitions component, then the ServiceName SHOULD match the name of (one or more of) the WSDL service(s) included therein; the endpoint (port) name SHOULD match as well if present.
| false |
| false | technology | active | false |
WSAMD:SPEC:3000 | 3 | 1 |
This specification supports a mechanism for indicating, in a WSDL description, that the endpoint conforms to the WS-Addressing specification. That mechanism uses WS-Policy Framework [WS Policy 1.5].
The mechanism for indicating that a binding or endpoint conforms to the WS-Addressing specification is through the use of the Web Services Policy - Framework [WS Policy 1.5] and Web Services Policy - Attachment [WS Policy 1.5 - Attachment] specifications. This specification defines three policy assertions.
The wsam:Addressing policy assertion applies to the endpoint policy subject.
For WSDL 1.1, these assertions may be attached to wsdl11:port or wsdl11:binding.
| true |
| false | technology | active | true |
WSAMD:SPEC:3000.1 | 3 | 1.1 |
The wsam:Addressing policy assertion is a nested policy container assertion. The meaning of this assertion, when present in a policy alternative, is that WS-Addressing is required to communicate with the subject. The wsam:Addressing assertion indicates that there are no restrictions on the use of WS-Addressing unless otherwise qualified by assertions in its nested policy expression. In order to indicate that the subject supports WS-Addressing but does not require its use, an additional policy alternative should be provided which does not contain this assertion; the compact authoring style for an optional policy assertion provided by WS-Policy V1.5 [WS Policy 1.5] may be used. The wsp:Optional attribute, as a syntactic shortcut, can be used with the wsam:Addressing assertion. This indicates two policy alternatives, one which contains the policy assertion, and another which does not.
The inclusion of this assertion implies support for the Web Services Addressing 1.0 - Core [WS-Addressing Core] and Web Services Addressing 1.0 - SOAP Binding [WS-Addressing SOAP Binding].
| true |
| false | technology | active | true |
WSAMD:SPEC:3001.2 | 3 | 1.2 |
The wsam:AnonymousResponses element MAY be used as a policy assertion nested within the wsam:Addressing assertion in accordance with the rules laid down by policy assertion nesting ([WS Policy 1.5], section 4.3.2).
The appearance of this element within the wsam:Addressing policy assertion indicates that the endpoint requires request messages to use response endpoint EPRs that contain the anonymous URI ("http://www.w3.org/2005/08/addressing/anonymous") as the value of [address]. In other words, the endpoint requires the use of anonymous responses.
The None URI ("http://www.w3.org/2005/08/addressing/none") may appear as the value of [address] in place of the anonymous URI; this value MUST be accepted.
| true |
| false | technology | active | true |
WSAMD:SPEC:3001.3 | 3 | 1.3 |
The wsam:NonAnonymousResponses element MAY be used as a policy assertion nested within the Addressing assertion in accordance with the rules laid down by policy assertion nesting ([WS Policy 1.5], section 4.3.2). The wsam:NonAnonymousResponses policy assertion MUST NOT be used in the same policy alternative as the wsam:AnonymousResponses policy assertion.
The appearance of this element within the wsam:Addressing assertion indicates that the endpoint expresses requires request messages to use response endpoint EPRs that contain something other than the anonymous URI as the value of [address]. In other words, the endpoint requires the use of non-anonymous responses. This assertion is deliberately vague; its presence indicates that some non-anonymous addresses will be accepted but doesn't constrain what such an address might look like. A receiver can still reject a request that contains an address that it doesn't understand or that requires a binding it doesn't support.
The None URI ("http://www.w3.org/2005/08/addressing/none") may appear as the value of [address] in place of a non-anonymous address; this value MUST be accepted.
| true |
| false | technology | active | true |
WSAMD:SPEC:3001.4 | 3 | 1.4 |
Example 3-1. Subject supports WS-Addressing
<wsp:Policy>
<wsam:Addressing wsp:Optional="true">
<wsp:Policy/>
</wsam:Addressing>
</wsp:Policy>
| true |
| false | technology | active | true |
WSAMD:SPEC:3001.5 | 3 | 1.4 |
Example 3-2. Subject requires WS-Addressing
<wsp:Policy>
<wsam:Addressing>
<wsp:Policy/>
</wsam:Addressing>
</wsp:Policy>
| true |
| false | technology | active | true |
WSAMD:SPEC:3001.6 | 3 | 1.4 |
Example 3-3. Subject requires WS-Addressing and requires the use of non-anonymous response EPRs
<wsp:Policy>
<wsam:Addressing>
<wsp:Policy>
<wsam:NonAnonymousResponses/>
</wsp:Policy>
</wsam:Addressing>
</wsp:Policy>
| true |
| false | technology | active | true |
WSAMD:SPEC:3001.7 | 3 | 1.5 |
Example 3-4. Subject supports WS-Addressing
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All/>
<wsp:All>
<wsam:Addressing>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All/>
</wsp:ExactlyOne>
</wsp:Policy>
</wsam:Addressing>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
| true |
| false | technology | active | true |
WSAMD:SPEC:3001.8 | 3 | 1.5 |
Example 3-5. Subject requires WS-Addressing
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<wsam:Addressing>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All/>
</wsp:ExactlyOne>
</wsp:Policy>
</wsam:Addressing>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
| true |
| false | technology | active | true |
WSAMD:SPEC:3001.9 | 3 | 1.5 |
Example 3-6. Subject requires WS-Addressing and requires the use of non-anonymous response EPRs
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<wsam:Addressing>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<wsam:NonAnonymousResponses/>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
</wsam:Addressing>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
| true |
| false | technology | active | true |
WSAMD:SPEC:3001.10 | 3 | 1.6 |
When a client is looking for an endpoint with compatible policy, one
common method used is to take the policy intersection between the policy
which the client is looking for, and the policy asserted in the WSDL
document; a non-empty intersection is sought. The policy used by the
client must be written carefully to avoid unexpected results. This is
most obvious when the client is not looking for explicit support of a
particular kind of response; failing to take care could mean missing a
compatible policy.
| true |
| false | technology | active | true |
WSAMD:SPEC:3001.11 | 3 | 1.6 |
Example 3-7. Client looking for an endpoint which supports Addressing, and which supports anonymous responses
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<wsam:Addressing>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<AnonymousResponses Optional=?true?/>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
</wsam:Addressing>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
| true |
| false | technology | active | true |
WSAMD:SPEC:3001.12 | 3 | 1.6 |
Example 3-8. Client looking for an endpoint which supports Addressing, and does not require support for responses (will intersect with anything)
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<wsam:Addressing> <-- supports all response types -->
<wsp:Policy>
</wsp:Policy>
</wsam:Addressing>
</wsp:All>
<wsp:All>
<wsam:Addressing> <-- requires Anonymous responses -->
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<AnonymousResponses />
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
</wsam:Addressing>
</wsp:All>
<wsp:All>
<wsam:Addressing> <- requires nonAnonymous responses -->
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<NonAnonymousResponses />
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
</wsam:Addressing>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
| true |
| false | technology | active | true |
WSAMD:SPEC:4000 | 4 | 1 |
A wsdl11:port element MAY be extended using a child wsa:EndpointReference element.
| false |
| false | technology | active | true |
WSAMD:SPEC:4000.1 | 4 | 1 |
When extended this way, the [address] property of the child EPR MUST match the address value provided by the relevant port extension (WSDL 1.1).
| true |
| false | technology | active | true |
WSAMD:SPEC:4001 | 4 | 2 |
The value of the [destination] message addressing property for a message sent to an endpoint typically matches the address value (if any) provided by the relevant port extension (WSDL 1.1).
| true |
| false | technology | active | true |
WSAMD:SPEC:4001.1 | 4 | 2 |
For a SOAP 1.1 port described using WSDL 1.1, the value is provided by the location attribute of the soap11:address extension element.
| true |
| false | technology | active | true |
WSAMD:SPEC:4001.2 | 4 | 2 |
For an endpoint or port extended with an EPR, the value is provided by the [address] property of the EPR.
| true |
| false | technology | active | true |
WSAMD:SPEC:4001.3 | 4 | 2 |
Additional runtime information could override the value of the [destination] message addressing property for messages sent to an endpoint.
| true |
| false | technology | active | true |
WSAMD:SPEC:4002 | 4 | 3 |
When a wsa:EndpointReference element is present in a wsdl11:port element, the value of the [reference parameters] message addressing property for a message sent to an endpoint MUST include the contents of the wsa:ReferenceParameters element, if one exists within that EPR.
| true |
| false | technology | active | true |
WSAMD:SPEC:4003 | 4 | 4.1 |
WS-Addressing defines a global attribute, wsam:Action, that can be used to explicitly define the value of the [action] property for messages in a WSDL description.
| true |
| false | technology | active | true |
WSAMD:SPEC:4003.1 | 4 | 4.1 |
The type of the attribute is xs:anyURI and it is used as an extension on the WSDL input element.
| true |
| false | technology | active | true |
WSAMD:SPEC:4003.2 | 4 | 4.1 |
The type of the attribute is xs:anyURI and it is used as an extension on the WSDL output element.
| true |
| false | technology | active | true |
WSAMD:SPEC:4003.3 | 4 | 4.1 |
The type of the attribute is xs:anyURI and it is used as an extension on the WSDL fault element.
| true |
| false | technology | active | true |
WSAMD:SPEC:4003.4 | 4 | 4.1 |
In the absence of a wsam:Action attribute on a WSDL input element where a SOAPAction value is specified, the value of the [action] property for the input message is the value of the SOAPAction specified.
| true |
| false | technology | active | true |
WSAMD:SPEC:4003.6 | 4 | 4.1 |
A client, however, MAY include Message Addressing Properties in the messages it sends, either on its own initiative or as described by other elements of the service contract, regardless of the presence or absence of wsam:Addressing.
| false |
| false | technology | active | false |
WSAMD:SPEC:4004 | 4 | 4.4 |
Default Action Pattern for WSDL 1.1 -
A default pattern is also defined for backwards compatibility with WSDL 1.1. In the absence of the wsam:Action attribute, the following patterns are used to construct a default action for inputs, outputs, and faults. The general form of an action IRI is defined using the following terms:
[delimiter]
is ":" when the [target namespace] is a URN, otherwise "/". Note that for IRI schemes other than URNs which aren't path-based (i.e. those that outlaw the "/" character), the default action value might not conform to the rules of the IRI scheme. Authors are advised to specify explicit values in the WSDL in this case.
"Fault"
is a literal character string to be included in the action.
[target namespace]
is the target namespace (/definition/@targetNamespace). If [target namespace] ends with a "/" an additional "/" is not added.
[port type name]
is the name of the port type (/definition/portType/@name).
[input|output name]
is the name of the element as defined in Section 2.4.5 of WSDL 1.1.
[fault name]
is the name of the fault (/definition/porttype/operation/fault/@name).
| true |
| false | technology | active | true |
WSAMD:SPEC:4004.1 | 4 | 4.4 |
In the absence of the wsam:Action attribute, the following pattern is used to construct a default action for inputs. The general form of an action IRI is as follows:
Structure of defaulted wsa:Action IRI.
[target namespace][delimiter][port type name][delimiter][input name]
| true |
| false | technology | active | true |
WSAMD:SPEC:4004.2 | 4 | 4.4 |
In the absence of the wsam:Action attribute, the following pattern is used to construct a default action for outputs. The general form of an action IRI is as follows:
Structure of defaulted wsa:Action IRI.
[target namespace][delimiter][port type name][delimiter][output name]
| true |
| false | technology | active | true |
WSAMD:SPEC:4004.3 | 4 | 4.4 |
In the absence of the wsam:Action attribute, the following pattern is used to construct a default action for faults. For fault messages, the general form of an action IRI is as follows:
Structure of default wsa:Action IRI for faults
[target namespace][delimiter][port type name][delimiter][operation name][delimiter]Fault[delimiter][fault name]
| true |
| false | technology | active | true |
WSAMD:SPEC:4004.4 | 4 | 4.4 |
WSDL defines rules for a default input name if the name attribute is not present. According to the rules defined in Section 2.4.5 of WSDL 1.1, if the name attribute is absent for the input of a request response operation the default value is the name of the operation with "Request" appended.
| true |
| false | technology | active | true |
WSAMD:SPEC:4004.5 | 4 | 4.4 |
WSDL defines rules for a default output name if the name attribute is not present. According to the rules defined in Section 2.4.5 of WSDL 1.1, if the name attribute is absent for the ouput of a request response operation the default value is the name of the operation with "Response" appended.
| true |
| false | technology | active | true |
WSAMD:SPEC:5000 | 5 | 1.1 |
WSDL 1.1 Message Exchange Patterns - One-way
This section describes which of the core message properties are mandatory for messages in the various MEPs defined by WSDL 1.1.
This is a straightforward one-way message. No responses are expected but related messages could be sent as part of other message exchanges.
Table 5-1. Message addressing properties for one way message.
Property Mandatory Description
[destination] Y Provides the address of the intended receiver of this message
[action] Y Identifies the semantics implied by this message
| true |
| false | technology | active | true |
WSAMD:SPEC:5001 | 5 | 1.2 |
WSDL 1.1 Message Exchange Patterns - Request-Response
This section describes which of the core message properties are mandatory for messages in the various MEPs defined by WSDL 1.1.
This is request-response. A reply is expected hence mandating [reply endpoint] in the request message. The response message might be a fault.
Table 5-2. Message addressing properties for request message.
Property Mandatory Description
[destination] Y Provides the address of the intended receiver of this message
[action] Y Identifies the semantics implied by this message
[reply endpoint] Y Intended receiver for the reply to this message.
[message id] Y Unique identifier for this message. Used in the [relationship] property of the reply message.
Table 5-3. Message addressing properties for response message.
Property Mandatory Description
[destination] Y Provides the address of the intended receiver of this message
[action] Y Identifies the semantics implied by this message
[relationship] Y Indicates that this message is a reply to the request message using the request message [message id] value and the predefined http://www.w3.org/2005/08/addressing/reply IRI.
| true |
| false | technology | active | true |
WSAMD:SPEC:5002 | 5 | 1.3 |
WSDL 1.1 Message Exchange Patterns - Notification
This section describes which of the core message properties are mandatory for messages in the various MEPs defined by WSDL 1.1.
From the WS-Addressing perspective this MEP is the same as One-way. The properties defined in 5.1.1 One-way apply to this MEP also.
| false |
| false | technology | active | false |
WSAMD:SPEC:5003 | 5 | 1.4 |
WSDL 1.1 Message Exchange Patterns - Solicit-response
This section describes which of the core message properties are mandatory for messages in the various MEPs defined by WSDL 1.1.
From the WS-Addressing perspective this MEP is the same as Request-response. The properties defined in 5.1.2 Request-Response apply to this MEP also.
| false |
| false | technology | active | false |