sc003 WS-Addressing 2008/11/03 Published This scenario is meant to test WS-Addressing. It will use the basic Notify/Echo message exchanges in sc002 by simply adding the use of WS-Addressing to the exchanges.
The tests in this scenario require the operations defined in sc002 and support for the W3C Recommendation version of WS-Addressing. A client that is capable of accepting connections on a network endpoint; therefore the wsa:ReplyTo refers to an addressable endpoint. A client that does not accept incoming incoming connections and the wsa:ReplyTo is either explicitly set to anonymous or the wsa:ReplyTo is not specified which implies an Anonymous URI. A SOAP message exchange in which a requester sends a SOAP message to a service and receives a response message. "Asynchronous" in this context refers to the manner in which the underlying transport protocol is used to carry the request and response messages. The response message is sent over a separate connection that is initiated by the service to the client (a "callback"). An application SOAP message for which no application SOAP response is expected. An application SOAP message for which an application SOAP response is expected. An application SOAP message triggered by a request message. A SOAP message exchange in which a requester sends a SOAP message to a service and receives a response message. "Synchronous" in this context refers to the way in which the underlying transport protocol used to carry the request and response messages. The response message is returned on the back channel of the request message.
In this scenario a client will send one of two messages: Notify or Echo.
See sc002 for more information of the specifics of those application messages.

This scenario is divided into two portions. The first focuses on the messages exchanges from an end-user's point of view. In other words, the scenario assumes that the user has implemented the Notify and Echo operations and now simply "turns on" WS-Addressing. From their point of view they simply want to ensure that the messages arrive at the service and, in the case of Echo, that the responses is sent to the proper endpoint. In these sets of tests the details are intentionally left a bit vague. For example, in the case of a client using the wsa:Anonymous endpoint for wsa:ReplyTo, we don't indicate whether the wsa:ReplyTo is specified with this value or whether it is simply defaulted, per WS-Addressing. Again, the main purpose is to ensure success from the application point of view.

The second portion of this scenario looks at testing WS-Addressing from a lower-level, a SOAP stack implementors point of view. These tests will explicitly state which WS-Addressing elements should be present in each message. Theses tests are aimed at testing some of the less main-line uses of WS-Addressing. While these are probably not the most common uses of WS-Addressing these tests will also not be a fully exaustive test of the WS-Addressing specification either. These are aimed at ensuring that there is interoperability even when the user leaves the most trivial uses of WS-Addressing.

When WS-Addressing is enabled the Notify operation has no semantic changes. The soap envelope will however be modified according to the following table:
Artifact Comment
wsa:Action This required Header must be present with the value of: http://www.wstf.org/docs/scenarios/sc002/Notify
wsa:To This Header must be present on HTTP request messages, and must be the same value as the HTTP URL. On HTTP response messages, this Header is optional - and per the WS-Addressing specification, with a default value of the WS-Addressing anonymous URI.

Other WS-Addressing Header may be present, e.g. wsa:MessageID, but their presence or absense should not influence the success of the test. In particular, due to Notify being a one-way message, any faults generated may or may not be sent back to the client. The client should not expect to ever see one, and this is true whether its a soap (e.g. mustUnderstand) fault or an application fault.

The Notify operation will have two variants in this part of the scenario. The following table summarizes the tests and the expected results. Client sends the Notify message with WS-Addressing headers. Exact list of WS-Addressing headers is implementation specific, however wsa:Action and wsa:To are required. Service responds with an HTTP 202 Client sends a faulting Notify message with WS-Addressing headers. Exact list of WS-Addressing headers is implementation specific, however wsa:Action and wsa:To are required. Service responds with an HTTP 202 When WS-Addressing is enabled the Echo operation has no semantic changes. The request soap envelopes will be modified according to the following table:
Artifact Comment
wsa:Action This required Header must be present with the value of: http://www.wstf.org/docs/scenarios/sc002/Echo
wsa:To This Header must be present on HTTP request messages, and must be the same value as the HTTP URL. On HTTP response messages, this Header is optional - and per the WS-Addressing specification, with a default value of the WS-Addressing anonymous URI.
wsa:MessageID This Header must be present
wsa:ReplyTo/wsa:FaultTo Either of these headers may appear in the message. Per WS-Addressing, if they are both absent then their implied value is the Anonymous URI

