The aim of this document is to provide an overview of best practices in on-demand provisioning of infrastructure services that includes both traditional Network Resources Provisioning Systems (NRPS) and emerging Cloud based infrastructure services. These provisioning processes must be both sufficiently explicit and flexible to dynamically instantiate complex task or project oriented infrastructures comprising of compute, storage, and application resources, as well network infrastructures interconnect them.

The proposed document summarises discussions among members of the OGF ISoD Research Group and aims to facilitate conversations on achieving interoperability, and effective use and development of modern and future infrastructure services provisioning systems.

This document describes a set of normative schemas which allow the description of computer network topologies.

The goal of the Authorization Interoperability activity is providing interoperability between middleware and authorization infrastructures. This is achieved by designing and implementing an authorization protocol common to OSG VO services, EGEE, Globus, and Condor. This protocol is based on the SAML profile of XACML v2.0 [XACML]. The C library that implements the profile is provided by the Globus Toolkit security group; the JAVA library by the SWITCH group of EGEE.

The authorization protocol is used by Policy Enforcement Points (PEP), i.e. resource gateways, to interact with Policy Decision Points (PDP), i.e. repository of authorization policies. For each access request, the PDP informs the PEP on whether access is granted or denied and the conditions to be enforced if access if granted. These conditions are expressed in the form of XACML Obligations and are the mechanism to restrict privileges at Grid resources.

For resources to be shared, sites must be able to exchange basic accounting and usage data in a common format. This document describes a common format which enables the exchange of basic accounting and usage data from different resources. This record format is intended to facilitate the sharing of usage information, particularly in the area of the accounting of jobs, computing, memory, storage and cloud usage but with a structure that allows an easy extension to other resources. This document describes the Usage Record components both in natural language form and annotated XML.

This document does not address how these records should be used, nor does it attempt to dictate the format in which the accounting records are stored. Instead, it defines a common exchange format. Furthermore, nothing is said regarding the communication mechanisms employed to exchange the records, i.e. transport layer, framing, authentication, integrity, etc.

The purpose of this document is to specify the syntax and semantics of the Activity Instance Description. An "activity", in this context, is a unit of work to be executed on a distributed system. It can be a job, a task, a data processing operation, a data access operation, an application execution, a program execution or a Web Service invocation. The Activity Instance Description captures the information related to this unit of work. Systems built based on this specification can provide a holistic view of an activity, for example for monitoring, auditing or checkpointing purposes. The specification pursues two different but complementary objectives: (i) it specifies a generic and extensible framework to capture the information related to an activity; and (ii) it specializes this generic framework using a number of Open Grid Forum specifications.

This document specifies the procedure to create Uniform Resource Names (URNs) in the urn:ogf:network namespace. URNs in this namespace can be used to define logical network resources, such a devices, (logical) ports, (logical) links, and topologies.

In this document the EU-project European Middleware Initiative (EMI) describes a storage accounting record (StAR), defined to reflect practical, financial and legal requirements of storage location, usage and space and data flow. The defined record might be the base for a standardized schema or an extension of an existing record like the OGF UR and this document is intended as information to be taken as input for incorporating storage resources into the OGF UR.

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.

This document provides a set of DFDL properties that can be used as defaults for creating DFDL schema.

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

URNs in the OGF namespace take the form urn:ogf:<snid>:<subnamespace-specific-string>.
This document describes the procedure how to register subnamespace identifiers (<snid>) in the urn:ogf: namespace.

This document defines the mapping from DFDL 1.0 Infoset to W3C XDM, and from W3C XDM to DFDL 1.0 infoset.

Relying Party Defined Namespace Constraints (RPDNC) are limitations on the subject namespace issued by X.509 certification authorities (CAs) that are defined and enforced by the end-point at the relying party side. As grid authentication based on X.509 credentials provides the subject DN as a handle that identifies the authenticated entity, the capability to ensure subject name uniqueness is of critical importance in ensuring overall integrity of the authentication system.

