FW: Proposed SOAP tests for implementation features 32.1-2, 38.1- 5, 53.1

-----Original Message-----
From: Paul Kulchenko [mailto:paulclinger@yahoo.com]
Sent: Tuesday, November 26, 2002 10:36 AM
To: Don Mullen; 'Henrik Frystyk Nielsen'; David Fallside; John Koropchak
Subject: Proposed SOAP tests for implementation features 32.1-2, 38.1-5,
53.1

Updated according to new SOAP1.2 Implementation Summary; several bugs
fixed.

> ACTION: PaulKul: Propose "get time" test for 32.1 and 32.2  [4]

(Feature 32.1) Support for SOAP Response Message Exchange Pattern
(non-RPC) can be verified using the following test.

method: getTime (non-RPC)

The Node A sends an HTTP GET request to Node C and Node C returns a
response that includes current time. An example of the request is:

GET /interop/doc/getTime HTTP/1.0

An example of the response is:

...
<m:time xmlns:m="http://soapinterop.org/">13:20:00-05:00</m:time>
...

(Feature 32.2) Support for SOAP Response Message Exchange Pattern
(RPC) can be verified using the following test.

method: getTime (RPC)

The Node A sends an HTTP GET request to Node C and Node C returns an
RPC response that includes current time. An example of the request
is:

GET /interop/rpc/getTime HTTP/1.0

An example of a response is:

...
<m:getTimeResponse xmlns:m="http://soapinterop.org/">
<r:result
xmlns:r="http://www.w3.org/2002/06/soap-rpc">return</r:result>
<return>13:20:00-05:00</return>
</m:getTimeResponse>
...

> ACTION: PaulKul: Find RPC test from R1 or R2 with two or more
> parameters that can be used to test 53.1 [6]

(Feature 53.1) Supports RPC invocation as structs where parameter
access is by name 

We use R2.echoSimpleTypesAsStruct [1] as the basis for the test as
follows:

The sample input is described in [1] as 

Input parameter name: inputString
Input parameter type: xsd:string
Input parameter name: inputInteger
Input parameter type: xsd:int
Input parameter name: inputFloat
Input parameter type: xsd:float

Instead of sending string, int, and float:

<m:echoSimpleTypesAsStruct xmlns:m="http://soapinterop.org/">
  <inputString>hello world</inputString>
  <inputInteger>42</inputInteger>
  <inputFloat>0.005</inputFloat>
</m:echoSimpleTypesAsStruct>

the Node A sends float, int, and string:

<m:echoSimpleTypesAsStruct xmlns:m="http://soapinterop.org/">
  <inputInteger>42</inputInteger>
  <inputFloat>0.005</inputFloat>
  <inputString>hello world</inputString>
</m:echoSimpleTypesAsStruct>

The result returned by Node C is struct as described in [1]:

<r:result xmlns:r="http://www.w3.org/2002/06/soap-rpc">
  <varInt>42</varInt>
  <varFloat>0.005</varFloat>
  <varString>hello world</varString>
</r:result>

> ACTION: paulK to identify which existing soapbldrs test will send a
> hdr in rpc context as the test for f59 [9]

We use R2.echoMeStringRequest test [2] with no modifications as the
basis for this assertion.

> ACTION: PaulKul: Match HTTP-based tests for VersionMismatch,
> MustUnderstand, Sender, Receiver, against R1-R4 and produce new
> test for DataEncodingUnknown [10]

(Feature 38.1) VersionMismatch

We use R1.echoVoid test [3] with SOAP1.1 request message as the basis
for this assertion. The node returns a fault with a value of
env:VersionMismatch for Code and an HTTP status code with a value of
500 Server Error.

(Feature 38.2) MustUnderstand

We use R2.echoMeUnknown test [4] as the basis for this assertion. The
Node A sends request to a Node C that includes header that is unknown
to that SOAP node:

<env:Header>
  <h:echoMeUnknown xmlns:h="http://unknown/"
env:role="http://www.w3.org/2002/06/soap-envelope/role/next"
env:mustUnderstand="1">nobody understands me!</h:echoMeUnknown>
</env:Header>

The Node C returns a fault with a value of env:MustUnderstand for
Code and an HTTP status code with a value of 500 Server Error.

(Feature 38.3) Sender

We use R1.echoInteger test [5] as the basis for this assertion.
Instead of sending a proper integer value the Node A sends string
instead:

<m:echoInteger xmlns:m="http://soapinterop.org/">
  <inputInteger>ouch!</inputInteger>
</m:echoInteger>

The Node C returns a fault with a value env:Sender for Code, a value
of rpc:BadArguments for Subcode, and an HTTP status code with a value
of 400 Bad Method.
(not all implementations generate fault under these circumstances;
maybe be need to design a better test)

(Feature 38.4) Receiver

We use R1.echoString test [6] as the basis for this assertion. The
Node A sends at least 1Gb of data (the sample message is not
included). The Node C returns (if possible) a fault with a value of
env:Receiver for Code and an HTTP status code with a value of 500
Server Error.

(Feature 38.5) DataEncodingUnknown

From the spec:
"A fault with a Value of "env:DataEncodingUnknown" for Code SHOULD be
generated when the arguments are encoded in a data encoding unknown
to the receiver."

What is "data encoding" in this context?

Comments?

Best wishes, Paul.

[1]
http://www.whitemesa.com/interop/proposalB.html#echoSimpleTypesAsStruct

[2]
http://www.whitemesa.com/interop/proposalC.html#echoMeHeaderString

[3] http://www.whitemesa.com/interop/proposal2.html#echoVoid

[4] http://www.whitemesa.com/interop/proposalC.html#echoMeUnknown

[5] http://www.whitemesa.com/interop/proposal2.html#echoInteger

[6] http://www.whitemesa.com/interop/proposal2.html#echoString




__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Received on Tuesday, 26 November 2002 10:52:11 UTC