Advances, Systems and Applications
From: The cloud application modelling and execution language
Aspect | Phase | Rationale |
---|---|---|
Deployment | All | The PITMs and PSTMs models drive both application reasoning and deployment, |
while execution-related activities should be reflected in PSTM models | ||
Requirement | Reasoning | The user requirements drive application deployment reasoning, |
Execution | while they are also used to restrain the way local scalability can be performed at runtime | |
Provider | Reasoning, | Provider models enable to matchmake and select suitable cloud offerings |
Security | Reasoning | High- and low-level security requirements can drive the offering space |
filtering, as well as the application deployment optimisation | ||
according to security criteria apart from the quality ones and cost | ||
Metric | Reasoning, | Metrics are used as optimisation criteria for deployment reasoning, while they |
Execution | also explicate how application monitoring can be performed during the execution phase | |
Scalability | Execution | Scalability rules drive the local application reconfiguration during execution |
Organisation | Reasoning, | An organisation can have accounts on certain providers which reduces the offering space |
Deployment | only to them. The credentials to these providers enable the platform to act on user | |
behalf for deploying application components to suitable VMs | ||
Location | Reasoning | Location requirements can be used to filter the offering space during deployment reasoning |
Execution | Reasoning, | Previous execution history knowledge can be used to improve application deployment |
Unit | All | Auxiliary aspect enabling to associate units of measurement to metrics and thus, |
indirectly, to the conditions (i.e., SLOs) posed on them | ||
Type | All | Auxiliary aspect enabling to provide types to language elements like metrics, as well as |
to define different kinds of values that can be assigned to element properties |