OASIS Cloud Application Management for Platforms (CAMP) TC

Cloud Computing is a new paradigm where applications run on shared, managed platforms and containers. Certain details may be abstracted from the users, who then no longer have need for, expertise in, or control over, the physical infrastructure.

The different types of Cloud Computing are often classified as the following (see http://csrc.nist.gov/groups/SNS/cloud-computing/ for more complete definitions of these terms) although other flavors of Cloud Computing are possible.

• Software as a Service (SaaS), where users interact with the applications directly
• Platform as a Service (PaaS), where users manage the platform that applications are hosted on
• Infrastructure as a Service (IaaS), where users manage virtual machine instances with stacks of middleware supporting applications

The purpose of this TC is to define models, mechanisms and protocols for the management of applications in, and their use of, a Platform as a Service (PaaS) environment.

The focus of this TC is to develop an interoperable protocol for PaaS (self service) management interfaces for cloud users to use in developing, deploying and the administration of their applications. PaaS management should allow for, but not require, IaaS management to manage the deployment of resources for an application. If an IaaS infrastructure is used as an underlying, enabling technology, the IaaS API should not show through to the PaaS management interface.

The TC will define interfaces for self-service provisioning, monitoring and control. A standard interface for PaaS application management is expected to enable an ecosystem consisting of common tools, plugins, libraries and frameworks, which would remedy the current situation of bespoke interfaces for different vendor platforms that do not provide much vendor value-add.

The TC will accept as input the CAMP V1.0 Specification published on 29^th August 2012:

http://www.cloudspecs.org/CAMP/CAMP_v1-0.pdf

which can be found at

http://www.cloudspecs.org

The TC will refine this initial contribution to produce an OASIS Standard specification, including necessary supporting documentation in the form of Committee Notes.

Other contributions will be accepted for consideration without any prejudice or restrictions and evaluated based on technical merit in so far as they conform to this charter. Members with extensive experience and knowledge in these areas are particularly invited to participate.

The scope of the TC's work includes the following features and capabilities:

• Facilities to compose application assemblies from custom components as well as application-level services provided by the platform. Assemblies will run on a cloud PaaS platform.
• Allow components to be imported from libraries/repositories. Manage libraries/repositories
• Configure components and assemblies
• Register/deregister/start/stop/hibernate/snapshot assemblies
• Allow patching and versioning of applications and components
• Monitor components and assemblies for performance and failure
• Allow introspection of components and assemblies to discover capabilities and customization points.
• Provide facilities to keep track of usage for metering and billing
• Describe a platform-packaging format for applications and components that will allow portability across platforms, and allow framework-specific and/or language-specific extensions for transporting and deploying the application code.
• Allow for development of applications either in a standalone Application Development Environment (ADE) or as part of the platform offering.
• Definition and/or development of facilities and artifacts to support testing, such as test assertions, test scenarios and test suites, as the TC decides is appropriate.
• Define management interfaces for common, widely available platform services. The interface that these platform services offer to the application for the service's primary function (e.g. database search interface) is specifically out of scope.

  To further clarify this point an example follows:

  • The definition of management interfaces for a messaging service (e.g. Platform Components and Platform Component Templates that represent a messaging service).

This scope is further detailed by the input contribution.

Out of Scope

The following is a non-exhaustive list provided only for the sake of clarity.

The following items are specifically out of scope of the work of the TC:

• Definition of any application-level Cloud services (SaaS)
• Definition of any non-management interfaces to platform services including those used by the application to access the primary function of the service (such as posting a message to a message service bus).

  To further clarify this point an example follows:

  • The definition of a functional interface to a messaging service (e.g. a Ruby API for interacting with a messaging service using AMQP).
• Facilities and interfaces that are programming language-specific and/or platform-specific (e.g. .Net, Java EE).
• Mechanisms and interfaces to manage infrastructure resources (IaaS), although hooks to such interfaces may be defined.

Testing

Testing of the specification shall be performed in periodic plug fests.

The TC has the following set of deliverables:

• A Platform Management architecture and interface specification that includes a model for managing the lifecycle of applications and a protocol binding defined using REST and JSON.

  This is to be completed within 18 months after the initial TC meeting.

• For all deliverables, the group shall define concrete exit criteria as early as possible. The exit criteria must be met before the deliverable advances to OASIS Standard. At a minimum, at least two interoperating implementations of both clients and servers must be available that test the mandatory and optional features of the specification. (Note: optional features may be tested by different implementations that implement different set of optional features (in addition to the mandatory features) as long as pairwise coverage for each optional feature is covered. Each client and each server must be from different respective code bases.

  In order to achieve the 18-month deadline of the main deliverable, testing shall start within 6 months of the start of the TC.

Optionally, other relevant non-standards track deliverables, such as tutorials and primers.

Maintenance

The TC will engage in Maintenance Activities with respect to the OASIS Final Deliverables it produces.

The TC will collect issues raised against the deliverables and periodically process those issues. Issues that request or require new or enhanced functionality shall be marked as enhancement requests and set aside. Issues that result in the clarification or correction of the deliverables shall be processed as part of that deliverable's Maintenance Activity The group shall maintain a list of these adopted clarifications and shall periodically and at least once a year create a new OASIS Final Deliverable including these updates.

The TC will operate under the Non Assertion IPR mode as defined in the OASIS Intellectual Property Rights (IPR) Policy effective 15 October 2010.

The anticipated audience for this work includes:

• Vendors offering products designed to support cloud applications in a PaaS environment.
• Software architects and programmers, who design, write, integrate and deploy cloud applications using a PaaS architecture.
• Policy administrators who create and govern policy for services and applications in a PaaS environment.
• Vendors making products used to integrate applications and services (both hardware and software), such as ESBs.

TC business will be conducted in English. The output documents will be written in English.