The Joint Task Force Transformation Initiative (JTFTI) is an Interagency Working Group working to produce a Unified Information Security Framework for the federal government. The JTFTI is made up of representatives from the Civil, Defense, and Intelligence Communities.
The Project Leader is Ron Ross of NIST.
The OASIS CAMP TC advances an interoperable protocol that cloud implementers can use to package and deploy their applications. CAMP defines interfaces for self-service provisioning, monitoring, and control. Based on REST, CAMP is expected to foster an ecosystem of common tools, plugins, libraries and frameworks, which will allow vendors to offer greater value-add.
Common CAMP use cases include:
For more information on CAMP, see the TC Charter.
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.
The Open Cloud Computing Interface (OCCI) is a RESTful Protocol and API for all kinds of management tasks. OCCI was originally initiated to create a remote management API for IaaS1 model-based services, allowing for the development of interoperable tools for common tasks including deployment, autonomic scaling and monitoring. It has since evolved into a flexible API with a strong focus on interoperability while still offering a high degree of extensibility. The current release of the Open Cloud Computing Interface is suitable to serve many other models in addition to IaaS, including PaaS and SaaS.
In order to be modular and extensible the current OCCI specification is released as a suite of complementary documents, which together form the complete specification. The documents are divided into four categories consisting of the OCCI Core, the OCCI Protocols, the OCCI Renderings and the OCCI Extensions.
The current specification consists of seven documents. This specification describes version 1.2 of OCCI and is backward compatible with 1.1.
This document defines the OCCI Infrastructure Compute resource template profile 1.1 (hereafter, “the Profile”), consisting of a set of well defined instances of the OCCI compute resource types. Section 1 introduces the Profile, and explains its relationships to other profiles. Section 2, "Profile Conformance," explains what it means to be conformant to the Profile.
Each subsequent section addresses a component of the Profile, and consists of two parts: an overview detailing the component specifications and their extensibility points, followed by subsections that address individual parts of the component specifications. Note that there is no relationship between the section numbers in this document and those in the referenced specifications.
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.
The Open Cloud Computing Interface (OCCI) is a RESTful Protocol and API for all kinds of management tasks. OCCI was originally initiated to create a remote management API for IaaS1 model-based services, allowing for the development of interoperable tools for common tasks including deployment, autonomic scaling and monitoring. It has since evolved into a flexible API with a strong focus on interoperability while still offering a high degree of extensibility. The current release of the Open Cloud Computing Interface is suitable to serve many other models in addition to IaaS, including PaaS and SaaS.
In order to be modular and extensible the current OCCI specification is released as a suite of complementary documents, which together form the complete specification. The documents are divided into four categories consisting of the OCCI Core, the OCCI Protocols, the OCCI Renderings and the OCCI Extensions.
The current specification consists of seven documents. This specification describes version 1.2 of OCCI and is backward compatible with 1.1.
This document provides a definition of a standard Data Format Description Language (DFDL). This language allows description of text, dense binary, and legacy data formats in a vendor- neutral declarative manner. DFDL is an extension to the XML Schema Description Language (XSDL).
DFDL is a language for describing data formats. A DFDL description allows data to be read from its native format and to be presented as an instance of an information set or indeed converted to the corresponding XML document. DFDL also allows data to be taken from an instance of an information set and written out to its native format.
DFDL achieves this by leveraging W3C XML Schema Definition Language (XSDL) 1.0.
An XML schema is written for the logical model of the data. The schema is augmented with special DFDL annotations. These annotations are used to describe the native representation of the data. This is an established approach that is already being used today in commercial systems.
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 implementors.
The Distributed Resource Management Application API Version 2 (DRMAA) specification defines an inter- face for tightly coupled, but still portable access to the majority of DRM systems. The scope is limited to job submission, job control, reservation management, and retrieval of job and machine monitoring information.
The DRMAA root specification describes the abstract API concepts and the behavioral rules of a compliant implementation, while this document standardizes the representation of API concepts in the C programming language.
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.
The Distributed Resource Management Application API Version 2 (DRMAA) specification defines an interface for tightly coupled, but still portable access to Distributed Resource Management (DRM) systems. The scope is limited to job submission, job control, reservation management, and retrieval of job and machine monitoring information.
This document acts as root specification for the abstract API concepts and the behavioral rules of a DRMAA- compliant implementation. The programming language representation of the API is defined by a separate language binding specification.
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.
The goal of WS-Agreement is to standardize the terminology, concepts, overall agreement structure with types of agreement terms, agreement template with creation constraints and a set of port types and operations for creation, expiration and monitoring of agreements, including WSDL needed to express the message exchanges and resources needed to express the state.
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.
This document defines the artifacts and APIs that need to be offered by a Platform as a Service (PaaS) cloud to manage the building, running, administration, monitoring and patching of applications in the cloud. Its purpose is to enable interoperability among self-service interfaces to PaaS clouds by defining artifacts and formats that can be used with any conforming cloud and enable independent vendors to create tools and services that interact with any conforming cloud using the defined interfaces. Cloud vendors can use these interfaces to develop new PaaS offerings that will interact with independently developed tools and components.
This document defines the artifacts and APIs that need to be offered by a Platform as a Service (PaaS) cloud to manage the building, running, administration, monitoring and patching of applications in the cloud. Its purpose is to enable interoperability among self-service interfaces to PaaS clouds by defining artifacts and formats that can be used with any conforming cloud and enable independent vendors to create tools and services that interact with any conforming cloud using the defined interfaces. Cloud vendors can use these interfaces to develop new PaaS offerings that will interact with independently developed tools and components.
The following is a non-exhaustive list of the use cases which are supported by this specification.
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.
The Open Cloud Computing Interface (OCCI) is a RESTful Protocol and API for all kinds of management tasks. OCCI was originally initiated to create a remote management API for IaaS1 model-based services, allowing for the development of interoperable tools for common tasks including deployment, autonomic scaling and monitoring. It has since evolved into a flexible API with a strong focus on interoperability while still offering a high degree of extensibility. The current release of the Open Cloud Computing Interface is suitable to serve many other models in addition to IaaS, including PaaS and SaaS.
In order to be modular and extensible the current OCCI specification is released as a suite of complementary documents, which together form the complete specification. The documents are divided into four categories consisting of the OCCI Core, the OCCI Protocols, the OCCI Renderings and the OCCI Extensions.
The current specification consists of seven documents. This specification describes version 1.2 of OCCI and is backward compatible with 1.1.
This document specifies the OCCI HTTP Protocol, a RESTful protocol for communication between OCCI server and OCCI client. The OCCI HTTP Protocol support multiple different data formats as payload. Data formats are specified in separate documents.
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.
The Open Cloud Computing Interface (OCCI) is a RESTful Protocol and API for all kinds of management tasks. OCCI was originally initiated to create a remote management API for IaaS1 model-based services, allowing for the development of interoperable tools for common tasks including deployment, autonomic scaling and monitoring. It has since evolved into a flexible API with a strong focus on interoperability while still offering a high degree of extensibility. The current release of the Open Cloud Computing Interface is suitable to serve many other models in addition to IaaS, including PaaS and SaaS.
In order to be modular and extensible the current OCCI specification is released as a suite of complementary documents, which together form the complete specification. The documents are divided into four categories consisting of the OCCI Core, the OCCI Protocols, the OCCI Renderings and the OCCI Extensions.
The current specification consists of seven documents. This specification describes version 1.2 of OCCI and is backward compatible with 1.1.
The OCCI Infrastructure document details how an OCCI implementation can model and implement an Infrastructure as a Service API offering by utilizing the OCCI Core Model. This API allows for the creation and management of typical resources associated with an IaaS service, for example, creating a Compute instance and Storage instance and then linking them with StorageLink. The main infrastructure types defined within OCCI Infrastructure are:
