Data resources play a significant role in many applications across multiple domains. Web services provide implementation neutral facilities for describing, invoking and orchestrating collections of networked resources. The OGF (Open Grid Forum) Open Grid Services Architecture (OGSA), and its associated specifications, define consistent interfaces through web services to components of the grid infrastructure. Both the web and grid communities stand to benefit from the provision of consistent and agreed web service interfaces for data resources and the systems that manage them.
This document presents a specification for a collection of querying interfaces for RDF(S) data resources, which extends interfaces defined in the Web Services Data Access and Integration document [WS-DAI]. It also presents interfaces for handling RDF graphs in RDF(S) data resources. This specification can be applied in regular web services environments or as part of a grid fabric.

This document describes the C language binding for the Distributed Resource Management Application API Version 2 (DRMAA). The intended audience for this specification are DRMAA Version 2 interface implementors.

Firewalls control traffic flows between internal and external communication partners. Mostly traffic from inside to outside is allowed, but traffic coming from outside must be explicitly configured. The rules which packets may traverse the firewall and which not are normally configured manually by firewall administrators. To speed up such kind of access list changes, it would be desirable to dynamically signal access requests and automatically change those access lists. Though some protocols are inspectable by firewalls already like FTP, SIP and H.323, a general protocol, which could be used for signaling dynamically required access rules, is not available until now.

This paper proposes a standard protocol, which would allow such signaling in a secure manner. Firewalls which have installed a corresponding inspection module could be configured automatically, which would ease the configuration of such systems a lot.

The proposed protocol (FiTP) can be used in two ways. First of all, a firewall aware of FiTP, could automatically allow connections signaled by authorized users. Secondly, an intermediate solution could be implemented, so that firewalls unaware of FiTP could be configured by the server process, which is the end point of the FiTP control connection. Via this approach a smooth transition would be possible. Installations having old firewall hard- and/or software could use the new protocol already, before installing a system which is FiTP enabled.

This document specifies an Information System Navigator API extension to the Simple API for Grid Applications (SAGA), a high level, application-oriented API for grid application development. This Information System Navigator API is motivated by a number of Use Cases collected by the OGF SAGA Research Group in GFD.70, and by requirements derived from those Use Cases, as specified in GFD.71. Though motivated by the need to allow users to find information about services additional to that available via the SAGA Service Discovery API it is not dependent upon the Service Discovery API and is applicable to any information system that can be mapped to an entity relationship model.

This document describes the Distributed Resource Management Application API Version 2 (DRMAA). It defines a generalized API to Distributed Resource Management (DRM) systems in order to facilitate the development of portable application programs and high-level libraries.

The intended audience for this specification are DRMAA language binding designers, DRM system vendors, high-level API designers and meta-scheduler architects. Application developers are expected to rely on product-specific documentation for the DRMAA API implementation in their particular DRM system.

This document describes the Web Services Agreement Negotiation Specification (WS-Agreement Negotiation), a Web Services protocol for negotiating agreement offers between two parties, such as between a service provider and a service consumer. An agreement offer negotiation may then result in the creation of an agreement using the WS-Agreement specification (published as GFD.192). WS-Agreement Negotiation can also be used to renegotiate an existing agreement.

WS-Agreement Negotiation provides an additional layer to create agreements with WS-Agreement. To achieve this, it defines an extensible XML language for specifying agreement offers and agreement templates. These templates are WS-Agreement-compliant and include a negotiation context and a set of negotiation constraints that are used for the negotiation. The specification includes all schemas required for the negotiation and the necessary port types.

All information for creating, managing, and monitoring an agreement is not described in this document but in the WS-Agreement specification.

This document describes Web Services Agreement Specification (WS-Agreement), a Web Services protocol for establishing agreement between two parties, such as between a service provider and consumer, using an extensible XML language for specifying the nature of the agreement, and agreement templates to facilitate discovery of compatible agreement parties. The specification consists of three parts which may be used in a composable manner: a schema for specifying an agreement, a schema for specifying an agreement template, and a set of port types and operations for managing agreement life-cycle, including creation, expiration, and monitoring of agreement states.

During almost three years after the publication as GFD.107 in May 2007 a number of typos and formatting problems have been reported. None of them was affecting the normative part of the specification. This document is a revised version of GFD.107, which fixes all typos in the descriptive part of the document. The changes have been implemented during the GRAAP sessions at OGF 28 in Munich. Oliver Wäldrich, Philipp Wieder and Wolfgang Ziegler have prepared this version of the document

A number of grid services aggregate data together in lists or maps as part of their inherent function. Consider RNS (the Resource Namespace Specification) which provides the means of mapping human readable names to resource endpoints. Also consider a grid queue or cluster management system that might both group together target or backend BESs (Basic Execution Services) as well as provide mechanisms for querying or manipulating lists of queued jobs. Numerous other examples exist. In both of these cases, it is unreasonable and inefficient to expect communication where the entire content of such a group is transferred in a single SOAP document. At the same time, given the potentially large and diverse spectrum of likely uses for which iteration might be ideal, a generic form of iteration is desirable – one for which iterable content is extensible.

A number of iteration service specifications exist already; in particular WS-Enumeration provides similar functionality. Unfortunately, WS-Enumeration is based off of an entirely different model of web service endpoint interaction then that of WSRF. While WSRF has adopted a notion of the “implied� target resource as identified by WS-Addressing information included in the request message's SOAP headers, WS-Enumeration uses a more service oriented, “token-in-the-soap-body� protocol. As such, in cases where grid service design is heavily influenced by and modeled after a WSRF pattern, WS-Enumeration is confusing and ungainly. In those cases, WS-Iterator provides the same functionality in a way that is more consistent with intended WSRF practices. For a more detailed description of why the existing WS-Enumeration specification is not suited to this task of WSRF-based iteration, please reference.

The Open Grid Services Architecture Data Movement Interface (OGSA-DMI) specification defines a standardized mechanism for moving data from a source to a destination. By abstracting this data transfer, the client complexity for moving data within a grid is greatly reduced. OGSA-DMI defines two port types for initiating, scheduling and managing data transfers from a given source to a specified destination. The source and destination are described through Data End Point References (DEPRs), a specialized form of a WS-Address.

The Open Grid Services Architecture Data Movement Interface Functional Specification 1.0 defines the abstract methods and attributes of the Data Transfer Factory (DTF) and the Data Transfer Instance (DTI) port types.

This document defines the normative WSDL interface for a plain (non-WSRF-based) Web Service rendering of the Functional Specification.

This document follows the document produced by the GridRPC-WG on GridRPC Model and API for End- User applications. This new document aims to complete the GridRPC API with Data Management mecha- nisms and API.

This document is not intended to provide features and capabilities for building data management middle- ware. Its goal is to complete the GridRPC set of functions and definitions to allow users to manipulate their data. The motivation for this document is to provide explicit functions to manipulate the exchange of data between users, components of a GridRPC platform and storage resources since (1) the size of the data used in Grid applications may be large and useless data transfers must be avoided; (2) data are not always stored on the client side but may be made available either on a storage resource or within the GridRPC platform. All functions in the API have been thought to be called by each part in a GridRPC platform (client, agent and server) if needed.