CampIssue17-ModelChanges-r3-NoMapx - Oasis

whooshribbitSoftware and s/w Development

Dec 2, 2013 (3 years and 6 months ago)

132 views

camp
-
spec
-
v1.1
-
wd07

Working Draft 0
7

05 March

2013

Standards Track
Draft

Copyright
©

O
ASIS Open 201
2, 2013
. All Rights Reserved.

Page
1

of
16

camp
-
spec
-
v1.1
-
wd07

Working Draft 0
7

05 March

2013

Standards Track
Draft

Copyright
©

O
ASIS Open 201
2, 2013
. All Rights Reserved.

Page
2

of
16

1

Introduction

camp
-
spec
-
v1.1
-
wd07

Working Draft 0
7

05 March

2013

Standards Track
Draft

Copyright
©

O
ASIS Open 201
2, 2013
. All Rights Reserved.

Page
3

of
16

2

Architecture

2.1

Management Model

This document specifies the self
-
service management API that a Platform as a Service offering presents
to the consumer of the platform. The API is typically the interface into a platform implementation layer that
controls the deployment of applications and their use of the platform.


Figure
1

-

Typical PaaS Architecture

The figure above shows a typical architecture of a Platform as a Service cloud. The platform
implementation is a
management client of the underlying resources that transforms (through policies) the
application requirements expressed by the Application Administrator into provisioning and other
operations on those resources. The Platform Administrator manages the under
lying hardware, storage,
networks, and software services that make up the platform through existing administrative interfaces.
Thus the Application Administrator is able to concentrate on their application and it’s deployment
environment rather than having

to be a systems administrator, database administrator and middleware
administrator as well (as is the case with IaaS).

camp
-
spec
-
v1.1
-
wd07

Working Draft 0
7

05 March

2013

Standards Track
Draft

Copyright
©

O
ASIS Open 201
2, 2013
. All Rights Reserved.

Page
4

of
16

The goal of the management interface is to provide the PaaS consumer with a model that is as simple as
possible, and yet still provides
the essential elements that give them control over the deployment,
execution, administration and metering of their application and it’s deployment environment.

2.1.1

PaaS Resource Model

The model of resources manipulated through the interface, in combination wit
h the protocol used to
remotely accomplish this, constitutes the self
-
service PaaS management API. The model contains
resource types corresponding to the artifacts discussed earlier.


Figure 2
-
1: PaaS Resources as UML Classes

Figure 2
-
1 is a UML Class
Diagram showing the PaaS Resources as UML classes, inheriting from a
CampResource class, which includes a set of attributes common to all CAMP resource representations.

Each attribute shown

in these UML class diagrams

has

a

CAMP common

type.

The + symbol
before the
each attribute name in the boxes expresses that the attribute
access is public (i.e., available thru the API),

In these UML diagrams, attributes which are not required to be present in all representations of that
resource are indicated using the

[0..1] UML multiplicity tag.

2.1.1.1

Platform

The
Platform

resource is the primary view of the platform and what is running on it. The Platform
references deployed applications (as
Assembly Templat
es
) as well as running applications (as
Assemblies
) and enables discovery of the PaaS offering in terms of
Platform Components

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

2.1.1.2

Assemblies

The
Assembly Template

resource represents a deployed application and its dependencies on the

platform and other application components.

class Platform Resource Model
PlatformComponent
+
external ManagementResource :URI [0..1]
ApplicationComponent
+
assembl y :Li nk
+
apppl i cati onComponents :Li nkArr [0..1]
+
pl atformComponents :Li nkArr [0..1]
Assembly
+
appl i cati onComponents :Li nkArr
+
assembl yTempl ate :Li nk
+
resourceState :ResourceState
PlatformComponentCapability
PlatformComponentRequirement
PlatformComponentTemplate
+
parameterDefi ni ti onsURI :URI [0..1]
ApplicationComponentCapability
ApplicationComponentRequirement
ApplicationComponentTemplate
+
assembl yTempl ate :Li nk
+
appl i cati onComponentTempl ates :Li nkArr [0..1]
+
pl atformComponentTempl ates :Li nkArr [0..1]
+
appl i cati onComponentRequi rements :Li nkArr [0..1]
+
pl atformComponentRequi rements :Li nkArr [0..1]
AssemblyTemplate
+
appl i cati onComponentTempl ates :Li nkArr [0..1]
+
appl i cati onComponentCapabi l ti es :Li nkArr [0..1]
+
parameterDefi ni ti onsURI :URI [0..1]
Platform
+
supportedFormatsUri :URI [0..1]
+
extensi onsURI :URI
+
typeDefi ni ti onsURI :URI
+
pl atformEndpoi ntsURI :URI
+
speci fi cati onVersi on :Stri ng
+
i mpl ementati onVersi on :Stri ng [0..1]
+
assembl yTempl ates :Li nkArr [0..1]
+
assembl i es :Li nkArr [0..1]
+
pl atformComponentTempl ates :Li nkArr [0..1]
+
pl atformCompnentCapabi l i ti es :Li nkArr [0..1]
+
pl atformComponents :Li nkArr [0..1]
+
parameterDefi ni ti onsURI :URI
CampResource
+
uri :URI
+
name :Stri ng
+
descri pti on :Stri ng [0..1]
+
tags :Stri ngArr [0..1]
+
type :Stri ng
+
representati onSkew :Stri ng [0..1]
camp
-
spec
-
v1.1
-
wd07

