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.

This document, part of a document series, produced by the OCCI working group within the Open Grid Forum (OGF), provides a high-level definition of a Protocol and API. The document is based upon previously gathered requirements and focuses on the scope of important capabilities required to support modern service offerings.

This document, part of a document series, produced by the OCCIâ„¢ working group within the Open Grid Forum (OGF), provides a high-level definition of a Protocol and API. The document is based upon previously gathered requirements and focuses on the scope of important capabilities required to support modern service offerings.

This document, part of a document series, produced by the OCCIâ„¢ working group within the Open Grid Forum (OGF), provides a high-level definition of a Protocol and API. The document is based upon previously gathered requirements and focuses on the scope of important capabilities required to support modern service offerings.

This document specifies a Message API extension to the Simple API for Grid Applications (SAGA), a high level, application-oriented API for grid application development. This Message API is motivated by a number of use cases collected by the OGF SAGA Research Group in GFD.70, and by requirements derived from these use cases, as specified in GFD.71). The API provides a wide set of communication pattern, and targets widely distributed, loosely coupled, heterogeneous applications.

This document specifies an Advert API extension to the Simple API for Grid Applications (SAGA), a high level, application-oriented API for grid application development. This Advert API is motivated by a number of use cases collected by the OGF SAGA Research Group in GFD.70, and by requirements derived from these use cases, as specified in GFD.71). It allows to persistently store application specific meta data in a name space hierarchy, along with serialized saga::object instances.

This document provides a definition of a standard Data Format Description Language (DFDL). This language allows description of dense binary and legacy data formats in a vendor-neutral declarative manner. DFDL is an extension to the XML Schema Description Language (XSDL).

In their 2002 book, “Distributed Systems: Principles and Paradigms�, Andrew Tannenbaum and Martin van Steen describe in great detail the properties, function, and benefit of naming schemes in distributed systems. Specifically, they describe a typical three-layer naming scheme whereby human readable names map to location-independent names or identifiers, which in turn map to location-dependent addresses. This three-tiered approach is instrumental in providing both usability for clients, as well as many of the classic distributed systems “transparencies� like fault and location transparency. WS-Naming provides the mapping between location-independent names (in the form of EndpointIdentifiers) and location-dependent addresses (i.e., WS-Addressing EPRs). In this specification we describe the Resource Namespace Service (RNS), a grid port type that allows clients to manipulate and retrieve mappings from human-readable strings to WS-Addressing Endpoint Reference Types , thus providing the higher level mapping described by Tannenbaum and van Steen.

In their 2002 book, “Distributed Systems: Principles and Paradigms�, Andrew Tannenbaum and Martin van Steen describe in great detail the properties, function, and benefit of naming schemes in distributed systems. Specifically, they describe a typical three-layer naming scheme whereby human readable names map to location-independent names or identifiers, which in turn map to location-dependent addresses. This three-tiered approach is instrumental in providing both usability for clients, as well as many of the classic distributed systems “transparencies� like fault and location transparency. WS-Naming provides the mapping between location-independent names (in the form of EndpointIdentifiers) and location-dependent addresses (i.e., WS-Addressing EPRs). In this specification we describe the Resource Namespace Service (RNS), a grid port type that allows clients to manipulate and retrieve mappings from human-readable strings to WS-Addressing Endpoint Reference Types , thus providing the higher level mapping described by Tannenbaum and van Steen.

The purpose of this document is to specify a protocol for accessing a Policy Decision Point (PDP) by a Grid Policy Enforcement Point (PEP) in order to obtain access control decisions containing obligations. The protocol is a profile of the SAML2.0 profile of XACMLv2 request/response contexts, tailored especially for grid use.

This document presents a specification for an authorization credential retrieval protocol based on the use of the Security Assertion Markup Language (SAML) and protocol as a format for requesting and retrieving attribute assertions.

This document provides a protocol for an authorization component to access an external credential validation service (CVS) prior to calling a policy decision point (PDP). The protocol is a profile of a SAML attribute assertion carried by WS-Trust.

This document defines the Advanced Filter extension – an alternative to the Basic Filter element described in the HPC Basic Profile 1.0 specification. The Basic Filter provides only an ‘on’ or ‘off’ approach to returning information about the activities or resources operating within the Basic Execution Service container. The Advanced Filter extension provides more flexibility to the client in returning information from an HPC Basic Profile complaint endpoint.

