# A Survey on Modeling Languages for Applications Hosted on Cloud-Edge Computing Environments
## 4 Conclusions and Future Research Directions
### Future Work  
The findings from our research survey will be utilized as the basis for our CML. As it was stated in the start of this paper, the main motivation for this research work was to identify how the deployment phase and runtime adaptation of applications in edge-cloud computing environments are described by existing CMLs. After an extensive literature review, it was decided to extend TOSCA to create a CML that can support the description of the deployment phase, runtime adaptation, and QoS criteria. This language aims to support numerous properties to facilitate deployment and runtime adaptation across cloud and edge environments, utilizing a syntax that is easy for developers to understand.  
The primary challenge is to develop a user-friendly syntax capable of describing runtime adaptation alongside QoS deterioration conditions/events, which will subsequently prompt adaptation actions. Our interest lies in establishing a structure for QoS deterioration conditions akin to those outlined in SYBL [34] and the Self-adaptive IoT DSL presented in [21], as they provide a well-defined condition structure that can be integrated into workflows. Workflows will be described as a list of QoS conditions and runtime adaptation actions that need to be performed by platforms during the runtime adaptation phase.  
The secondary challenge for our CML is to simplify application component deployment on infrastructure with minimal re-engineering, regardless of the deployment unit. Taking inspiration from [PERSON] et al. [17], our CML will empower developers with the ability to describe application components as either virtual machines or containers. To streamline application component orchestration, our CML has to facilitate the description of input parameters and dependencies between components using environment values. Platforms can leverage these features to furnish input parameters or configurations, ensuring seamless deployment and communication among application components. To optimize the orchestration of application components, the description of resource requirements and the concept of placement will also be supported in our CML.  
Furthermore, the development of the CML must follow a cloud provider-independent approach to ensure compatibility with any platform. This entails designing a syntax that offers generic information not tied to any specific platform, while also being easily adaptable across various platforms. In line with recommendations from the literature sources [1, 16, 17, 29, 33, 38], platforms and frameworks that incorporate the usage of a CMLmust utilize their own reasoners to extract knowledge from models written in our provided CML. This is crucial for the effective execution of deployment and runtime adaptation plans. To facilitate the implementation of our language, we will draw inspiration from [PERSON] et al. [15], who propose the possibility of implementing TOSCA with Kubernetes. As documented in [4; 6; 17], the availability of supporting tools and documentation plays a crucial role in the successful implementation of the language. Consequently, we aim to develop a TOSCA to Kubernetes reasoner, leveraging existing research and insights to simplify the implementation process.  
[PERSON] contributed in the conceptualization, data collection and writing of the paper. [PERSON] contributed in the conceptualization, writing and reviewing and revising the paper. [PERSON] contributed in securing the funding for the work, conceptualization, reviewing and revising the paper as well as in the team work coordination. The paper reflects only the authors' views. The EU Commission is not responsible for any use that may be made of the information it contains. All authors have read and agreed to the published version of the manuscript.  
This research received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No 871793 (project ACCORDION) and No 101016509 (project CHARITY).  
Not applicable.  
The authors declare no conflicts of interest.