Testable Features for Web Services Addressing 1.0 Core and SOAP Binding

1. For a synchronous request/response using SOAP/HTTP, verify on the service endpoint that predefined anonymous [address] property value should be used for [source endpoint], [reply endpoint] and [fault endpoint].
2. For a one-way request using SOAP/HTTP, verify on the service endpoint that predefined anonymous [address] property value should be used for [source endpoint] and predefined none [address] property value should be used for [reply endpoint] and [fault endpoint].
3. Create two EPRs, eprReply and eprFault. Both the EPRs use the predefined anonymous [address], contain WSDL as the metadata, and different set of reference parameters. eprReply EPR is used as the value of [reply endpoint] and eprFault EPR is used as the value of [fault endpoint]. The client invokes the service endpoint.
   1. On the service endpoint, validate the WSDL metadata on both eprReply and eprFault EPR.
   2. On the client, in case of a normal reply, validate the reference parameters set on eprReply.
   3. On the client, in case of a fault, validate the reference parameters set on eprFault. This (and previous bullet) will also validate isReferenceParameter="true" semantics.
4. Create an EPR with predefined anonymous [address] and an additional property <ns1:transient xmlns:ns1="urn:foobar">true</transient>. Use this EPR for [reply endpoint] message addressing property. Verify that service endpoint is able to digest the [reply endpoint] EPR and an expected response is received at the client.
5. For a synchronous request/response MEP, verify that [relationship] message addressing property uses the predefined reply value and the message id matches that of the request for normal and fault reply.
6. Attribute extensibility
   1. Generate a request message with xml:id attribute on  [destination], [source endpoint], [reply endpoint], [fault endpoint], [action], and [message id] properties. For such a request, service endpoint should generate a standard response.
   2. For a standard request message, generate a response message with xml:id attribute on [message id], [relationship], [destination] and [action] message addressing properties. Client should be able to digest such a response.
7. Securing the Addressing headers: Can it reveal any addressing-related interop issues ?
8. Faults
   1. Invalid Addressing Header: Each of the following faults are generated with the [Reason] "A header representing a Message Addressing Property is not valid and the message cannot be processed".
      1. Invalid Address: Generate a request message with [reply endpoint] set to a ??? How is an invalid address defined ?
      2. Invalid EPR: Generate request message with [reply endpoint] set to a URI. The service endpoint must generate a fault with wsa:InvalidEPR [Subsubcode] and/or wsa:InvalidAddressingHeader [Subcode] and/or S:Sender [Code].
      3. Invalid Cardinality: Generate request messages with exactly one of the following properties duplicate in each message:
         • [source endpoint]
         • [destination]
         • [reply endpoint]
         • [fault endpoint]
         • [action]
         • [message id]

         In each case, the service endpoint must generate a fault with wsa:InvalidCardinality [Subsubcode] and/or wsa:InvalidAddressingHeader [Subcode] and/or S:Sender [Code].

      4. Missing Address In EPR: Generate a request message with [reply endpoint] set to an EPR with no [address] property. The service endpoint must generate a fault with wsa:InvalidCardinality [Subsubcode] and/or wsa:InvalidAddressingHeader [Subcode] and/or S:Sender [Code].
      5. Duplicate Message ID: Is the runtime expected to maintain a cache of message ids ?
      6. Action Mismatch: Generate a request message with [action] property not matching with SOAPAction. The service endpoint must generate a fault with wsa:ActionMismatch [Subsubcode] and/or wsa:InvalidAddressingHeader [Subcode] and/or S:Sender [Code]. [Details] may contain <wsa:ProblemHeader> or <wsa:ProblemHeaderQName>.
   2. Message Addressing Header Required: Each of the following faults are generated with the [Reason] "A required header representing a Message Addressing Property is not present".
      1. Synchronous request/response using SOAP/HTTP: Generate a request with exactly one of the following message addressing properties missing:
         • [destination]
         • [action]
         • [reply endpoint]
         • [message id]

         In each case, the service endpoint must generate a fault with wsa:MessageAddressingHeaderRequired [Subcode] and/or S:Sender [Code].

      2. Should I list all WSDL 2.0 MEPs ? 
   3. Destination Unreachable: Shutdown the service endpoint and then send a valid request from client to the endpoint. The client must get a response message with wsa:DestinationUnreachable [Subcode] and/or S:Sender [Code]. The [Reason] must contain "No route can be determined to reach [destination]". The [Details] may contain <wsa:ProblemIRI> that conveys the [address] of the [destination].
   4. Action Not Supported: For a service endpoint expecting default [action], generate a request with non-default [action]. The service endpoint must generate a fault with wsa:ActionNotSupported [Subcode] and/or S:Sender [Code]. The [Details] must contain <wsa:ProblemAction> with a required <wsa:Action> child element. The [Reason] must contain "The [action] cannot be processed at the receiver".
   5. Endpoint Unavailable: How is it different from Destination Unreachable ?

SOAP 1.2 specific

1. From the client, generate a SOAP 1.2 message where http://www.w3.org/2003/05/soap/features/action/Action feature has a non-null value. On the service endpoint, http://www.w3.org/20050/08/addressing/features/Action feature should exactly match that value.

SOAP 1.1 specific

1. From the client, generate a SOAP 1.1 message with non-null [action] message addressing property. On the service endpoint, SOAPAction HTTP header must match the [action] property value.

Last updated: August 29, 2005 10:14 AM