Monday, August 19, 2013

CAMP Goes to Public Review

Disclaimer: The opinions expressed in this post are, for better or for worse, my own and not intended to reflect the policies or positions of my employer, Oracle, or those of OASIS.


The CAMP (Cloud Application Management for Platforms) specification has been released for Public Review. Comments are due by September 19, 2013 and should be sent according to the instructions in How to Submit Public Review Comments. Public comments submitted on this work and for other work of this TC are publicly archived and can be viewed at: Public Comments List.

CAMP is an emerging standard for Platform as a Service (PaaS). If your have not been following the developments in Cloud services you may be wondering what PaaS is, and how it differs from other kinds of Cloud services, so a brief introduction may be helpful.

A good place to start is the NIST Cloud Definition paper which defines three cloud architectures: IaaS (Infrastructure as a Service), PaaS (Platform as a Service) and SaaS (Software as a Service). These have recently been followed by a plethora of *aaS acronyms: NaaS (Network as a Service), DBaaS (Database as a Service), STaaS (Storage as a Service) and even DTaaS (Desktop as a Service) but the original three catogories are fundamental.

IaaS was the first to arrive. It allowed the user to rent computing, storage and networking resources on a remote data center. This started as an economic proposition: even factoring in the communication costs, it was less expensive per cycle to run on a very large data center than your own server. But there were other benefits that were more significant. You did not have to staff and naintain a data center and keep the software updated. If you were a little startup you could start immediately and renting provided flexibility; it was easy to ride out seasonal bumps and if your business did well it was easy to add additional resources.

Initiating and managing interdependent remote resources is, however, not straightforward. And how do you know when to scale up or scale down? Wouldn't it be simpler to just upload your application to a platform and, as the platform may advertise, leave the driving to it? This is what PaaS provides. You upload your application to a platform and the platform runs it for you. In fact, there is another, bigger benefit. The platform can offer services such as database and messaging and the application can be written to use the services. This can significantly simplify application construction and provide great value but, of course, if you use exotic platform services that will lock you in to the platform.


To run an application on a platform you need to be able to encapsulate it and stage it on the platform. CAMP calls this a Platform Development Package (PDP) and it is a fairly general format that lets you package an application along with its components and some metadata. The components have dependencies on one another and, more important, have dependencies on platform services provided by platform components. Platform components exhibit capabilities and during the deployment process requirements from the application components are matched with platform component capabilities.

CAMP identifies resources by URIs and defines REST operations to upload a PDP onto a platform, register it and deploy it. During the deployment process the application can be customized. If successfully deployed, the the application can be instantiated (run). The figure below, from an earlier version of the spec, depicts the application lifecycle.

An important aspect of Cloud Servicing is scaling. CAMP does not define specific scaling policies but, instead, provides a framework consisting of sensors that gather metrics which can be used with other data such as static or dynamic thresholds to trigger actions. Users can use this framework to provide their own scaling policies.


CAMP is a an important first step towards the standardization of PaaS. It is a simple specification that provides basic operations to upload a application to a platform and manage its lifecycle. It is designed to be extensible so users can customize it to their needs. Please review look at the spec and comment.

Friday, August 9, 2013

Linked Data Goes to Last Call

Disclaimer: The opinions expressed in this post are, for better or for worse, my own and not intended to reflect the policies or positions of my employer, Oracle, or those of the W3C

The Linked Data spec that I blogged about earlier in this space has gone to Last Call. This is an important step because it indicates that the spec has reached a certain level of maturity.

Please review and send comments to: (subscribe, archives). Comments period ends Sept 2, 2013.