This document described the rationale and use cases for relying party defined name space constraints, and lists the set of desired features a policy language expressing such constraints should have.

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 provides a complete description of the VOMS AC format, both syntax and semantics. It also describes the related extensions that must be used in a proxy certificate to make it fully VOMS-compliant.

The Production Grid Infrastructure Working Group (PGI-WG) is elaborating documents permitting to improve interoperability of Production Grids.

The purpose of this ‘Glossary of Acronyms and Terms’ is to provide an expansion of acronyms and an unambiguous definition of terms used in the context of a Production Grid.

It is based on the ‘OGSA® Glossary of terms’ GFD.120, the ‘GLUE Specification v. 2.0’ GFD.147 and the PGI ‘Vocabulary’ Wiki page.

The root terms are ‘Data processing’, ‘Administrative domain’, ‘Trust’ and ‘Federation’.

It provides a minimum background information about Grids, but does NOT attempt to justify the definitions or the context in which they may be used. The reader is referred to external documents for further explanation where necessary.

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.

This document defines the detailed specifications and implementation requirements for the Inter-Domain Controller Protocol (IDCP). This document level of detail is intended to be sufficient to support independent implementation efforts.

This specification is provided to the OGF NSI Working Group as an informational document. The objective of this submission is to provide another example of a currently deployed protocol in this area, in case it is helpful to the ongoing NSI standardization efforts.

This protocol development work began as part of the DICE Control Plane Working Group. DICE is a collaboration amongst DANTE (GEANT), Internet2, CANARIE, ESnet, USLHCnet, and others. This protocol has been implemented and is currently deployed by ESnet, Internet2, GEANT AutoBAHN, USLHCnet, and others.

The IDCP defines a protocol and associated message formats that enable the dynamic provision of network resources across multiple administrative domains. The IDC architecture supports dynamic networking, the concept by which network resources (i.e. bandwidth, VLAN number, etc) are requested by end-users, automatically provisioned by software, and released when they are no longer needed. This is in contrast with the more traditional “static� networking where network configurations are manually made by network operators and usually stay in place for long periods of time.

The IDC protocol defines messages for reserving network resources, signaling resource provisioning, and gathering information about previously requested resources. These messages are defined in a SOAP web service format. This document and others relating to the IDCP are maintained at the IDCP Control Plane web site: www.controlplane.net.

Grids use X.509 certificates for authentication and authorization. These certificates are issued to subscribers that comprise a virtual organization, and are typically issued by Certification Authorities operated by real institutions. In order to ensure compliance with established policies and operational procedures, and to recommend necessary changes in controls, policies or procedures, these Certification Authorities (CAs) should be externally audited periodically. The International Grid Trust Federation (IGTF) has, based on templates established by OGF, established such sets of operational policies and procedures. This document provides an audit checklist which describes auditing items to be considered by CAs accredited by the IGTF to be compliant with the ‘Classic’ Authentication Profile, and provides the acceptable evidence for the verification of these items. Detailed processes of auditing are also described in this document which is intended as guidelines for auditing Grid CAs. Spread sheets of the check list for ‘Classic’, ‘Short Lived Credential Services (SLCS)’, and ‘Member Integrated Credential Services (MICS)’ profiles are provided as separate documents and available on the IGTF web site. This document as well as the spread sheets will be maintained and updated when there is a newer version of authentication profiles available than it refers.

This document is a result of the work of OGF RISGE-RG. It presents collection of use cases that covers various existing approaches in defining remote access interfaces to sophisticated laboratory equipment. One of the important aspect covered by these examples is an exploitation of Grid technologies for conducting and monitoring measurement tasks and experiments on complex remote scientific equipment.

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 NML-WG goal is to define a schema for describing topologies of hybrid networks. This schema is in first instance intended for:
* lightpath provisioning applications to exchange topology information intra and inter domain;
* reporting performance metrics.

This document constitutes Deliverable 1 of the working group. It provides a detailed overview of the framework in which the working group operates, detailing the already existing topology schemas and providing the basis for the integration of the various projects.

