Cloud Application Management for Platforms · agree to grant you a royalty-free license, under reasonable, non-discriminatory terms and conditions to patents that they deem necessary

Cloud Application Management for Platforms

Version 1.0

August 29, 2012

Authors (alphabetically):

Mark Carlson (Oracle)

Martin Chapman (Oracle)

Alex Heneveld (Cloudsoft)

Scott Hinkelman (Oracle)

Duncan Johnston-Watt (Cloudsoft)

Anish Karmarkar (Oracle)

Tobias Kunze (Red Hat)

Ashok Malhotra (Oracle)

Jeff Mischkinsky (Oracle)

Adrian Otto (Rackspace)

Vivek Pandey (CloudBees Inc.)

Gilbert Pilz (Oracle)

Zhexuan Song (Huawei)

Prasad Yendluri (Software AG)

Location: http://cloudspecs.org/camp/CAMP-v1.0.pdf

Abstract

This document defines the artifacts and APIs that need to be offered by a Platform

as a Service (PaaS) cloud to manage the building, running, administration,

monitoring and patching of applications in the cloud. Its purpose is to enable

interoperability among self-service interfaces to PaaS clouds by defining artifacts

and formats that can be used with any conforming cloud and enable independent

vendors to create tools and services that interact with any conforming cloud using

the defined interfaces. Cloud vendors can use these interfaces to develop new

PaaS offerings that will interact with independently developed tools and

components.


Copyright Notice

© Copyright CloudBees, Cloudsoft, Huawei, Oracle, Rackspace, Red Hat, Software AG, 2010, 2012. All

rights reserved.

License

The Cloud Application Management for Platforms (CAMP) Specification is being provided by the

copyright holders under the following license. By using and/or copying this work, you agree that you have

read, understood and will comply with the following terms and conditions:

Permission to copy, display and distribute the Cloud Application Management for Platforms (CAMP)

Specification and/or portions thereof, without modification, in any medium without fee or royalty is hereby

granted, provided that you include the following on ALL copies of the Cloud Application Management for

Platforms (CAMP) Specification, or portions thereof, that you make:

1. A link or URL to the Cloud Application Management for Platforms (CAMP) Specification at this location:

http://cloudspecs.org/camp/CAMP-v1.0.pdf

2. The full text of the copyright notice as shown in the Cloud Application Management for Platforms

(CAMP) Specification.

CloudBees, Cloudsoft, Huawei, Oracle, Rackspace, Red Hat, Software AG (collectively, the "Authors")

agree to grant you a royalty-free license, under reasonable, non-discriminatory terms and conditions to

patents that they deem necessary to implement the Cloud Application Management for Platforms (CAMP)

Specification.

THE Cloud Application Management for Platforms (CAMP) SPECIFICATION IS PROVIDED "AS IS,"

AND THE AUTHORS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED,

REGARDING THIS SPECIFICATION AND THE IMPLEMENTATION OF ITS CONTENTS, INCLUDING,

BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR

PURPOSE, NON-INFRINGEMENT OR TITLE.

THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR

CONSEQUENTIAL DAMAGES ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF

THE Cloud Application Management for Platforms (CAMP) SPECIFICATION.

The name and trademarks of the Authors may NOT be used in any manner, including advertising or

publicity pertaining to the Cloud Application Management for Platforms (CAMP) Specification or its

contents without specific, written prior permission. Title to copyright in the Cloud Application Management

for Platforms (CAMP) Specification will at all times remain with the Authors.

No other rights are granted by implication, estoppel or otherwise.


Version 1.0 Copyright 2012 CloudBees, Cloudsoft, Huawei, Oracle, Rackspace, Red Hat, Software AG i

Contents

Abstract .................................................................................................................................................... 1 1

1. Introduction ............................................................................................................................................ 1 2

1.1. Overview ....................................................................................................................................... 1 3

1.2. Purpose ......................................................................................................................................... 1 4

1.3. Example ........................................................................................................................................ 2 5

1.4. Non-Goals ..................................................................................................................................... 3 6

1.5. PaaS Roles ................................................................................................................................... 3 7

1.6. Document Conventions ................................................................................................................. 4 8

2. Architecture ............................................................................................................................................ 4 9

2.1. Management Model ...................................................................................................................... 4 10

2.1.1. PaaS Resource Model .......................................................................................................... 6 11

2.1.2. Resource Relationships ........................................................................................................ 7 12

2.1.3. Management Model Diagrams .............................................................................................. 9 13

2.2. Importing a Platform Deployment Package ................................................................................ 12 14

2.3. Exporting a Platform Deployment Package ................................................................................ 13 15

3. Application Lifecycle ............................................................................................................................ 13 16

3.1. Uploaded ..................................................................................................................................... 14 17

3.2. Deployed ..................................................................................................................................... 14 18

3.3. Instantiated .................................................................................................................................. 14 19

3.4. Suspended .................................................................................................................................. 14 20

4. Platform Deployment Package ............................................................................................................ 15 21

4.1. PDP Package Structure .............................................................................................................. 15 22

4.2. Deployment Plan ......................................................................................................................... 15 23

4.2.1. Deployment Plan Schema ................................................................................................... 15 24

5. Resources ............................................................................................................................................ 16 25

5.1. Common Types ........................................................................................................................... 16 26

5.1.1. Boolean ............................................................................................................................... 16 27

5.1.2. String ................................................................................................................................... 16 28

5.1.3. URI ...................................................................................................................................... 16 29

5.1.4. Timestamp ........................................................................................................................... 16 30

5.1.5. Link ...................................................................................................................................... 16 31

5.1.6. ResourceState ..................................................................................................................... 16 32

5.2. Attribute Constraints .................................................................................................................... 17 33

CAMP-v042.doc#_Toc328123774


ii Copyright 2012 CloudBees, Cloudsoft, Huawei, Oracle, Rackspace, Red Hat, Software AG Version 1.0

5.2.1. Cardinality ........................................................................................................................... 17 34

5.2.2. Mutability ............................................................................................................................. 17 35

5.2.3. Writeable ............................................................................................................................. 17 36

5.3. Common Resource Attributes ..................................................................................................... 17 37

5.3.1. uri ........................................................................................................................................ 17 38

5.3.2. name ................................................................................................................................... 17 39

5.3.3. description ........................................................................................................................... 17 40

5.3.4. created ................................................................................................................................ 18 41

5.3.5. tags ...................................................................................................................................... 18 42

5.4. Error Response Message ........................................................................................................... 18 43

5.5. Extensibility to the resource model ............................................................................................. 20 44

5.6. Platform ....................................................................................................................................... 20 45

5.6.1. specificationVersion ............................................................................................................ 21 46

5.6.2. implementationVersion ........................................................................................................ 21 47

5.6.3. assemblyTemplates ............................................................................................................ 21 48

5.6.4. assemblies .......................................................................................................................... 21 49

5.6.5. platformComponentTemplates ............................................................................................ 21 50

5.6.6. platformComponentCapabilities .......................................................................................... 21 51

5.6.7. platformComponents ........................................................................................................... 22 52

5.6.8. resourceState ...................................................................................................................... 22 53

5.7. AssemblyTemplate ...................................................................................................................... 22 54

5.7.1. definition .............................................................................................................................. 23 55

5.7.2. basedOn .............................................................................................................................. 23 56

5.7.3. applicationComponentTemplates ........................................................................................ 23 57

5.7.4. platformComponentTemplates ............................................................................................ 23 58

5.7.5. dependencies ...................................................................................................................... 23 59

5.8. ApplicationComponentTemplate ................................................................................................. 24 60

5.8.1. definition .............................................................................................................................. 24 61

5.8.2. basedOn .............................................................................................................................. 24 62

5.9. ApplicationComponentRequirement ........................................................................................... 24 63

5.9.1. definition .............................................................................................................................. 25 64

5.10. ApplicationComponentCapability ................................................................................................ 25 65

5.10.1. definition .............................................................................................................................. 25 66

5.11. PlatformComponentTemplate ..................................................................................................... 26 67

5.11.1. definition .............................................................................................................................. 26 68


Version 1.0 Copyright 2012 CloudBees, Cloudsoft, Huawei, Oracle, Rackspace, Red Hat, Software AG iii

5.12. PlatformComponentRequirement ............................................................................................... 26 69

5.12.1. definition .............................................................................................................................. 27 70

5.13. PlatformComponentCapability .................................................................................................... 27 71

5.13.1. definition .............................................................................................................................. 27 72

5.14. Assembly ..................................................................................................................................... 27 73

5.14.1. definition .............................................................................................................................. 28 74

5.14.2. applicationComponents ....................................................................................................... 28 75


5.14.4. assemblyTemplate .............................................................................................................. 28 77

5.14.5. resourceState ...................................................................................................................... 29 78

5.15. ApplicationComponent ................................................................................................................ 29 79

5.15.1. definition .............................................................................................................................. 29 80

5.15.2. applicationComponents ....................................................................................................... 30 81


5.15.4. resourceState ...................................................................................................................... 30 83

5.16. PlatformComponent .................................................................................................................... 30 84

5.16.1. definition .............................................................................................................................. 31 85

5.16.2. externalManagementResource ........................................................................................... 31 86

5.16.3. resourceState ...................................................................................................................... 31 87

6. Protocol ................................................................................................................................................ 32 88

6.1. Transport Protocol ....................................................................................................................... 32 89

6.2. URI Space ................................................................................................................................... 32 90

6.3. Media Types ................................................................................................................................ 32 91

6.4. Request Headers ........................................................................................................................ 33 92

6.5. Request Parameters ................................................................................................................... 33 93

6.6. Response Headers ..................................................................................................................... 33 94

6.7. HTTP Status Codes .................................................................................................................... 33 95

6.8. Concurrent API versions ............................................................................................................. 33 96

6.9. Registering a PDP ....................................................................................................................... 34 97

6.10. Instantiating an Application ......................................................................................................... 34 98

6.11. Suspending and Resuming an Application ................................................................................. 35 99

6.12. Deleting an Application Instance and a Deployed Application .................................................... 35 100

7. Normative References ......................................................................................................................... 35 101

8. Non-Normative References ................................................................................................................. 36 102

Annex A. Glossary .................................................................................................................................. 37 103


iv Copyright 2012 CloudBees, Cloudsoft, Huawei, Oracle, Rackspace, Red Hat, Software AG Version 1.0

Annex B. Use Cases (Non-Normative) ................................................................................................... 38 104

B.1. Building the Application ............................................................................................................... 38 105

B.1.1. Build Application and Package ................................................................................................ 38 106

B.1.2. Build Application in the Cloud and Optionally Package .......................................................... 39 107

B.2. Deploying and Managing the Application .................................................................................... 40 108

B.2.1. Import Platform Deployment Package .................................................................................... 41 109

B.2.2. Upload Application .................................................................................................................. 41 110

B.2.3. Run/Stop/Suspend/Snapshot .................................................................................................. 42 111

B.2.4. Patch an Application Component Template ............................................................................ 42 112

B.2.5. Patch a Created, Deployed or Running Application................................................................ 42 113