Working Draft 0
7

05 March

2013

Standards Track
Draft

Copyright
©

O
ASIS Open 201
2, 2013
. All Rights Reserved.

Page
5

of
16

The
Assembly

resource represents a running application. Operations on an Assembly affect the
components and elements of that application.

2.1.1.3

Components

There are two kinds of components,
a
pplic
ation
c
omponents

and p
latform
c
omponents
, each of which
may exist in either template or instantiated forms.

The
Application Component Template

resource represents a discrete configuration of a deployed
application component. The attributes of this resource represent the configuration values that will be
applied to the component upon instantiation.

The
Application Component

resource represents an instantiated instan
ce of an application component.

The
Platform Component Template

resource represents a discrete configuration of a platform component.
The attributes of this resource represent the configuration values that will
be applied to the component
upon instantiation.

The
Platform Component

resource represents an instantiated instance of a platform component in use by
an application. In addition to the configuration metadata (derived fr
om the corresponding Platform
Component Template on instantiation), the attributes of this resource also include metering information
for this component. Such information is typically used in generating the consumer’s bill.

2.1.1.4

Capabilities and Requirements


Figure 2
-
2: Capabilities, Requirements and Template Relationships

Figure 2
-
2 shows the relationships between capabilities, requirements, and template resources.
Associations which are visible thru pointer attributes in Resource s (i.e., URI , Link, or Link
Arr attribute
types) are show using UML named associations with Navigation arrows.

Associations which model
class Capabilities and Requirements
CampResource
PlatformComponentCapability
CampResource
PlatformComponentRequirement
CampResource
PlatformComponentTemplate
+
parameterDefi ni ti onsURI :URI [0..1]
CampResource
ApplicationComponentTemplate
+
assembl yTempl ate :Li nk
+
appl i cati onComponentTempl ates :Li nkArr [0..1]
+
pl atformComponentTempl ates :Li nkArr [0..1]
+
appl i cati onComponentRequi rements :Li nkArr [0..1]
+
pl atformComponentRequi rements :Li nkArr [0..1]
CampResource
ApplicationComponentRequirement
CampResource
ApplicationComponentCapability
-sati sfi es
*
-meets
*
-parameteri zed
*
-capabi l i ty
*
-parameteri zed
*
-capabi l i ty
*
*
requi res
*
*
requi res
*
*
uses
*
*
uses
*
-sati sfi es
*
-meets
*
camp
-
spec
-
v1.1
-
wd07

Working Draft 0
7

05 March

2013

Standards Track
Draft

Copyright
©

O
ASIS Open 201
2, 2013
. All Rights Reserved.

Page
6

of
16

implementation specific
relationships
, not visible thru the API, are represented using the UML association
end notation, without navigation arrows.

The association end names were chosen to represent the role
that resource plays in t
he relationship.

The


symbol before the association end names
expresses that
they

have private access (i.e,
navigation across resource links is

not available

thru the AP
I
)

Like Templates, Capability resources represent the configuration of instantiatable Components
(Application Components or Platform Components). Unlike Templates, which delineate discrete
configurations, Capabilities specify ranges of configuration values
.

Requirement resources are created by the Application Developer or Application Administrator to express
an application’s dependency on a component that is capable of satisfying a certain set of requirements.
For example, an application component may depen
d upon a messaging service that supports a certain
version of an AMQP API, can accept messages of up to 2MB in size, and which provides a persistent
message store.