Web-based online communities such as blogs, forums and scientific communities have become important places for people to seek and share expertise. Search engines such as Google, Yahoo!, Live etc. are not yet capable to address queries that require deep semantic understanding of the query or the document. Instead, it may be preferable to find and ask someone who has related expertise or experience on a topic. Web-based online communities are the places people often seek advice or help. Before an analysis of search capabilities for these communities can be done, we need to gather the data (questions and answers, social support or discussion, comments or advice, content rating, social relations, and so forth) that describe the communities. There is no universal standard data structure for the outline of user participation in these communities. Also, as these communities rarely interoperate, each typically only has access to its own social data and cannot benefit from other communities’ data. Extracting, aggregating and analyzing data from these communities for finding experts on a single framework is a challenging task. In this document, we present a Grid-enabled framework of expertise search (GREFES) engine, which utilizes online communities as sources for experts on various topics. We suggest an open data structure called SNML (Social Network Markup Language) to outline user participation in online communities. The architecture addresses major challenges in crawling of community data and query processing by utilizing the computational power and high bandwidth inherently available in the Grid. Our framework supports open APIs for third party providers or developers to build new solutions in order to get more user feedback to improve the system.

The Database Access and Integration Services Working Group (DAIS-WG) has submitted three specifications to the Open Grid Forum (OGF) recommendation track [WS-DAI, WS-DAIR, WS-DAIX]. These specifications define a basic set of interfaces, properties and patterns for service-based access to data. The core WS-DAI specification outlines a set of generic interfaces and properties that are common to most types of data access. These may then be extended to access specific types of data. For instance, the WS-DAIR and WS-DAIX specifications extend the base specification to provide access to relational and XML types of data respectively.

This document outlines and motivates a further extension to the WS-DAI family of specifications to provide access to RDF(S) data. This will define a standard mechanism for accessing RDF(S) data in a manner consistent with the framework defined by the WS-DAI core specification. The main outcome of this work will be two specifications that provide complementary ways for accessing RDF(S) data: by using the W3C defined SPARQL query language or through the use of ontological primitives.

This document motivates this work by presenting an overview of the role of RDF(S) in a grid context with several motivational use cases.

This document is an informal description of Use Cases and requirements for the OCCI™ Cloud API. Created by the Open Cloud Computing Interface working group. This document records the needs of Infrastructure-as-a-Service Cloud computing managers and administrators in the form of Use Cases. The Use Cases serve as the primary guide for the development of API requirements. The document is the first deliverable to demonstrate and validate the features of the Open Cloud Computing Interface.

This document describes a multi-server based namespace data management system for Resource Namespace Service (RNS), which is introduced in GFD 101. In this system, RNS can be accessed through a master node, which provides the standard interfaces and functions defined in GFD 101. When the master node receives the RNS request, it will dispatch the request to one of the slave nodes based on load balancing policy. Every slave node stores a copy of the namespace data and responses to the read request, such as list and query functions, while only one slave node responses to the write request, such as add, update and remove function. There is a data synchronization process to keep the data consistence on all the slave nodes. In this method, even though one or more slave servers failed, the RNS can also provide stable service. This multi-server based namespace data management system can improve the availability and scalability of RNS.

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.

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 describes the various components that make up the authorization decision function of a Grid service provider. It looks at the different ways in which the various components can be combined together, and data flows between the components. This document is for informational purposes only and is not intended to form a grid standard.

This is an OGF informational document outlining the need for, and some possible approaches to developing, a Professional Grid Certification Program. It is aimed at the stakeholders who might be interested in developing such a certification programme, including potential employers of certified Grid professionals as well as the certification and training industries and middleware and technology providers.

The document outlines a possible structure of a Certification Program along with some options for how to develop and sustain such an effort. Finally, some possible future directions are outlined in the Future work section.

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 is a call to action, identifying issues and proposing a strategy in order to support and make progress in grid and e-Science education and training. Inevitably, it is neither complete nor definitive. The intention is that it will seed much greater efforts to further develop the understanding of requirements, to better characterise challenges and to propose specific strategies, curricula and collaborative efforts for international adoption. The ET-CG is already fostering other more specific work and documents that form elements of that development.