Annex C. Example Database Platform Component (Non-Normative) .................................................... 42 114

C.1. Model ........................................................................................................................................... 42 115

C.2. DatabaseCapability ..................................................................................................................... 42 116

C.2.1. definition .................................................................................................................................. 43 117

C.2.2. clusterTypes ............................................................................................................................ 43 118

C.2.3. maxNumberNodes .................................................................................................................. 44 119

C.2.4. maxCores ................................................................................................................................ 44 120

C.2.5. maxMemSize ........................................................................................................................... 44 121

C.2.6. maxDiskSize ............................................................................................................................ 44 122

C.2.7. backupAvailable ...................................................................................................................... 44 123

C.2.8. synchronousCopyAvailable ..................................................................................................... 44 124

C.2.9. partitionAvailable ..................................................................................................................... 45 125

C.2.10. compressionAvailable ............................................................................................................. 45 126

C.2.11. retentionAvailable .................................................................................................................... 45 127

C.2.12. tunings ..................................................................................................................................... 45 128

C.2.13. cachingAvailable ..................................................................................................................... 45 129

C.3. DatabaseRequirement ................................................................................................................ 45 130

C.3.1. definition .................................................................................................................................. 46 131

C.3.2. clusterTypes ............................................................................................................................ 46 132

C.3.3. numberNodesRange ............................................................................................................... 47 133

C.3.4. coreRange ............................................................................................................................... 47 134

C.3.5. memSizeRange ....................................................................................................................... 47 135

C.3.6. diskSizeRange ........................................................................................................................ 47 136

C.3.7. backupEnabled........................................................................................................................ 47 137

C.3.8. synchronousCopyEnabled ...................................................................................................... 47 138


Version 1.0 Copyright 2012 CloudBees, Cloudsoft, Huawei, Oracle, Rackspace, Red Hat, Software AG v

C.3.9. partitionEnabled ...................................................................................................................... 48 139

C.3.10. compressionEnabled ............................................................................................................... 48 140

C.3.11. retentionEnabled ..................................................................................................................... 48 141

C.3.12. tunings ..................................................................................................................................... 48 142

C.3.13. cachingEnabled ....................................................................................................................... 48 143

C.4. DatabaseTemplate ...................................................................................................................... 48 144

C.4.1. definition .................................................................................................................................. 49 145

C.4.2. clusterType .............................................................................................................................. 49 146

C.4.3. numberNodes .......................................................................................................................... 50 147

C.4.4. cores ........................................................................................................................................ 50 148

C.4.5. memSize ................................................................................................................................. 50 149

C.4.6. diskSize ................................................................................................................................... 50 150

C.4.7. backupEnabled........................................................................................................................ 50 151





C.4.12. tuning ....................................................................................................................................... 51 156


C.5. Database ..................................................................................................................................... 51 158

C.5.1. definition .................................................................................................................................. 52 159

C.5.2. externalManagementResource ............................................................................................... 52 160

C.5.3. clusterType .............................................................................................................................. 53 161

C.5.4. numberNodes .......................................................................................................................... 53 162

C.5.5. cores ........................................................................................................................................ 53 163

C.5.6. memSize ................................................................................................................................. 53 164

C.5.7. diskSize ................................................................................................................................... 53 165

C.5.8. backupEnabled........................................................................................................................ 53 166





C.5.13. tuning ....................................................................................................................................... 54 171


C.5.15. operationsThroughput ............................................................................................................. 54 173


vi Copyright 2012 CloudBees, Cloudsoft, Huawei, Oracle, Rackspace, Red Hat, Software AG Version 1.0

C.5.16. operationsBandwidth ............................................................................................................... 55 174

C.5.17. resourceState .......................................................................................................................... 55 175

Annex D. Implementation Considerations (Non-Normative) ................................................................... 55 176

D.1. Types of Platform Deployments .................................................................................................. 55 177

D.2. Scaling ......................................................................................................................................... 56 178

179


1 Copyright 2012 CloudBees, Cloudsoft, Huawei, Oracle, Rackspace, Red Hat, Software AG Version 1.0

1. Introduction

1.1. Overview

Platform as a Service (PaaS) is a term that refers to a type of cloud computing in which the service 180

provider offers customers/consumers access to one or more instances of a running application computing 181

platform or application service stack. NIST defines PaaS [SP800-145] as a “service model” with the 182

following characteristics: 183

The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or 184

acquired applications created using programming languages and tools supported by the provider. The 185

consumer does not manage or control the underlying cloud infrastructure including network, servers, operating 186

systems, or storage, but has control over the deployed applications and possibly application hosting 187

environment configurations. 188

There are multiple commercial PaaS offerings in existence using languages such as Java, Python and 189

Ruby and frameworks such as Spring and Rails. Although these offerings differ in such aspects as 190

programming languages, application frameworks, etc., there are inherent similarities in the way they 191

manage the lifecycle of the applications that are targeted for, and deployed upon them. The core 192

proposition of this specification is that these similarities can be leveraged to produce a generic application 193

and platform management API that is language, framework, and platform neutral. 194

For PaaS consumers this management API would have the following benefits: 195

“Portability between clouds” is emerging as one of the primary concerns of cloud computing. By 196

standardizing the management API for the use cases around deploying, stopping, starting, and 197

updating applications, this specification increases consumers’ ability to port their applications 198

between PaaS offerings. 199

It is likely that implementations of this specification will appear as plugins for application 200

development environments (ADEs) and application management systems. Past experience has 201

shown that, over time, such generic implementations are likely to receive more attention and be 202

of higher quality than the implementations written for solitary, proprietary application management 203

interfaces. 204

For PaaS providers this management API would have the following benefits: 205

Because the strength and features of a PaaS offering’s application management API are unlikely 206

to be perceived as key differentiators from other PaaS offerings, the existence of a consensus 207

management API allows providers to leverage the experience and insight of the specification’s 208

contributors and invest their design resources in other, more valuable areas. 209

By increasing the portability of applications between PaaS offerings, this management API helps 210

“grow the pie” of the PaaS marketplace by addressing one of the key pain points for PaaS 211

consumers. 212

1.2. Purpose

This document defines the artifacts and APIs that need to be offered by a Platform as a Service (PaaS) 213

cloud to manage the building, running, administration, monitoring and patching of applications in the 214

cloud. Its purpose is to enable interoperability among self-service interfaces to PaaS clouds by defining 215

artifacts and formats that can be used with any conforming cloud and enable independent vendors to 216

create tools and services that interact with any conforming cloud using the defined interfaces. Cloud 217


Version 1.0 Copyright 2012 CloudBees, Cloudsoft, Huawei, Oracle, Rackspace, Red Hat, Software AG 2

vendors can use these interfaces to develop new PaaS offerings that will interact with independently 218

developed tools and components. 219

The following is a non-exhaustive list of the use cases which are supported by this specification. Details 220

of these use cases can be found in Annex B. 221

Building and packaging an application in a local Application Development Environment (ADE) 222

Building an application in an ADE running in the cloud 223

Importing a Platform Deployment Package into the cloud 224

Uploading application artifacts into the cloud 225

Run, stop, suspend, snapshot, and patch an application 226

1.3. Example

This example illustrates a scenario in which the application administrator wants to run and monitor an 227

application. It assumes that the application package was previously made available to the platform, either 228

because it was uploaded to the platform or developed directly on the platform. 229

The administrator starts by deploying the application package to the platform. This is done by sending an 230

HTTP POST request to the platform entry point URL as shown below, where "/myPaaS" is the entry point 231

and "/myPaas/pkgs/1" is the location of the application package. 232

POST /myPaaS HTTP/1.1 233

Host: example.org 234

Content-Type: application/vnd.org.example.PaaS+json; type=... 235 Content-Length: ... 236

237

{ 238

"pdp_uri": "/myPaaS/pkgs/1" 239 } 240

On receiving such a request the platform deploys the application package and creates a new resource 241

"/myPaas/templates/1" that represents the deployed application. The response from the platform is show 242

below. 243

HTTP/1.1 201 Created 244

Location: http://example.org/myPaaS/templates/1 245 Content-Type: ... 246

Content-Length: ... 247

248 ... 249

Once the application is deployed, the administrator starts the application by sending an HTTP POST 250

request to the resource that represents the deployed application, which was obtained in the previous step 251

("/myPaaS/templates/1"). 252

POST /myPaaS/templates/1 HTTP/1.1 253


On successful start the platform creates a new resource representing the running application and 255

provides the URL of that resource "/myPaaS/apps/1" in the response as show below. 256


Location: http://example.org/myPaaS/apps/1 258

Content-Type: ... 259



Content-Length: ... 260

261 ... 262

The administrator can now monitor the running application by sending an HTTP GET request to the 263

resource that represents the running application, which was obtained in the previous step 264

("/myPaas/apps/1"). 265

GET /myPaaS/apps/1 HTTP/1.1 266


The response contains the JSON representation of the running application as shown below. 268

HTTP/1.1 200 OK 269

Content-Type: application/vnd.org.example.PaaS+json; type=Assembly 270 Content-Length: ... 271

272

{ 273

"uri": "http://example.org/myPaaS/apps/1", 274 "name": "Hello Cloud App", 275

"description": "Hello Cloud Application Running in a PaaS Env", 276

"created": "2012-06-04T20:47Z", 277 "definition": "...", 278

"applicationComponents": [ 279

{ 280 "href": "/myPaaS/apps/1/acs/1" 281

}, 282

{ 283

"href": "myPaaS/apps/1/acs/2" 284 } 285

], 286

"platformComponents": [ 287 { 288

"href": "/myPaaS/pcs/1" 289

}, 290 { 291

"href": "myPaaS/pcs/2" 292

} 293

], 294 "assemblyTemplate": "/myPaaS/templates/1", 295

"resourceState": { 296

"state": "RUNNING" 297 } 298

} 299

1.4. Non-Goals

The specification of functional interfaces specific to services provided by individual components (see 300

Application Components and Platform Components, below) is out of scope for this document. This is 301

because such interfaces may be quite diverse and differ significantly from platform to platform. 302

1.5. PaaS Roles

There are many roles that can be defined for a PaaS environment. For the purposes of this specification 303

we identify four roles: 304



Application Developer: The person that builds and tests an application and presents the developed 305

artifacts for deployment. 306

Application Administrator: The person that deploys applications and manages the application 307

throughout its life-cycle. 308

Together these two roles make up the consumers of the management API described in this specification. 309

This specification is intended mainly for Application Administrators, though it does constraint the artifacts 310

that an Application Developer presents for deployment. 311

Platform Administrator: The person that manages the platform. This specification describes some of the 312

functions of a Platform Administrator, though most of the functions of this role are outside its scope. 313

Application End-User: A user of an application deployed on the platform. The interactions of the 314

Application end-user and the application are outside the scope of this specification. 315

1.6. Document Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 316

NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described 317

in RFC 2119 [RFC2119]. 318

Only the lower case versions of these keywords are used in this document in accordance with RFC 2119 319

in order to conform to ISO document requirements. 320

2. Architecture

