So far, the PCM does not support the modelling of hierarchical resource containers. This is a major limitation for deployers, since they cannot model different software layers running on the same machine. For example, virtualisation of operating systems cannot be specified. Furthermore, it is not possible to describe systems that contain multiple components that are placed on different software layers, e.g. operating system and application server, but on the same machine.
Another limitation stems from the modelling of linking resources. At the moment, we only allow a single linking resource between two resource environments with one specification. Thus, scenarios in which two hardware nodes are connected by multiple links, e.g. LAN and wireless LAN connection cannot be modelled. Furthermore, it is not possible to explicitly allocate connectors between components to linking resources. With only one connection between two containers, this can be done automatically using direct links only. However, if multiple connections are allowed the allocation of connectors must be modelled explicitly. The same problem arises when indirect communication between containers is allowed. In this case, the communication path between components is ambiguous even with only one connection between two containers.
In section 3.4.3, we described how to specify new resource types. Even though this provides a high flexibility, it requires component developers and deployers to agree on a common set of resource types. For scientific purposes, this is feasible. However, we need to integrate a standardised set of resources into our model so that there are no mismatches between the specifications of different parties. As the modelling of execution environments is not as elaborated as other parts of the PCM, we left the specification of resources open for the time being. For the future, we plan to fix the available set of resources.
Also, the specifiable properties of the resource types are limited. So, if a new resource type has additional attributes that have to be specified, this cannot be described. For example, queues could be introduced as a passive resource. Usually, queues are used for asynchronous communication between multiple processes and threads. One process puts a message or any data into the queue while another process reads it. A producer-consumer system is a common example for such a scenario. A special application for queues can be found in combination with active objects [34]. Instead of calling a method of an active object directly, the call with its parameters is placed in a message queue. The scheduler of the active object fetches the messages from the queue and processes them. Queues do not only have a capacity as all passive resource do, but also require an attribute which specifies the order in which its items are processed, like LIFO or FIFO. This is not possible so far.
Furthermore, multicore processors and multi-processor systems are becoming more and more common forming new challenges for the PCM, as we need appropriate mechanisms to specify the QoS-relevant aspects of these systems. For example, the number of memory buses and caches has a significant influence on the performance of a multithreaded application. So, specifying two processors with the same properties might not be sufficient, as these processors share other important resources that are not modelled explicitly.