A new OASIS technical committee is being formed. The OASIS Cloud Application Management for Platforms (CAMP) TC has been proposed by the members of OASIS listed in the charter below. The TC name, statement of purpose, scope, list of deliverables, audience, IPR mode and language specified in the proposal will constitute the TC’s official charter. Submissions of technology for consideration by the TC, and the beginning of technical discussions, may occur no sooner than the TC’s first meeting.
The eligibility requirements for becoming a participant in the TC at the first meeting are:
(a) you must be an employee or designee of an OASIS member organization or an individual member of OASIS, and
(b) you must join the Technical Committee, which members may do by using the “Join this TC” button on the TC’s home page at [a].
To be considered a voting member at the first meeting, you must:
(a) join the Technical Committee at least 7 days prior to the first meeting (on or before 16 October 2012); and
(b) you must attend the first meeting of the TC, at the time and date fixed below (23 October 2012).
Participants also may join the TC at a later time. OASIS and the TC welcomes all interested parties.
Non-OASIS members who wish to participate may contact us about joining OASIS [b]. In addition, the public may access the information resources maintained for each TC: a mail list archive, document repository and public comments facility, which will be linked from the TC’s public home page at [c].
Please feel free to forward this announcement to any other appropriate lists. OASIS is an open standards organization; we encourage your participation.
—–
[a] http://www.oasis-open.org/apps/org/workgroup/camp
[b] See http://www.oasis-open.org/join/
[c] http://www.oasis-open.org/committees/camp/
—
OASIS Cloud Application Management for Platforms (CAMP) Technical Committee Charter
(1) The Charter of the TC:
(1)(a) Name of the TC
OASIS Cloud Application Management for Platforms (CAMP) TC
(1)(b) Statement of purpose:
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.
(1)(c) Scope of work
The TC will accept as input the CAMP V1.0 Specification published on 29th 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.
(1)(d) A list of deliverables
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 Committee Specification. 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.
(1)(e) IPR Mode
The TC will operate under the Non Assertion IPR mode as defined in the OASIS Intellectual Property Rights (IPR) Policy effective 15 October 2010.
(1)(f) Anticipated Audience
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.
(1)(g) Language
TC business will be conducted in English. The output documents will be written in English.
(2) Non-normative information regarding the startup of the TC
(2)(a) Similar or Applicable Work
1. CAMP adopts Representational State Transfer (REST) principles for exposing and consuming resources services over Hypertext Transfer Protocol (HTTP) based systems. JSON is used for defining formats for representing data to/from the resources.
2. The DMTF Cloud Management Working Group is finishing up work on standardizing the model and interfaces for managing IaaS facilities in the Cloud [1].
3. The Open Grid Forum has produced a specification called Open Cloud Computing Interface [2], also for managing IaaS.
4. The Storage Networking Industry Association SNIA has produced the Cloud Data Management Interface (CDMI) [3], and has submitted it to JTC 1 for ISO standardization.
5. OASIS has an Identity in the Cloud Technical Committee [4] and recently started the OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC [5].
6. There is also a DMTF standard called Open Virtualization Format for packaging and distributing virtual appliances, or more generally software stacks, to be run in virtual machines [6].
7. The Open Data Center Alliance has recently published OCDA Usage Model: Platform as a Service (Paas) Interoperability Rev 1.0 [8]
8. A more complete list of cloud standards activities can be found on the Cloud Standards Wiki [7].
(2)(b) Date, Time, and Location of First Meeting
The first meeting of the CAMP TC will be a teleconference to be held on Tuesday 23rd October 2012, 8am to 9:30am Pacific Time. This teleconference will be sponsored by Oracle. A face-to-face meeting has been scheduled for Tuesday through Thursday 06-08 November, 2012 in the San Francisco Bay area.
(2)(c) On-Going Meeting Plans & Sponsors
It is anticipated that the CAMP TC will meet via teleconference every week for 90 minutes at a time determined by the TC members during the TC’s first meeting. It is anticipated that the CAMP TC will meet face-to-face every 3-4 months at a time and location to be determined by the TC members. TC members will determine the actual pace of face-to-face and teleconference meetings. One of the proposers, as listed below, will sponsor the teleconferences unless other TC members offer to donate their own facilities.
(2)(d) Proposers of the TC
Mark Carlson, mark.carlson@oracle.com, Oracle
Siddhartha Chandurkar, siddhartha.chandurkar@shephertz.com, ShepHertz
Martin Chapman, martin.chapman@oracle.com, Oracle
Alex Heneveld, alex.heneveld@cloudsoftcorp.com, Cloudsoft
Scott Hinkelman, scott.hinkelman@oracle.com, Oracle
David Jilk, dave.jilk@standingcloud.com, Standing Cloud
Duncan Johnston-Watt, duncan.johnstonwatt@cloudsoftcorp.com, Cloudsoft
Anish Karmarkar, anish.karmarkar@oracle.com, Oracle
Tobias Kunze, tkunze@redhat.com, Red Hat
Ashok Malhotra, ashok.malhotra@oracle.com, Oracle
Jeff Mischkinsky, jeff.mischkinsky@oracle.com, Oracle
Adrian Otto, adrian.otto@rackspace.com, Rackspace
Gilbert Pilz, gilbert.pilz@oracle.com, Oracle
David Sawyer, david.sawyer@jumpsoft.net, JumpSoft
Zhexuan Song, Zhexuan.Song@huawei.com, Huawei
Prasad Yendluri, Prasad.Yendluri@softwareag.com, Software AG
(2)(e) Statements of Support
Martin Chapman, martin.chapman@oracle.com, Oracle: As Oracle’s Primary Representative to OASIS, I approve the CAMP TC Charter, and endorse all Oracle proposers listed in (2)(d).
Siddhartha Chandurkar, siddhartha.chandurkar@shephertz.com, ShepHertz Technologies Pvt. Ltd.: As ShepHertz’s Primary Representative to OASIS, I approve the CAMP TC Charter, and endorse all ShepHertz proposers listed in (2)(d).
David Jilk, dave.jilk@standingcloud.com, Standing Cloud: As Standing Cloud’s Primary Representative to OASIS, I approve the CAMP TC Charter, and endorse all Standing Cloud proposers listed in (2)(d).
Duncan Johnston-Watt, duncan.johnstonwatt@cloudsoftcorp.com, CloudSoft: As Cloudsoft’s Primary Representative to OASIS, I approve the CAMP TC Charter, and endorse all Cloudsoft proposers listed in (2)(d).
Mark Little, mlittle@redhat.com, Red Hat: As Red Hat’s representative to OASIS, I approve the CAMP TC Charter, and endorse all Red Hat proposers listed in (2) (d).
Adrian Otto, adrian.otto@rackspace.com, Rackspace: As Rackspace’s representative to OASIS, I approve the CAMP TC Charter, and endorse all Rackspace proposers listed in (2) (d).
David Sawyer, david.sawyer@jumpsoft.net, JumpSoft: As JumpSoft’s Primary Representative to OASIS, I approve the CAMP TC Charter, and endorse all JumpSoft proposers listed in (2)(d).
Zhexuan Song, zhexuan.song@huawei.com, Huawei: As Huawei’s Primary Representative to OASIS, I approve the CAMP TC Charter, and endorse all Huawei proposers listed in (2)(d).
Prasad Yendluri, Prasad.Yendluri@softwareag.com, Software AG: As Software AG’s primary representative to OASIS, I approve the CAMP TC Charter, and endorse all our proposers listed in (2) (d).
(2)(f) TC Convener
Jeff Mischkinsky, jeff.mischkinsky@oracle.com, Oracle, will be the Convener of the CAMP TC.
(2)(g) Affiliation to Member Section
None
(2)(h) Initial Contribution
CAMP v1.0, 29th August 2012, http://www.cloudspecs.org/CAMP/CAMP_v1-0.pdf
(2)(i) Draft Frequently Asked Questions (FAQ) (optional)
N/A
(2)(j) Working title and acronym for the Work Products to be developed by the TC
Cloud Application Management for Platforms specification (CAMP)
References
[1] DMTF Cloud Infrastructure Management Interface: http://www.dmtf.org/cloud
[2] Open Cloud Computing Interface – Core: http://www.ogf.org/documents/GFD.183.pdf & Infrastructure: http://www.ogf.org/documents/GFD.184.pdf
[3] SNIA Cloud Data Management Interface (CDMI): http://www.snia.org/cloud
[4] OASIS Identity in the Cloud TC: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=id-cloud
[5] OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) : http://www.oasis-open.org/committees/tosca
[6] DMTF OVF Specification V1.1.0 (ISO standard): http://www.dmtf.org/sites/default/files/standards/documents/DSP0243_1.1.0.pdf
[7] ODCA Usage Model: Platform as a Service (PaaS) Interoperability Rev 1.0 http://www.opendatacenteralliance.org/docs/ODCA_PAAS_Interop_UM_Rev1.0_BD.pdf
[8] Cloud Standards Wiki: http://cloud-standards.org/wiki/index.php