2.1. Management Model

This document specifies the self-service management API that a Platform as a Service offering presents 321

to the consumer of the platform. The API is typically the interface into a platform implementation layer that 322

controls the deployment of applications and their use of the platform. 323



Figure 1 - Typical PaaS Architecture

The figure above shows a typical architecture of a Platform as a Service cloud. The platform 324

implementation is a management client of the underlying resources that transforms (through policies) the 325

application requirements expressed by the Application Administrator into provisioning and other 326

operations on those resources. The Platform Administrator manages the underlying hardware, storage, 327

networks, and software services that make up the platform through existing administrative interfaces. 328

Thus the Application Administrator is able to concentrate on their application and it’s deployment 329

environment rather than having to be a systems administrator, database administrator and middleware 330

administrator as well (as is the case with IaaS). 331

The goal of the management interface is to provide the PaaS consumer with a model that is as simple as 332

possible, and yet still provides the essential elements that give them control over the deployment, 333

execution, administration and metering of their application and it’s deployment environment. 334



2.1.1. PaaS Resource Model

The model of resources manipulated through the interface, in combination with the protocol used to 335

remotely accomplish this, constitutes the self-service PaaS management API. The model contains 336

resource types corresponding to the artifacts discussed earlier. 337

2.1.1.1. Platform

The Platform resource is the primary view of the platform and what is running on it. The Platform 338

references deployed applications (as Assembly Templates) as well as running applications (as 339

Assemblies) and enables discovery of the PaaS offering in terms of Platform Components and their 340

capabilities. The Platform also determines the scope of access for sharing amongst multiple applications. 341

2.1.1.2. Assemblies

The Assembly Template resource represents a deployed application and its dependencies on the 342

platform and other application components. 343

The Assembly resource represents a running application. Operations on an Assembly affect the 344

components and elements of that application. 345

2.1.1.3. Components

There are two kinds of components, application components and platform components, each of which 346

may exist in either template or instantiated forms. 347

The Application Component Template resource represents a discrete configuration of a deployed 348

application component. The attributes of this resource represent the configuration values that will be 349

applied to the component upon instantiation. 350

The Application Component resource represents an instantiated instance of an application component. 351

The Platform Component Template resource represents a discrete configuration of a platform component. 352

The attributes of this resource represent the configuration values that will be applied to the component 353

upon instantiation. 354

The Platform Component resource represents an instantiated instance of a platform component in use by 355

an application. In addition to the configuration metadata (derived from the corresponding Platform 356

Component Template on instantiation), the attributes of this resource also include metering information 357

for this component. Such information is typically used in generating the consumer’s bill. 358

2.1.1.4. Capabilities and Requirements

Like Templates, Capability resources represent the configuration of instantiatable Components 359

(Application Components or Platform Components). Unlike Templates, which delineate discrete 360

configurations, Capabilities specify ranges of configuration values. 361

Requirement resources are created by the Application Developer or Application Administrator to express 362

an application’s dependency on a component that is capable of satisfying a certain set of requirements. 363

For example, an application component may depend upon a messaging service that supports a certain 364

version of an AMQP API, can accept messages of up to 2MB in size, and which provides a persistent 365

message store. 366

The process of matching Requirements with Capabilities is referred to as “requirement resolution”. 367



2.1.2. Resource Relationships

A Platform provides a set of Platform Components that may be used by the invoking applications. 368

Examples of Platform Components include a servlet container, a web server, an LDAP store, and a 369

database instance. The implementation and operation of Platform Components is managed by the 370

Platform Administrator. Platforms may also provide higher-level business components such as a business 371

rules manager to gain competitive advantage and developer loyalty. 372

An application is composed of a set of Application Components that depend on one or more Platform 373

Components. Examples of Application Components include Ruby gems, Java libraries, and PHP 374

modules. Application Components may also include non-code artifacts such as datasets and collections 375

of identity information. 376

Application Components may also interact with other Application Components. Thus, an Application 377

Component has two different sets of dependencies. It depends on the Components provided by the 378

platform, and depends on services provided by other Application Components. Such Application 379

Components may be on the same platform or may reside at some other location. The Assembly resource 380

is used to aggregate the management of these components as shown below: 381

Figure 2 - Runtime Management Resources

Platform Components have a set of Platform Component Capabilities that an application can choose from 382

to meet its requirements. Applications can tailor Platform Component Requirements (a refinement or 383

narrowing of the configuration ranges in the Capabilities) to meet their needs based on the range of 384

parameters expressed in the Platform Component Capability. 385

The relationships of an Assembly Template to Application Component Templates and Platform 386

Component Templates, or their Requirements are shown below: 387



Figure 3 - Template Management Resources

An Application Component can express the exact configuration of its dependency on other Components 388

using one of the Component Template resources (either an Application Component Template or Platform 389

Component Template). Alternatively, it can express a range of configuration values that are acceptable 390

for that dependency by using one of the Component Requirement resources (either an Application 391

Component Requirement or Platform Component Requirement). This might be done, for example, in an 392

ADE when the existing Component Templates are not known. During the deployment, these 393

Requirements are matched with Capabilities that have attribute values that fall within the ranges specified 394

by the Requirements. 395

An Application Component Template cannot be instantiated unless all of its dependencies are satisfied. 396

An Assembly Template cannot be instantiated until all of its Application Component Templates are 397

successfully instantiated. 398

When instantiated, an Assembly Template results in an Assembly. The Assembly resource references the 399

Assembly Template it was instantiated from, although attributes of the Assembly can deviate from the 400

original template. An Assembly can be snapshot at a point in time and the resulting snapshot can be used 401

to create a new Assembly Template. 402

A Deployment Plan is packaging management meta-data that includes a serialized copy of the Assembly 403

Template resource and all dependent management resources such as Application Component 404

Templates. Deployment Plans are an essential part of a Platform Deployment Package (PDP). 405

A Platform Deployment Package is an archive of executable images, dependency descriptions and 406

metadata (management resources) that can be used to move an Application and its Components from 407

Platform to Platform, or between an Application Development Environment and a Platform. It can be 408

thought of as a serialized form of an Assembly Template and all of its dependent management resources. 409



2.1.3. Management Model Diagrams

The figures in this section list attributes for various management resources. The attributes listed here are 410

not exhaustive. For a comprehensive list of attributes for resources see Section 5. 411

2.1.3.1. Basic Platform Resources

The CAMP model includes the resources below when no Assemblies have been created. 412

Figure 4 - Basic Platform Resources

An empty Platform will have a number of resources visible through the API when the Application 413

Administrator first accesses a new account. The Platform resource is used to find the other resources in 414

this diagram. The various Platform Component Capabilities allow for discovery of all the platform services 415

that are available with value ranges for each service’s attributes. The various Platform Component 416

Templates may represent pools of previously configured platform resources and represent this 417

configuration as specific values for each of the attributes. These values are chosen from the range of 418

values in the corresponding Platform Component Capability. 419

2.1.3.2. Resources Loaded

After loading a PDP, the model may appear as follows: 420



Figure 5 - Loaded Resources

An Assembly Template now is available with one or more Application Component Templates, Application 421

Component Requirements and Platform Component Requirements. The Application Component 422

Template resources represent actual code that was loaded with the deployment plan. The Application 423

Component Requirement resources were used to find Application Component Templates (pre-existing 424

software libraries for example) that were not part of the deployment plan but are required for the 425

application. The Application Component Capability resources show the range of configurable attributes 426

that the loaded Application Components can take on, when reused by future Application Components. 427

The Platform Component Requirement resources were used to find Platform Component Templates (pre-428

configured platform resources) that were part of the platform and required by the loaded Application 429

Components, but perhaps unknown at the time the deployment plan was created (in an ADE for 430

example). 431

2.1.3.3. Instantiated Resources

To start an application utilizing all of the previously configured Application Components and Platform 432

Components, an Assembly is created using the Assembly Template. This also causes the Application 433

Components and Platform Components corresponding to their respective templates to be created as 434

shown below. 435



Figure 6 - Instantiated Resources

To manage the operation of the application, the Application Administrator interacts with the Assembly 436

resource and the related Application Component and Platform Component resources. 437

The traversal of the resources in the model can be accomplished by following arrays of URIs from each 438

resource to the other resources it depends on as shown by the red arrows in the figure below: 439



Figure 7 - Traversing Resources

2.2. Importing a Platform Deployment Package

A Platform Deployment Package may be imported into the platform and as a result the following takes 440

place: 441

1. One or more Assembly Templates are created with URIs to the other elements and with any 442

binary executables installed onto the platform. 443

2. One or more Application Component Templates are created with URIs to the other elements and 444

with and binary executables installed onto the platform. 445

3. Zero or more Platform Component Requirements are created, representing the requirements on 446

the underlying platform components. Connections may be made to existing Platform Component 447

Templates whose attribute values fall within the ranges specified by the requirements. 448

4. Zero or more Application Component Requirements are created, representing the requirements 449

on previously installed Application Components. Connections may be made to existing 450



Application Component Templates whose attribute values fall within the ranges specified by the 451

requirements. 452

2.3. Exporting a Platform Deployment Package

A Platform Deployment Package may be exported from the platform by an operation on an Assembly or 453

an Assembly Template. The Assembly (Assembly Template), dependent Application Components 454

(Application Component Templates) and Platform Components (Platform Component Templates) and 455

associated Capabilities Requirements, if any, as well as all related images are then used to create the 456

Deployment Plan and Platform Deployment Package. A URI to the Platform Deployment Package is 457

returned as a result. 458

3. Application Lifecycle

The following state diagram depicts lifecycle of an Application from the perspective of the PaaS 459

Management API. 460

Uploaded

Deployed

Instantiated Suspended

upload package

register

register

suspend

resume

delete instance

delete

delete instance

customize

instantiate

Figure 8 - Application Lifecycle

The following sections describe this diagram. It is important to note: 461

The states and transitions shown in this diagram are abstract and do not necessarily correspond 462

in a one-to-one fashion with any specific information or activities maintained or performed by 463

either the Consumer or the Provider. 464

The entities that define “the Application” vary between states. For example, in the “Deployed” 465

state, the Application is represented by the graph of entities rooted in an Assembly Template. In 466



in the “Instantiated” state, the Application is represented by the graph of entities rooted in an 467

Assembly. 468

Platform-specific environments might add to or extend this lifecycle to accommodate the needs of 469

a particular framework or language. Such extensions are outside the scope of this specification. 470

3.1. Uploaded

While the development of Applications and their components is outside the scope of this specification, 471

nonetheless it is recognized that such development may occur either within the PaaS environment itself, 472

or externally (i.e. on the Application Developer’s local machine). In the latter case, the executable images, 473

and Deployment Plan, and other metadata that make up the Application shall be imported into the 474

platform in the form of a PDP. Because the PDP represents a significant interoperability point, the 475

Uploaded state exists to depict the upload package transition. During this transition the PDP is un-476

archived, validated, and parsed (not necessarily in that order). Invalid PDPs will cause the upload 477

package transition to fail. Once uploaded, the Application/PDP may be persisted in some fashion outside 478

