OASIS Cloud Application Management for Platforms (CAMP) TC
Standardizing cloud PaaS management API
Table of Contents
- TC Liaisons
- TC Tools and Approved Publications
- Technical Work Produced by the Committee
- Expository Work Produced by the Committee
- External Resources
- Mailing Lists and Comments
- Press Coverage and Commentary
- Standing Rules
- Additional Information
Participation in the OASIS CAMP TC is open to all interested parties. Contact firstname.lastname@example.org for more information.
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:
- moving on-premise applications to the cloud (private or public)
- redeploying applications across cloud platforms from multiple vendors
For more information on CAMP, see the TC Charter.
No subcommittees have been formed for this TC.
No TC Liaisons have been announced for this TC.
There are no approved expository work products for this TC yet.
Although not produced by the OASIS CAMP TC, the following information offers useful insights into its work:
- Submission specification: Cloud Application Management for Platforms, Version 1.0, 29 Aug 2012
- CAMP support web site
- "Oracle rallies PaaS providers to float cloud interop spec"; The Register; 30 Aug 2012
- "CAMP will allow customers to more easily manage their PaaS workloads in the cloud"; InfoWorld; 30 Aug 2012
- "Cloud computing standards debate heats up with CAMP formation"; TechTarget; Sept 2012
- "Oracle and Partners release CAMP specification for PaaS Management"; Mark Carlson (Blog)
- "Cloud Application Management for Platforms"; Gilbert Pilz (Blog)
- Rule 1 (adopted nov 2012) :the TC will follow the issues lifecycle defined in CAMP TC Proposed Issues Process v6.ppt
- Rule 2 (adopted nov 2012): Chair is responsible for applying all JIRA state transitions except resolved->applied, which will be handled by the editors
- Rule 3 (adopted nov 2012):All JIRA transitions except resolved->applied and reopen require majority approval.
- Rule 4 (adopted nov 2012):Reopening a closed or deferred issue requires 2/3rd majority.
Providing Feedback: OASIS welcomes feedback on its technical activities from potential users, developers, and others to better assure the interoperability and quality of OASIS work.