The process of matching Requirements with Capabilities is referred to as “requirement resolu
tion”.

camp
-
spec
-
v1.1
-
wd07

Working Draft 0
7

05 March

2013

Standards Track
Draft

Copyright
©

O
ASIS Open 201
2, 2013
. All Rights Reserved.

Page
7

of
16

2.1.1.5

PaaS
Resource Relationships


Figure 2
-
3: Platform Resource Relationships as UML associations

Figure 2
-
3 shows the relationships between Platform Resources using a UML class diagram.

Associations which are visible thru pointer attributes in
Resource s (i.e., URI , Link, or LinkArr attribute
types) are show using UML named associations with Navigation arrows.


Associations which model implementation specific
relationships
, not visible thru the API, are represented
using the UML association end

notation, without navigation arrows.

The


symbol on these association
ends expresses that acces
s is private (i.e, navigation using resource links is not available thru the API).

Strict aggregation (i.e.,
has relationship
) is indicated using a solid diam
ond on the association end
attached to the
owning

resource.

This implies that the
owned

resource cannot exist independent of its
owner.

A
Platform

provides a set of
Platform Components

that
may be used by the invoking applications.
Examples of Platform Components include a servlet container, a web server, an LDAP store, and a
class PlatformAssociations
CampResource
Platform
+
supportedFormatsUri :URI [0..1]
+
extensi onsURI :URI
+
typeDefi ni ti onsURI :URI
+
pl atformEndpoi ntsURI :URI
+
speci fi cati onVersi on :Stri ng
+
i mpl ementati onVersi on :Stri ng [0..1]
+
assembl yTempl ates :Li nkArr [0..1]
+
assembl i es :Li nkArr [0..1]
+
pl atformComponentTempl ates :Li nkArr [0..1]
+
pl atformCompnentCapabi l i ti es :Li nkArr [0..1]
+
pl atformComponents :Li nkArr [0..1]
+
parameterDefi ni ti onsURI :URI
CampResource
PlatformComponentTemplate
+
parameterDefi ni ti onsURI :URI [0..1]
CampResource
PlatformComponent
+
external ManagementResource :URI [0..1]
CampResource
Assembly
+
appl i cati onComponents :Li nkArr
+
assembl yTempl ate :Li nk
+
resourceState :ResourceState
CampResource
AssemblyTemplate
+
appl i cati onComponentTempl ates :Li nkArr [0..1]
+
appl i cati onComponentCapabi l ti es :Li nkArr [0..1]
+
parameterDefi ni ti onsURI :URI [0..1]
CampResource
ApplicationComponentTemplate
+
assembl yTempl ate :Li nk
+
appl i cati onComponentTempl ates :Li nkArr [0..1]
+
pl atformComponentTempl ates :Li nkArr [0..1]
+
appl i cati onComponentRequi rements :Li nkArr [0..1]
+
pl atformComponentRequi rements :Li nkArr [0..1]
CampResource
ApplicationComponent
+
assembl y :Li nk
+
apppl i cati onComponents :Li nkArr [0..1]
+
pl atformComponents :Li nkArr [0..1]
CampResource
PlatformComponentRequirement
CampResource
PlatformComponentCapability
CampResource
ApplicationComponentCapability
CampResource
ApplicationComponentRequirement
*
uses
*
1
has
*
1
has
*
1
has
*
1
has
*
-parameteri zed
*
-capabi l i ty
*
-i nstanti ated
-from
1
has
*
*
i nstanti atedUsi ng
1
1
has
*
1
has
*
-sati sfi es
*
-meets
*
*
uses
*
*
requi res
*
*
requi res
*
-parameteri zed
*
-capabi l i ty
*
*
uses
*
*
uses
*
-i nstanti ated
*
-from
1
-sati sfi es
*
-meets
*
1
has
*
camp
-
spec
-
v1.1
-
wd07

Working Draft 0
7

05 March

2013

Standards Track
Draft

Copyright
©

O
ASIS Open 201
2, 2013
. All Rights Reserved.

Page
8

of
16

database instance. The implementation and operation of Platform Components is managed by the
Platform Administrator. P
latforms may also provide higher
-
level business components such as a business
rules manager to gain competitive advantage and developer loyalty.

An a
pplication

is composed of a set of
Application Components

that depend on one or more Platform
Components. Examples of Application Components include Ruby gems, Java libraries, and PHP
modules. Application Components may also include non
-
code artifacts such as datasets and collections
of identity information.