Other WS-Addressing Headers may be present but their presence or absence should not influence the success of the test.

And, the response soap envelopes will be modified according to the following table:
Artifact Comment
wsa:Action This required Header must be present with the value of: http://www.wstf.org/docs/scenarios/sc002/EchoResponse
wsa:To This Header must be present on HTTP request messages, and must be the same value as the HTTP URL. On HTTP response messages, this Header is optional - and per the WS-Addressing specification, with a default value of the WS-Addressing anonymous URI.
ref-parameters Additional Headers may appear if there were reference parameters in the wsa:ReplyTo/wsa:FaultTo of the request.
wsa:RelatesTo This header must be present and reference the wsa:MessageID value that was specified in the request.

Other WS-Addressing Header may be present but their presence or absense should not influence the success of the test.

The Echo operation will have several variants. The following table describes each one and specifies the expected results. Client sends a non-faulting Echo message with WS-Addressing headers to indicate a synchronous response is expected. Exact list of WS-Addressing headers is implementation specific, however wsa:Action, wsa:To and wsa:MessageID are required. If a wsa:ReplyTo and/or wsa:FaultTo are included then they must be set to wsa:Anonymous. Service responds with the appropriate EchoResponse on the HTTP back-channel, with the appropriate WS-Addressing headers (wsa:Action and wsa:RelatesTo at a minimum). Client sends a non-faulting Echo message with WS-Addressing headers to indicate an asynchronous response is expected. Exact list of WS-Addressing headers is implementation specific, however wsa:Action, wsa:To, wsa:MessageID and wsa:ReplyTo are required. The wsa:ReplyTo must refer to an addressable endpoint. Service responds with the appropriate EchoResponse on a new connection to the wsa:ReplyTo EPR specified in the Echo message. On the original connection an HTTP 202 is returned. The EchoResponse message will contain the appropriate WS-Addressing headers (wsa:Action, wsa:To and wsa:RelatesTo at a minimum). Client sends a faulting Echo message with WS-Addressing headers to indicate a synchronous response/fault is expected. Exact list of WS-Addressing headers is implementation specific, however wsa:Action, wsa:To and wsa:MessageID are required. If the wsa:ReplyTo and/or wsa:FaultTo are included then they must be set to wsa:Anonymous. Service responds with a fault on the HTTP back-channel, with the appropriate WS-Addressing headers (wsa:Action and wsa:RelatesTo at a minimum). Client sends a faulting Echo message with WS-Addressing headers to indicate an asynchronous response/fault is expected. Exact list of WS-Addressing headers is implementation specific, however wsa:Action, wsa:To, wsa:MessageID and wsa:FaultTo are required. The wsa:FaultTo must refer to an addressable endpoint. Service responds with a fault on a new connection to the wsa:FaultTo EPR specified in the Echo message. On the original connection an HTTP 202 is returned. The fault message will contain the appropriate WS-Addressing headers (wsa:Action and wsa:RelatesTo at a minimum). The following tests will focus on interoperability testing of the WS-Addressing specification from a technical point of view. These tests are designed to ensure a common understanding of the most commonly used WS-Addressing features - as such, these tests will be more precise with respect to what is expected to be seen in the SOAP Envelopes. Client sends Notify with wsa:Action header but no other WS-Addressing headers (not even a wsa:MessageID). Service responds with an HTTP 202. Client sends Notify with wsa:Action and wsa:MessageID headers but no other WS-Addressing headers. Service responds with an HTTP 202. Client sends Notify with wsa:Action, wsa:MessageID and wsa:ReplyTo set to wsa:None but no other WS-Addressing headers. Service responds with an HTTP 202. Client sends Notify with wsa:Action, wsa:MessageID and wsa:FaultTo set to wsa:None but no other WS-Addressing headers. Service responds with an HTTP 202. Client sends Notify with wsa:Action, wsa:MessageID and wsa:ReplyTo and wsa:FaultTo set to wsa:None but no other WS-Addressing headers. Service responds with an HTTP 202. Client sends a faulting Notify with wsa:Action and wsa:ReplyTo and wsa:FaultTo set to wsa:Anonymous but no other WS-Addressing headers. Note: there is no wsa:MessageID header. Service responds with an HTTP 202. Client sends a faulting Notify with wsa:Action, wsa:MessageID and wsa:ReplyTo and wsa:FaultTo set to wsa:Anonymous but no other WS-Addressing headers. Service responds with an HTTP 202. Client sends a faulting Notify with wsa:Action, wsa:MessageID and wsa:ReplyTo and wsa:FaultTo set to wsa:None but no other WS-Addressing headers. Service responds with an HTTP 202. Client sends a Notify with wsa:Action, wsa:MessageID and an additional unknown SOAP Header that is marked with the mustUnderstand attribute set to 'true'. Service responds with an HTTP 202. Client sends an Echo with wsa:Action and wsa:MessageID but no other WS-Addressing headers. Service responds with the appropriate EchoResponse on the HTTP back-channel, with the appropriate WS-Addressing headers (wsa:Action and wsa:RelatesTo at a minimum). Client sends an Echo with wsa:Action, wsa:MessageID and wsa:ReplyTo set to wsa:Anonymous but no other WS-Addressing headers. Service responds with the appropriate EchoResponse on the HTTP back-channel, with the appropriate WS-Addressing headers (wsa:Action and wsa:RelatesTo at a minimum). Client sends an Echo with wsa:Action, wsa:MessageID and wsa:ReplyTo set to wsa:Anonymous but no other WS-Addressing headers. The wsa:ReplyTo must include some Reference Parameters. Service responds with the appropriate EchoResponse on the HTTP back-channel, with the appropriate WS-Addressing headers (wsa:Action, wsa:RelatesTo and the request's wsa:ReplyTo's Reference Parameters at a minimum). Client sends an Echo with wsa:Action, wsa:MessageID and wsa:ReplyTo and wsa:FaultTo set to wsa:Anonymous but no other WS-Addressing headers. The wsa:ReplyTo and wsa:FaultTo must include some Reference Parameters and the wsa:ReplyTo's Reference Parameters must differ from the wsa:FaultTo Reference Parameters. Service responds with the appropriate EchoResponse on the HTTP back-channel, with the appropriate WS-Addressing headers (wsa:Action, wsa:RelatesTo and the request's wsa:ReplyTo's Reference Parameters at a minimum). Client sends a faulting Echo with wsa:Action, wsa:MessageID and wsa:ReplyTo set to wsa:Anonymous but no other WS-Addressing headers. The wsa:ReplyTo must include some Reference Parameters. Service responds with a fault on the HTTP back-channel, with the appropriate WS-Addressing headers (wsa:Action, wsa:RelatesTo and the request's wsa:ReplyTo's Reference Parameters at a minimum). Client sends a faulting Echo with wsa:Action, wsa:MessageID and wsa:ReplyTo and wsa:FaultTo set to wsa:Anonymous but no other WS-Addressing headers. The wsa:ReplyTo and wsa:FaultTo must include some Reference Parameters and the wsa:ReplyTo's Reference Parameters must differ from the wsa:FaultTo Reference Parameters. Service responds with a fault on the HTTP back-channel, with the appropriate WS-Addressing headers (wsa:Action, wsa:RelatesTo and the request's wsa:FaultTo's Reference Parameters at a minimum). -- test removed -- Client sends a faulting Echo with wsa:Action, wsa:MessageID, wsa:ReplyTo set to an addressable EPR, and wsa:FaultTo set to wsa:Anonymous but no other WS-Addressing headers. Service responds with a fault on the HTTP back-channel, with the appropriate WS-Addressing headers (wsa:Action, wsa:RelatesTo and any request's wsa:FaultTo's Reference Parameters at a minimum). Client sends an Echo with wsa:Action, wsa:MessageID, wsa:ReplyTo set to wsa:None but no other WS-Addressing headers. Service responds with an HTTP 202. Client sends an Echo with wsa:Action, wsa:MessageID, wsa:ReplyTo set to an addressable EPR, wsa:FaultTo set to wsa:None and there is a SOAP Header with the mustUnderstand flag set to 'true' but the header is unknown to the service. Service responds with a mustUnderstand fault on the HTTP back-channel. Client sends an Echo with wsa:Action, wsa:MessageID, wsa:ReplyTo and wsa:FaultTo set to an addressable EPR and there is a SOAP Header with the mustUnderstand flag set to 'true' but the header is unknown to the service. Service responds with an mustUnderstand fault on the HTTP back-channel. Client sends an Echo without a wsa:Action SOAP Header but does inlcude the wsa:MessageID SOAP Header and wsa:ReplyTo SOAP Header set to an addressable EPR. Service responds with WS-Addressing "Message Addressing Header Required" Fault sent to the wsa:ReplyTo EPR. Client sends a faulting Echo with wsa:Action, wsa:MessageID and an addressable wsa:ReplyTo. Service responds with a fault to the wsa:ReplyTo EPR with the appropriate WS-Addressing headers (wsa:Action, wsa:RelatesTo and any request's wsa:ReplyTo's Reference Parameters at a minimum). Client sends a faulting Echo with wsa:Action, wsa:MessageID, an addressable wsa:ReplyTo and the wsa:FaultTo EPR set to wsa:Anon. Service responds with a fault on the HTTP back-channel with the appropriate WS-Addressing headers (wsa:Action, wsa:RelatesTo and any request's wsa:FaultTo's Reference Parameters at a minimum). Client sends an Echo with wsa:Action, wsa:MessageID and an addressable wsa:ReplyTo. Service responds with the appropriate EchoResponse to the wsa:ReplyTo EPR with the appropriate WS-Addressing headers (wsa:Action, wsa:RelatesTo and the request's wsa:ReplyTo's Reference Parameters at a minimum). Client sends an Echo with wsa:Action, wsa:MessageID, wsa:From, wsa:ReplyTo and wsa:FaultTo with any appropriate values. All of the headers are marked with the mustUnderstand attribute set to 'true'. Service responds with the appropriate EchoResponse to the wsa:ReplyTo EPR with the appropriate WS-Addressing headers (wsa:Action, wsa:RelatesTo and the request's wsa:ReplyTo's Reference Parameters at a minimum). No mustUnderstand Fault must be generated. Client sends an Echo with wsa:Action, wsa:MessageID, and wsa:ReplyTo set to an unreachable URI. A WS-Addressing "Destination Unreachable" fault it generated. However, where does it go? If anywhere. There are two options:
1) an HTTP 202 is returned and the fault is never seen by the client
2) the fault is returned on the HTTP back-channel (ie. wsa:FaultTo).
But what if the wsa:FaultTo is unreachable as well???

