This document describe experience gained while implementing the Smoa Computing Service, a component which development was steered by the following OGF specifications:
* GFD 108 - OGSA® Basic Execution Service Version 1.0
* GFD.114 - HPC Basic Profile, Version 1.0
* GFD.135 - HPC File Staging Profile, Version 1.0
In addition to comments on those specifications, this document presents possible extension to the Basic Execution Service: a separate interface for managing Advance Reservations based on the BES-Factory port.

The SAGA Core API (or short, SAGA API) has been implemented by a vari- ety of groups, in different languages. As the SAGA API specification itself is language neutral (it specifies the API in SIDL), it is difficult to define interop- erability between these implementations, in the conventional sense. That is left to later experience reports addressing specific language bindings.

This report rather will show that (a) the SAGA API can be mapped to various programming languages, without losing any functionality, and (b) that these im- plementations can provide the required semantics for a wide variety of grid (and non-grid) backends. We consider those properties as necessary and sufficient to promote the proposed SAGA API specification (P-REC) to full recommendation status (REC).

This document describes the implementation experiences of independent implementations of WS-Agreement along with an overview of the projects that have implemented WS-Agreement so far. It also presents the features of WS-Agreement used by 8 of the implementations. Finally, the document contains information on set-up and results of an experiment where two independent implementations of WS-Agreement were used to mutually exchange templates describing jobs and create agreements.

This document describes experience in building an INFOD system from the specification document. It also includes changes that should be included in a new version of an INFOD specification.

The Data Access and Integration Services (DAIS) Working Group have defined three proposed recommendations within the Open Grid Forum (OGF). The OGF process and requirements document (GFD.152) states that two independent interoperable implementations are required for a proposed recommendation to become a full OGF recommendation. This OGF experimental document reports on interoperability testing of two implementations of WS-DAIR (GFD.76) – one from the OGSA-DAI group at The University of Edinburgh and the other based on AMGA from KISTI. In addition, as the WS-DAIR proposed recommendation is an extension to WS-DAI (GFD.74), the testing process has encompassed both the WS-DAIR and WS-DAI proposed recommendations. The tests documented in this OGF experimental document establish that it is indeed possible to obtain client-based interoperability for these two implementations. However, as a result of this interoperation process a number of changes are recommended for the WS-DAI and WS-DAIR documents before they gain full recommendation status.

It is important to note that this document establishes a set of interoperability requirements between two or more implementations of the WS-DAI specifications, taking into account the criteria established in GFD.77. This document is not intended to establish a validation process to test the compliance of any particular implementation to any of the (proposed) DAIS recommendations.

A few groups have developed independent implementations of the Storage Resource Management (SRM) interface specification v2.2. This document describes those implementations and experiences in interoperability testing. Issues that were identified during the implementations of the specification and the production deplopyments of the implementations in various projects help develop more robust specification in the next version.

This document describes the experiences of interoperability testing of independent implementations of the OGSA WSRF Basic Profile 1.0, and the specifications that it incorporates by reference, namely Web Services Addressing 1.0 - Core, Web Services Resource Properties 1.2, Web Services Resource Lifetime 1.2, Web Service Base Faults 1.2, and Web Services Base Notification 1.3.

Many problems were encountered during the tests, largely related to schema errors, platform/tooling incapability, and specification issues. Despite this the tests proved in so much as they identified two issues in the OGSA WSRF Basic Profile and the WS-BaseNotifiation specifications. Solutions were proposed and were agreed by all implementers and original Profile authors.

This document reports about experiences made with running OGSA ByteIO working group interoperability test scenarios based on the ByteIO OGSA® WSRF Basic Profile Rendering 1.0 of the ByteIO Specification 1.0 as implemented by the four groups participating in the OGSA ByteIO Interoperability Fiesta. The four groups represented different implementation environments: Genesis II by the University of Virginia (UVa), UNICORE by Forschungszentrum Jülich, OGSA-DAI by EPCC, the University of Edinburgh (EPCC), and a clean-room implementation by Fujitsu Labs of Europe (FLE).

This document also remarks on the special considerations made to implement the OGSA ByteIO specifications on different Web Services and XML stacks. The main difficulties arise because of the way that different Web Services and XML tooling interprets particular elements. These arose not in the implementation of the ByteIO specification itself, but in the associated implementation required for the interoperability experiments.

This document describes the implementation and interoperability experiences of independent implementations of the Job Submission Description Language (JSDL) 1.0.

This document describes the experience of interoperability testing of independent implementa-tions of the High Performance Computing Basic Profile (HPCBP) and the specifications which it profiles, the Basic Execution Service (BES) and the Job Submission Description Language (JSDL).