App
lication Components may also interact with other Application Components. Thus, an Application
Component has two different sets of dependencies. It depends on the Components provided by the
platform, and depends on services provided by other Application Com
ponents. Such Application
Components may be on the same platform or may reside at some other location. The
Assembly

resource
is used to aggregate the management of these components as shown
in Figure 2
-
3.
:

Platform Components have a set of
Platform Component Capabilities

that an application can choose from
to meet its requirements. Applications can tailor
Platform Component Requirements

(a refinement or
narrowing of the configuration ranges in the Capabilities) to meet their needs based on the range of
parameters expressed in the Platform Component Capability.

The re
lationships of an
Assembly Template

to
Application Component Templates

and
Platform
Component Templates
, or their Requirements are shown
in Figure 2
-
3.

An Application Component can express the exact configuration of its dependency on other Components
using one of the Component Templat
e resources (either an Application Component Template or Platform
Component Template). Alternatively, it can express a range of configuration values that are acceptable
for that dependency by using one of the Component Requirement resources (either an Appl
ication
Component Requirement or Platform Component Requirement). This might be done, for example, in an
ADE when the existing Component Templates are not known. During the deployment, these
Requirements are matched with Capabilities that have attribute va
lues that fall within the ranges specified
by the Requirements.

An Application Component Template cannot be instantiated unless all of its dependencies are satisfied.
An Application Component Template shall be referenced by a single Assembly Template.
An A
ssembly
Template
shall not

be instantiated until all of its Application Component Templates are successfully
instantiated.

When instantiated, an Assembly Template results in an Assembly. The Assembly resource references the
Assembly Template it was instant
iated from, although attributes of the Assembly can deviate from the
original template. An Assembly can be snapshot at a point in time and the resulting snapshot can be used
to create a new Assembly Template.

A
Deployment
Plan

is packaging management meta
-
data that includes a serialized copy of the Assembly
Template resource and all dependent management resources such as Application Component
Templates. Deployment Plans are an essential part of a
Platform Deployment Package (PDP)
.

A Platform Deployment Package is an archive of executable images, dependency descriptions and
metadata (management resources) that can be used to move an Application and its Components from
Platform to P
latform, or between an Application Development Environment and a Platform. It can be
thought of as a serialized form of an Assembly Template and all of its dependent management resources.

camp
-
spec
-
v1.1
-
wd07

Working Draft 0
7

05 March

2013

Standards Track
Draft

Copyright
©

O
ASIS Open 201
2, 2013
. All Rights Reserved.

Page
9

of
16

2.1.2

P
latform Endpoint

and Meta Data
Resource Model


Figure 2
-
4:
Platform Endpoint and Meta Data Resources as UML Classes



class Platform Endpoint Model
CampResource
+
uri :URI
+
name :Stri ng
+
descri pti on :Stri ng [0..1]
+
tags :Stri ngArr [0..1]
+
type :Stri ng
+
representati onSkew :Stri ng [0..1]
Format
+
mi meType :Stri ng
+
versi on :Stri ng [0..1]
+
documentati on :URI
Formats
+
formatLi nks :Li nkArr
TypeDefinitions
+
typeDefi ni ti onLi nks :Li nkArr
TypeDefinition
+
documentati on :URI
+
attri buteDefi ni ti onLi nks :Li nkArr
AttributeDefinition
+
documentati on :URI
+
attri buteType :Stri ng
+
requi red :Bool ean
+
mutabl e :Bool ean
+
consumerMutabl e :Bool ean
PlatformEndpoints
+
pl atformEndpoi ntLi nks :Li nkArr
Extension
+
versi on :Stri ng
+
documentati on :Li nk
PlatformEndpoint
+
speci fi cati onVersi on :Stri ng
+
backwardCompati bl eSpeci fi cati onVersi ons :Stri ngArr [0..1]
+
i mpl ementati onVersi on :Stri ng [0..1]
+
backwardCompati bl eImpl ementati onVersi ons :Stri ngArr [0..1]
+
pl atformURI :URI
Extensions
+
extensi onLi nks :Li nkArr
ParameterDefinition
+
parameterType :Stri ng
+
requi red :Bool ean
+
defaul tVal ue :Stri ng [0..1]
+
parameterExtensi onsURI :URI [0..1]
ParameterDefinitions
+
parameterDefi ni ti onLi nks :Li nkArr
camp
-
spec
-
v1.1
-
wd07