Test 2.26 (Echo+Unreachable-ReplyTo) introduces some interesting aspects to the process of responses when the destination EPR is unreachable. For example, if the destination EPR for a response message is not reachable then should the service notify the sender of the request message even if the wsa:ReplyTo and wsa:FaultTo are non-anonymous?

There are three cases the group focused on:
ReplyTo/FaultTo are both unreachable
This covers the case where there is no FaultTo and therefore defaults to the ReplyTo EPR.
In this case the client should expect to get back an HTTP 202 response. If the server is able to determine that the response's destination EPR is problematic (either invalid or unreachable) then the server may choose to send back a fault (e.g. wsa:InvalidAddress) back to the client if the HTTP connection still happens to be available. However, the client should not rely on this.
 ReplyTo is unreachable, FaultTo is addressable and reachable
In this case an HTTP 202 should be returned back to the client. Any fault generated (either from the application or from trying to connect to the ReplyTo EPR) should be sent to the FaultTo EPR.
 ReplyTo is unreachable, FaultTo is anonymous
In this case any fault generated is sent back to the client on the HTTP back-channel. As is the case whenever faults are generated, they may not be transmitted due to security concerns. An issue was detected around the processing model of one-way message and faults related to these messages. While normally one-way messages are considered to be "fire-and-forget" messages, there can still be faults generated from them. For example, if a one-way message is sent, without Reliable Messaging, to an endpoint that requires WS-ReliableMessaging to be used then a fault will be generated. If (though it is not a requirement) the service decides to send back a fault to the client then the service will run into a problem. Per the WS-Addressing spec (section 3.4), all responses (faulting or non-faulting) must include a wsa:RelatesTo header. If the one-way message did not include a wsa:MessageID then the fault will not be able to include a wsa:RelatesTo header - and the WS-Addressing spec says that the service must fault (again) due to this. In cases where a sender is interested in seeing faults that might be generated, they really should include a wsa:MessageID on all outgoing messages.

Initial draft Convert to xml Misc typos Add findings about msgID