The Production Grid Infrastructure (PGI) working group works on a well-defined set of standard profiles, and additional standard specifications if needed, for job and data management that are aligned with a Grid security and information model that addresses the needs of production Grid infrastructures. These needs have been identified in various international endeavors and are in many cases based on lessons learned obtained from the numerous activities in the Grid Interoperation Now (GIN) community group. Therefore, PGI can be considered as a spin-off activity of the GIN group in order to feed back any experience of using early versions of open standards (e.g. BES, JSDL, SRM, GLUE2, UR, etc.) in Grid production setups to improve the standards wherever possible. This particular document is a survey of common use cases provided by different stakeholders of PGI profiles or standard specifications. Such stakeholders include production Grid and e-science infrastructures as well as technology providers. The goal of this document is to have a foundation for a set of important requirements to be addressed by the PGI set of profiles and/or specifications.

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.

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.

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).

The topology descriptions used at Internet2 are provided in an XML format for use in the Dynamic Circuit Network suite. The topology descriptions developed by the University of Amsterdam is the Network De- scription Language.

In August and September 2009 Jeroen van der Ham worked at Internet2 on the translation of topology descriptions. This report describes some of the findings in creating this translation.

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).

Version 1.0 of the Network Services Framework describes a framework to support the request and management of Network Services; it allows an application or network provider to request Network Services from other network providers. The framework covers the interface, protocols, agents and associated services. The Network Service Interface (NSI) is the interface between two software agents that communicate via the NSI protocol.

This document should be read in conjunction with each of the NSI Network Service informational documents and its counterpart protocol recommendation.

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.