the scope of this specification. The invocation of the register transition may occur either automatically or 479

via some unspecified action on the part of the Application Administrator. 480

3.2. Deployed

The Application enters the Deployed state via one of the register transitions. During these transitions the 481

Deployment Plan is parsed and validated and the corresponding Assembly Template, Application 482

Component Templates, Application Component Requirements, etc. are created as addressable entities in 483

the Platform. The register transition also encompasses the process of dependency resolution in which 484

Platform Component Requirements and Application Component Requirements are matched 485

(respectively) against candidate Platform Component Templates and Application Component Templates. 486

Note this process may require interaction with the Consumer. If the required dependencies are not 487

resolved or if the metadata is incomplete, the register transition shall not happen. 488

Once deployed, an Application may be customized by the Application Administrator. This is represented 489

by the customize transition. Customization may include changes to configuration parameters, modifying 490

dependencies, etc. Application Administrators may elect to copy or create new Assembly Templates – 491

effectively creating a new Application. 492

Deployed Applications may be removed as represented by the delete transition. Deleting an Application 493

removes its Assembly Template, Application Component Template, Platform Component Requirement, 494

and Application Component Requirement entities. 495

3.3. Instantiated

The Instantiated state represents a running Application. The management entity for an Application in this 496

state is the Assembly. The Assembly and its graph of dependent Application Components and Platform 497

Components are created upon entry to this state via the instantiate transition and removed during the 498

delete instance transition. 499

3.4. Suspended

The optional Suspended state represents an Application that has been suspended. During this state the 500

Application is unavailable to its clients and does not process any requests. This specification does not 501

specify whether the suspension is done at full scale with all its existing resources allocated, or scaled 502

back with minimum resources necessary to preserve its runtime context, or something in between. An 503



implementation can specify scale at which suspension is done or allow clients to specify the scale of 504

suspension via extensions. The scale at which the suspension is done affects resource utilization and 505

therefore cost during the suspension phase. It also affects the time it takes to resume processing client 506

requests at roughly the same rate as before suspension. 507

Note the delete instance transition has the same effect as the delete instance transition for an Instantiated 508

Application. 509

4. Platform Deployment Package

The Platform Deployment Package (PDP) ensures portability across platforms. It can be created by a 510

platform to export to another platform, which then imports it. It can also be created by an Application 511

Development Environment running locally or deployed as Software as a Service in the cloud. 512

4.1. PDP Package Structure

A PDP consists of the following files: 513

One Deployment Plan file with extension .dp 514

Zero or one manifest file with the extension .mf 515

Zero or one certificate with the extension .cert 516

Zero or more language specific bundles 517

Zero or more additional resource files 518

The manifest file contains a list of all the other files in the package and may contain file-related metadata 519

such as checksums. The certificate is used to sign the package manifest. The PDP may be delivered as a 520

single tar file consisting of the above items. 521

4.2. Deployment Plan

The Deployment Plan is an XML file that contains the templates, dependencies and platform component 522

configurations that enables the platform to create the environment and instantiate all the components in 523

order to launch the application. Attributes in the deployment plan are used by the platform to create the 524

Assembly Template, Component Templates and Component Dependencies. 525

4.2.1. Deployment Plan Schema

This section will be completed when the resource encoding in section 4 is complete. The intent is to reuse 526

that encoding in the Deployment Plan Schema such that implementations have a ready capability to 527

generate Platform Deployment Plans from their internal representations. 528



5. Resources

The following sections describe the resources defined by this specification. 529

5.1. Common Types

Resource attributes are defined using the following types: 530

5.1.1. Boolean

As defined by JSON [RFC4627], a token having a literal value of either true or false. 531

5.1.2. String

A UNICODE string as defined by JSON [RFC4627]. 532

5.1.3. URI

A String (see above) that conforms to the syntax defined in RFC 3986 [RFC3986]. 533

5.1.4. Timestamp

A String (see above) that conforms to the syntax defined in ISO 8601 [ISO 8601:20044]. 534

5.1.5. Link

The management model defined in this specification involves resource entity attribute values that link to 535

other resource entities. For example, one of the Platform resource entity attribute values points to 536

Assembly Templates. The “Link” type defined here is used for such attribute values. 537

Link has one or more attributes. The attribute href whose value is a URL MUST be present. Other 538

attributes, not defined in this specification, MAY also be present. A JSON example is shown below: 539

"LinkName": {"href": "http://example.org/paas1/assemblies/1"} 540

5.1.6. ResourceState

This type is used to denote the state of the resource within the lifecycle defined for that resource. 541

The following table is the data model of this type. 542

Table 1 – ResourceState Data Model

Field Type Occurs Description

state String 1 Current state of the resource. This is a label

containing lifecycle state (e.g. INITIATED,

CREATING, CREATED, DESTROYING,

DESTROYED, READY).

When there are vendor extensions, the vendor

shall publish and document their semantics

progress Integer between 0 and 100 0..1 Indicates the progress made as an approximate

percentage. Not all state labels assign semantic

meaning to this field



messages Message[] 0..1 Include the message data model instances to

denote noteworthy communications

5.2. Attribute Constraints

Resource attributes are constrained along a number of axes. These are: 543

5.2.1. Cardinality

This constraint indicates the cardinality of the attribute. 544

5.2.2. Mutability

This constraint indicates the mutability of the attribute’s value(s). “immutable” indicates that the value of 545

the attribute, once set, shall not change for the lifetime of the resource. “mutable” indicates that the value 546

of the attribute may change due to the actions or activity of either the provider or the user. 547

5.2.3. Writeable

This constraint indicates the ability of a user to update the value of the attribute. It is only relevant for 548

mutable attributes. “false” indicates that the value(s) of the attribute can only be changed by the provider. 549

“true” indicates that users may change the value(s) of the attribute. 550

5.3. Common Resource Attributes

All the resources in this specification contain the following common attributes: 551

5.3.1. uri

Type: URI 552

Cardinality: 1 553

Mutability: immutable 554

This attribute expresses the URI of the resource. 555

5.3.2. name

Type: String 556

Cardinality: 1 557

Mutability: mutable 558

Writeable: true 559

This attribute expresses the human-readable name of the resource. 560

5.3.3. description

Type: String 561

Cardinality: 0..1 562


Writeable: true 564

This attribute expresses the human-readable description of the resource. 565



5.3.4. created

Type: Timestamp 566

Cardinality: 1 567


This attribute expresses the time which the resource was created. 569

5.3.5. tags

Type: String[] 570



Writeable: true 573

This attribute is an array of String values that may be assigned by the provider or the user. These values 574

can be used for keywording and terms-of-interest. 575

5.4. Error Response Message

Media Type: application/vnd.org.example.PaaS+json;type=ErrorMessage 576

Successful requests will generally return an HTTP status code of 200 (OK), 201 (Created), 202 577

(Accepted), or 204 (No Content), to indicate that the requested action has been successfully performed or 578

submitted. In addition, they might include a response message body (with an appropriate media type) 579

containing a representation of the requested information. However, it is possible for a number of things to 580

go wrong. The various underlying causes are described (as discussed in the previous section) by various 581

HTTP status codes in the range 400-499 (for client side errors) or 500-599 (for server side problems). 582

If a response is returned with an error status code (400-499 or 500-599), where appropriate, the server is 583

encouraged to include a response message body containing an ErrorMessage object (as defined 584

below). The text values of such messages might be used, for example, to communicate with a human 585

user of the client side application. 586

The list of messages included in a single error response is encapsulated in the ErrorMessage data model. 587

The media type shall be returned in the Content-Type header. The client shall not include the 588

ErrorMessage media type in the Accept header. 589

Table 2 – ErrorMessage Data Model


message Message 0..n Zero or more message data for each individual

message.

An individual message contains the following fields: 590

Table 3 - Message Data Model


code String 0..1 Symbolic error code identifying the type of error

reported by this message



field String 0..1 Name of the field from the request data model

that this message is associated with

hint String 0..1 Localized text further describing the nature of

the problem, possibly including potential

workarounds that the client could try

text String 1 Localized text describing the nature of the

problem reported by this message

severity String 0..1 Label indicating the severity of the error

condition represented by this message

Vendor shall publish the enumerators that are

associated with this field and their semantics

stackTrace String 0..1 Vendor specific stack trace associated with this

message

source String 0..1 Symbolic identifier of the implementation

component that triggered this message

uri URI 0..1 A unique URI that reference this particular

message

namespace URI 0..1 A reference to the standard URI to indicate the

meaning of this message

The namespace attribute indicates the semantic meaning of the message which clients may handle 591

automatically. Messages with the same namespace shall adhere to the semantic requirements of that 592

namespace, but the payload (hint, text, severity, stackTrace) may be different. In other words, 593

given a namespace, clients processing the message should be able to subsequently interact with the 594

providers in a consistent manner across. 595

Each provider may extend the namespace to include specific scenarios and use cases. 596

The information captured in the message data element should be complementary to the HTTP status 597

code, and COULD provide more detailed information. However, it shall not contradict the HTTP status 598

code that is returned with the request. 599

The following table outlines the common namespace that would accompany this specification. 600

Table 4 - Common Message Namespace

Namespace Description

/msg/unknown Unknown error and information given is descriptive in nature

/msg/security Security issues

/msg/security/authentication An authentication error

/msg/access Access violation error



/msg/allocation Allocation related issues

/msg/allocation/insufficient Insufficient resource to satisfy the request

/msg/infrastructure Infrastructure related issues

/msg/infrastructure/maintenance The request cannot be immediately responded due to the

infrastructure being in maintenance status

5.5. Extensibility to the resource model

To support returning selective attributes, the following shall be observed by the service provider: 601

The attribute name of a resource shall contain alphanumeric characters with “_” and “-“. Thus, [a-602

zA-Z0-9_\-] 603

5.6. Platform

Media Type: application/vnd.org.example.PaaS+json;type=Platform 604

For a user, a Platform represents the user’s starting view of all accessible resources and deployed 605

entities. This resource has the following, general representation: 606

{ 607

"uri": URI, 608

"name": String, 609

"description": String, 610 "created": Timestamp, 611

"tags": [ 612

String, + 613 ], ? 614

"specificationVersion": String[], 615

"implementationVersion": String, ? 616

"assemblyTemplates": [ 617 {"href": URI}, + 618

], ? 619

"assemblies": [ 620 {"href": URI}, + 621

], ? 622

"platformComponentTemplates": [ 623 {"href": URI}, + 624

], ? 625

"platformComponentCapabilities": [ 626

{"href": URI}, + 627 ], ? 628

"platformComponents": [ 629

{"href": URI}, + 630 ], ? 631


"state": String, 633

"progress": String, ? 634 "messages": [ 635

{ Message }, + 636

] ? 637



} 638

} 639

The Platform resource contains the following attributes: 640

5.6.1. specificationVersion

Type: String[] 641

Cardinality: 1 642


This attribute lists the version(s) of this specification this instance the Platform supports. See section 6.8 644

for details on concurrent version support. 645