Working Draft 0
7

05 March

2013

Standards Track
Draft

Copyright
©

O
ASIS Open 201
2, 2013
. All Rights Reserved.

Page
10

of
16

2.1.2.1

P
latform Endpoint

Resource
Relationships

class PlatformEndpointsAndTypes
CampResource
Extension
+
versi on :Stri ng
+
documentati on :Li nk
CampResource
Extensions
+
extensi onLi nks :Li nkArr
CampResource
Format
+
mi meType :Stri ng
+
versi on :Stri ng [0..1]
+
documentati on :URI
CampResource
Formats
+
formatLi nks :Li nkArr
CampResource
AttributeDefinition
+
documentati on :URI
+
attri buteType :Stri ng
+
requi red :Bool ean
+
mutabl e :Bool ean
+
consumerMutabl e :Bool ean
CampResource
TypeDefinition
+
documentati on :URI
+
attri buteDefi ni ti onLi nks :Li nkArr
CampResource
TypeDefinitions
+
typeDefi ni ti onLi nks :Li nkArr
CampResource
Platform
+
supportedFormatsUri :URI [0..1]
+
extensi onsURI :URI
+
typeDefi ni ti onsURI :URI
+
pl atformEndpoi ntsURI :URI
+
speci fi cati onVersi on :Stri ng
+
i mpl ementati onVersi on :Stri ng [0..1]
+
assembl yTempl ates :Li nkArr [0..1]
+
assembl i es :Li nkArr [0..1]
+
pl atformComponentTempl ates :Li nkArr [0..1]
+
pl atformCompnentCapabi l i ti es :Li nkArr [0..1]
+
pl atformComponents :Li nkArr [0..1]
+
parameterDefi ni ti onsURI :URI
CampResource
PlatformEndpoints
+
pl atformEndpoi ntLi nks :Li nkArr
CampResource
PlatformEndpoint
+
speci fi cati onVersi on :Stri ng
+
backwardCompati bl eSpeci fi cati onVersi ons :Stri ngArr [0..1]
+
i mpl ementati onVersi on :Stri ng [0..1]
+
backwardCompati bl eImpl ementati onVersi ons :Stri ngArr [0..1]
+
pl atformURI :URI
0..*
extensi on
0..*
1
has
1
1
has
1
0..*
pl atform
1
0..*
supported format
0..*
1
has
0..1
0..*
attri bute
0..*
0..*
type
0..*
1
endpoi nt
0..*
1
has
1

Figure 2
-
5: Platform Endpoint Relationships as UML Classes

camp
-
spec
-
v1.1
-
wd07

Working Draft 0
7

05 March

2013

Standards Track
Draft

Copyright
©

O
ASIS Open 201
2, 2013
. All Rights Reserved.

Page
11

of
16

2.1.2.2

Parameter Definitions

Resource
Relationships

class Parameter Definition Associations
CampResource
Platform
+
supportedFormatsUri :URI [0..1]
+
extensi onsURI :URI
+
typeDefi ni ti onsURI :URI
+
pl atformEndpoi ntsURI :URI
+
speci fi cati onVersi on :Stri ng
+
i mpl ementati onVersi on :Stri ng [0..1]
+
assembl yTempl ates :Li nkArr [0..1]
+
assembl i es :Li nkArr [0..1]
+
pl atformComponentTempl ates :Li nkArr [0..1]
+
pl atformCompnentCapabi l i ti es :Li nkArr [0..1]
+
pl atformComponents :Li nkArr [0..1]
+
parameterDefi ni ti onsURI :URI
CampResource
AssemblyTemplate
+
appl i cati onComponentTempl ates :Li nkArr [0..1]
+
appl i cati onComponentCapabi l ti es :Li nkArr [0..1]
+
parameterDefi ni ti onsURI :URI [0..1]
CampResource
PlatformComponentTemplate
+
parameterDefi ni ti onsURI :URI [0..1]
CampResource
ParameterDefinitions
+
parameterDefi ni ti onLi nks :Li nkArr
CampResource
ParameterDefinition
+
parameterType :Stri ng
+
requi red :Bool ean
+
defaul tVal ue :Stri ng [0..1]
+
parameterExtensi onsURI :URI [0..1]
1
has
*
1
has
*
*
defs
1
*
defs
0..1
*
defs
0..1
*
def
*

Figure 2
-
6: Parameter Definition Relationships
as UML Classes