This document specifies the syntax and semantics of the proposed Parameter Sweep extension to the Job Submission Description Language (JSDL) 1.0 [JSDL]. The syntax and semantics defined in this document provide an alternative to explicitly submitting thousands of individual JSDL job submissions of the same base job template, except with a different set of parameters for each.

The GLUE specification is an information model for Grid entities described using the natural language and UML Class Diagrams. As a conceptual model, it is designed to be independent from the concrete data models adopted for its implementation. Rendering to concrete data models such XML Schema, LDAP Schema and SQL are provided in a separate document.

This document species a Service Discovery API extension to the Simple API
for Grid Applications (SAGA), a high level, application-oriented API for grid
application development. This Service Discovery API is motivated by a number
of Use Cases collected by the OGF SAGA Research Group in GFD.70 [4], and
by requirements derived from these Use Cases, as specied in GFD.71 [5]). It
allows users to nd services with minimal prior knowledge of the grid or grids
they plan to use.

An OGSA basic profile is a profile in the style of WS-Interoperability (WS I) that defines recommended usage of infrastructure-level standards for Grid scenarios. OGSA services are expected to use one such profile for each infrastructure capability needed. This document defines such a basic profile for security by bringing together two general, non-OGSA specific, profiles on secure addressing and secure communication.
This profile can be composed with other basic profiles. In particular this profile satisfies the security requirements of the WSRF Basic Profile 1.0 and can be composed with it.

This document specifies the semantics and structure of the Job Submission Description Lan-guage (JSDL). JSDL is used to describe the requirements of computational jobs for submission to resources, particularly in Grid environments, though not restricted to the latter. The document includes the normative XML Schema for the JSDL, along with examples of JSDL documents based on this schema.

This document profiles the File staging capabilities of the Job Submission Description Language (JSDL) for use by HPC Basic Profile-compliance services. It includes clarifications, refinements, interpretations and amplifications of JSDL which promote interoperability.

This document defines the HPC Basic Profile, consisting of a set of non-proprietary specifications, along with clarifications, refinements, interpretations and amplifications of those specifications which promote interoperability.

This document specifies the semantics and structure of the HPC Profile Application. The HPC Profile Application is an extension to JSDL 1.0 [JSDL10] that is used to describe an executable running as an operating system process. The document includes the normative XML Schema for the HPC Profile Application, along with examples of documents based on this schema.

This document presents a specification for a Basic Execution Service (BES): a service to which clients can send requests to initiate, monitor, and manage computational activities. The specification defines an extensible state model for activities; an extensible information model for a BES and the activities that it creates; and two port-types; BES-Management and BES-Factory. BES-Management defines operations for managing the BES itself. BES-Factory defines operations for initiating, monitoring, and managing sets of activities, and for accessing information about the BES. An optional unspecified BES-Activity port-type indicates an extension point for operations relating to the monitoring and management of individual activities.

This document provides information to the grid community, proposing a standard for a WS-Disagreement protocol (WS-NO), to communicate disagreement messages between components, and also between humans.

This document specifies the core components for the Simple API for Grid Applications (SAGA Core API), a high level, application-oriented API for grid application development. The scope of this API is derived from the requirements specified in GFD.71 (�A Requirements Analysis for a Simple API for Grid Applications�). It will in the future be extended by additional API extensions.

In 2010/2011, a number of errata have been applied to this document. A complete changelog can be found in the appendix. Note that the API specified in this document version is thus labelled as version 1.1, and as such obsoletes the previous API version 1.0. Most changes should be backward compatible with the original specification (for details see changelog).

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, defines 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 data access interfaces for relational data resources, which extends interfaces defined in the “Web Services Data Access and Integration” document. The specification can be applied in regular web service environments or as part of a grid fabric.

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, defines consistent interfaces through web services to components of a 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 generic data interfaces developed by the Database Access and Integration Services (DAIS) Working Group that can be extended to support specific kinds of data resources, such as relational databases, XML repositories, RDF data sources, or files. Related specifications define how specific data resources and systems can be described and manipulated through such extensions. The specifications can be applied in regular web service environments or as part of a grid fabric.