5.6.2. implementationVersion

Type: String 646



This attribute expresses the vendor specific version of the server implementation. 649

5.6.3. assemblyTemplates

Type: Link[] 650



Writeable: false 653

This attribute is an array of Links to the AssemblyTemplates that are accessible to the user. 654

5.6.4. assemblies

Type: Link[] 655




This attribute is an array of Links to the Assembly resources that are accessible to the user. 659

5.6.5. platformComponentTemplates

Type: Link[] 660




This attribute is an array of Links to the PlatformComponentRequirement resources that are accessible to 664

the user. 665

5.6.6. platformComponentCapabilities

Type: Link[] 666






This attribute is an array of Links to the PlatformComponentCapability resources that are accessible to 670

the user. 671

5.6.7. platformComponents

Type: Link[] 672




This attribute is an array of Links to the PlatformComponentCapability resources that are accessible to 676

the user. 677

5.6.8. resourceState

Type: ResourceState 678

Cardinality: 1 679



This attribute expresses state of the resource within the lifecycle. 682

5.7. AssemblyTemplate

Media Type: application/vnd.org.example.PaaS+json;type=AssemblyTemplate 683

For an Application Administrator, an Assembly Template represents the definition of the deployable 684

Application. Application Administrators can create an Assembly Instance by specifying the URI of a 685

Assembly Template as a field in a deployment request. The platform shall instantiate the Application 686

Components and their configurations as specified in the definition of the Assembly Template. This 687

resource has the following, general representation: 688

{ 689

"uri": URI, 690

"name": String, 691 "description": String, 692

"created": Timestamp, 693

"tags": [ 694

String, + 695 ], ? 696

"definition": String, 697

"basedOn": {"href": URI}, ? 698 "applicationComponentTemplates": [ 699

{"href": URI}, + 700

], ? 701

"platformComponentTemplates": [ 702 {"href": URI}, + 703

], ? 704

"dependencies": [ 705



{"href": URI}, + 706

] ? 707 } 708

The AssemblyTemplate resource contains the following attributes: 709

5.7.1. definition

Type: String 710

Cardinality: 1 711


Writeable: true 713

This attribute contains the definition of the AssemblyTemplate represented in some format, such as XML, 714

that contains the metadata necessary for the platform to deploy the Application. 715

5.7.2. basedOn

Type: Snapshot 716




The attribute contains the snapshot of the Assembly on which this AssemblyTemplate is based. 720

5.7.3. applicationComponentTemplates

Type: Link[] 721



Writeable: true 724

This attribute is an array of Links to the ApplicationComponentTemplate resources that are part of this 725

AssemblyTemplate. 726

5.7.4. platformComponentTemplates

Type: Link[] 727



Writeable: true 730

This attribute is an array of Links to the PlatformComponentTemplate resources that are part of this 731

AssemblyTemplate. 732

5.7.5. dependencies

Type: Link[] 733



Writeable: true 736



This attribute is an array of Links to the Dependency resources that are part of this AssemblyTemplate. 737

5.8. ApplicationComponentTemplate

Media Type: application/vnd.org.example.PaaS+json;type=ApplicationComponentTemplate 738

For an Application Administrator, an Application Component Template represents the definition of the 739

deployable Component. Application Administrators can create an Application Component by specifying 740

the URI of an Application Component Template (with referenced Application Component Templates) as a 741

field in a deployment request to create a standalone service. The cloud shall instantiate the Components 742

and their configurations as specified in the definition of the Application Component Template. This 743


{ 745 "uri": URI, 746

"name": String, 747


"tags": [ 750

String, + 751 ], ? 752


"basedOn": {"href": URI} ? 754

} 755

The ApplicationComponentTemplate resource contains the following attributes: 756

5.8.1. definition

Type: String 757

Cardinality: 1 758


Writeable: true 760

This attribute contains the definition of the ApplicationComponentTemplate represented in some format, 761

such as XML, that contains the metadata necessary for the platform to deploy the Application. 762

5.8.2. basedOn

Type: Snapshot 763




The attribute contains the snapshot of the ApplicationComponent on which this 767

ApplicationComponentTemplate is based. 768

5.9. ApplicationComponentRequirement

Media Type: application/vnd.org.example.PaaS+json;type=ApplicationComponentRequirement 769

For an Application Administrator, an Application Component Requirement represents an Application 770

Component’s requirement on another Application Component and its required range of component 771



capabilities. Each Application Component Requirement implements this class and adds its’ own Attribute 772

Ranges to the list below. This resource has the following, general representation: 773

{ 774

"uri": URI, 775 "name": String, 776

"description": String, 777


"tags": [ 779 String, + 780

], ? 781

"definition": String 782 } 783

The ApplicationComponentRequirement resource contains the following attributes: 784

5.9.1. definition

Type: String 785

Cardinality: 1 786


Writeable: true 788

This attribute contains the definition of the ApplicationComponentRequirement represented in some 789

format, such as XML, that contains the metadata necessary for the platform to deploy the Application. 790

5.10. ApplicationComponentCapability

Media Type: application/vnd.org.example.PaaS+json;type=ApplicationComponentCapability 791

For an Application Administrator, an Application Component Capability represents the definition of an 792

Applicaton Component’s range of component capabilities. This resource has the following, general 793

representation: 794

{ 795

"uri": URI, 796

"name": String, 797


"tags": [ 800

String, + 801 ], ? 802

"definition": String 803

} 804

Each Application Component Capability implements this class and adds its’ own Attributes to the list 805

below. 806

5.10.1. definition

Type: String 807

Cardinality: 1 808


Writeable: true 810



This attribute contains the definition of the ApplicationComponentCapability represented in some format, 811


5.11. PlatformComponentTemplate

Media Type: application/vnd.org.example.PaaS+json;type=PlatformComponentTemplate 813

For an Application Administrator, a Platform Component Template represents the desired configuration of 814

a Platform Component with specific values for the component capabilities. The specified value for each 815

component attribute shall be in the range defined in the corresponding Platform Component Capability. 816

This resource has the following, general representation: 817

{ 818

"uri": URI, 819



"tags": [ 823

String, + 824 ], ? 825

"definition": String 826

} 827

Each Platform Component implements this class and adds its own Component Attributes to the list below. 828

5.11.1. definition

Type: String 829

Cardinality: 1 830


Writeable: true 832

This attribute contains the definition of the PlatformComponentTemplate represented in some format, 833


5.12. PlatformComponentRequirement

Media Type: application/vnd.org.example.PaaS+json;type=PlatformComponentRequirement 835

For an Application Administrator, a Platform Component Requirement represents an Application 836

Component’s requirement on a Platform Component and its required range of component capabilities. 837

This resource has the following, general representation: 838

{ 839 "uri": URI, 840

"name": String, 841


"created": Timestamp, 843 "tags": [ 844

String, + 845

], ? 846 "definition": String 847

} 848



Each Platform Component Requirement implements this class and adds its own Attribute Ranges to the 849

list below. 850

5.12.1. definition

Type: String 851

Cardinality: 1 852


Writeable: true 854

This attribute contains the definition of the PlatformComponentRequirement represented in some format, 855


5.13. PlatformComponentCapability

Media Type: application/vnd.org.example.PaaS+json;type=PlatformComponentCapability 857

For an Application Administrator, a Platform Component Capability represents the definition of Platform 858

Component and its range of component capabilities. This resource has the following, general 859

representation: 860

{ 861




String, + 867

], ? 868 "definition": String 869

} 870

Each Platform Component Capability implements this class and adds its’ own Attributes to the list below. 871

5.13.1. definition

Type: String 872

Cardinality: 1 873


Writeable: true 875

This attribute contains the definition of the PlatformComponentCapability represented in some format, 876


5.14. Assembly

Media Type: application/vnd.org.example.PaaS+json;type=Assembly 878

For an Application Administrator, an Assembly represents the definition of the deployed Application at 879

runtime. This resource has the following, general representation: 880

{ 881






String, + 887

], ? 888

"definition": String, 889 "applicationComponents": [ 890

{"href": URI}, + 891

], ? 892 "platformComponents": [ 893

{"href": URI}, + 894

], ? 895 "assemblyTemplate": {"href": URI}, ? 896




{ Message }, + 901

] ? 902 } 903

} 904

The Assembly resource contains the following attributes: 905

5.14.1. definition

Type: String 906

Cardinality: 1 907


This attribute contains the definition of the Assembly represented in some format, such as XML, that 909

contains the metadata necessary for the platform to deploy the Application. 910

5.14.2. applicationComponents

Type: Link[] 911



This attribute is an array of Links to the ApplicationComponent resources that are part of this Assembly. 914


Type: Link[] 915



This attribute is an array of Links to the PlatformComponent resources that are part of this Assembly. 918

5.14.4. assemblyTemplate

Type: Link 919

Cardinality: 1 920




This attribute is a Link to the AssemblyTemplate resource from which this Assembly was created. 922



Cardinality: 1 924




5.15. ApplicationComponent

Media Type: application/vnd.org.example.PaaS+json;type=ApplicationComponent 928

For an Application Administrator, an Application Component represents the management of the deployed 929

Component at runtime. This resource has the following, general representation: 930

{ 931

"uri": URI, 932



"tags": [ 936 String, + 937

], ? 938


"applicationComponents": [ 940 {"href": URI} + 941

], ? 942

"platformComponents": [ 943 {"href": URI}, + 944

], ? 945


"state": String, 947 "progress": String, ? 948

"messages": [ 949

{ Message }, + 950 ] ? 951

} 952

} 953

The ApplicationComponent resource contains the following attributes: 954

5.15.1. definition

Type: String 955

Cardinality: 1 956


This attribute contains the definition of the ApplicationComponent represented in some format, such as 958

XML, that contains the metadata necessary for the platform to deploy the Application. 959



5.15.2. applicationComponents

Type: Link[] 960



This attribute is an array of Links to the ApplicationComponent resources that this ApplicationComponent 963

depends on. 964


Type: Link[] 965



This attribute is an array of Links to the PlatformComponent resources that this ApplicationComponent 968

depends on. 969



Cardinality: 1 971




5.16. PlatformComponent

Media Type: application/vnd.org.example.PaaS+json;type=PlatformComponent 975

For an Application Administrator, a Platform Component represents the runtime instance of a platform 976

component and its configuration of component attributes as well as metrics associated with those 977

attributes. This resource has the following, general representation: 978

{ 979

"uri": URI, 980



"tags": [ 984

String, + 985 ], ? 986


"externalManagementResource": URI, ? 988 "resourceState": { 989



{ Message }, + 993

] ? 994

} 995 } 996



Each Platform Component implements this class and adds its own attributes and to the list below. 997

5.16.1. definition

Type: String 998

Cardinality: 1 999


This attribute contains the definition of the PlatformComponent represented in some format, such as 1001


5.16.2. externalManagementResource

Type: URI 1003



A URI to an external management interface to manage this platform component (such as an IaaS API to 1006

manage the virtual machines that support this component). This is platform dependent and requires 1007

external documentation to understand its meaning. 1008



Cardinality: 1 1010