2.1.2.3

CAMP Common Base Types

The attributes in these UML class diagrams
have one of the CAMP Common Base types, specified in
Section
5.1.
Figure 2
-
6 is a UML diagram showing the common data types as UML Data Types, which
are used for the Types

of these Resource Attribute definitions.


camp
-
spec
-
v1.1
-
wd07

Working Draft 0
7

05 March

2013

Standards Track
Draft

Copyright
©

O
ASIS Open 201
2, 2013
. All Rights Reserved.

Page
12

of
16


Figure 2
-
6: CAMP Common Base Types for Resource Attribute Definitions

Multi
-
valued member attributes ar
e used to model the elements
of the LingArr, StringArr, and Map types.

This is for modeling purposes, the a
ttribute name "element" does not appear in the JSON serialization for
these common types.

The two array types
have their elements

tagged as ordered
.


2.1.3

Representation Skew

There can be situations in which the information in the resources provided by the CAMP

API is not a
complete or accurate representation of the state of the underlying platform implementation. For example,
while instantiating a new instance of an application, a CAMP server might be asked to provide a
representation of an Application Componen
t that corresponds to a dataset that is in the process of being
loaded onto a database service. While the CAMP server might not be able to provide all of the information
about this Application Component, it would be inaccurate to say that Application Compo
nent does not
exist; it exists but it an intermediate state. It is expected that these sorts of situations will be the exception
and that, during the majority of its existence, a CAMP resource will be in synch with the state of its
underlying platform impl
ementation.

The significance of this skew is the manner in which it affects the client’s interactions with, and
expectations about, the resource. In the above example, while the client cannot reasonably expect to
make any changes to the Application Compone
nt until it has reached a steady state, the client can expect
that the resource will reach this state in the near future. There are other situations in which, through some
sort of error or breakdown, the CAMP API cannot tell when or if the information in t
he resource will ever
be synchronized with the underlying implementation.

Details on how this skew is exposed in the CAMP API are provided in the
ResourceSkew section

of the
Common Resource Attributes of this specif
ication.

2.1.4

Management Model Diagrams

The figures in this section
are UML object instance diagrams, which represent related Resource
instances at
various
stages of Platform Resource instantiation.

Attributes for these

resources

are not
shown for simplication
.

For a comprehensive list of attributes for resources see Section
Error! Reference
source not found.
.

class Common Data Types
«dataType»
ResourceState
(from BaseTypes)
«dataType»
LinkArr
+
el ement :Li nk [0..*] {ordered}
(from BaseTypes)
«dataType»
String
(from BaseTypes)
«dataType»
Boolean
(from BaseTypes)
«dataType»
StringArr
+
el ement :Stri ng [0..*] {ordered}
(from BaseTypes)
«dataType»
Link
+
href :URI
+
targetName :Stri ng
(from BaseTypes)
«dataType»
TimeStamp
(from BaseTypes)
«dataType»
URI
(from BaseTypes)
«dataType»
CampCommonType
(from BaseTypes)
camp
-
spec
-
v1.1
-
wd07

Working Draft 0
7

05 March

2013

Standards Track
Draft

Copyright
©

O
ASIS Open 201
2, 2013
. All Rights Reserved.

Page
13

of
16

Instances in these diagrams is indicated by boxes, with an underlined
object
-
name: Class

label.
Relationships visible thru the API are shown using associations with navigation arrows. Implementation
Specific relationships are indicated using the associat
ion end notation, without navigation arrows.

2.1.4.1

Basic Platform Resources

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


Figure
2

-

Basic Platform Resources

An empty Platform will have a number of resources visible through the API when the Application
Administrator first accesses a new account. The Platform resource is used to find the other resources in
this diagram. The various Platform Component Capabilitie
s allow for discovery of all the platform services
that are available with value ranges for each service’s attributes. The various Platform Component
Templates may represent pools of previously configured platform resources and represent this
configuration

as specific values for each of the attributes. These values are chosen from the range of
values in the corresponding Platform Component Capability.

2.1.4.2

Resources Loaded

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

obj ect Basic Platform Resources
p1 :Platform
pct1 :
PlatformComponentTemplate
pct2 :
PlatformComponentTemplate
pcc1 :
PlatformComponentCapability
pcc2 :
PlatformComponentCapability
-parameteri zed
-capabi l i ty
-parameteri zed
-capabi l i ty
has
has
has
has
camp
-
spec
-
v1.1
-
wd07

