Today OASIS announced the second Public Review of the Cloud Application Management for Platforms (CAMP) specification. The CAMP Technical Committee considers its work on this version (1.1) to be finished. Baring any substantive changes needed to address review comments and pending the fulfillment of the implementation requirements in the charter, this is the draft that will be approved as Committee Specification and, hopefully, become an OASIS Standard. If you have an interest in this space, you might want to review this draft and, if you have any concerns or issues, comment via the public mailing list.
To keep from rehashing previous material, I'll direct you to the blog entries on the
original announcement and
first PR and focus on some of the major changes in this version of the specification.
One-step deployment process
Previous drafts of the spec defined a two-step process to deploy an application: (1) POST a PDP or Plan file to the Platform resource to create an Assembly Template resource, (2) POST to this Assembly Template resource to instantiate an application (represented by an Assembly resource). One of the comments the TC received on the first PR was something along the lines of "What were you thinking? No commercial PaaS offering requires such a two-step process." Point taken, so CAMP now supports a single-step deployment process in which the client simply POSTs a PDP or a Plan file to the assemblies resource collection which, in the success case, results in the creation of a new application (still represented by an assembly resource).
Resource model simplification
Another issue with the first PR draft was the complexity of the resource model. Components were separated into "Application" and "Platform" components". Every component had a corresponding template, thus Application Component Template, Platform Component Template, etc., and each of these had corresponding Requirement and Capabilities resources. The whole thing was a bit dizzying, even to those accustomed to the spec. To address this the TC simplified the resource model by removing templates, requirements, and capabilities. There are now three main CAMP resources: assembly resources, which represents instantiated applications; component resources, which represent the components of an application (no more split between "application" and "platform" components); and service resources, which represents the services offered by the underlying platform. The various metadata resources that support the advertisement and discovery of the types, extensions, etc. supported by the platform are largely unchanged from the first PR draft.
Resource type inheritance
CAMP resources are strongly typed and extensible. This version of the spec adds an inheritance model that allows providers to define resource types that inherit the attributes and behavior of one or more other resource types. For example, a provider could define a database component resource that inherits from the CAMP-defined component resource and adds the required attributes 'database_uri' and 'cache_size'. This new resource type could be used anywhere CAMP specifies the use of a component resource. The metadata resources used to describe resource types have been updated to include these inheritance relationships and eliminate redundant information.
The plan resource
CAMP Plans provide "a description of 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". In this version of the spec, Plans can be represented as JSON resources as well as YAML files. Plan resources accomplish the function that the old template, requirement, and capability resources attempted to fulfill; namely allowing developers and admins to wire application artifacts to the services needed to support those artifacts. This is particularly useful in cases where there isn't a match between the requirements described in the initial Plan file and the services offered by the target platform. Plan resources can be used to create an application in the same way that Plan files are used - by POSTing a reference to the Plan to the assemblies resource collection.
For an example of what a CAMP 1.1 system would look like, I suggest checking out the Solum project, which was designed based on the concepts expressed in the CAMP spec. In addition to this there is the proof-of-concept implementation, nCAMP.