6. Protocol

6.1. Transport Protocol

All of The Platform APIs are based on the Hypertext Transfer Protocol, version 1.1 [RFC2616]. Each 1014

request will be authenticated using HTTP Basic Authentication [RFC2617] unless otherwise noted. 1015

Therefore, requests sent from clients across unsecured networks should use the HTTPS protocol. TLS 1016

1.1 [RFC4346] shall be implemented by the provider and TLS 1.2 [RFC5246] is strongly encouraged. 1017

When TLS is implemented, the following cipher suites shall be supported to ensure a minimum level of 1018

security and interoperability between implementations: 1019

TLS_RSA_WITH_AES_128_CBC_SHA (mandatory for TLS 1.1/1.2) 1020

TLS_RSA_WITH_AES_256_CBC_SHA256 (addresses 112-bit security strength requirements) 1021

TLS_RSA_WITH_NULL_SHA (for TLS without encryption) 1022

6.2. URI Space

The resources in the system are identified by URIs. To begin operations, a client shall know the URI for a 1023

resource. Dereferencing the URI will yield a representation of the resource containing resource attributes 1024

and links to associated resources. 1025

Clients shall not make assumptions about the layout of the URIs or the structure of the URIs of the 1026

resources. 1027

6.3. Media Types

In this specification, resource representations and request bodies are encoded in JSON, as specified in 1028

[RFC4627]. 1029

Each type of resource has its own media-type, which matches the pattern 1030

application/vnd.org.example.PaaS+json;type=Xxxxx, where “Xxxxx” represents the portion of the identifier 1031

unique to a particular resource type. The identifier shall be unique within the namespace of 1032

vnd.org.example.PaaS, and the media type should be registered in accordance to [RFC4288]. 1033

Note: The media types of the resources defined in this specification is an 1034

active area of discussion, and the authors seek feedback from readers and 1035

developers on this topic1. 1036

The Platform shall provide representations of all resources available in JSON, but other formats are 1037

allowed. This specification doesn't define any schemata or aid in validating an XML encoding. 1038

The Platform shall accept requests from clients encoded in JSON. 1039

If alternative formats are supported they shall be supported uniformly for all resources. 1040

1 The authors are aware that using the type parameter in the Content-Type HTTP header field is an

issue for Python.



6.4. Request Headers

This API does not impose any requirements on clients’ use of HTTP headers. All PUT requests that 1041

update a resource SHOULD contain the If-Match header field with a single entity tag value. If the If-1042

Match header field value in the request does not match the one on the server-side, the server MUST 1043

send back a '412 Precondition Failed' status code. 1044

6.5. Request Parameters

In order to address a subset of attributes in a resource, the client can use request parameters in GET and 1045

PUT requests to formulate the following 1046

Table 5 – Request Parameters

Format Description Example

?SelectAttr=attr

1,attr2,…

Comma (“,”) separated attribute names of

the resource to return.

If an attribute is not part of the resource,

an HTTP 4XX status code shall be

returned.

Assembly132?SelectAttr

=name,description,status

Would access only “name”, “description”,

“status” attributes of Assembly132.

The “SelectAttr” query parameter may appear more than once (separated by an “&”). The client shall URL 1047

encode the request parameters. 1048

When one or more request parameters are specified for a PUT request, a client shall not include 1049

attributes in the request entity body that are not specified in the request parameter. Upon receiving such a 1050

request the server shall respond with a 400 status code. 1051

6.6. Response Headers

Responses returned by the Platform makes standard use of HTTP headers. All HTTP responses that 1052

return representation of a resource SHOULD use strong ETag response header field indicating the 1053

current value of the entity tag for the resource. 1054

6.7. HTTP Status Codes

The API returns standard HTTP response codes. 1055

6.8. Concurrent API versions

Multiple API versions may be offered concurrently to allow backward compatibility for clients. To discover 1056

available versions a client issues a GET request for the <platform-url>/api/versions resource 1057

and may select one of the listed versions. Each available API version is assigned a namespace identified 1058

by a URL. 1059

The response to a GET request for <platform-url>/api/versions will include a list of available API 1060

versions and the URL where each version may be accessed. The list of available versions shall be 1061

expressed using the common Link type with an additional name version added to the link and its 1062

corresponding value. 1063

An example of client requests to the platform are as follows: 1064



GET / => {…, "links": […, "/api/versions", …], …} 1065

1066 GET /api/versions => [ 1067

{"version" : "1.0", "href": "http://paas.example.org/"}, 1068

{"version" : "1.1", "href": "http://api.example.org/foo"}, 1069

] 1070

Only versions defined by a CAMP specification can be listed. Additional features not defined in this 1071

specification can be implemented using the extensibility features discussed in this specification. 1072

6.9. Registering a PDP

As indicated in Section 3, registering a package moves it to the deployed state. To register a PDP, a 1073

client sends a POST HTTP request to the Platform URL. The entity body of the request contains the URI 1074

that identifies the PDP that is being registered. If the URI that identifies the PDP is a relative URI, its base 1075

URI is the Platform URI. The JSON serialization of the HTTP request entity body is: 1076

{"pdp_uri" : "<uri-of-the-pdp>"} 1077

Where, the pdp_uri points to the URI of the PDP to be registered. The JSON object MAY contain 1078

additional name-value pairs that are not defined in this specification. On successful registration of the 1079

PDP, the server creates an AssemblyTemplate resource and sends a 201 Created HTTP status code with 1080

the Location header in the HTTP response. The Location header points to the newly created 1081

AssemblyTemplate resource. The server also updates the application_templates attribute of the 1082

Platform resource to include a reference to the newly created assembly template. 1083

An example HTTP request-response is as follows: 1084

POST /<platform-url> HTTP/1.1 1085 Host: example.org 1086

Content-Type: application/vnd.org.example.PaaS +json;type=Xxxxx 1087

Content-Length: ... 1088 1089

{"pdp_uri": "/paas/pdp/1"} 1090

1091 HTTP/1.1 201 Created 1092

Location: http://example.org/paas/asm_template/1 1093

Content-Type: ... 1094


... 1097

6.10. Instantiating an Application

Once the application is in the deployed state, a client can instantiate the application by sending a POST 1098

HTTP request to the corresponding AssemblyTemplate URL. The entity body of the request can be 1099

empty. Interpretation of a non-empty entity body of the request is implementation-dependent. On success 1100

the server creates an Assembly resource and sends a 201 Created HTTP status code with the Location 1101

header in the HTTP response. The Location header points to the newly created Assembly resource. 1102

The server also updates the AssemblyInstances attribute of the Platform resource to include a 1103

reference to the newly created assembly. 1104


http://example.org/paas/asm_template/1



POST /paas/asm_template/1 HTTP/1.1 1106

Host: example.org 1107 1108


Location: http://example.org/paas/assembly/1 1110

Content-Type: ... 1111 Content-Length: ... 1112

1113

... 1114

6.11. Suspending and Resuming an Application

To suspend, or resume an application, a client sends a POST HTTP request to the assembly resource 1115

URL. The entity body of the request contains the value of the new state for the application. The JSON 1116

serialization of the HTTP request entity body is: 1117

{"new_state" : "<new-state-value>"} 1118

Where, new_state specifies the new desired value for the application state. This specification defines 1119

two such values: "suspend", and "resume," whose semantics are as defined in Section 3. An 1120

implementation MAY have additional state values that it allows. The JSON object MAY contain additional 1121

name-value pairs that are not defined in this specification. An implementation can define additional state 1122

values or name-value pairs, to allow clients to specify the scale at which the application is suspended and 1123

resumed. 1124


POST /<assembly-resource-url> HTTP/1.1 1126 Host: example.org 1127

Content-Type: application/vnd.org.example.PaaS +json;type=Xxxxx 1128


{"new_state": "suspend"} 1131

1132

HTTP/1.1 200 OK 1133

6.12. Deleting an Application Instance and a Deployed Application

To delete an application instance (an assembly), a client sends a DELETE HTTP request to the assembly 1134

resource URL. Similarly, to delete a deployed application, a client sends a DELETE HTTP request to the 1135

assembly template URL. 1136

7. Normative References

[RFC2119] 1137

S. Bradner, “Key words for use in RFCs to Indicate Requirement Levels”, IETF RFC 2119, March 1138

1997 1139

http://www.ietf.org/rfc/rfc2119.txt 1140

[RFC2616] 1141

R. Fielding et al, “Hypertext Transfer Protcol – HTTP/1.1”, IETF RFC 2616, June 1999 1142

http://www.w3.org/Protocols/rfc2616/rfc2616.html 1143

[RFC2617] 1144

http://www.ietf.org/rfc/rfc2119.txt

http://www.w3.org/Protocols/rfc2616/rfc2616.html



J. Franks et al, “HTTP Authentication: Basic and Digest Access Authentication”, IETF RFC 2617, 1145

June 1999 1146


[RFC 3986] 1148

T.Berners-Lee et al, “Uniform Resource Identifiers (URI): Generic Syntax”, IETF RFC 3986, August 1149

1998 1150


[RFC4288] 1152

N. Freed, J. Klensin, “Media Type Specifications and Registration Procedures”, IETF RFC 4288, 1153

December 2005 1154


[RFC4346] 1156

T. Dierks, E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2”, IETF RFC 4346, 1157

April 2006 1158


[RFC4627] 1160

D. Crockford, “The application/json Media Type for JavaScript Object Notation (JSON)”, IETF RFC 1161

4627, July 2006 1162


[RFC5246] 1164

T. Dierks, E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2”, IETF RFC 5246, 1165

August 2008 1166


[ISO 8601:20044] 1168

International Organization for Standardization, Geneva, Switzerland, “Data elements and interchange 1169

formats -- Information interchange - - Representation of dates and times”, March 2008 1170

http://www.iso.org/iso/iso_catalogue/ catalogue_tc/catalogue_detail.htm?csnumber=40874 1171

8. Non-Normative References

[SP800-145] 1172

Peter Mell, Timothy Grance, “The NIST Definition of Cloud Computing”, Special Publication 800-145, 1173

September 2011 1174

http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf 1175

[OVF] 1176

Distributed Management Task Force, “Open Virtualization Format Specification”, DSP0243, 12 1177

January 2010 1178

http://www.dmtf.org/sites/default/files/standards/documents/DSP0243_1.1.0.pdf 1179

[Git] 1180

The Software Freedom Conservancy, “Git, the fast version control system”, March 2012 1181

http://git-scm.com/ 1182







http://www.iso.org/iso/iso_catalogue/%20catalogue_tc/catalogue_detail.htm?csnumber=40874

http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf

http://www.dmtf.org/sites/default/files/standards/documents/DSP0243_1.1.0.pdf

http://git-scm.com/



Annex A. Glossary

application – a set of components that act together to provide useful functions and are typically exposed 1183

as a service to Application end-users. An application is represented by different resources (e.g. Assembly 1184

Template, Assembly) throughout its lifecycle. 1185

Application Component – a collection of code, resources and metadata that provides a set of related 1186

services or functionality. Examples include a Java library, or a PHP module. 1187

