Coordination

One of the main subjects of criticism for existing adaptation support platforms presented in chapter 2 is the lack of efficient coordination between applications. Specifically, many adaptation systems (e.g. Puppeteer, Laissez-Fair applications) tend to treat applications in isolation from the rest of the system. System’s based on open architectures break this isolation but rely on the application developer to use information about other ap- plications and achieve coordinated adaptation. There are platforms that were developed in order to support coordination. However, these platform tend to look at coordination from a limited point of view. For example, coordination support platforms such as the Event Heap considers the support for the the exchange of notification messages between applications. Such approach relies on the applications themselves to use these notifica- tions and coordinate their activities. Middleware platforms consider coordination as a mechanism to achieve balanced resource sharing between applications. In Odyssey in particular, allowing applications to specify their requirements in terms of resources and maintaining resource sharing according to these requirements is considered a form of coordination.

In this thesis we consider coordination as the ability of the system to coordinate the actions taken by adaptive applications based on a set of specified rules. The aforemen- tioned approaches are either special cases of this approach (e.g. resource sharing) or

supporting technologies (e.g. event exchange mechanisms).

In order to look at the support for coordination offered by the platform presented in this thesis, a simple coordination scenario was implemented. This scenario shows how two applications (a Web browser and an E-mail client) can coordinate the use of the network in order to improve the delivery time of web content. In particular, using the adaptation interfaces described in section 6.2.1 a set of policy rules were defined that control the two application to trigger the e-mail client to suspend the use of the network when a web page is downloaded. This can be a required behaviour for a system con- nected over a weak link. In particular, as the web browser is an interactive application, disrupting the loading of a page in order to check for new e-mails would be undesirable for the user. In order to achieve this effect two additional rules were added to coordinate the e-mail client with the web browser:

event webDownload :−WebBrowser.state = "downloading" condition { happens(webDownload) } action { Email.SuspendNet() }

This rule causes the e-mail client to suspend all network activity when the web browser starts to download a page. An additional rule is specified that will trigger the email client to resume the network usage when the page has been downloaded.

event webDownload :−WebBrowser.state = "downloading" event webNotDownload :−WebBrowser.state <> "downloading" fluent webNotDownloading {

initiates(webNotDownload) terminates(webDownload) }

condition {

initiates(webNotDownloading, webNotDownload, t1) and not clipped(webNotDownloading, t1, t2) and

t2 = t1+10 }

action {

Email.ResumeNet() }

This rule triggers the e-mail client to resume network activity when the web browser has stopped downloading pages for more than 10 seconds.

As we can see from this example the actual approach that is used by the platform presented in this thesis is quite different from the adaptation approach used by existing middleware applications. In more detail, existing systems require the applications to specify their resource requirements and possible coordination is performed implicitly by allowing sharing of the resources. However, here the adaptation rules control the actual actions that the applications are required to take. In more detail, the notion of coordination as it is approached by this work relates to activities and resources used.

An implication that is derived from this approach is that the adaptation mechanism is not related to a specific resource. In more detail, coordinated actions can be specified for applications regardless of the involvement of resource sharing or not. Indeed, in a context-aware environment coordination exceeds the boundaries of resource sharing. Applications may require to coordinate their actions simply because that is what the user wants. These coordinated actions may be related to a resource (as presented in the previous scenario) or it can be a requirement of the user. For example, one scenario that falls in this category is to coordinate applications in relation to the location of the user. Specifically, a rule that can switch off the audio from the video player when the user enters the corridor of the building is the following:

event corridorIn :−Location.locationLabel = "corridor" event corridorOut :−Location.locationLabel <> "corridor" fluent inCorridor { initiates(corridorIn) terminates(corridorOut) } condition { initiates(inCorridor, corridorIn, t1) } action { VideoPlayer.StopAudio() }

By extending the rule body this rule can be used to coordinate other applications that should be triggered when the user enters the corridor:

action {

VideoPlayer.StopAudio()

WebBrowser.SetProxy(10.10.10.1, 8080) }

As discussed in the previous paragraphs, an existing approach in resource manage- ment is to allow applications to specify resource requirements and rely on the system

to satisfy their requirements. Although the design of this platform does not rely on resource reservation mechanisms to control resource sharing, the actual design of the platform does not prevent this. In more detail, the adaptation interfaces of the applica- tion can include state variables that express the resource requirements of the application. One such example is the video player. The state variables representing the existing bit rate of the video stream along with the bit rates of lower and higher bit rate streams are actually indications of resource windows that the video can switch to. The default policy rules that were described in section 6.2.1.1 control how the application can adapt if the network resources are either enough to support a higher quality video stream or not enough for the current stream and the player should switch to a lower quality one. Nevertheless even in this case the policy rules that control such an application are based on actions that should be taken instead of an explicitly resource related adaptation ap- proach. Specifically, the rules include the actions that the application should take in order to adapt or collaborate in a coordinated adaptation. This characteristic allows the platform to offer a general purpose coordination mechanism.

One observation that is derived from the video example and the coordination sce- nario presented earlier is that there is a clear relationship between the adaptation inter- faces exposed by the applications and the degree to which coordination can be achieved. In more detail, in the web browser-email client coordination scenario the fact that the e-mail client implements an adaptation interface with the method callsSuspendNetand ResumeNetis vital to achieve the specific coordinated action. Generalising this obser- vation it is clear that the level of flexibility offered by this platform is directly linked to the level of control applications offer to the platform. Considering a system where appli- cations follow an open approach (i.e. a Reflective approach) in their design might allow the platform to have a greater degree of control over the actions of the applications.

Summarising the discussion on coordination, the adaptation support platform dis- cussed here follows an approach where adaptation is not related to resource sharing between applications according to the requirements expressed by applications. Rather the approach followed is related to the actual actions that the applications are required to take in order to achieve resource related coordination or any other type of coordina- tion. Specifically, this approach is general enough to allow coordination for any context related information that applications should respond to (e.g. location). One observation that is derived from this investigation is that the degree of flexibility in achieving coor- dination between applications is directly related to the adaptation interfaces exposed by

the applications. In particular the more control applications offer to the platform, the more flexibility is possible to coordinate adaptive applications.