In order to identify desirable features for a platform to support coordinated adaptive context-aware applications it is necessary to analyse the fundamental characteristics of adaptation. As discussed in chapter 2, the operation of an adaptive application is similar to the operation of control systems. More specifically, a simplified closed loop system can be considered as an abstraction of an adaptive system (Figure 4.1). This adaptation system includes three entities: the monitoring entity feeding the system with information that may cause adaptation, the control entity that is responsible for deciding when adaptation is required and the actuator that implements the adaptive mechanism.
In typical adaptive or context-aware applications all three components are part of the application itself. This is principally a consequence of previous research that has shown [Noble97] that fully transparent adaptation platforms cannot provide sufficient support for the requirements of all applications: current approaches in the design of adaptive applications advocate the breaking of the transparency and the shift of adaptation mech- anisms away from the system and into the application itself. Indeed, it is normally the
Application
Control
Actuator Monitor
Figure 4.1: Basic adaptation cycle
application developer that has a clear knowledge of the application’s semantics and re- quirements. Therefore, the developer can best implement the adaptation mechanism required for a specific application. In typical examples of adaptive applications the ap- plication developer implements two of the three adaptation entities: the actuator that is directly related to the logic of the application and the control entity that is usually hard- coded as a static component that decides when adaptation is required. In these systems the monitoring entity is offered by the system (e.g. a power monitoring tool). In certain cases even the monitoring entity retrieving the specific information that is necessary for the operation of the adaptive application is implemented by the application developer (e.g. in [Davies99, Microsoft03, Real03]). It is also quite common for such systems to blur the boundaries between the three entities, sometimes combining two or even all three of them. In particular, it is quite common for adaptive systems to combine the con- trol entity with the actuator [Kistler92, deLara01], while context-aware systems tend to combine the monitoring entity with the control system [Cheverst00, Schilit94a].
In chapter 3 the analysis section showed clearly why this static architecture cannot support systems with multiple adaptive context-aware applications: lack of coordina- tion can lead to conflicts and low performance while lack of user involvement can lead to insufficient support for the user requirements. chapter 3 concludes with a list of requirements for a system that can overcome the aforementioned limitations.
The first requirement (R1) for supporting adaptive context-aware applications is to decouple the adaptation control and the actuator. This requirement is based on the fact that the mechanisms implementing adaptation actuators are tightly linked with the se- mantics of the application and therefore should be part of the application’s implemen- tation. In contrast, the adaptation controls are entities that play a more general role: the
Application
Control
Actuator Monitor
Figure 4.2: Decouple adaptation control and adaptation action
role of an adaptation controller is to receive input in terms of value changes and pro- duce output in terms of invocations of adaptation mechanisms. Therefore, it is possible to follow the same design guidelines for designing all adaptation controllers regardless of the application being controlled. In addition to this fact the decoupling of adapta- tion control and adaptation actions allows adaptation control entities to be externalised and become part of the system supporting adaptation. This means that the application developer is no longer responsible for implementing the adaptation control mechanism but they can rely on the system support offering the control mechanism (Figure 4.2). Finally, the need for decoupling adaptation control and adaptation actions is a prereq- uisite for meeting the the requirements for externalising application state and adaptive mechanisms, necessary to achieve coordinated adaptation.
The second requirement (R2) for supporting adaptive context-aware applications is to externalise application state information. This requirement is based on the fact that information collected by an application as part of their monitoring functionality may be of importance for the adaptation controllers involved in the adaptation cycles of other applications in the system. Externalising information reduces the need for replicat- ing similar monitoring functionalities in many applications. Moreover, the state of an application running in a system can be an important factor for the decision of other applications about when and how to adapt. In terms of platform design this require- ment suggests a system design where adaptation control entities can receive monitoring information from multiple applications (Figure 4.3 ). In practice this means that the adaptation controller of a single application is not isolated from the activities of other applications active in the system. This externalisation requires an open design approach where applications can express their state through a specified interface definition lan- guage. Moreover, since the actual state variables that are reported by applications are not known in advance, the system supporting adaptation must be able to dynamically parse the interface exported by the application and construct the appropriate components
Application Control Actuator Monitor Application Monitor
Figure 4.3: Externalise application state that will collect application state information during runtime.
The third requirement (R3) for supporting adaptive context-aware applications is for applications to externalise their adaptive mechanisms. Satisfying this requirement means that adaptation control entities do not have to be related to a single application. As all adaptive applications in an adaptive system externalise their adaptation mecha- nisms it is possible for adaptation controllers to invoke adaptation in multiple applica- tions. This functionality allows the implementation of coordinated adaptation: a single adaptation controller responsible for implementing a specific adaptation policy can trig- ger multiple applications to perform coordinated actions as required (Figure 4.4). In terms of design, this requirement can be supported by expressing an application inter- face as described in the previous paragraph. More specifically, the application interface exported by applications should include the definitions of methods corresponding to adaptation actuators. These methods could then be called by external entities in order to request that the application performs a specific adaptation action. As discussed above, application interfaces should be dynamic, i.e. the external entity invoking actions on applications should be able to dynamically marshall the data required to perform the
Application Control Actuator Monitor Application Monitor Application Actuator Monitor
invocation as described by the application interface.
The final requirement for supporting adaptive context-aware applications is to sup- port a mechanism that enables adaptation control to be modified by the end user. This means that the actual decision taking policies implemented by the adaptation controllers should not be hard coded by a developer but rather provided in a way where the decision logic can be inspected by the end user. Since applications require default adaptation con- trol functionality when they are installed it should be possible for the end user to have access to this default adaptation control policy and to be able to modify it as they wish. Apart from support for user involvement, this requirement is also the basis for support- ing extensibility and coordinated adaptation. Both of these features include adaptation controllers that either receive monitoring information from multiple applications or in- voke actions on multiple applications. It is not realistic to expect such controllers to be defined by an application developer as default adaptation control policies. Indeed, application developers do not have any knowledge about the existence of other appli- cations in the end system and therefore cannot specify the default adaptation control policy so as to perform coordinated adaptation (invoking actions to other applications in the system) or receive monitoring information from other applications. However, the end user does have knowledge about the configuration of the system and they are capa- ble of modifying the adaptation control policy so that it supports coordinated adaptation. The design requirements derived from these observations are that the adaptation control mechanism should be based on a design where the end user can:
• Inspect the adaptation policies employed by existing adaptation controllers.
• Modify the decision logic of existing adaptation controllers.
• Extend existing controllers with the inclusion of new monitoring information.
• Extend existing controllers with the inclusion of new targets for adaptive actions.
• Add their own adaptation controllers with all the above features (multiple moni- tors, multiple actions).
Technologies that provide the aforementioned features have already been used in other domains of computer science. A particular approach that has been employed in systems where reconfiguration without re-implementation is needed is the use of policy management systems. As E. Lupu and M. Sloman define in [Lupu99]:
“A Policy is information which can be used to modify the behaviour of a system. Separating policies from the managers which interpret them per- mits the modification of the policies to change the behaviour and strategy of the management system without re-coding the managers. The manage- ment system can then adapt to changing requirements by disabling policies or replacing old policies with new ones without shutting down the system."
The features of policy based systems described in this definition appear to cover a significant part of the requirements presented earlier for supporting coordinated adapta- tion and in particular, the ability to adapt the behaviour of a system without the need to re-code the management system itself. The extent to which a policy based system can support all of the aforementioned requirements depend to some extend on the specific characteristics of the policy language used.