# A Survey on Modeling Languages for Applications Hosted on Cloud-Edge Computing Environments
## 3 Results
### Description of Hosts  
In the orchestration's matchmaking process, application components require mapping to appropriate hosts. This mapping is depicted through relationships in modeling languages, defining associations between components and hosts. Some modeling languages treat hosts and application components as distinct entities, aiding orchestrators in efficiently matching components with hosts. In edge-cloud computing environments, application components have the flexibility to be hosted on either physical devices or virtual machines. [PERSON] et al. [29] introduce a modeling language that includes a property enabling developers to describe both virtual machines and physical devices in cloud and edge environments. In their subsequent research, the SMADA-Fog [12] deployment model outlines three types of devices prevalent in fog environments: consumer devices, servers, and network devices. Servers represent the computing infrastructure capable of hosting applications. Further details about consumer devices are provided in Section 3.11, which delves into their representation in recent CMLs. Additionally, the network device type describes physical devices at the network layer, responsible for implementing networking protocols and executing specific network functions to facilitate communication. Examples include routers, switches, firewalls, load balancers, intrusion detection systems, and parental control devices. All device types support descriptions including IP address, MAC address, number of cores, memory and storage capacity, and processor architecture. The SMADA-Fog deployment model is not the sole one to describe network devices. In a similar manner, [PERSON] et al. present a router description using MoDMaCAO [23]. Similarly, [PERSON] et al. [21; 22] in the fog DSL present an entity called Node. This entity supports sub-entities capable of describing nodes in edge, fog, and cloud environments. Sub-entities support the description of CPU cores, architecture of processor, hostname, IP address, OS, memory, and storage. However, TOSCA only specifies the hardware and operating system requirements of physical devices or virtual machines using the tosca.nodes.Compute node type, without providing information on whether they are located at the edge or in the cloud. One usage example is the TOSCA-based language employed by MiCADO [17], which enables the description of virtual machines provided by the OpenStack, Azure and EC2 cloud provider. MiCADO's CML employs separate entities to describe virtual machines belonging to different supported cloud providers. Each entity has its own distinct set of properties, as there are variations in the semantics used by the respective cloud providers. [PERSON] et al. introduce a processing node entity in their proposed TOSCA extension [20]. This entity can describe hardware and OS capabilities, and includes a resource property indicating whether the processing node belongs to the cloud or the edge. Occasionally, languages may support the same properties in different entities due to variations in their scope. For instance, [PERSON] et al. [20] illustrate sensors as a list of properties within a tos in. Conversely, [PERSON] et al. in the SMADA-Fog Framework [12] represent sensors as properties of IoT devices within the entity labeled and devices (see Section 3.11). The primary reason for this distinction arises from the classification of IoT devices into two main categories: edge devices and user devices. Another noteworthy aspect is the perspective of considering both virtual machines and physical devices as hosts within the same cluster. MoDMaCAO [23] demonstrates this capability by enabling the description of physical devices and virtual machines that can serve as hosts for applications. Furthermore, it allows the representation of how multiple servers can be combined to form a cluster of hosts. In contrast, some CMLs lack the ability to clearly differentiate between application components and underlying resources, which can be attributed to the constrained scope of these languages.