Introduction of a Pre-Configuration Process

We present theclustering framework we developed to enable the automatic selec-tion of the cluster head and cluster member roles in Secselec-tion 4.3.2. This clustering framework represents the basis for the automatic adaptation of the degree of decen-tralization in the application configuration. For centralized configuration, it only introduces one single cluster around the most powerful device. Later in Section4.4, we extend the clustering strategy to enable multiple clusters for hybrid configura-tion with a balanced configuraconfigura-tion load among the powerful devices, and we present cluster maintenance strategies to keep the balanced configuration load even in dy-namically changing environments.

4.1. Design Rationale 81 A configuration process is initiated when the user starts an application on his or her mobile device. Then, the relevant information about the application, i.e. the application structure and information about the dependencies that have to be re-solved, is automatically transmitted to all present devices. The arising latency is heavily depending on the wireless network and is denoted by T_n (network latency).

In the following, the present devices cooperatively calculate a valid configuration in a distributed manner, i.e., using the algorithm proposed by Handte et al. [HBR05].

The corresponding latency is called distributed configuration latency, or T_dc. After the devices have found a valid composition, the initialization of the bindings be-tween the different components is started, yielding the initialization latency T_i. Thus, the application configuration process (covering calculations and component initialization) lasts for T_a,decent = T_dc +T_i. Finally, the complete composition is transmitted to the user’s device, causing again latency T_N as this transmission de-pends on the wireless network. Now, the application is executed and available to the user. Consequently, the overallwaiting time T_w,decentof a user which covers the time span between the user’s application start and the can be expressed by the following equation:

T_w,decent = 2·T_n+T_a,decent = 2·T_n+T_dc+T_i (4.4) (Waiting time of decentralized configuration) Switching from decentralized to centralized configuration, the corresponding inter-action model changes, as Figure4.7shows. When the user starts an application that is to be configured in a centralized manner, then at first the most powerful device has to be found. Subsequently, the cluster around this device needs to be estab-lished, which takes the additional cluster time T_c. In the next step, the cluster head requests the resource information of the other devices in order to enable the local calculation of a composition on the powerful device. The time between the cluster head’s request and the receipt of all resource information is denoted by theresource retrieve time T_r. After the weak devices have sent their resource information to the cluster head, this device calculates a valid composition, without involvement of the other devices. We denote the respective centralized configuration latency by the centralized configuration time T_cc. Then, the powerful device sends the configuration information to the other devices, which initialize the respective component bindings then. The final step is the same as in the decentralized approach: The assembly is sent back to the user’s device, and the application is executed. Like before, we can easily determine the arising waiting time for the user as follows, where T_a,cent denotes the changed latency for the centralized configuration process:

T_w,cent = 2·T_n+T_a,cent = 2·T_n+T_c+T_r+T_cc+T_i (4.5) (Waiting time of centralized configuration) The local calculation on the powerful device does not involve message communi-cation with the other weak devices. Furthermore, it is supposed that the powerful

device calculates valid compositions faster than the weak devices, due to its signif-icantly increased computation power, i.e. T_cc < T_dc. However, centralized configu-ration introduces the timesT_c to establish the cluster andT_r to gather the resource information from the weak devices. So, the centralized configuration is only faster than the decentralized configuration (i.e.,T_w,cent < T_w,decent) ifT_c+T_r+T_cc< T_dc.

Figure 4.7.: Interaction diagram of centralized configuration

As the centralized configuration as shown above needs a powerful device to retrieve resource information (which introduces the additional time T_r), a main focus for a centralized configuration approach is to increase its efficiency by speeding up specific parts of the configuration. Therefore, we evaluate the arising latencies from Figure4.7 according to their potential for speed ups:

• As the timesT_n for transmitting information about the application and found compositions mainly depend on the bandwidth of the network connection, reducing these latencies is only possible if the wireless technology is changed, e.g., from IEEE 802.11b (11 Mbit/s) to 802.11g (54 Mbit/s) or 802.11n (up to 600 Mbit/s). We do not follow this approach here.

4.1. Design Rationale 83

• As the interaction model in Figure 4.7shows, the times T_cfor establishing the cluster and T_r for retrieving the resource information of the weak devices are included in the overall latencyT_w. However, the powerful device does not need to wait for the user’s application start to request the resource information, but may already request this information prior to the configuration, i.e. when the weak devices come into communication range. The same holds for the retrieval of the resource information. So, an approach to increase efficiency of centralized configuration is to accomplish some configuration-relevant tasks before the user actually starts an application. We follow this approach in Sec-tion 4.3.5 and call the premature cluster establishment and resource retrieval a pre-configuration process.

Figure 4.8.: Interaction diagram of centralized configuration with pre-configuration process

• The time T_cc for the actual configuration depends solely on the centralized configuration algorithm. Therefore, it is important to have an efficient config-uration algorithm to be executed on the powerful devices, without involving thrashing effects or unnecessary subsequent adaptations within a configura-tion. For this purpose, we present Direct Backtracking as an efficient central-ized algorithm in Section 4.2.

• Initializing the bindings between those components which have been deter-mined as valid components is only depending on the deterdeter-mined composition and the location of the components among the present devices. Reducing this binding overhead by finding special configurations that involve many neigh-boring components on the application tree which are resident on the same device is left for future work, as Section7.2.1 will briefly discuss.

So, the main challenge to reduce the overall latencies is to provide a mechanism that automatically loads the weak devices’ resource information to the powerful devices, prior to a configuration, as Figure 4.8 shows. This reduces the overall waiting time to

T_w,preconf = 2·T_n+T_a,preconf = 2·T_n+T_cc+T_i (4.6) (Waiting time of centralized configuration with pre-configuration process) So, centralized configuration that involves a pre-configuration process is always faster than centralized configuration without pre-configuration (i.e., T_w,preconf <

Tw,cent) when no configuration information needs to be obtained at configuration time. Moreover, centralized configuration is also faster than decentralized config-uration (i.e., T_w,preconf < T_w,decent) if T_cc < T_dc, which is – in compliance with the discussion we led above – typically the case in heterogeneous environments. To achieve such an efficient centralized configuration, we will take a closer look on how to proactively and automatically retrieve remote resource information by the powerful device in Section 4.3.5.

As introduced above, a hybrid configuration scheme has to combine the advantages of both decentralized and centralized configuration. Figure4.9shows the interaction diagram of the hybrid approach. As main difference to the centralized scheme, there are several powerful devices involved in the configuration. Like in centralized con-figuration, the powerful devices also perform a pre-configuration process, covering the establishment of several clusters (contrary to the centralized approach where onlyone cluster is established), and the retrieval of the resource information of the mapped weak devices. Furthermore, another difference arises at the configuration calculation stage, where the powerful devices cooperatively calculate a valid config-uration. As this configuration is performedin parallel and only on the resource-rich devices without involvinh the weak devices, the configuration latencyThc of the hy-brid configuration is supposed to be lower than the configuration latencyT_cc of the centralized configuration.

In consequence, the waiting time T_w,hybrid for an application user when hybrid configuration with pre-configuration is used can be denoted as follows:

T_w,hybrid = 2·T_n+T_a,hybrid= 2·T_n+T_hc+T_i (4.7) (Waiting time of hybrid configuration with pre-configuration process)