[the SOAP 1.2 Addressing] feature may be used with any SOAP MEP.
http://www.w3.org/TR/ws-addr-soap/#s12featuredesc
Need to enumerate SOAP MEPs under test.
A binding that supports [the SOAP 1.2 Addressing] feature MUST provide a means to transmit the properties [listed] and to reconstitute their values on receipt of a message.
http://www.w3.org/TR/ws-addr-soap/#s12featuredesc
Not directly testable, enumerated below. Expect to split each property into separate, multiple assertions for format, cadinality, etc.
Corresponds to the abstract [destination] property.
http://www.w3.org/TR/ws-addr-soap/#s12featureprops
Negative test cases for cardinatlity (1..1), non IRI format.
Corresponds to the abstract [source endpoint] property. [feature at risk]
http://www.w3.org/TR/ws-addr-soap/#s12featureprops
Test cases for cardinatlity (0..1).
Corresponds to the abstract [reply endpoint] property.
http://www.w3.org/TR/ws-addr-soap/#s12featureprops
Test cases for cardinatlity (0..1).
Corresponds to the abstract [reply endpoint] property.
http://www.w3.org/TR/ws-addr-soap/#s12featureprops
Tests with FaultEndpoint which succeed and fail. Tests which fault, but for which FaultEndpoint is missing. Test cases for cardinatlity (0..1).
Corresponds to the abstract [action] property.
http://www.w3.org/TR/ws-addr-soap/#s12featureprops
Negative tests with invalid IRI. Test cases for cardinatlity (1..1).
Corresponds to the abstract [message id] property.
http://www.w3.org/TR/ws-addr-soap/#s12featureprops
Negative tests with invalid IRI. Test cases with duplicated IRI values (results unlcear)? Test cases for cardinatlity (0..1).
Corresponds to the abstract [relationship] property.
http://www.w3.org/TR/ws-addr-soap/#s12featureprops
Negative tests with invalid IRI values. Test cases for cardinality (0..unbounded), spec implies they should be in type/value pairs.
Corresponds to the abstract [reference parameters] property.
http://www.w3.org/TR/ws-addr-soap/#s12featureprops
Complex XML. Test cases for cardinatlity (0..unbounded).
[extensibility of SOAP headers]
http://www.w3.org/TR/ws-addr-soap/#s12featuredesc
I'm sure the schema alows for attribute extensibility, but is this explicity stated?
If the http://www.w3.org/2003/05/soap/features/action/Action property of the SOAP Action feature has a value, then the value of the http://www.w3.org/@@@@/@@/addressing/feature/Action property of the SOAP 1.2 Addressing 1.0 feature MUST be identical to it. Failure to have an identical value results in an Invalid Addressing Header fault.
http://www.w3.org/TR/ws-addr-soap/#s12featureinteractions
Easily testable.
By default, the resulting header blocks are targeted at the ultimate recipient in the SOAP message path (note that extensions to WS-Addressing could be written to specify different targetting).
A message MUST NOT contain more than one wsa:To, wsa:ReplyTo, wsa:FaultTo, wsa:Action, or wsa:MessageID header targeted at a recipient. A recipient MUST generate a wsa:InvalidAddressingHeader fault if such a message is received.
http://www.w3.org/TR/ws-addr-soap/#s12moduledesc
Easily testable.
The SOAP processing model dictates that message addressing properties targeted at an intermediary do not normally get relayed as message addressing properties when the message is forwarded along the message path.
The specification for a SOAP header used as a reference property can override {SOAP12-Module-MAP-Targeting}.
The the soap:relay attribute can override {SOAP12-Module-MAP-Targeting}.
When a message is to be addressed to an endpoint, the XML Infoset representation of each message addressing property that has been assigned a value is inserted into the message as a SOAP header block subject to {SOAP12-Module-Binding-MAPs-Header}, {SOAP12-Module-isReferenceParameter}
http://www.w3.org/TR/ws-addr-soap/#bindingrefp
Whole raft of tests possible in this area, not least inclusion of Reference Properties which clash with those from other sources.
The value, if any, of the [reference parameters] property is added to the SOAP message header: the element information item of each of the [reference parameters] (including all of its [children], [attributes] and [in-scope namespaces]) is added as a SOAP header block in the new message.
http://www.w3.org/TR/ws-addr-soap/#bindingrefp
Easily testible
Each header block added as a result of {SOAP12-Module-MAP-Binding} is annotated with a wsa:IsReferenceParameter attribute whose value is a valid xs:boolean representaion of true
http://www.w3.org/TR/ws-addr-soap/#bindingrefp
Easily testible
[When processing] {SOAP12-Module-MAP-Binding]} any existing wsa:IsReferenceParameter attribute on the header block is replaced.
http://www.w3.org/TR/ws-addr-soap/#additionalinfoset
Test case with existing wsa:IsReferenceParameter in the EPR.
When [the anonymous URI] is specified as the address of the ReplyTo EPR, the underlying SOAP protocol binding provides a channel to the specified endpoint. Any underlying protocol binding supporting the SOAP request-response message exchange pattern provides such a channel. For instance, the SOAP 1.2 HTTP binding puts the reply message in the HTTP response.
http://www.w3.org/TR/ws-addr-soap/#soaphttp
Test cases for SOAP over HTTP with anonymous address in ReplyTo EPR.
{SOAP-Module-Anonymous-Address-FaultTo} [applied to FaultTo EPR]
http://www.w3.org/TR/ws-addr-soap/#soaphttp
Test cases for SOAP over HTTP with anonymous address in FaultTo EPR.
Use of the SOAPAction HTTP header is required when using the SOAP 1.1 HTTP binding. The value of the SOAPAction HTTP header MUST either be identical to the value of the wsa:Action header, or be empty. [snip] Failure to have an identical value, or an empty value for SOAPAction, results in an Invalid Message Addressing Property fault.
http://www.w3.org/TR/ws-addr-soap/#soaphttp
Positive test case for SOAP 1.1 over HTTP with identical and empty SOAPAction values. Negative test cases for SOAP 1.1 over HTTP with non-identical and empty SOAPAction values.
[...]
http://www.w3.org/TR/ws-addr-soap/#securityconsiderations
Test cases composed with WS-Security.
[The RetryAfter] element (whose content is of type xs:unsignedLong) is a suggested minimum duration in milliseconds to wait before retransmitting the message. Omission of this element indicates that a retry is never likely to succeed.
http://www.w3.org/TR/ws-addr-soap/#faultdetailelements
Test cases for retrying.
[The RetryAfter element is open to] Optional extensibility attributes that do not affect processing.
http://www.w3.org/TR/ws-addr-soap/#faultdetailelements
Test cases for retrying including extra attributes.
[enumerated fault sub-codes]
http://www.w3.org/TR/ws-addr-soap/#faultdetailelements
Undecided if these are separate assertions, or may be tied to existing assertions as a possible outcome ..
Copyright © 2004-2005 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.