# A Survey on Modeling Languages for Applications Hosted on Cloud-Edge Computing Environments
## 3 Results
### Description of Runtime Adaptation  
Besides facilitating the description of deployment processes, certain modeling languages also provide support for runtime adaptation, including self-healing and auto-scaling through event-driven lifecycle operations. According to [PERSON] et al. [14], TOSCA allows the description of lifecycle operations through relationship and node types. Specifically, it is mentioned that users can include lifecycle operation scripts in the relationship part of a node type, which contain the necessary lifecycle operations. This approach allows for self-healing adaptation during runtime. Given that EDDM's [7] syntax is inspired by TOSCA, it shares a comparable logical structure. EDDM features an operation entity that can execute procedures for managing the components or relationships defined in the deployment model. As a result, the operation entity has the potential to describe an executable file that contains a self-healing operation. The research conducted by [PERSON] et al. [30] introduced TOSCA Light as a new language that combines elements from both EDDM and TOSCA approaches. To enable the use of lifecycle operation scripts in TOSCA Light, the authors performed a mapping between EDDM operations and the interface section of TOSCA. In Wrangler [25], developers are provided with a similar approach for self-healing, where they can add additional scripts to descriptions in order to perform operations on virtual machines dynamically during runtime. CAMEL [1,31] also supports the attached script feature that contains lifecycle operations to describe the execution flow. As it is suggested in CAMEL, the lifecycle operations are performed by the Executionware component, which reads models written in CAMEL in order to perform deployments, apply scalability rules and perform provisioning. Conversely, the event-driven lifecycle operations are intricately linked to the syntax of workflows, which govern the conditions and steps to dynamically adjust an application at runtime. For instance, the TOSCA official documentation provides examples of workflows that contain conditional logic which depends on the status of components. If TOSCA is extended, it has the potential to incorporate additional custom metrics into the conditional logic. A case in point is the TOSCA extension proposed by [PERSON] et al. [32], which enables the description of cloud-native application lifecycle management. This extension utilizes conditional logic that has the potential to support newly introduced metrics as well. On the other hand, TOSCA also has the capability to utilize established workflow languages such as BPMN (Business Process Modeling Notation) by referencing BPMN files in the workflow section. BPMN is a specification used to model business process diagrams, which can also be translated into software process components. However, it appears that this syntax may not be very user-friendly when it comes to describing lifecycle operations. TOSCA policies offer a standardized approach to defining scaling, placement, availability, and security requirements in cloud deployments, enabling automated management and orchestration of complex applications. Through the inclusion of policies within TOSCA templates, cloud administrators and developers can ensure consistent behavior across diverse cloud platforms and environments, facilitating interoperability and streamlining application management. [PERSON] et al. [17] utilize policy descriptions for specifying scalability, monitoring, and other non-functional requirements. However, policies alone are insufficient for describing event-driven logic. [PERSON] et al. [20] propose a TOSCA extension that incorporates various policies to enhance application deployment. These policies include collocation, anti-affinity, precedence, device exclusion, and placement policies. The collocation policy enables grouping application components on the same cloud provider's hosts, ensuring their colocated placement.