# Enabling Role-Based Orchestration for Cloud Applications
## 3 TOSCA Model-Based Approach to Cloud Application Orchestration
### Architectural Design of a Topology Model-Based Orchestration System
#### 3.1.1 TOSCA Modeling
Additionally, the node _dcc.operational.root_ empowers its child node types with common capability _operational_ and common requirement _attach-to_. Thus, a workload node and an operational node are interconnected through the normative relationship type of _AttachesTo_ that can fulfill the requirement _attach-to_. When definingthe properties of a capability node type, it is sufficient for application builders to specify a small number of configuration parameters to control the behaviour of the capabilities rather than each and every field of its underlying resources. This way, the complexity of application orchestration specification can be kept low. In a real-world scenario, deciding which properties or parameters concern a particular role is a task for the platform builders who leverage our approach to build platform capabilities. They should be familiar with overall configuration of a specific capability and have good knowledge on the concerns of roles who will consume this capability in designated orchestration scenarios. Taking all of the above into account, they can decide which configuration points are supposed to present through capability properties while others should be hidden. With these extended types, we can define the TOSCA Topology Template of the motivational scenario as diagrammed in Figure 1.  
```
1 node_types:
2 dcc.worldload.containerized:
3 derived_from: dcc.workload.root
4 attributes:
5 arch:
6 type: string
7 required: false
8 containers:
9 type: list
10 required: true
11 entry_schema:
12 description: runtime configuration
13 type: dcc.datatypes.containerinfo
14
15#extensiondatatypes
16 data_types:
17 dcc.datatypes.containerinfo:
18 derived_from: tosca.datatypes.root
19 properties:
20 name:
21 type: string
22 required: true
23 image:
24 type: string
25 required: true
```  
Listing 2: Extension Node Type of dcc.workload.containerized. ```
1 node_types:
2 dcc.operational.autoScaling:
3 derived_from: dcc.operational.root
4 attributes:
5 maxReplicaCount:
6 type: integer
7 required: true
8 minReplicaCount:
9 type: integer
10 required: true
11 promQuery:
12 type: string
13 required: true
14 promThreshold:
15 type: integer
16 required: true
17
18 dcc.operational.simpleRollout:
19 derived_from: dcc.operational.root
20 attributes:
21 batch:
22 type: string
23 required: true
24 replicas:
25 type: integer
26 required: true
27 required: true
28 required: true
29
30
31
32
33 In order to guarantee that parsed TOSCA specifications can be input into the model conversion module, we have developed a TOSCA parser based on an open-source TOSCA processor named Puccini [17]. Puccini provides a stand-alone TOSCA parser that can fulfill normalization, validation, inheritance, and assignment of TOSCA Service Templates. It outputs a flat, serializable data structure for the ensuing model conversion. #### 3.1.2 Application Model Conversion

To convert TOSCA Service Templates to OAM Application Configurations, we have identified and defined a set of mapping rules between two models as summarized in Table 1. In our approach, TOSCA is used to describe application topology and orchestration configuration. We employ the primitives of TOSCA type system to build a set of extension types to represent specific capability entities. Thus, our conversion task focuses on in-house extension types but not all TOSCA normative types. Since our extension TOSCA Node types have now been further divided into two kinds for developers and operators, TOSCA types can be easily mapped to OAM entities that have also been refined into two corresponding sub-types. The conversion process is composed of five phases: validating whether each TOSCA Node type has a matching OAM entity, rendering OAM components for workload type nodes, rendering OAM traits for operational capability nodes, resolving the relationships between the nodes, and generating an OAM Application Configuration. Regarding the properties conversion in a node, we rely on a simple mapping strategy that ensures that each property has a matching OAM entity _spec_ field with the same name.