• Keine Ergebnisse gefunden

Backtracking (BT)

5.8. Summary and Discussion

In this chapter, we have introduced the concept of integrating the results from pre-vious configurations into future configuration processes. This is achieved by caching parts of a valid configuration for their future re-use. We call a set of components which have been used within a previous application configuration in combination and form a subset of the application tree aPartial Application Configuration (PAC).

We have addressed several issues that have to be regarded while integrating par-tial configurations into application compositions. In order to enable the storage of PACs, a cache has to be provided. This cache needs to be of limited size to obtain applicability of the approach in realistic pervasive scenarios. The determination of a suitable cache size which is neither too small, nor too large has shown to be a main issue for the performance and the applicability of the PACapproach.

Another important issue that arised was how to proceed when the cache space is exceeded. Therefore, we have suggested to use a replacement strategy which

5.8. Summary and Discussion 167 introduces a utility value for each cached PAC that is based on the recency and frequency of the PAC’s availability. The PAC utility values are updated whenever a configuration process is taken. When the cache space is exceeded, only the PACs with the lowest utility values are replaced. Moreover, to increase the efficiency of the cache space usage, we have decided to distinguish between two different types of PACs in the cache: WhilegreenPACs represent thePACs with currently highest utility value and are stored in a complete format which can simply be integrated into configuration assemblies, yellow PACs represent partial configurations with lower utility values that store the information about the PAC components in a much more compact format. Because of this, the number of storable PACs is significantly increased. However, yellow PACs cannot be directly integrated into configuration assemblies. But as their utility values are recorded, they may become green PACs in the future when their utility value increases. In this case, the complete format of this PAC is automatically created, which is possible as the yellow PACs contain all required information. Then, the formerly green PACwith lowest utility value is replaced. The provision of a reasonable number of green PACs in combination with additional yellowPACs guarantees to always have a large set of highly usablePACs in the cache, yielding low cache miss rates, as our evaluations have shown.

To integratePACs into configuration processes, the configuration approaches pre-sented in Chapter 4 needed to be extended so that they first check if a usablePAC exists that fulfills the dependencies given by an application contract. In this case, the PAC is simply loaded from cache, and no calculations need to be taken for the respective application parts. Otherwise, the contract dependency needs to be re-solved in the standard way using contract matching. The corresponding extensions of the configuration assemblers are of minor nature, so the simple integration of the PAC concept into additional assemblers is ensured.

In our evaluations, we have determined suitable parameters of thePACapproach for the overall cache size, the distribution of the cache into green and yellow PACs, and the influence of the recency and frequency for the replacement strategy. In these measurements, we have shown that a replacement strategy which equally weighs the recency and frequency of the PAC availability provides the lowest average cache miss rates. This strategy also yields significantly lower cache miss rates than stan-dard replacement strategies like FIFO or pure LRU or LFU. Following, we have determined an overall cache size of 400 kB as a good tradeoff that provides a low cache miss rate and, hence, a low configuration latency, while at the same time, keeps the disk space requirements on the involved devices low. The fraction f of cache space which should be reserved for yellow PACs has shown to monotonously rise with an increasing fraction of resource-rich devices. After having determined static values for thePAC parameters (overall cache size, fraction of cache for yellow PACs, recency/frequency parameter of the replacement strategy), we focused on providing dynamic parameters which automatically adapt themselves to changing environments. Therefore, we have presented approximation functions that solely depend on the relative amount of resource-rich devices as input parameter, since this parameter has shown to have the highest influence on the performance of the PAC approach in our measurements. With dynamic parameters, the configuration latencies could further be reduced compared to the use of static parameters.

In summary, we have presented a solution for the effective caching and use of PACs that are highly valuable for future configuration. Through this, the number of components that actually need to be configured is reduced, leading to configura-tion processes which are around 35 % faster on average than configuraconfigura-tion without PAC use. This leads to less user distraction and, in consequence, to more seam-less configurations and adaptations. So far, none of the related projects features a similar mechanism. Thus, the use of PACs represents a completely novel approach in the research area of automated composition of distributed applications. Corre-spondingly, the PAC concept represents a large step towards realizing the vision of Pervasive Computing in configuring adaptive distributed applications.

6

Prototype