[BYTEIO-WG] ByteIO Interoperability Fiesta

Mon Jul 23 15:02:41 CDT 2007

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:start-offset>
    <rbyteio:bytes-per-block> 6 </rbyteio:bytes-per-block>
    <rbyteio:num-blocks> 1 </rbyteio:num-blocks>
    <rbyteio:stride> 0 </rbyteio:stride>
    <rbyteio:transfer-information transfer-mechanism=
"http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple"/>
</rbyteio:read>
  _____  

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:start-offset>
    <rbyteio:bytes-per-block> 6 </rbyteio:bytes-per-block>
    <rbyteio:stride> 0 </rbyteio:stride>
    <rbyteio:transfer-information transfer-mechanism=
"http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple">
        <byteio:data> KysrKysr </byteio:data>
    </rbyteio:transfer-information>
</rbyteio:write>

*	5.3.1 The client MUST use "KysrKysr" as value for
sbyteio:seekWrite/sbyteio:transfer-information 

<sbyteio:seekWrite>
    <sbyteio:offset> 20 </sbyteio:offset>
    <sbyteio:seek-origin>

http://schemas.ggf.org/byteio/2005/10/streamable-access/seek-origins/beginni
ng
    </sbyteio:seek-origin>
    <sbyteio:transfer-information transfer-mechanism=
"http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple">
        <byteio:data> KysrKys= </byteio:data> 
    </sbyteio:transfer-information>
</sbyteio:seekWrite> 
  _____  

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>
    <rbyteio:transfer-information transfer-mechanism=
"http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple"> 
        MTExMjEzMTQxNTE2
    </rbyteio:transfer-information>
</rbyteio:readResponse>

but it MUST read: 

<rbyteio:readResponse>
    <rbyteio:transfer-information
transfer-mechanism="http://schemas.ggf.org/byteio/2005/10/transfer-mechanism
s/simple"> 
        <byteio:data>MTExMjEzMTQxNTE2</byteio:data>
    </rbyteio:transfer-information>
</rbyteio:readResponse>

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>
    <rbyteio:transfer-information
transfer-mechanism="http://schemas.ggf.org/byteio/2005/10/transfer-mechanism
s/simple"> 
        <byteio:data> MTExMjEzMTQxNTE2 </byteio:data>
    </rbyteio:transfer-information>
</rbyteio:readResponse>

*	4.3 Read Operation Response (ii) 

<rbyteio:readResponse>
    <rbyteio:transfer-information transfer-mechanism=
"http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple">
        <byteio:data> MDIwNDA2MDgxMA==  </byteio:data> 
    </rbyteio:transfer-information>
</rbyteio:readResponse>

*	4.4 Read Operation Response (ii) 

<rbyteio:readResponse>
    <rbyteio:transfer-information transfer-mechanism=
"http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple">
        <byteio:data> MDEwMjAzMDQwNTA2MDQwNTA2MDcwODA5 </byteio:data>
    </rbyteio:transfer-information>
</rbyteio:readResponse>

*	4.5.1 Write Operation Request (i) 

<rbyteio:write>
    <rbyteio:start-offset> 20 </rbyteio:start-offset>
    <rbyteio:bytes-per-block> 6 </rbyteio:bytes-per-block>
    <rbyteio:stride> 0 </rbyteio:stride>
    <rbyteio:transfer-information transfer-mechanism=
"http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple">
        <byteio:data> KysrKysr </byteio:data>
    </rbyteio:transfer-information>
</rbyteio:write> 

*	4.6.1 Write Operation Request (ii) 

<rbyteio:write>
    <rbyteio:start-offset> 22 </rbyteio:start-offset>
    <rbyteio:bytes-per-block> 2 </rbyteio:bytes-per-block>
    <rbyteio:stride> 4 </rbyteio:stride>
    <rbyteio:transfer-information transfer-mechanism=
"http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple">
       <byteio:data>  KysrKysrKysrKw== </byteio:data>
    </rbyteio:transfer-information>
</rbyteio:write> 

*	4.7.1 Write Operation Request (iii) 

<rbyteio:write>
    <rbyteio:start-offset> 0 </rbyteio:start-offset>
    <rbyteio:bytes-per-block> 6 </rbyteio:bytes-per-block>
    <rbyteio:stride> 3 </rbyteio:stride>
    <rbyteio:transfer-information transfer-mechanism=
"http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple">
        <byteio:data> Pz8/Pz8/KysrKysr </byteio:data> 
    </rbyteio:transfer-information>
</rbyteio:write> 

*	4.8.1 Append Operation Request 

<rbyteio:append>
    <rbyteio:transfer-information transfer-mechanism=
"http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple">
        <byteio:data> KysrKysr </byteio:data> 
    </rbyteio:transfer-information>
</rbyteio:append> 

*	4.9.1 TruncAppend Operation Request 

<rbyteio:truncAppend>
    <rbyteio:offset> 30 </rbyteio:offset>
    <rbyteio:transfer-information transfer-mechanism=
"http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple">
        <byteio:data> KysrKysr </byteio:data>
    </rbyteio:transfer-information>
</rbyteio:truncAppend> 

} 

*	5.2 SeekRead Operation Response 

<sbyteio:seekReadResponse>
    <sbyteio:transfer-information transfer-mechanism=
"http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple"> 
        <byteio:data> MTExMjEzMTQxNTE2 </byteio:data>
    </sbyteio:transfer-information>
</sbyteio:seekReadResponse>
  _____  

  _____  

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/byteio-wg/attachments/20070723/fb57d2ff/attachment.html 