Application Component Capability – a management resource that represents an Application 1188

Component’s capabilities. 1189

Application Component Requirement – a management resource that represents a requirement on an 1190

Application Component, expressed with attributes that may have value ranges. 1191

Application Component Template - a management resource that represents an unrealized Application 1192

Component and includes a reference to the executable code as well as metadata for configuring the 1193

Application Component and referencing its platform and other components. 1194

Application Development Environment (ADE) – a developer tool used to create an application (can be 1195

an offline tool installed locally or part of the platform offering itself). 1196

Assembly – a management resource that represents a running application. 1197

Assembly Template - a management resource that represents an unrealized Assembly and includes a 1198

reference to the Application Component Templates used within the Application as well as metadata for 1199

configuring the Application Component and referencing its platform and other components. 1200

Deploy – the step of creating one or more management resources on the platform. Deployment can be 1201

done through the API for individual management resources (i.e via a POST to a URI), or can be done as 1202

part of the import of a Platform Deployment Package. 1203

Deployment Plan - packaging management meta-data that includes a serialized copy of the Assembly 1204

Template resource and all dependent management resources such as Application Component 1205

Templates. Deployment Plans are an essential part of a Platform Deployment Package. 1206

Platform – The collection of management resources that constitute the consumer visible view of the 1207

Platform as a Service offering. The Platform management resource is an aggregation and discovery 1208

point for all the Applications and their dependencies currently deployed and running. 1209

Platform as a Service (PaaS) - A type of cloud computing in which the service provider offers 1210

customers/consumers access to one or more instances of a running application computing platform or 1211

application service stack. 1212

Platform Component – a management resource that represents an application’s use of a realized and 1213

running Platform Component. 1214

Platform Component Capability – a management resource that represents a Platform Component’s 1215

capabilities. 1216

Platform Component Requirement – a management resource that represents a requirement on a 1217

Platform Component, expressed with attributes that may have value ranges. 1218



Platform Component Template - a management resource that represents an unrealized Platform 1219

Component and includes references to metadata for configuring an instance of that Platform Component. 1220

Platform Deployment Package (PDP) - an archive of executable images, dependency descriptions and 1221

metadata (Management Resources serialized into a Deployment Plan) that can be used to move an 1222

Application and its Components from Platform to Platform, or between an Application Development 1223

Environment and a Platform (e.g. a storefront application with component binaries, database images and 1224

all the configurations needed to install and run). 1225

Annex B. Use Cases (Non-Normative)

The following is non-exhaustive list of detailed use cases addressed by this specification. 1226

B.1. Building the Application

B.1.1. Build Application and Package

The Application Developer selects a local Application Development Environment (ADE) and uses it to 1227

build an application. The ADE may be aware of the Platform Components that are available in the target 1228

platform for the application and may provide the developer with assistance in consuming these 1229

Components. Once built, the Components that make up the application are packaged along with any 1230

necessary metadata as part of a deployment package. The output of the ADE is a Platform Deployment 1231

Package (PDP) with bundled Component executables (including language specific packages such as 1232

.war files) and Metadata included in the deployment plan (including the requirements for Platform 1233

Component elements). This is shown in the Figure below. 1234

Figure 9 - Platform Deployment

If the platform is using an IaaS infrastructure, there will be additional packages for the deployment of 1235

Platform Components virtual machines referenced by the metadata in the PDP as shown below: 1236



Figure 10 - Platform Deployment with IaaS

This shows the configuration of Platform Components in a virtual machine configuration and packaging 1237

tool, which outputs OVF [OVF] packages (one for each Platform Component). These OVF packages are 1238

then deployed in an Infrastructure as a Service environment, creating the platform. The PaaS 1239

Management API will include extension points for the Platform Components that allow the administrator to 1240

invoke the IaaS management API to manage the Platform Components. 1241

B.1.2. Build Application in the Cloud and Optionally Package

This use case is the same as that described in the previous section except for the following: 1242

The ADE is itself an application that may be deployed on the Platform (see SaaS). 1243

The ADE is aware of the Platform Components that are available on the Platform for the 1244

Application. 1245

If the target platform for the application is “the same” as the platform that hosts the ADE, the 1246

packaging, registering and instantiation process may be simplified. 1247



Figure 11 - ADE Development to a Platform

B.2. Deploying and Managing the Application

To deploy an application the Application Administrator shall have an account with the platform provider 1248

and access to the required resources. Assume that Assembly Templates, Application Component 1249

Templates and Platform Component Templates have already been created in the ADE and serialized into 1250

a Platform Deployment Package as shown below: 1251

Figure 12 - Platform Deployment Package (PDP)



B.2.1. Import Platform Deployment Package

This allows the Application Administrator to import a Platform Deployment Package and that creates the 1252

corresponding Management Resources on the Platform. The Platform Deployment Package is unpacked 1253

and Assembly Templates, Application Component Templates and their Platform Component Templates 1254

are realized in the API as Management Resources and an Assembly Instance can then be created that is 1255

ready to run. Any resources that the Components depend on are created as well. The inverse export 1256

operation creates a Platform Deployment Package from a given set of Management Resources. The 1257

imported Management Resources are shown in the Figure below: 1258

Figure 13 - Imported Platform Deployment Package

B.2.2. Upload Application

Instead of importing a Platform Deployment Package, the PaaS Management API also supports 1259

uploading of application files, be it code, configuration, or data files, in full or in part. The typical use case 1260

is that of “pushing” incremental updates (“diffs”) as one would when using a version control system such 1261

as Git [Git]. However, this upload mechanism is not limited to incremental uploads. It may also be used to 1262

upload applications in their entirety. 1263



B.2.3. Run/Stop/Suspend/Snapshot

This allows the Application Administrator to run an Assembly or individual Application Components, stop 1264

them, put them into suspension or snapshot them. Assemblies in suspension can be restarted and 1265

Assemblies can be restarted from snapshots. 1266

B.2.4. Patch an Application Component Template

Replaces one or more Application Component Templates within an Assembly Template with, usually, 1267

updated versions. These updated templates will be used the next time an Assembly Instance is created 1268

from the Assembly Template or when already created Assemblies take up the change. 1269

B.2.5. Patch a Created, Deployed or Running Application

This operation replaces one or more Application Component Templates within the Assembly Template 1270

associated in a deployed or running Assembly. The updated templates are used the next time the 1271

Assembly or an Application Component within the Assembly Instance is deployed. 1272

Annex C. Example Database Platform Component (Non-Normative)

One important Platform Component that can be provided by many platforms is a database. The following 1273

sections illustrate how database components could be provided by extending the model defined in this 1274

specification. The material in these sections is non-normative. 1275

C.1. Model

A Database Platform Component provides four sub-classed resources as shown in the below diagram: 1276

Figure 14 - Database Platform Component Model

C.2. DatabaseCapability

Media Type: application/vnd.org.example.PaaS+json;type=DatabaseCapability 1277



For an Application Administrator, a Database Capability represents the definition of a database platform 1278

component and its range of capabilities. This resource has the following, general representation: 1279

{ 1280




"tags": [ 1285 String, + 1286

], ? 1287

"definition": String, 1288 "clusterTypes": [ 1289

String, + 1290

], 1291

"maxNumberNodes": String, 1292 "maxCores": String, 1293

"maxMemSize": String, 1294

"maxDiskSize": String, 1295 "backupAvailable": Boolean, 1296

"synchronousCopyAvailable": Boolean, 1297

"partitionAvailable": Boolean, 1298 "compressionAvailable": Boolean, 1299

"retentionAvailable": Boolean, 1300

"tunings": [ 1301

String, + 1302 ], 1303

"cachingAvailable": Boolean, 1304

} 1305

Each type of DatabasePlatformComponent implements this class and populates the attributes in the list 1306

below. 1307

C.2.1. definition

Type: String 1308

Cardinality: 1 1309



This attribute contains the definition of the DatabaseCapability represented in some format, such as XML, 1312


C.2.2. clusterTypes

Type: String[] 1314

Cardinality: 1 1315



An array of supported cluster types. Values include: “active” and “passive”. 1318



C.2.3. maxNumberNodes

Type: String 1319

Cardinality: 1 1320



Expresses the maximum number of supported nodes for scaling purposes. 1323

C.2.4. maxCores

Type: String 1324

Cardinality: 1 1325



Expresses the maximum number of supported cores for scaling purposes. 1328

C.2.5. maxMemSize

Type: String 1329

Cardinality: 1 1330



Expresses the maximum size of supported memory for an instance. 1333

C.2.6. maxDiskSize

Type: String 1334

Cardinality: 1 1335



Expresses the limit to the size of a disk for an instance. 1338

C.2.7. backupAvailable

Type: Boolean 1339

Cardinality: 1 1340



true if backup can be enabled. 1343

C.2.8. synchronousCopyAvailable

Type: Boolean 1344

Cardinality: 1 1345





true if synchronous copy can be enabled 1348

C.2.9. partitionAvailable

Type: Boolean 1349

Cardinality: 1 1350



true if partitioning can be enabled 1353

C.2.10. compressionAvailable

Type: Boolean 1354

Cardinality: 1 1355



true if compression can be enabled 1358

C.2.11. retentionAvailable

Type: Boolean 1359

Cardinality: 1 1360



true if retention can be enabled 1363

C.2.12. tunings

Type: String[] 1364

Cardinality: 1 1365



An array of supported tuning types. Values include: “OLAP”, “DataMining”, and “Spatial” 1368

C.2.13. cachingAvailable

Type: Boolean 1369

Cardinality: 1 1370



true if caching can be enabled 1373

C.3. DatabaseRequirement

Media Type: application/vnd.org.example.PaaS+json;type=DatabaseRequirement 1374



For an Application Administrator, a Database Requirement represents an Application Component’s 1375

requirements on a database platform component and its required range of capabilities. This resource has 1376

the following, general representation: 1377

{ 1378

"uri": URI, 1379



"tags": [ 1383 String, + 1384

], ? 1385


"clusterTypes": [ 1387 String, + 1388

], 1389

"numberNodesRange": String, 1390 "coreRange": String, 1391

"memSizeRange": String, 1392

"diskSizeRange": String, 1393

"backupEnabled": Boolean, 1394 "synchronousCopyEnabled": Boolean, 1395

"partitionEnabled": Boolean, 1396

"compressionEnabled": Boolean, 1397 "retentionEnabled": Boolean, 1398

"tunings": [ 1399

String, + 1400 ], 1401

"cachingEnabled": Boolean 1402

} 1403

Each type of DatabaseRequirement implements this class and populates the attributes in the list below. 1404

C.3.1. definition

Type: String 1405

Cardinality: 1 1406


Writeable: true 1408

This attribute contains the definition of the DatabaseRequirement represented in some format, such as 1409


C.3.2. clusterTypes

Type: String[] 1411

Cardinality: 1 1412



An array of required cluster types. Values include: “active” and “passive”. 1415



C.3.3. numberNodesRange

Type: String 1416

Cardinality: 1 1417



Expresses the range of the number of nodes for scaling purposes 1420