This document defines the types of OGF documents and the development and review processes for each type. This document obsoletes GFD.1 and replaces it as the description of OGF community practice surrounding the document series. The process reflects several years of experience with OGF document publication, and borrows heavily from the Internet Engineering Task Force Request for Comments document process.

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.

Grids in their current form of deployment and implementation have not been as successful as hoped in engendering distributed applications. Amongst other reasons, the level of detail that needs to be controlled for the successful development and deployment of applications remains too high. We argue that there is a need for higher levels of abstractions for current Grids. By introducing the relevant terminology, we try to understand Grids and Clouds as systems; we nd this leads to a natural role for the concept of Anity, and argue that this is a missing element in current Grids. Providing these anities and higher-level abstractions is consistent with the common concepts of Clouds. Thus this paper establishes how Clouds can be viewed as a logical and next higher-level abstraction from Grids.

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.

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.

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 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 requirements for construction and operation of grid systems. This document does not say “Grid Systems must satisfy these requirements�. It says “These requirements shall be considered when someone designs / constructs / operates on Grid Systems�

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.

This document describes the representation of the DRMAA 1.0 API in the Python programming language. It is based on the DRMAA 1.0 IDL recommendation (GFD-R-P.130), and maps the DRMAA IDL interface definition to specific Python language constructs.

This document describes and evaluates approaches and solutions for firewall issues, such as application level gateways, host based firewalls, VPN style gateways etc., which are currently available to solve some of the problems Grid applications may face when dealing with firewalls located between the source and the destination of their communication paths.

This document shows how specifications, that have been developed within and external to the Open Grid Forum, can be used to enable desktop access to distributed computing resources. Increasingly, Independent Software Vendors (ISVs) are developing applications that have two components – a graphical client that resides on the client and a compute intensive server compo-nent that can run on a ‘back-end’ compute cluster. Integrating these two components within net-works which frequently have firewalls and NATs, across different operating systems and software environments, provides many challenges. A standards based interface to this environment would provide ISVs with a solid foundation upon which to build their own applications.

We identify and describe a set of standards and specification that have been developed to facili-tate access to distributed computing resources. We illustrate how these specifications could en-able access to distributed computing resources through five scenarios. These range from simple job submission to a compute cluster where the client and the cluster have a common file system, to a client that stages files to and from the compute cluster while having bi-directional interaction between the application running on the compute cluster and the remote client.

By illustrating how these specifications can be applied to these scenarios we identify require-ments for both the middleware providers and the ISVs – recognizing that we are providing advice rather than rigid prescriptive solutions. Finally, we identify some open issues for discussion and feedback by the community relating to resource selection and security.

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

On February 28, 2008, as part of OGF22, the Open Grid Forum held Data Movement and Management Workshop. During the day-long meeting, speakers from research and industry described challenges in data movement and management and detailed some possible solutions. The goal was to look for common issues and points for collaboration among the OGF working group and with the Storage Networking Industry Association. The common theme that emerged was the challenge of metadata management. Both research centers and commercial enterprises are flooded with data and are struggling to provide useful access.

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.

Resources in a grid need to advertise their capabilities, and activities in a grid need to consume those resources. This architecture paper defines the way to model resources’ capabilities and requirements in OGSA grids. It builds on the wealth of existing systems management information already modeled and instantiated in systems today. Examples are included.

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

The Open Grid Forum (OGF) has embraced the Open Grid Services Architecture (OGSA) as the blueprint for standards-based grid computing. "Open" refers to the process used to develop standards that achieve interoperability. "Grid" is concerned with the integration, virtualization, and management of services and resources in a distributed, heterogeneous environment. It is "service-oriented" because it delivers functionality as loosely coupled, interacting services aligned with industry-accepted Web service standards. The “architecture� defines the components, their organizations and interactions, and the design philosophy used.

The purpose of this document is to provide an overview of the many interrelated recommendations and informational documents being produced by the OGSA and related working groups. Although, some documents are not OGSA specific, for example the "reference model," they have an important role within the OGSA concept and hence are explained in this document. This document also provides information regarding the intended completion dates of the documents in question, along with their dependencies on other OGSA and non-OGSA documents.

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.