Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News CAMP 1.0 – An Open API for PaaS Application Management

CAMP 1.0 – An Open API for PaaS Application Management

This item in japanese


Several companies including Oracle, Rackspace, Red Hat and CloudBees have proposed an API for PaaS application management. The API allows developers to manage applications within and across various PaaS that will implement the specification without having any knowledge of the underlying cloud infrastructure.

CloudBees, Cloudsoft Corporation, Huawei, Oracle, Rackspace, Red Hat, and Software AG have announced a new PaaS management API called Cloud Application Management for Platforms (CAMP). The API can be used by cloud service providers and users to create applications for managing resources in the cloud. The initiators start from the idea that cloud users should not deal with low-level resources such as virtual machines, storage or networking, but rather should be able to access high-level resources, such as applications and their components. Also, users should be able to access PaaS services from different vendors using a single management console, and they should be able to easily transfer resources between different clouds.

CAMP’s API is built on top of HTTP/1.1, includes a RESTful binding and uses JSON for transferring resources. CAMP functionality is to be provided as plugins to an Application Development Environment (ADE) or an Application Management System, allowing developers to create their application with ADE then upload, deploy and instantiate it within the cloud of their choice.

CAMP defines [PDF] a number of resources including cloud platform, platform components, application, and application components. A cloud platform is the entire PaaS seen as a resource accessed though CAMP, while a platform component may be various services offered. CAMP currently defines only one such service, namely a Database-as-a-Service (DBaaS).

One of the main resources is application, and CAMP offers interfaces for dealing with it throughout its entire life cycle depicted below:


An application is instantiated using a POST command, as in the following request-response sequence:

POST /paas/asm_template/1 HTTP/1.1

HTTP/1.1 201 Created
Content-Type: ...
Content-Length: ...

while suspending an applications may be done as in the following example:

POST /<assembly-resource-url> HTTP/1.1
Content-Type: application/ +json;type=Xxxxx
Content-Length: ...

{"new_state": "suspend"}

HTTP/1.1 200 OK

CAMP has been submitted to OASIS for standardization, including a proposed charter (PDF) for the technical committee that is supposed to adopt it as a standard in 18 months. Oracle is the most involved company in the creation of CAMP with 7 out of 14 specification authors.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Don't see it working out

    by Eugene Tolmachev,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    - There's already an API to manage all the parametrization and at least 2 leading providers implement it: Amazon WebServices (it's one of the Rackspace selling points!)

    - On the opposite end of the cloud deployment spectrum, there's are high-level package deployment services, like Azure and Heroku

    While the API itself seems simple, I could see the package authorization, URI standardization, versioning, etc. quickly becoming a hurdle no one will want to deal with.

  • Re: Don't see it working out

    by Gilbert Pilz,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I'm not sure what you mean by an "parametrization".

    As for Azure and Heroku, yes they have APIs that allow you to deploy, start, stop, restart, etc. your application as does Engine Yard, Google, Cloud Foundry, etc. The point is that all these APIs are different and there really isn't any point in them being that way; it's not like anybody ever said "I prefer to use FooCloud because their application management APIs are so cool."

    As for your other concerns: security and versioning are difficult (though not impossible) but I don't see why we would need to standardize URIs.

  • Re: Don't see it working out

    by Eugene Tolmachev,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    If you look a the API, it has two aspects: VM management (provisioning/modification specification, i.e. parametrization) and package deployment (with requirements specification).
    For the former, AWS API looks well thought out and very comprehensive (and I don't see Amazon in the CAMP camp).
    For the latter, URIs would have to be standardized in order to provision correct dependencies (as those are identified by URIs). The scope of the standard can vary, but narrow it down too much - and it's too burdensome for the consumer, too much - and it's too unwieldy for the vendors. Basically, how portable are my packages?
    And yes, I'd say API (or modus operandi in general) along with the price would be the top two factors in choosing a cloud provider. That's how I pick, anyways.
    What are your top two factors?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p