Hello All,
Once again I am emailing everyone what I just posted on the Wiki regarding
some issues with the Interop documentation. I deleted the issues I posted
previously that do not apply to the current documentation.
Also, I wanted to bring an issue to everyone's attention:
There is a potential race condition brought on by the fact that the
ByteIOInterop factory port type's DeleteResource operation is defined as a
one-way message.
-Karolina
Wiki Update:
ByteIO Interoperability Testing Scenarios Document Issues and Corrections
This section lists issues in v.12 of the ByteIO Interoperability Testing
Scenarios document and presents corrections. The issues are listed in the
order that they appear in the document and reference the specific
sections/pages they refer to.
_____
Incorrect Blocks-per-Byte in SOAP Example
(4.2) rbyteio:read operation (i)
The non-normative example of the SOAP elements in the body of the request
message does not match the specifications of test 4.2. The required
bytes-per-block is 12 not 6. The SOAP body of the requet message should be
as follows:
rbyteio:read
rbyteio:start-offset 20
rbyteio:bytes-per-block 6
rbyteio:num-blocks 1
rbyteio:stride 0
http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple"/>
_____
Incorrect Write Value of Transfer-Information
(4.5) rbyteio:write operation (i) (5.3.1) sbyteio:seekWrite operation'
"KysrKysr" is the value that corresponds to writing a block of bytes
equivalent to "++++++". This value is incorrectly given as "KysrKys=" in
Section 4.5 and 5.3.1. The corrected SOAP request messages follow:
* 4.5 The client MUST use "KysrKysr" as value for
rbyteio:write/rbyteio:transfer-information
rbyteio:write
rbyteio:start-offset 20
rbyteio:bytes-per-block 6
rbyteio:stride 0
http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple">
byteio:data KysrKysr
* 5.3.1 The client MUST use "KysrKysr" as value for
sbyteio:seekWrite/sbyteio:transfer-information
sbyteio:seekWrite
sbyteio:offset 20
sbyteio:seek-origin
http://schemas.ggf.org/byteio/2005/10/streamable-access/seek-origins/beginni
ng
http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple">
byteio:data KysrKys=
_____
Wrong Treatment of Transfer-Information-Type XML element throughout Document
The Interoperability Testing Specification repeatedly and consistently uses
wrong "transfer-information-type" XML elements in both sample XML fragments,
and in its interoperability requirements.
For example, the document gives as sample SOAP fragment:
rbyteio:readResponse
http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple">
MTExMjEzMTQxNTE2
but it MUST read:
rbyteio:readResponse
http://schemas.ggf.org/byteio/2005/10/transfer-mechanism
s/simple">
byteio:dataMTExMjEzMTQxNTE2
This mistake is spread all over the document.
Per Appendix C of the ByteIO Recomendation Document
<https://forge.gridforum.org/sf/docman/do/downloadDocument/projects.byteio-w
g/docman.root.current_documents/doc14668/1> , a byteio:data tag should
surround data being passed. This applies to response messages of read
operations and request messages of write operations. (Request messages of
read operations and response messages of write operations should not contain
data.)
The corrected SOAP body messages of the affected tests are listed below:
* 4.2 Read Operation Response (i)
rbyteio:readResponse
http://schemas.ggf.org/byteio/2005/10/transfer-mechanism
s/simple">
byteio:data MTExMjEzMTQxNTE2
* 4.3 Read Operation Response (ii)
rbyteio:readResponse
http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple">
byteio:data MDIwNDA2MDgxMA==
* 4.4 Read Operation Response (ii)
rbyteio:readResponse
http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple">
byteio:data MDEwMjAzMDQwNTA2MDQwNTA2MDcwODA5
* 4.5.1 Write Operation Request (i)
rbyteio:write
rbyteio:start-offset 20
rbyteio:bytes-per-block 6
rbyteio:stride 0
http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple">
byteio:data KysrKysr
* 4.6.1 Write Operation Request (ii)
rbyteio:write
rbyteio:start-offset 22
rbyteio:bytes-per-block 2
rbyteio:stride 4
http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple">
byteio:data KysrKysrKysrKw==
* 4.7.1 Write Operation Request (iii)
rbyteio:write
rbyteio:start-offset 0
rbyteio:bytes-per-block 6
rbyteio:stride 3
http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple">
byteio:data Pz8/Pz8/KysrKysr
* 4.8.1 Append Operation Request
rbyteio:append
http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple">
byteio:data KysrKysr
* 4.9.1 TruncAppend Operation Request
rbyteio:truncAppend
rbyteio:offset 30
http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple">
byteio:data KysrKysr
}
* 5.2 SeekRead Operation Response
sbyteio:seekReadResponse
http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple">
byteio:data MTExMjEzMTQxNTE2
_____
_____
Discussion
This section lists issues that need to be discussed to resolve ambiguity for
the Interoperability Fiesta.
_____
ByteIO Interop Port Type, DeleteResource, and Race Conditions
Per Appendix A of the ByteIO Interoperability Testing Scenarios
<https://forge.gridforum.org/sf/docman/do/downloadDocument/projects.byteio-w
g/docman.root.current_documents/doc14667/1> , the ByteIOInterop::PortType
defines the DeleteResource operation as a one-way message. This results in a
race condition if a resource is deleted and then tested for successful
deletion.
