Análisis de óptimo paretiano:

The high level architecture presented in chapter 4 does not make any statements about the location of each individual component of the platform. However, the level of distri- bution chosen for the system has implications for the implementation of the platform. In this section we examine the possible configurations for an implementation of a platform supporting adaptive context-aware applications.

The platform configurations presented here follow an increasing level of distribu- tion. Specifically, the discussion begins with the configuration of a system where all applications and the platform are located in the same host and finishes with a configura- tion where applications and platform components are distributed across multiple hosts.

5.2.1

Non Distributed with Local Applications

The single host configuration assumes a system where all platform components and applications are located on the same host. (Figure 5.1(a)). This configuration has min- imal requirements in terms of communication. Specifically, there is no need for a net- work protocol to be used between the applications and the platform or between the platform components. In particular, both, communication between applications and ap- plication managers and the internal communication layer, can be implemented using an inter-process communication mechanism such as shared memory. Moreover, the time- ordered delivery of events from the application managers to the system manager will not face the delay issues experienced by a distributed configuration.

Host 1

Internal Communication Layer

System Manager

Applications

Application Managers

(a) Non distributed with local applica- tions

Host 3 Host 2

Host 1

Internal Communication Layer

System Manager Applications

Application Managers

(b) Non distributed with remote appli- cations

Host 3 Host 2

Host 1

Internal Communication Layer

System Manager

Applications

Application Managers

(c) Partially distributed platform

Host 3 Host 2

Host 1

Internal Communication Layer

System Manager 2 Applications Application Managers System Manager 1

(d) Fully distributed platform

Figure 5.1: Platform configurations

5.2.2

Non Distributed with Remote Applications

The second configuration assumes a system where applications can be distributed across different hosts while the platform is located on a single host (Figure 5.1(b)). This config- uration implies a requirement for the use of a network protocol for the communication between applications and application controllers. In more detail, this configuration re- quires the employment of a technology for remote process invocation and event dissem- ination. Technologies like Corba, Java/RMI and Web Services (Section 4.4.1) would be appropriate candidates for an implementation of this system. In terms of the internal communication, both the application managers and the system manager are located in the same host. Therefore the communication between these components can be based on inter-process communication as described in the previous paragraph. However, since there are delays between the time state variables change and the time these changes are reported to the platform, an appropriate mechanism to ensure timely delivery of these

notifications should be implemented.

5.2.3

Partially Distributed Platform

The third configuration assumes a system where both applications and application con- trollers can be distributed across different hosts (Figure 5.1(c)). In this case the burden of network communication is pushed away from the application managers and into the internal communication layer. Specifically, application managers can be located on the same hosts as the remote applications. Thus the network traffic concerns the com- munication between the application manager and the system manager. This particular configuration would require the employment of a middleware platform handling the ex- change of notification events from the application managers. Platforms such as L2imbo, the Event Heap and CEA are examples of plausible choices (Section 4.5.1).

5.2.4

Fully Distributed Platform

In a system where applications are distributed across multiple hosts, having a single central system manager can significantly reduce the responsiveness of the system, es- pecially where high latency or low bandwidth networks are used. Having system man- agers located on the same hosts as the applications can improve the responsiveness of the system. The fourth configuration is where the system manager is distributed across different hosts. (Figure 5.1(d)). In more detail, adaptation polices that are related to a particular application can be located on a system manager running on the same host. Thus, the adaptation reaction related to that particular application should have faster responses as compared to a remote system manager. This configuration requires the im- plementation of a policy management system that allows the distribution of policy rules across different system managers. As presented in section 4.7.3, the Event Calculus Policy Language allows the specification of policy rules that are complete and have no requirements regarding the co-existence of other policy rules. In particular, each policy rule contains the definitions of all entities required for its evaluation (events, fluents). Therefore, it is possible to distribute policy rules across hosts allowing their manage- ment by distributed policy managers.

However, such a configuration imposes additional requirements on the implemen- tation of the internal communication layer. In particular, state variable changes must

be delivered to all system managers that are handling policy rules related to the state variables in question. The use of a tuple space mechanism offers a significant benefit. As state variable notifications are shared among all components in the system, system managers can retrieve the notifications they require for the sub-set of policy rules they are handling. Therefore, there is no need for the internal communication layer to em- ploy mechanisms to maintain the delivery of the notifications to the appropriate system managers. Moreover, the approach of a replicated tuple space (such as the one used by L2imbo, section 4.5.1.4) can reduce the delay overhead for the requests of application state information. In particular system managers can retrieve information about the state of distributed application controllers using their local replica of the tuple space. Consid- ering the fact that the implementation of the replicated tuple-space is based on multicast, this means that the total network traffic would be considerable smaller, compared to a mechanism based on point-to-point communication where each system manager would retrieve information from each distributed application controller.