Features:
An explicit wsaw:Action is specified on the input and output message. The presence of correct Action header is checked on the request and response message.
Port: wsaTestPortTypePortExplicitAction
Features:
An explicit wsaw:Action is specified on the input and output message. The request message contains an incorrect Action header. A fault message is returned on the HTTP response indicating the nature of fault.
Port: wsaTestPortTypePortExplicitAction
Features:
An explicit wsaw:Action is specified on the input and fault message. Application fault message is returned on the HTTP response. The presence of correct Action header is checked on the request and fault message.
Port: wsaTestPortTypePortExplicitAction
Features:
No wsaw:Action on the input and output message of the operation. The presence of implicit Action is checked on the request and response message.
Port: wsaTestPortTypePortAddressingRequired
Features:
No wsaw:Action on the input and output message of the operation. The request message contains an incorrect Action header. A fault message is returned on the HTTP response indicating the nature of fault.
Port: wsaTestPortTypePortAddressingRequired
Features:
No wsaw:Action on the input and fault message of the operation. Application fault message is returned on the HTTP response. The presence of correct Action header is checked on the request and fault message.
Port: wsaTestPortTypePortAddressingRequired
Features:
Normal WSDL (same as we have been using) with no action value specified and SOAPAction specified in binding. assertion: client sends action value the same as SOAPAction and server responds with correct response
Port: wsaTestPortTypePortSoapAction
Features:
The WSDL has a target namespace using urn scheme. The presence of correction Action header is checked on the request and response message.
Port:
Features:
The WSDL has a target namespace using urn scheme. No wsaw:action is specified on the input and output message. The request message contains an incorrect Action header. A fault message is received on the HTTP response with approrpiate fault code/subcode.
Port: wsaTestPortTypePortAddressingRequired
Features:
The WSDL has a target namespace using urn scheme. No wsaw:Action on the input and fault message of the operation. Application fault message is returned on the HTTP response. The presence of correct Action header is checked on the response message.
Port: wsaTestPortTypePortAddressingRequired
Features:
This scenario covers the case of a client sending messages with the response endpoint URI set to http://www.w3.org/2005/08/addressing/anonymous. The service endpoint fully supports WS-Addressing without any constraints - the service endpoint uses a wsam:Addressing policy assertion <wsp:Policy wsu:Id="MixedModeEndpoint"><wsam:Addressing><wsp:Policy/></wsam:Addressing></wsp:Policy>. The client sends an Anonymous Request and receives an Anonymous Response on the HTTP response.
Port: IEchoString
Features:
This scenario covers the case of a client sending messages with the response endpoint URI set to a non-anonymous URI. The service endpoint fully supports WS-Addressing without any constraints - the service endpoint uses a wsam:Addressing policy assertion <wsp:Policy wsu:Id="MixedModeEndpoint"><wsam:Addressing><wsp:Policy/></wsam:Addressing></wsp:Policy>. The client sends a non-anonymous Request and receives a non-anonymous Response on a new HTTP connection.
Port: IEchoString
Features:
This scenario covers the case of a client sending messages with the response endpoint URI set to http://www.w3.org/2005/08/addressing/none. The service endpoint fully supports WS-Addressing without any constraints - the service endpoint uses a wsam:Addressing policy assertion <wsp:Policy wsu:Id="MixedModeEndpoint"><wsam:Addressing><wsp:Policy/></wsam:Addressing></wsp:Policy>. The client sends a None Request and receives an HTTP 202 Accepted response.
Port: IEchoString
Features:
This scenario covers the case of a client sending valid messages with an anonymous URI in the ReplyTo header and a non-anonymous URI in the FaultTo header. The service endpoint fully supports WS-Addressing without any constraints - the service endpoint uses a wsam:Addressing policy assertion <wsp:Policy wsu:Id="MixedModeEndpoint"><wsam:Addressing><wsp:Policy/></wsam:Addressing></wsp:Policy>. The client sends a Valid Anonymous ReplyTo / Non-Anonymous FaultTo Request and receives an Anonymous Response on the HTTP response.
Port: IEchoString
Features:
This scenario covers the case of a client sending invalid, fault inducing messages with an anonymous URI in the ReplyTo header and a non-anonymous URI in the FaultTo header. The service endpoint fully supports WS-Addressing without any constraints - the service endpoint uses a wsam:Addressing policy assertion <wsp:Policy wsu:Id="MixedModeEndpoint"><wsam:Addressing><wsp:Policy/></wsam:Addressing></wsp:Policy>. The client sends an Invalid Anonymous ReplyTo / Non-Anonymous FaultTo Request and receives an Non-Anonymous wsa:ActionNotSupported fault on a new HTTP connection.
Port: IEchoString
Features:
This scenario covers the case of a client sending valid messages with a non-anonymous URI in the ReplyTo header and an anonymous URI in the FaultTo header. The service endpoint fully supports WS-Addressing without any constraints - the service endpoint uses a wsam:Addressing policy assertion <wsp:Policy wsu:Id="MixedModeEndpoint"><wsam:Addressing><wsp:Policy/></wsam:Addressing></wsp:Policy>. The client sends a Valid Non-Anonymous ReplyTo / Anonmyous FaultTo Request and receives a Non-Anonymous Response on a new HTTP connection.
Port: IEchoString
Features:
This scenario covers the case of a client sending invalid, fault inducing messages with a non-anonymous URI in the ReplyTo header and an anonymous URI in the FaultTo header. The service endpoint fully supports WS-Addressing without any constraints - the service endpoint uses a wsam:Addressing policy assertion <wsp:Policy wsu:Id="MixedModeEndpoint"><wsam:Addressing><wsp:Policy/></wsam:Addressing></wsp:Policy>. The client sends an Invalid Non-Anonymous ReplyTo / Anonymous FaultTo Request and receives a wsa:ActionMismatch fault on the HTTP response.
Port: IEchoString
Features:
This scenario covers the case of a client sending messages with the response endpoint URI set to an anonymous URI. The service endpoint requires WS-Addressing and requires the use of anonymous responses - the service’s wsam:Addressing assertion is <wsp:Policy wsu:Id="AnonymousOnlyEndpoint"><wsam:Addressing><wsp:Policy><wsam:AnonymousResponses/></wsp:Policy></wsam:Addressing></wsp:Policy>. The client sends an Anonymous Request and receives an Anonymous Response.
Port: IEchoString
Features:
This scenario covers the case of a client sending messages with the response endpoint URI set to http://www.w3.org/2005/08/addressing/none. The service endpoint requires WS-Addressing and requires the use of anonymous responses - the service’s wsam:Addressing assertion is <wsp:Policy wsu:Id="AnonymousOnlyEndpoint"><wsam:Addressing><wsp:Policy><wsam:AnonymousResponses/></wsp:Policy></wsam:Addressing></wsp:Policy>. The client sends a None Request and receives an HTTP 202 Accepted response.
Port: IEchoString
Features:
This scenario covers the case of a client sending messages with the response endpoint URI set to a non-anonymous URI. The service endpoint requires WS-Addressing and requires the use of non-anonymous responses - the service’s wsam:Addressing assertion is <wsp:Policy wsu:Id="NonAnonymousOnlyEndpoint"><wsam:Addressing><wsp:Policy><wsam:NonAnonymousResponses/></wsp:Policy></wsam:Addressing></wsp:Policy>. The client sends a Non-Anonymous Request and receives an Non-Anonymous Response.
Port: IEchoString
Features:
This scenario covers the case of a client sending messages with the response endpoint URI set to http://www.w3.org/2005/08/addressing/none. The service endpoint requires WS-Addressing and requires the use of non-anonymous responses - the service’s wsam:Addressing assertion is <wsp:Policy wsu:Id="NonAnonymousOnlyEndpoint"><wsam:Addressing><wsp:Policy><wsam:NonAnonymousResponses/></wsp:Policy></wsam:Addressing></wsp:Policy>. The client sends a None Request and receives an HTTP 202 Accepted response.
Port: IEchoString
Features:
This scenario covers the case of a client sending messages with the response endpoint URI set to http://www.w3.org/2005/08/addressing/anonymous. The service endpoint fully supports WS-Addressing without any constraints - the service endpoint uses a wsam:Addressing policy assertion <wsp:Policy wsu:Id="MixedModeEndpoint"><wsam:Addressing><wsp:Policy/></wsam:Addressing></wsp:Policy>. The client sends an Anonymous Request and receives an Anonymous Response on the HTTP response.
Port: IEchoString
Features:
This scenario covers the case of a client sending messages with the response endpoint URI set to a non-anonymous URI. The service endpoint fully supports WS-Addressing without any constraints - the service endpoint uses a wsam:Addressing policy assertion <wsp:Policy wsu:Id="MixedModeEndpoint"><wsam:Addressing><wsp:Policy/></wsam:Addressing></wsp:Policy>. The client sends a non-anonymous Request and receives a non-anonymous Response on a new HTTP connection.
Port: IEchoString
Features:
This scenario covers the case of a client sending messages with the response endpoint URI set to http://www.w3.org/2005/08/addressing/none. The service endpoint fully supports WS-Addressing without any constraints - the service endpoint uses a wsam:Addressing policy assertion <wsp:Policy wsu:Id="MixedModeEndpoint"><wsam:Addressing><wsp:Policy/></wsam:Addressing></wsp:Policy>. The client sends a None Request and receives an HTTP 202 Accepted response.
Port: IEchoString
Features:
This scenario covers the case of a client sending valid messages with an anonymous URI in the ReplyTo header and a non-anonymous URI in the FaultTo header. The service endpoint fully supports WS-Addressing without any constraints - the service endpoint uses a wsam:Addressing policy assertion <wsp:Policy wsu:Id="MixedModeEndpoint"><wsam:Addressing><wsp:Policy/></wsam:Addressing></wsp:Policy>. The client sends a Valid Anonymous ReplyTo / Non-Anonymous FaultTo Request and receives an Anonymous Response on the HTTP response.
Port: IEchoString
Features:
This scenario covers the case of a client sending invalid, fault inducing messages with an anonymous URI in the ReplyTo header and a non-anonymous URI in the FaultTo header. The service endpoint fully supports WS-Addressing without any constraints - the service endpoint uses a wsam:Addressing policy assertion <wsp:Policy wsu:Id="MixedModeEndpoint"><wsam:Addressing><wsp:Policy/></wsam:Addressing></wsp:Policy>. The client sends an Invalid Anonymous ReplyTo / Non-Anonymous FaultTo Request and receives an Non-Anonymous wsa:ActionNotSupported fault on a new HTTP connection.
Port: IEchoString
Features:
This scenario covers the case of a client sending valid messages with a non-anonymous URI in the ReplyTo header and an anonymous URI in the FaultTo header. The service endpoint fully supports WS-Addressing without any constraints - the service endpoint uses a wsam:Addressing policy assertion <wsp:Policy wsu:Id="MixedModeEndpoint"><wsam:Addressing><wsp:Policy/></wsam:Addressing></wsp:Policy>. The client sends a Valid Non-Anonymous ReplyTo / Anonmyous FaultTo Request and receives a Non-Anonymous Response on a new HTTP connection.
Port: IEchoString
Features:
This scenario covers the case of a client sending invalid, fault inducing messages with a non-anonymous URI in the ReplyTo header and an anonymous URI in the FaultTo header. The service endpoint fully supports WS-Addressing without any constraints - the service endpoint uses a wsam:Addressing policy assertion <wsp:Policy wsu:Id="MixedModeEndpoint"><wsam:Addressing><wsp:Policy/></wsam:Addressing></wsp:Policy>. The client sends an Invalid Non-Anonymous ReplyTo / Anonymous FaultTo Request and receives a wsa:ActionMismatch fault on the HTTP response.
Port: IEchoString
Features:
This scenario covers the case of a client sending messages with the response endpoint URI set to an anonymous URI. The service endpoint requires WS-Addressing and requires the use of anonymous responses - the service’s wsam:Addressing assertion is <wsp:Policy wsu:Id="AnonymousOnlyEndpoint"><wsam:Addressing><wsp:Policy><wsam:AnonymousResponses/></wsp:Policy></wsam:Addressing></wsp:Policy>. The client sends an Anonymous Request and receives an Anonymous Response.
Port: IEchoString
Features:
This scenario covers the case of a client sending messages with the response endpoint URI set to http://www.w3.org/2005/08/addressing/none. The service endpoint requires WS-Addressing and requires the use of anonymous responses - the service’s wsam:Addressing assertion is <wsp:Policy wsu:Id="AnonymousOnlyEndpoint"><wsam:Addressing><wsp:Policy><wsam:AnonymousResponses/></wsp:Policy></wsam:Addressing></wsp:Policy>. The client sends a None Request and receives an HTTP 202 Accepted response.
Port: IEchoString
Features:
This scenario covers the case of a client sending messages with the response endpoint URI set to a non-anonymous URI. The service endpoint requires WS-Addressing and requires the use of non-anonymous responses - the service’s wsam:Addressing assertion is <wsp:Policy wsu:Id="NonAnonymousOnlyEndpoint"><wsam:Addressing><wsp:Policy><wsam:NonAnonymousResponses/></wsp:Policy></wsam:Addressing></wsp:Policy>. The client sends a Non-Anonymous Request and receives an Non-Anonymous Response.
Port: IEchoString
Features:
This scenario covers the case of a client sending messages with the response endpoint URI set to http://www.w3.org/2005/08/addressing/none. The service endpoint requires WS-Addressing and requires the use of non-anonymous responses - the service’s wsam:Addressing assertion is <wsp:Policy wsu:Id="NonAnonymousOnlyEndpoint"><wsam:Addressing><wsp:Policy><wsam:NonAnonymousResponses/></wsp:Policy></wsam:Addressing></wsp:Policy>. The client sends a None Request and receives an HTTP 202 Accepted response.
Port: IEchoString
Features:
This scenario covers the case of a WSDL document which explicitly defines the WS-Addressing action for each message. The wsdl:portType element in the WSDL would appear as follows: <wsdl:portType name="IEchoString"> <wsdl:operation name="Echo"> <wsdl:input wsam:Action="http://tempuri.org/IEchoString/Echo" message="tns:IEchoString_Echo_InputMessage"/> <wsdl:output wsam:Action="http://tempuri.org/IEchoString/EchoResponse" message="tns:IEchoString_Echo_OutputMessage"/> </wsdl:operation> </wsdl:portType>. A client generated from a WSDL that contained the XML fragment above and that is connected to an endpoint defined by the port type above must have the highlighted input action above in its wsa:Action header. The endpoints must respond with a message that has the highlighted output action in its wsa:Action header. See the Anonymous Request and Anonymous Response messages as an example.
Port: IEchoString
Features:
This scenario covers the case of a WSDL document with a single wsdl:portType element. The wsdl:portType element contains two operations as follows: <wsdl:portType name="IEchoString"> <wsdl:operation name="Echo"> <wsdl:input wsam:Action="http://tempuri.org/IEchoString/Echo" message="tns:IEchoString_Echo_InputMessage"/> <wsdl:output wsam:Action="http://tempuri.org/IEchoString/EchoResponse" message="tns:IEchoString_Echo_OutputMessage"/> </wsdl:operation> <wsdl:operation name="EchoToInt"> <wsdl:input wsam:Action="http://tempuri.org/IEchoString/EchoToInt" message="tns:IEchoString_Echo_InputMessage"/> <wsdl:output wsam:Action="http://tempuri.org/IEchoString/EchoToIntResponse" message="tns:IEchoString_EchoToInt_OutputMessage"/> </wsdl:operation> </wsdl:portType>. Since wsdl:input element’s message attribute has the same value for both operations, the request body will be the same. The endpoint will have to dispatch the request correctly based on the wsa:Action header only and respond with a message that has the right endpoint’s action and body. The first message sent by this scenario will carry action http://tempuri.org/IEchoString/Echo and expect action http://tempuri.org/IEchoString/EchoResponse in return. The second message sent by this scenario will carry action http://tempuri.org/IEchoString/EchoToInt and expect action http://tempuri.org/IEchoString/EchoToIntResponse in return.
Port: IEchoString
Features:
This scenario covers the case of a WSDL document with a single wsdl:portType element. The wsdl:portType elements contains two operations as follows: <wsdl:portType name="IEchoString"> <wsdl:operation name="Echo"> <wsdl:input name="Echo" message="tns:IEchoString_Echo_InputMessage"/> <wsdl:output name="EchoResponse" message="tns:IEchoString_Echo_OutputMessage"/> </wsdl:operation> <wsdl:operation name="EchoToInt"> <wsdl:input name="EchoToInt" message="tns:IEchoString_Echo_InputMessage"/> <wsdl:output name="EchoToIntResponse" message="tns:IEchoString_EchoToInt_OutputMessage"/> </wsdl:operation> </wsdl:portType> The reasoning for this scenario is identical as for scenario 2.2. The only difference is that the wsa:Action header is now inferred from the WSDL. The first message sent by this scenario will carry action http://tempuri.org/IEchoString/Echo/Echo and expect action http://tempuri.org/IEchoString/EchoResponse/EchoResponse in return. The second message sent by this scenario will carry action http://tempuri.org/IEchoString/EchoToInt/EchoToInt and expect action http://tempuri.org/IEchoString/EchoToIntResponse/EchoToIntResponse in return.
Port: IEchoString
Features:
This scenario covers the case of an EPR containing an empty wsa:Metadata element: <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"> <wsa:Address> http://www.w3.org/2005/08/addressing/anonymous </wsa:Address> <wsa:Metadata></wsa:Metadata> </wsa:EndpointReference> This scenario shows that the processor can successfully extract WS-Addressing Core defined values (e.g. [address]) from an EPR
Port:
Features:
This scenario covers the case of an EPR containing a wsa:Metadata element containing just a wsam:InterfaceName element: <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"> <wsa:Address> http://www.w3.org/2005/08/addressing/anonymous </wsa:Address> <wsa:Metadata xmlns:test="http://www.example.org/wsamTest/"> <wsam:InterfaceName>test:wsamTest3</wsam:InterfaceName> </wsa:Metadata> </wsa:EndpointReference> This scenario shows that the processor can successfully extract WS-Addressing Core defined values (e.g. [address]) from an EPR
Port:
Features:
This scenario covers the case of an EPR containing a wsa:Metadata element containing just a wsam:ServiceName element.: <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"> <wsa:Address> http://www.w3.org/2005/08/addressing/anonymous </wsa:Address> <wsa:Metadata xmlns:test="http://www.example.org/wsamTest/"> <wsam:ServiceName>test:wsamTest2SOAP</wsam:ServiceName> </wsa:Metadata> </wsa:EndpointReference> This scenario shows that the processor can successfully extract WS-Addressing Core defined values (e.g. [address]) from an EPR
Port:
Features:
This scenario covers the case of an EPR containing a wsa:Metadata element containing a wsam:ServiceName element with an EndpointName attribute: <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"> <wsa:Address> http://www.w3.org/2005/08/addressing/anonymous </wsa:Address> <wsa:Metadata xmlns:test="http://www.example.org/wsamTest/"> <wsam:ServiceName EndpointName="wsamTest2SOAP">test:wsamTest2SOAP</wsam:ServiceName> </wsa:Metadata> </wsa:EndpointReference> This scenario shows that the processor can successfully extract WS-Addressing Core defined values (e.g. [address]) from an EPR
Port:
Features:
This scenario covers the case of an EPR containing a wsa:Metadata element containing both a wsam:InterfaceName element and a wsam:ServiceName element with an EndpointName attribute: <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"> <wsa:Address> http://www.w3.org/2005/08/addressing/anonymous </wsa:Address> <wsa:Metadata xmlns:test="http://www.example.org/wsamTest/"> <wsam:InterfaceName>test:wsamTest2</wsam:InterfaceName> <wsam:ServiceName EndpointName="wsamTest2SOAP">test:wsamTest2SOAP</wsam:ServiceName> </wsa:Metadata> </wsa:EndpointReference> This scenario shows that the processor can successfully extract WS-Addressing Core defined values (e.g. [address]) from an EPR
Port:
Features:
This scenario covers the case of an EPR a wsa:Metadata element with a valid wsdli:wsdlLocation attribute: <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"> <wsa:Address> http://www.w3.org/2005/08/addressing/anonymous </wsa:Address> <wsa:Metadata xmlns:test="http://www.example.org/wsamTest/" xmlns:wsdli="http://www.w3.org/ns/wsdl-instance" wsdli:wsdlLocation="http://www.example.org/wsamTest/ http://people.apache.org/~davidillsley/wsamTest/wsamTest.wsdl"> <wsam:InterfaceName>test:wsamTest2</wsam:InterfaceName> <wsam:ServiceName EndpointName="wsamTest2SOAP">test:wsamTest2SOAP</wsam:ServiceName> </wsa:Metadata> </wsa:EndpointReference> This scenario shows that the processor can successfully extract WS-Addressing Core defined values (e.g. [address]) from an EPR
Port:
Features:
This scenario covers the case of an Invalid EPR containing the wsa:Metadata element with more than one wsam:InterfaceName element: <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"> <wsa:Address> http://www.w3.org/2005/08/addressing/anonymous </wsa:Address> <wsa:Metadata xmlns:test="http://www.example.org/wsamTest/"> <wsam:InterfaceName>test:wsamTest3</wsam:InterfaceName> <wsam:InterfaceName>test:wsamTest3</wsam:InterfaceName> </wsa:Metadata> </wsa:EndpointReference> This scenario shows that the processor faults when processing an EPR which does not conform to the WS-Addressing Metadata specification.
Port:
Features:
This scenario covers the case of an Invalid EPR containing the wsa:Metadata element with more than one wsam:ServiceName element: <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"> <wsa:Address> http://www.w3.org/2005/08/addressing/anonymous </wsa:Address> <wsa:Metadata xmlns:test="http://www.example.org/wsamTest/"> <wsam:ServiceName>test:wsamTest2SOAP</wsam:ServiceName> <wsam:ServiceName>test:wsamTest2SOAP</wsam:ServiceName> </wsa:Metadata> </wsa:EndpointReference> This scenario shows that the processor faults when processing an EPR which does not conform to the WS-Addressing Metadata specification.
Port:
Features:
This scenario covers the case of an EPR containing the wsa:Metadata contains a wsam:InterfaceName element and the value contained is extracted.: <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"> <wsa:Address> http://www.w3.org/2005/08/addressing/anonymous </wsa:Address> <wsa:Metadata xmlns:test="http://www.example.org/wsamTest/"> <wsam:ServiceName>test:wsamTest2SOAP</wsam:ServiceName> <wsam:ServiceName>test:wsamTest2SOAP</wsam:ServiceName> </wsa:Metadata> </wsa:EndpointReference> This scenario shows that the processor extracts the wsam:Metadata from conforming EPRs.
Port:
Features:
This scenario covers the case of an EPR containing the wsa:Metadata contains a wsam:ServiceName element and the value contained is extracted. <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"> <wsa:Address> http://www.w3.org/2005/08/addressing/anonymous </wsa:Address> <wsa:Metadata xmlns:test="http://www.example.org/wsamTest/"> <wsam:ServiceName>test:wsamTest2SOAP</wsam:ServiceName> </wsa:Metadata> </wsa:EndpointReference> This scenario shows that the processor extracts the wsam:Metadata from conforming EPRs.
Port:
Features:
This scenario covers the case of an EPR containing wsa:Metadata contains a wsam:InterfaceName and wsam:ServiceName element and the values contained are extracted. <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"> <wsa:Address> http://www.w3.org/2005/08/addressing/anonymous </wsa:Address> <wsa:Metadata xmlns:test="http://www.example.org/wsamTest/"> <wsam:InterfaceName>test:wsamTest2</wsam:InterfaceName> <wsam:ServiceName>test:wsamTest2SOAP</wsam:ServiceName> </wsa:Metadata> </wsa:EndpointReference> This scenario shows that the processor extracts the wsam:Metadata from conforming EPRs.
Port:
Features:
This scenario covers the case of an EPR containing wsa:Metadata contains a wsam:InterfaceName and a wsam: ServiceName element with an EndpointName attribute and the valuse contained are extracted. <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"> <wsa:Address> http://www.w3.org/2005/08/addressing/anonymous </wsa:Address> <wsa:Metadata xmlns:test="http://www.example.org/wsamTest/"> <wsam:InterfaceName>test:wsamTest2</wsam:InterfaceName> <wsam:ServiceName EndpointName="wsamTest2SOAP">test:wsamTest2SOAP</wsam:ServiceName> </wsa:Metadata> </wsa:EndpointReference> This scenario shows that the processor extracts the wsam:Metadata from conforming EPRs.
Port:
Features:
This scenario covers the case of an EPR containing wsa:Metadata contains a wsam:ServiceName element with an EndpointName attribute and the related WSDL is referenced by the wsdi:wsdlLocation attribute.The name of the binding from the WSDL document referenced using the wsam:ServiceName and EndpointName is extracted. <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"> <wsa:Address> http://www.w3.org/2005/08/addressing/anonymous </wsa:Address> <wsa:Metadata xmlns:test="http://www.example.org/wsamTest/" xmlns:wsdli="http://www.w3.org/ns/wsdl-instance" wsdli:wsdlLocation="http://www.example.org/wsamTest/ http://people.apache.org/~davidillsley/wsamTest/wsamTest.wsdl"> <wsam:InterfaceName>test:wsamTest2</wsam:InterfaceName> <wsam:ServiceName EndpointName="wsamTest2SOAP">test:wsamTest2SOAP</wsam:ServiceName> </wsa:Metadata> </wsa:EndpointReference> This scenario shows that the processor extracts the wsam:Metadata from conforming EPRs.
Port:
Features:
An explicit wsaw:Action is specified on the input and output message. The presence of correct Action header is checked on the request and response message.
Port: ServiceInterface
Features:
An explicit wsaw:Action is specified on the input and output message. The presence of correct Action header is checked on the request and response message.
Port: ServiceInterface
Features:
An explicit wsaw:Action is specified on the input and output message. The presence of correct Action header is checked on the request and response message.
Port: ServiceInterface
Features:
An explicit wsaw:Action is specified on the input and output message. The presence of correct Action header is checked on the request and response message.
Port: ServiceInterface
Features:
An explicit wsaw:Action is specified on the input and output message. The presence of correct Action header is checked on the request and response message.
Port: ServiceInterface
Features:
An explicit wsaw:Action is specified on the input and output message. The presence of correct Action header is checked on the request and response message.
Port: ServiceInterface
Generated from testcases.xml using
testcases.xsl.
$Date: 2007-07-30 15:07:33 $
Copyright © 2006 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 andMember privacy statements.