# A Survey on Modeling Languages for Applications Hosted on Cloud-Edge Computing Environments
## 3 Results
### Cloud Provider-Independent Models  
Many users look for modeling languages that are not tied to a specific cloud provider. This is because they often have to learn a new specification each time they switch to a different platform for deploying applications. TOSCA, as a provider-independent modeling language, offers a solution to this challenge by providing a generic description for deployment and lifecycle management, allowing for users to employ the same specification across different cloud platforms. GENTL is presented as a viable solution for creating cloud provider-independent models in [9]. It is a generic topology language that enables the mapping of different languages to a common model, with the goal of describing deployment and lifecycle management in a cloud provider-agnostic manner. This approach provides an alternative option for achieving cloud portability without being bound to specific cloud providers. EDDM, which was introduced in [7], is another CML that offers universal models that are not specific to any cloud provider. While languages like GENTL, EDDM, and TOSCA offer an abstract approach that is cloud provider-independent, HOT does not possess this characteristic. It is specifically designed for use within the OpenStack cloud computing platform, but it is also being adopted and shared among multiple cloud providers due to its vendor-independent specifications for launching applications in the cloud environment, as mentioned in [10]. The documentation of HOT highlights the presence of a provider section, enabling developers to define providers. In the context of HOT, the deployment unit is portrayed as a virtual machine necessitating deployment on the server resources of a particular cloud provider. In their introduction of CAMEL, [PERSON] et al. [1] discuss how CAMEL can generate cloud provider-independent models usable across multiple cloud providers. Despite sharing a similar capability with HOT, CAMEL uses a different syntax for expressing providers. It supportsvarious packages for designing different aspects of an application and its requirements, including a dedicated provider package specifically for describing cloud providers. The abstract approach, which caters to multiple technologies, is also present in container description languages. For instance, Velo DSL [11] functions as an abstract deployment language for container orchestration and is capable of facilitating deployments across three container technologies: Docker Swarm, Kubernetes, and Mesos Marathon. [PERSON] et al. [12] introduce SMADA-Fog (Semantic Model driven Approach to Deployment and Adaptivity of container-based applications in Fog Computing), a semantic model-driven approach that presents a framework facilitating automated code generation for infrastructure management. This includes the creation of Docker containers and SDN rules. As mentioned earlier, many CMLs depend on translator tools to convert high-level, cloud-agnostic models into technical representations compatible with one or more cloud platforms. For instance, Uni4 Cloud, as mentioned in [13], utilizes the OVF (Open Virtualization Format) to provide a cloud provider-agnostic representation of application components, their relationships, and requirements. OVF is a standard by DMTF ([[https://www.dmtf.org/standards/ovf](https://www.dmtf.org/standards/ovf)]([https://www.dmtf.org/standards/ovf](https://www.dmtf.org/standards/ovf))) (accessed on 10 October 2023) that aims to offer a cloud-agnostic solution for deploying virtual machines in the cloud. Uni4 Cloud also employs the OCCI (Open Cloud Computing Interface) ([[https://occi-wg.org/](https://occi-wg.org/)]([https://occi-wg.org/](https://occi-wg.org/))) (accessed on 10 October 2023) as a generic API that provides details deployment of applications in the cloud. Uni4 Cloud includes a Cloud Adapter component that translates the details of OCCI into specific commands for each cloud provider. In their research, [PERSON] et al. [1] use the term Reasoner to refer to the translator tool.