# A Survey on Modeling Languages for Applications Hosted on Cloud-Edge Computing Environments
## 3 Results
### Description of Hosts
For instance, in [35], a CML is described that exclusively focuses on describing physical devices, edge nodes, smartwatches, edge devices, and end devices, assuming that an application component is running on top of them. Unlike other modeling languages, EDDM syntax, as introduced by [PERSON] et al. [7], does not feature a separate entity for describing hosts or resources. Rather, it utilizes the extensibility of the tos in entity to describe hosts and their resources. Additionally, some CMLs are limited in their ability to describe only a single type of host. For instance, Aelolus Blender [24; 33] utilizes a universe file that provides details about available virtual machine hosts for deploying application components. This file contains essential information related to virtual machine resources, such as memory, package repository, existing services, and packages. Similarly, GENTL [9] describes virtual machines as hosts for application components. However, there are CMLs, such as Aelolus Blender [33], Wrangler [25], HOT, CAMEL [1] and Uni4 Cloud [13], that are not specifically designed to describe all types of physical devices that can host applications. To address this limitation, the authors in [29] propose a way to model both physical and virtual devices, based on ARM and x86 architectures. In some cases, physical devices are depicted as vessels for hosting virtual machines that in turn host application components. For example, in [28], the Unified Modeling Language (UML) is extended to include a specification level deployment diagram that conceptually represents virtual machines as instances of physical machines, implying that a physical machine could instantiate one or more virtual machines. These virtual machines can then serve as hosts in cloud platforms for orchestrating application components. The same applies for HOT which can describe virtual machines as deployment units, allowing for application developers to deploy multiple virtual machine images. The target cloud platform then attempts to identify suitable physical devices for deploying one or more virtual machines, enabling the execution of these virtual machines. Developers have the option to either instantiate a virtual machine using HOT that would serve as a host in OpenStack or pre-install their application components in various virtual machine images and utilize them as vessels. As it was mentioned before, certain CMLs are designed to be used across multiple cloud providers, and therefore need to be able to describe the desired host for an application while specifying the associated cloud provider. For example, in CAMEL [1], users can define a cloud provider along with the desired virtual machine resources, such as hardware, OS, and location, for an application component. The use of provider package in CAMEL allows for the description of virtual machines offered by a cloud provider. Developers can instantiate one or more objects of the virtual machine type within this package to specify the flavor, OS, RAM size, storage size, and number of CPU cores for the desired virtual machines. Furthermore, the provider package of CAMEL supports additional features such as indicating whether the target cloud should be private or public, specifying the type of service provided by the cloud (IaaS/SaaS/PaaS), and defining the API endpoint of the cloud provider. In CAMEL, developers specify virtual machine requirements by defining a virtual machine object in the deployment package, with actual values detailed in the requirements package. This allows for developers to determine if a component needs a virtual machine with specific resources, such as CPU cores and storage, OS, and location. Understanding how CAMEL describes hosts suggests that hosts are characterized by their resources, a principle also applicable to other CMLs. TOSCA provides the tosca.nodes.Compute node type, which allows for developers to describe CPU cores, memory, and disk space requirements for a component to be executed.