Backtracking (BT)
5.1. Motivation
5
Partial Application Configurations
In this chapter, we introduce a completely new approach that integrates the results from configuration processes that have taken place before to reduce the number of contracts which actually need to be configured [SHRB13]. Thus, the configuration latency is significantly reduced in all of the scenarios and algorithms introduced in Section 4, as we will show in our evaluations. In Section 5.1, we give a motivation for the use of Partial Application Configurations (PACs). Following in Section 5.2, we discuss the challenges that come along with the partial application configura-tion concept and have to be addressed by the aspired soluconfigura-tion. After discussing the structure of the PACs in Section 5.3, we suggest a solution which is based on the introduction of utility values for each partial application configuration (Sec-tion 5.4). As the partial application configurations are stored in a cache of limited size, the maintenance of the cache entries is addressed in Section 5.5. Following in Section 5.6, we illustrate the integration of thePAC concept into the existing con-figuration approaches. After presenting the results of our evaluation measurements in Section 5.7, we summarize this chapter in Section 5.8 and discuss the developed approach.
needs of the involved devices. Using pre-cached component sets in configuration pro-cesses helps in solving these problems. As they represent pre-configured application parts, we refer to one of these component sets as a Partial Application Configu-ration (PAC). The components involved within a PAC represent a pre-computed subtree of the complete application tree. If all components included in a cachedPAC are currently available, this PAC can be integrated into the current configuration.
As the cache size is typically limited due to practicability issues, only those PACs with the largest expected utility for future configuration processes should be cached.
[0,0]
[0,0]
[2,0]
[0,0]
[0,0]
[0,0]
[0,0]
[2,0]
[0,0]
[0,0]
[2,0]
[1,0]
[0,0]
[2,0]
[1,1]
[0,0]
[1,0]
[1,2]
Acoustic & Optical Output Device
Optical Output Acoustic & Haptic
Input Device
[0,0]
[1,0]
[1,1]
[0,0]
[1,0]
[1,0]
Source File Input Device
[0,0]
[0,0] Acoustic
Input
Haptic Input
[0,0]
[1,0]
[0,1]
[0,0]
[1,0]
[0,0]
Application Anchor (Root)
[0,0]
[1,0]
Acoustic Output Source
File
PAC0 PAC1
PAC2
Figure 5.1.: Configuration using Partial Application Configurations (PACs) As an exemplary scenario where thePACconcept is suited to reduce configuration latencies, consider Figure 5.1 which shows the distributed presentation application introduced before, and threePACs which have been determined and cached for their future re-use:
• When a speaker gives a talk, he or she may have the presentation file stored on his or her Smart Phone. If the speaker gives the same talk (e.g., the presenta-tion of a new product) several times for changing audiences, the configurapresenta-tion always comprises the use of the Smart Phone and the presentation file main-tained on the Smart Phone’s internal storage. Because of this, P AC0 which covers these two components is created and cached.
• The input components are typically provided using the speaker’s laptop or a dedicated presentation device. Thus, P AC1 – which covers the speaker’s laptop (CoID [0,0][1,0]), the microphone (CoID [0,0][1,0][0,1]) and the mouse (CoID[0,0][1,0][1,0]) that are connected to the laptop – is frequently used and represents another suitable candidate for caching.
• Concerning the components for acoustic and optical output, P AC2 – cov-ering a speaker system (CoID [0,0][2,0][0,0]) and a video projector (CoID [0,0][2,0][1,0]), which are connected to a control PC (CoID [0,0][2,0]) – rep-resents a third possible PACfor caching.
5.1. Motivation 145 Figure 5.2 shows the interaction diagram of a configuration process which uses the PAC concept. Please note that in this figure, PACs are used in combination with the hybrid configuration approach. We expect that strongly heterogeneous environments offer the highest potential for the use of PACs because of the available resource-rich, typically stationary infrastructure devices. However, thePACconcept itself is independent from specific configuration algorithms and, thus, can also be used by configuration algorithms other than the hybrid one, i.e., by centralized or decentralized algorithms (cf. Chapter 4).
Figure 5.2.: Interaction diagram of hybrid configuration with pre-configuration pro-cess and use ofPACs
As major difference compared to the configuration without PACs (as illustrated in Figure 5.2), each configuration device has access to a so-called PAC Repository, which contains the Partial Application Configurations that have been used in previ-ous configuration processes and cached locally in this repository. Configuration with PACs should also use the pre-configuration process introduced in Section 4.3.2 to maintain the up-to-date resource information of the mapped Passive Devices on the Active Devices. Furthermore, the pre-configuration process is used to update the validity of a PAC: APAC is supposed to be valid and, thus, usable within a
config-uration process only if all components which are covered by the PAC are currently available, meaning the device where they are resident is up and the component is not used by any other currently executed application. More formally, the validity V(P) of a PAC P consisting of n componentsC1, . . . , Cn can be determined by
V(P) = V(C1)∧V(C2)∧ · · · ∧V(Cn), (5.1) where V(Ci) represents the validity of a component Ci (i ∈ 1, . . . , n). In the configuration phase, the applied configuration algorithm tries to configure as many components as possible via the cached PACs to reduce the number of contracts which actually need to be configured, i.e., by matching the available components’
offers of functionality with a contract’s requirements. As the simple integration of pre-cached components is much faster than the standard configuration (we will show more details on that issue in our evaluations in Section 5.7), the configuration la-tency Thc,P AC is reduced compared to the latency Thc of hybrid configuration which does not rely on a PAC framework. As the initialization phase remains unchanged, the application configuration latency Ta,P AC becomes the sum of the configuration calculation latency Thc,P AC and the component initialization latency TI. In conse-quence, the total latency
Tw,P AC = 2·Tn+Ta,P AC = 2·Tn+Thc,P AC +TI, (5.2) whereTn represents the network latency, is also reduced compared to configuration withoutPAC use.
After a successful configuration process, the configuration devices update their PAC Repository by including new PACs and, in case of exceeded cache space, re-move selectedPACs from the repository. We will present more details on the utility of specific PACs in Section 5.4, and introduce cache replacement strategies in Sec-tion 5.5.