CAMP defines the following:

• A domain-specific language that describes the artifacts that make up an application, the services that are required to execute or utilize those artifacts, and the relationship of the artifacts to those services.
• A resource model for representing applications and their constituent components as well the services used by those components along with runtime status information, configuration information, and metadata that describes the PaaS system.
• A RESTful protocol for manipulating these resources and, by so doing, changing the state of the underlying application.

Most PaaS systems provide some form of application management API. These APIs are used to upload applications into the cloud, configure which services will be used to run the application, start the application, monitor the status and performance of the application, stop the application, etc. These APIs are usually hidden behind a web application and/or a command line tool. This kind of API is a "me too" technology; its existence is a necessary prerequisite to providing a workable PaaS system, but there is little advantage in providing a better management API than your competitors. No one ever selected a PaaS offering solely on the strength of its application management API. Meanwhile, the fact that every PaaS system provides a custom application management API creates a number of issues:

• Any monitoring or management systems, continuous integration systems, etc. written to consume such APIs will need to be re-written if a customer wishes to change or add additional PaaS systems. This increases the cost of switching between PaaS providers which, in turn, decreases the value of using PaaS.
• Integrated development environments that wish to target PaaS environments must do so on an individual, case-by-case basis (for example, by providing custom connectors for each PaaS system). This both increases the initial development effort as well as the accumulated "technical debt" of maintaining each of these connectors.
• Because the quality of the application management API is not a differentiator, time spent designing/tweaking the management API is not a good investment. Platform providers can save time and resources by implementing a basic, consensus API. Value-added features can be implemented as extensions to this basic API.

CAMP 1.0 edit

CAMP 1.0^[1] was produced as a collaboration between CloudBees, Cloudsoft Corporation, Huawei, Oracle, Rackspace, Red Hat, and Software AG.^[2] It was published in August, 2012.

CAMP 1.1 edit

In August, 2012 CAMP 1.0 was submitted to OASIS CAMP Technical Committee with the intent of producing an OASIS Standard. This Technical Committee has produced an OASIS Committee Specification.^[3] As per its charter, the CAMP TC is awaiting evidence of two, interoperable implementations of CAMP v1.1 before asking OASIS to approve the specification as an OASIS Standard.

nCAMP edit

Developed in tandem with the work of the OASIS CAMP Technical Committee, nCAMP is a proof-of-concept implementation of the CAMP v1.1 specification. nCAMP was not intended to be a useful PaaS system but, instead, to act as a vehicle to test the concepts and constructs of the CAMP specification. nCAMP presents a simple system that uses Tomcat and MySQL to support Java Servlet based web applications that can use MySQL as a database.^[4]

Project Solum edit

Solum is an OpenStack Related Stackforge project designed to make cloud services easier to consume and integrate into the developers application development process. Solum's resource model and plan schema are based on CAMP, but not fully CAMP compliant. Work is currently ongoing to provide an additional, CAMP-compliant API^[5] in addition to the native Solum API.

Apache Brooklyn edit

Apache Brooklyn is a framework for modeling, monitoring, and managing applications through autonomic blueprints. Apache Brooklyn blueprints conform to CAMP v1.1 Public Review Draft 01.

• OASIS Cloud Application Management for Platforms (CAMP) TC
• CAMP in 7 Slide: Episode 2
• IPv4 Cloud VPS