Working Draft 0
7

05 March

2013

Standards Track
Draft

Copyright
©

O
ASIS Open 201
2, 2013
. All Rights Reserved.

Page
14

of
16


Figure
3

-

Loaded Resources

An Assembly Template now is available with one or more Application Component Templates, Application
Component Requirements and Platform Component Requirements. The Application Component
Template management resources represent code and/
or associated resources that were loaded with the
PDP. The Application Component Requirement resources were used to find Application Component
Templates (pre
-
existing software libraries for example) that were not part of the deployment plan but are
require
d for the application. The Application Component Capability resources show the range of
configurable attributes that the loaded Application Components can take on, when reused by future
Application Components.

The Platform Component Requirement resources w
ere used to find Platform Component Templates (pre
-
configured platform resources) that were part of the platform and required by the loaded Application
Components, but perhaps unknown at the time the deployment plan was created (in an ADE for
example).

2.1.4.3

Ins
tantiated Resources

To start an application utilizing all of the previously configured Application Components and Platform
Components, an Assembly is created using the Assembly Template. This also causes the Application
Components and Platform Components c
orresponding to their respective templates to be created as
shown below.

obj ect Resources Loaded
p1 :Platform
pct2 :
PlatformComponentTemplate
pct1 :
PlatformComponentTemplate
pcc2 :
PlatformComponentCapability
pcc1 :
PlatformComponentCapability
at1 :
AssemblyTemplate
act1 :
ApplicationComponentTemplate
act2 :
ApplicationComponentTemplate
acc1 :
ApplicationComponentCapability
acc2 :
ApplicationComponentCapability
pcr3 :
PlatformComponentRequirement
acr1 :
ApplicationComponentRequirement
has
has
has
has
has
-parameteri zed
-capabi l i ty
-parameteri zed
-capabi l i ty
-sati sfi es
-meets
has
has
+sati sfi es
+meets
has
-parameteri zed
-capabi l i ty
-parameteri zed
-capabi l i ty
uses
requi res
uses
requi res
has
camp
-
spec
-
v1.1
-
wd07

Working Draft 0
7

05 March

2013

Standards Track
Draft

Copyright
©

O
ASIS Open 201
2, 2013
. All Rights Reserved.

Page
15

of
16


Figure
4

-

Instantiated Resources

To manage the operation of the application, the Application Administrator interacts with the Assembly
resource and the r
elated Application Component and Platform Component resources.

The traversal of the resources in the model can be accomplished by following
the navigation arrows on
the associations in these object instance diagrams,

from each resource to the

other resources it depends
on
.

2.2

Importing a Platform Deployment Package

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

1.

One or more Assembly Templates are created with URIs to the other elements and with any
binary executables installed onto the platform.

2.

One or more Application Component Templates are created with URIs to the other
elements and
with and binary executables installed onto the platform.

3.

Zero or more Platform Component Requirements are created, representing the requirements on
the underlying platform components. Connections may be made to existing Platform Component
Temp
lates whose attribute values fall within the ranges specified by the requirements.

4.

Zero or more Application Component Requirements are created, representing the requirements
on previously installed Application Components. Connections may be made to existin
g
Application Component Templates whose attribute values fall within the ranges specified by the
requirements.

obj ect Instantiated Resources
p1 :Platform
pct1 :
PlatformComponentTemplate
at1 :
AssemblyTemplate
act1 :
ApplicationComponentTemplate
act2 :
ApplicationComponentTemplate
pc1 :
PlatformComponent
a1 :Assembly
ac1 :
ApplicationComponent
ac2 :
ApplicationComponent
uses
uses
i nstanti ate usi ng
has
has
uses
uses
has
has
has
has
has
has
camp
-
spec
-
v1.1
-
wd07

Working Draft 0
7

05 March

2013

Standards Track
Draft

Copyright
©

O
ASIS Open 201
2, 2013
. All Rights Reserved.

Page
16

of
16

2.3

Exporting a Platform Deployment Package

A
Platform Deployment Package

may be exported from the platf
orm by an operation on an Assembly or
an Assembly Template. The Assembly (Assembly Template), dependent Application Components
(Application Component Templates) and Platform Components (Platform Component Templates) and
associated Capabilities Requirements
, if any, as well as all related images are then used to create the
Deployment Plan and Platform Deployment Package. A URI to the Platform Deployment Package is
returned as a result.