1. © 2006 Open Grid Forum DAIS-WG Status Report Implementations and Interoperability Testing Steven Lynden AIST

2. 2 OGF IPR Policies Apply “ I acknowledge that participation in this meeting is subject to the OGF Intellectual Property Policy. ” Intellectual Property Notices Note Well: All statements related to the activities of the OGF and addressed to the OGF are subject to all provisions of Appendix B of GFD-C.1, which grants to the OGF and its participants certain licenses and rights in such statements. Such statements include verbal statements in OGF meetings, as well as written and electronic communications made at any time or place, which are addressed to: – the OGF plenary session, – any OGF working group or portion thereof, – the OGF Board of Directors, the GFSG, or any member thereof on behalf of the OGF, – the ADCOM, or any member thereof on behalf of the ADCOM, – any OGF mailing list, including any group list, or any other list functioning under OGF auspices, – the OGF Editor or the document authoring and review process Statements made outside of a OGF meeting, mailing list or other function, that are clearly not intended to be input to an OGF activity, group or function, are not subject to these provisions. Excerpt from Appendix B of GFD-C.1: ” Where the OGF knows of rights, or claimed rights, the OGF secretariat shall attempt to obtain from the claimant of such rights, a written assurance that upon approval by the GFSG of the relevant OGF document(s), any party will be able to obtain the right to implement, use and distribute the technology or works when implementing, using or distributing technology based upon the specific specification(s) under openly specified, reasonable, non- discriminatory terms. The working group or research group proposing the use of the technology with respect to which the proprietary rights are claimed may assist the OGF secretariat in this effort. The results of this procedure shall not affect advancement of document, except that the GFSG may defer approval where a delay may facilitate the obtaining of such assurances. The results will, however, be recorded by the OGF Secretariat, and made available. The GFSG may also direct that a summary of the results be included in any GFD published containing the specification. ” OGF Intellectual Property Policies are adapted from the IETF Intellectual Property Policies that support the Internet Standards Process.

3. 3 Full Copyright Notice Copyright (C) Open Grid Forum (2006-2007). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. The limited permissions granted above are perpetual and will not be revoked by the OGF or its successors or assignees.

4. Current implementations of WS- DAI specifications http://www.admire-project.eu/ WS-DAIRWS-DAIXWS-DAI-RDF Querying WS-DAI-RDF Ontology UPM OGSA-DAI Glite- AMGA planned Interop completed

5. WS-DAIR Interoperability Testing DAIS-WG Interoperability testing approach published in 2006 (GFD-77)  Defines method used and how to apply to WS-DAI, WS- DAIR and WS-DAIX WS-DAI and WS-DAIR testing started in early 2009  KISTI (AMGA project) and OMII-UK (OGSA-DAI project) were involved  Experiences document currently in public comment WS-DAI and WS-DAIR Implementations - Experimental Document. S. Lynden, M. Antonioletti, M. Jackson, S. Ahn http://www.ogf.org/gf/docs/?public_comment 5

6. Background WS-DAI  Core properties –Readable, writable, transaction support etc.  Common port-types and operations –List resources, retrieve properties, generic querying  Common Faults –Not authorized, invalid expression, service busy etc. WS-DAIR  Extends WS-DAI (a WS-DAI realization)  Relational data resource properties –e.g. Schema description  Relational data resource port-types and operations –e.g. SQL execute  Relational data resource faults –e.g. Invalid SQL expression parameter fault 6

7. Implementations Description of implementations provided by: Mike Jackson, EPCC (OGSA-DAI) Sunil Ahn, KISTI (AMGA) 7

8. Testing process From [GFD77]  Test client interoperability –The implementations do not interact –Messages sent by a client produced the same desired behaviour in two implementations  Scope of testing –Some features are difficult to test  Their behaviour is difficult to replicate or trigger –Some features are optional  They may only present if the underlying infrastructure supports them –The testing process aspires to test every optional feature in one implementation and every mandatory feature in both implementations 8

9. Optional tests Some features of the specifications are optional, e.g  GenericQuery –Allows an unspecified query language to be sent to a WS-DAI service. –Difficult to test with implementations that only support SQL  Stored procedures –Only testable if the underlying database management system supports them 9

10. Features for which tests were not written PreferredTargetService parameter  The specification permits and implementation to ignore it DataResourceUnavailableFault The effects on the behaviour of the resource given different values of the following properties were ignored:  Readable/writeable  Transaction{Initiation/Isolation}  ParentSensitiveToChild  ChildSensitiveToParent The above features were considered to be out of scope for the testing process. 10

11. Implementation constraints Must use SOAP 1.1 The binding must be “document/literal” style Rationale  Consistent with ByteIO-WG’s interoperability testing process  Document/literal recommended elsewhere, e.g. OASIS 11

12. Test suite Test suite constructed consisting of 34 tests divided into optional/mandatory categories Implemented with soapUI (www.soapui.org)www.soapui.org  Allows SOAP messages to be sent and the responses validated URI for the test suite is published in the experiences document  Can be used to test future implementations to check they are interoperable 12

13. Results All tests for mandatory features were passed by both implementations Summary of optional features not tested 13 FeatureOGSA-DAIAMGA GenericQuery Not tested Stored procedures (6 tests) Not tested ServiceBusyFault Not tested SQLCommunications Area Not tested

14. ServiceBusyFault The only test result that doesn’t satisfy our criteria for validation A fault that can be generated when a service is busy an unable to execute a request  Wasn’t tested because both implementations support concurrency without an explicit limit Consistent with how other faults are defined  Potential impact of not testing it is low. May be of limited use depending on how implementations are constructed, but it was decided to keep it in the specification 14

15. Errata and clarifications Success of many of the tests is dependent on some modifications to the specification document  The conclusion in the experiences document is that if the modifications are made, the spec implementations were shown to be interoperable Minor errors in the specifications document were found in addition to parts of the text that needed clarification A comprehensive list is included in the experiences document 15

16. Significant recommended changes Introduce a DatasetToLarge fault  Recommended by the AMGA project Change DataResourceAddress to wsa:EndpointReference  JAXB incompatible with the WSDL, as discovered by the UPM and AIST WS-DAI-RDF implementations All other changes (nearly 50 of them!) are generally typos, clarifications or other bug fixes, e.g:  Clarify how items should be ordered in an SQLResultSet  Clarify that configuration properties are hints that can be ignored by the implementation  Remove ambiguity associated with the definition of some of the faults, such as InvalidExpressionFault 16

17. Conclusion We have two interoperable implementations of WS-DAIR. WS-DAIR extends WS-DAI, therefore we have two interoperable implementation of WS-DAI. Some changes to the specifications are required.  Mainly typos and clarifications  Some WSDL changes Document is in public comment  Awaiting comments before planning the next move  Comments would be very welcome 17

18. Future plans WS-DAIX  Currently we only have one implementation (OGSA-DAI) WS-DAI-RDF(S)  Querying –Plans exist to do interoperability testing (AIST and UPM)  Ontology –Much more complex specification than the others  Many more port-types and operations  Different approach –Split into three profiles –AIST and UPM have committed to implementing and testing the basic profile (profile 0) 18