C.3.4. coreRange

Type: String 1421

Cardinality: 1 1422



Expresses the required range of number of cores. 1425

C.3.5. memSizeRange

Type: String 1426

Cardinality: 1 1427



Expresses the range of required memory sizes. 1430

C.3.6. diskSizeRange

Type: String 1431

Cardinality: 1 1432



Expresses the range if disk sizes required. 1435

C.3.7. backupEnabled

Type: Boolean 1436

Cardinality: 1 1437



true if backup is required. 1440

C.3.8. synchronousCopyEnabled

Type: Boolean 1441

Cardinality: 1 1442





true if synchronous copy is required. 1445

C.3.9. partitionEnabled

Type: Boolean 1446

Cardinality: 1 1447



true if partitioning is required. 1450

C.3.10. compressionEnabled

Type: Boolean 1451

Cardinality: 1 1452



true if compression is required. 1455

C.3.11. retentionEnabled

Type: Boolean 1456

Cardinality: 1 1457



true if retention is required. 1460

C.3.12. tunings

Type: String[] 1461

Cardinality: 1 1462



An array of required tuning types. Values include: “OLAP”, “DataMining” and “Spatial”. 1465

C.3.13. cachingEnabled

Type: Boolean 1466

Cardinality: 1 1467



true if caching is required. 1470

C.4. DatabaseTemplate

Media Type: application/vnd.org.example.PaaS+json;type=DatabaseTemplate 1471



A Database Template represents the desired configuration of a Database Platform Component with 1472

specific values for the component capabilities. The specified value for each component attribute shall be 1473

in the range defined in the corresponding Database Capability. Some PaaS offerings might only offer a 1474

fixed number of Database Template instances that cannot be modified (read-only, no new instances) 1475

indicating pre-tuned and configured pools of database resources from which these draw. Other PaaS 1476

offerings may allow newly created Database Template instances with values in any combination. This 1477


{ 1479




"tags": [ 1484 String, + 1485

], ? 1486

"definition": String, 1487 "clusterType": String, 1488

"numberNodes": String, 1489

"cores": String, 1490

"memSize": String, 1491 "diskSize": String, 1492

"backupEnabled": Boolean, 1493

"synchronousCopyEnabled": Boolean, 1494 "partitionEnabled": Boolean, 1495

"compressionEnabled": Boolean, 1496

"retentionEnabled": Boolean, 1497 "tuning": String, 1498

"cachingEnabled": Boolean 1499

} 1500

Each type of DatabaseTemplate implements this class and populates the attributes in the list below. 1501

C.4.1. definition

Type: String 1502

Cardinality: 1 1503



This attribute contains the definition of the DatabaseTemplate represented in some format, such as XML, 1506


C.4.2. clusterType

Type: String 1508

Cardinality: 1 1509



The desired cluster type. Values include: “active” and “passive” 1512



C.4.3. numberNodes

Type: String 1513

Cardinality: 1 1514



The desired number of nodes for an instance 1517

C.4.4. cores

Type: String 1518

Cardinality: 1 1519



The desired number of cores for an instance 1522

C.4.5. memSize

Type: String 1523

Cardinality: 1 1524



The desired size of memory for an instance 1527

C.4.6. diskSize

Type: String 1528

Cardinality: 1 1529



The desired size of a disk for an instance. 1532


Type: Boolean 1533

Cardinality: 1 1534



true if backup is desired for an instance. 1537


Type: Boolean 1538

Cardinality: 1 1539





true if synchronous copy is desired for an instance. 1542


Type: Boolean 1543

Cardinality: 1 1544



true if partitioning is desired for an instance 1547


Type: Boolean 1548

Cardinality: 1 1549



true if compression is desired for an instance 1552


Type: Boolean 1553

Cardinality: 1 1554



true if retention is desired for an instance 1557

C.4.12. tuning

Type: String 1558

Cardinality: 1 1559



The desired tuning types. Values include: “OLAP”, “DataMining” and “Spatial” 1562


Type: Boolean 1563

Cardinality: 1 1564



true if caching is desired for an instance 1567

C.5. Database

Media Type: application/vnd.org.example.PaaS+json;type=Database 1568



A Database represents the runtime instance of a Database Template and its configuration of component 1569

attributes as well as metrics associated with those attributes. Each Application’s use of a Database is 1570

represented by an instance of this resource. This resource has the following, general representation: 1571

{ 1572

"uri": URI, 1573



"tags": [ 1577 String, + 1578

], ? 1579


"externalManagementResource": String, 1581 "clusterType": String, 1582

"numberNodes": String, 1583

"cores": String, 1584 "memSize": String, 1585

"diskSize": String, 1586

"backupEnabled": Boolean, 1587

"synchronousCopyEnabled": Boolean, 1588 "partitionEnabled": Boolean, 1589

"compressionEnabled": Boolean, 1590

"retentionEnabled": Boolean, 1591 "tuning": String, 1592

"cachingEnabled": Boolean, 1593

"operationsThroughput": String, 1594 "operationsBandwidth": String, 1595




{ Message }, + 1600

] ? 1601 } 1602

} 1603

Each type of Database implements this class and populates the attributes in the list below. 1604

C.5.1. definition

Type: String 1605

Cardinality: 1 1606


This attribute contains the definition of the Database represented in some format, such as XML, that 1608

contains the metadata necessary for the platform to deploy the Application. 1609

C.5.2. externalManagementResource

Type: URI 1610





A URI to an external management interface to manage this platform component (such as an IaaS API to 1613

manage the virtual machines that make up this database). This is platform dependent and requires 1614

external documentation to understand its meaning. 1615

C.5.3. clusterType

Type: String 1616

Cardinality: 1 1617


The actual cluster type. Values include: “active” and “passive” 1619

C.5.4. numberNodes

Type: String 1620

Cardinality: 1 1621


The actual number of nodes for an instance. 1623

C.5.5. cores

Type: String 1624

Cardinality: 1 1625


The actual number of cores for an instance. 1627

C.5.6. memSize

Type: String 1628

Cardinality: 1 1629


The actual size of memory for an instance. 1631

C.5.7. diskSize

Type: String 1632

Cardinality: 1 1633


The actual size of a disk for an instance. 1635


Type: Boolean 1636

Cardinality: 1 1637


true if backup is enabled for this instance. 1639


Type: Boolean 1640



Cardinality: 1 1641


true if synchronous copy is enabled for this instance. 1643


Type: Boolean 1644

Cardinality: 1 1645


true if partitioning is enabled for this instance. 1647


Type: Boolean 1648

Cardinality: 1 1649


true if compression is enabled for this instance. 1651


Type: Boolean 1652

Cardinality: 1 1653


true if retention is enabled for this instance. 1655

C.5.13. tuning

Type: String 1656

Cardinality: 1 1657


The actual tuning type of the database instance. Values include: “OLAP”, “DataMining” and “Spatial” 1659


Type: Boolean 1660

Cardinality: 1 1661


true if caching is enabled for this instance. 1663

C.5.15. operationsThroughput

Type: String 1664

Cardinality: 1 1665



The billable operations per second. 1668



C.5.16. operationsBandwidth

Type: String 1669

Cardinality: 1 1670



The billable MegaBytes per second. 1673

C.5.17. resourceState


Cardinality: 1 1675



This attribute expresses state of the database instance within its lifecycle. 1678

Annex D. Implementation Considerations (Non-

Normative)mplementation Considerations (Non-Normative)

D.1. Types of Platform Deployments

Platforms can be built with resources that provide isolation at different levels. For example, each Platform 1679

Component (e.g. application server, database) can sit atop a stack of virtual machine, operating system, 1680

and component, as seen below: 1681

Figure 15 - Platform Component Virtual Machine Isolation

The point of isolation in the above is the virtual machine. 1682

The level at which isolation is provided has profound effects upon the way in which Platform Components 1683

are managed and secured. In the above example, each consumer is provided with a dedicated VM, OS, 1684

and Platform Component. It is likely (though not certain) that, in the above model, the Consumer will 1685

perform both the Application Administrator and the Platform Administrator roles - managing not only their 1686

application but also the underlying infrastructure including, potentially, the operating system. 1687

Platform Components can also be deployed without a hypervisor, and instead use multiple Platform 1688

Components running on a single OS as shown below: 1689



Figure 16 - Platform Component Operating System Isolation

The point of isolation in the above is the operating system. 1690

Although the consumer may still perform both the Application Administrator and some portions of the 1691

Platform Administrator roles, for obvious security reasons consumers cannot be allowed control of the 1692

operating system as a single OS can be shared by multiple consumers. 1693

Lastly, the Platform Component container itself can offer virtualize instances of the Platform Component 1694

to each consumer and isolate multiple consumers from each other as shown below: 1695

Figure 17 - Platform Component Container Isolation

The point of isolation in the above is the Platform Component container. 1696

In the above case the consumer can only act as an Application Administrator. The tasks of configuring 1697

and managing the Platform Component container (tasks assigned to the Platform Administrator) can only 1698

be performed by the cloud provider. 1699

This PaaS Management API is agnostic with respect to the above deployment models as it deals only 1700

with the management of an Application’s dependencies on various Platform Components and not with the 1701

lifecycle of the Platform Components themselves. The API may be extended to include the management 1702

of Platform Component containers, Platform Components, operating systems, and other infrastructural 1703

elements. 1704

D.2. Scaling

The PaaS Management API assumes that applications are organized architecturally in tiers, some of 1705

which are hosted on the platform, while others may be external to the platform (and hence unmanaged). 1706

Each tier may consist of one or more components. For example, the “application tier” of a PHP 1707

application may be implemented by a mod_php component combined with an Apache component. 1708

Components in turn can be either provided by the platform or by the application itself. 1709

Conceptually, scaling operations affect individual application tiers. In practice however, since tiers are 1710

composed of Application and Platform Components, this means they affect Components. In addition, 1711

scaling operations are also specific to each Component and may be subject to explicit or implicit 1712



restrictions and policies imposed by the Component on both, scaling operations and grouping. For 1713

instance, a Component such as a database may be inherently non-replicable. Conversely, a Component 1714

such as PHP module may need to be in the same group as its hosting Apache instance because it needs 1715

to be dynamically loaded into the latter--even though it can scale out without limit. 1716

Individual Components may define events and policies for implementing auto-scaling. For instance, a 1717

multithreaded webserver component may trigger a scale-up if the number of idle worker threads drops 1718

below a given threshold. Or a MongoDB component may impose a policy that scaling may only happen in 1719

increments of 3 nodes. 1720

Scaling operations may also be performed directly on the Application Component’s Platform Component 1721

resources. This is known as manual scaling and generally results in a new reservation being created in 1722

the platform’s auto-scaling setup. Other forms of scaling may require changes to how the Assembly 1723

Template uses Application Component Templates and Platform Component Templates. The actual 1724

scaling architecture for a Platform Component is outside the scope of this specification. 1725

Cloud Application Management for Platforms · agree to grant you a royalty-free license, under reasonable, non-discriminatory terms and conditions to patents that they deem necessary

Documents