Ann. Telecommun. DOI 10.1007/s12243-012-0307-x
Low response time context awareness through extensible parameter adaptation with ORCA Jean-Yves Tigli · Stéphane Lavirotte · Gaëtan Rey · Vincent Hourdin · Nicolas Ferry · Christophe Vergoni · Michel Riveill
Received: 30 June 2011 / Accepted: 14 February 2012 © Institut Mines-Télécom and Springer-Verlag 2012
Abstract Ubiquitous computing applications or widespread robots interactions execute in unforeseen environments and need to adapt to changeful available services, user needs, and variations of the environment. Context-awareness ability addresses such a need, enabling, through adaptation rules, applications to react to the perceived dynamic variations. Responses to adaptation have to be quick enough to maximize the time during which the application is coherent with its environment. Adaptation rules, associating variations of the environment to application reactions, are usually established at design time. However, in unforeseen and partially anticipated environments, we claim that adaptation rules have to be dynamically extensible to match previously unexpected variations. Our approach enables rule composition and ensures a deterministic result. We propose to use parameter adaptation to quickly respond to environmental variations and
dynamic compositional adaptation to provide extensibility to the parameter adaptation. To foster even lower response times, we internalize context-awareness processing and decision into the application. Keywords Response time · Dynamic adaptation · Internalized context awareness · Rule composition · Extensible parameter adaptation
1 Introduction The ubiquitous computing paradigm envisions an environment where most artifacts of our daily life are networked and can communicate with each other. They can be both pure logical entities such as services or mixed logical physical entities such as devices, sensors, or actuators. These devices are either static, for
This work is part of the Continuum Project (French research) ANR-08-VERS-005. J.-Y. Tigli (B) · S. Lavirotte · G. Rey · V. Hourdin · N. Ferry · C. Vergoni · M. Riveill Laboratoire I3S (Université de Nice - Sophia Antipolis/CNRS), 930 route des Colles, B.P. 145 06903, Sophia-Antipolis Cedex, France e-mail:
[email protected]
C. Vergoni e-mail:
[email protected]
S. Lavirotte e-mail:
[email protected]
N. Ferry CSTB (Centre Scientifique et Technique du Bâtiment), 290 route des Lucioles, B.P. 209 06904, Sophia-Antipolis Cedex, France
G. Rey e-mail:
[email protected] V. Hourdin e-mail:
[email protected] N. Ferry e-mail:
[email protected]
M. Riveill e-mail:
[email protected]
C. Vergoni GFI Informatique, Emerald Square - Batiment 2, Avenue Evariste Galois, B.P. 199 06904, Sophia Antipolis Cedex France
Ann. Telecommun.
example attached to a window pillar, or mobile, in which case they are carried by users or robots. As raised by [1], robotics and ubiquitous computing share the same paradigm shift switching from personal robots (the personal computer era in particular) towards widespread robots or “ubibots” (ubiquitous and pervasive computing entities in particular). A different point of view, expressed by James Crowley and Joëlle Coutaz, assimilates ubiquitous computing environment as a robot. Indeed, the whole computing system is autonomous and self-managed and uses lots of mechanisms that emerged in robotics. From inside this robotic environment, the user, as the center of the system, can influence, not necessarily voluntarily, his own computing environment. Added to this, the user’s mobility and the intrinsic dynamicity of the outside environment bring out the need for the system to adapt itself to its context [2]. An important challenge shared by ubiquitous computing and ubibots [1] is to provide new and relevant services in line with dynamic and unpredictable environments along with user’s needs [3]. For both, this implies that they must be able to adapt to changes in their environment. The context awareness provides this ability to a system. Among the issues to be addressed, the temporal relevance remains poorly studied. It is related to the consistency between a system’s state and its environment for a given period of time. The time required to adapt the system when a change in the environment is detected, called response time thereafter, has to be low both to enhance user experience and to make services or applications well suited and consistent to their actual environment [4]. Common ways to achieve low response times are simple context processings [5, 6] and parameter adaptation [7]. However, since services or applications do not evolve in completely foreseen environments and in completely predictable user’s goals, their parameters cannot be established exhaustively at design time. In a such environment, parameter adaptation should be dynamically extensible in order to extend the system’s fast adaptation capability without stoping it. In our knowledge, very few works on dynamic adaptation are able to take into account new adaptation rules at run time to match changing execution environments. And even less approaches have capabilities to solve potential conflicts between adaptation rules dynamically, required by the fact that we cannot assume that an expert end user or a developer is behind each computing issue. We thus propose a low response time and dynamic context adaptation rule system, ORCA, based on simple context processing and parameter adaptation. We
tackle the issue of the parameter targeted by adaptation being unknown at design time by using the compositional adaptation otherwise used to adapt application to important context changes. Rules can thus be activated or deactivated at run time and are composed with each other and with applications in a deterministic way controlled by policies. Rules are projected to the application framework and internalized into applications to provide even better response times to parameter adaptations. In the following sections, we will first discuss about response time implications and requirements (Section 2). We will continue by proposing our contextawareness rule model, its internalization and rule composition (Section 3). We will then present how it can be projected onto the WComp experimental platform (Section 4) and evaluate the context-awareness response time (Section 5). We will then discuss related works (Section 6), conclude, and present future works (Section 7).
2 Context awareness needs rapid adaptation and dynamic extensibility Ubiquitous robots or widespread devices evolve in a dynamic environment. Whether or not these devices are mobile, they have their own dynamics. Each contextaware device perceives its environment and acts accordingly autonomously. The environment in which each of these devices evolves owns itself multiple dynamics (e.g., the social situation, the ambient brightness, the user behavior, and so on). Each of these dynamics is independent. Devices, enriched by context awareness, aim to correlate their own dynamics with an external one. The correlation is provided by the device dynamic adaptation to an external variation. In such a dynamic environment, all possible variations involving adaptation cannot be exhaustively identified at once. These environments are intrinsically open and partially predictable [8]. On one hand, the adaptation time has to be as fast as possible to prevent introducing lag between the dynamics correlated. On the other hand, the adaptation policies established upstream have to be dynamically extensible to match new situations unplanned before. 2.1 Context awareness must be done in a timely fashion With respect to the evolving dynamics of the environment, we can consider that adaptive applications are always in one of the three states presented in Fig. 1.
Ann. Telecommun. Fig. 1 Adaptation to context: states of the application [4]
State (1) is the normal execution state of the application, where it is consistent with its environment. It means that the application’s behavior is in line with its environment. State (2) occurs when a change happens in the environment while the application is still in the same state as before the environment changes. During state (3), the application is in its adaptation phase and unavailable. It is considered in an inconsistent state because the application is not in line with its environment. Changes can occur in the environment while the application is in state (2). If a change occurs during state (3), then the produced application falls in step (2) again. The time spent in states (2) and (3) has to be consistent with the two types of dynamics: (a) environment’s dynamics and (b) application’s dynamics. First, adaptation’s dynamics has to be consistent with the dynamics of the changing environment (a) [4]. In other words, it is essential that –
–
The system does not stay in the inconsistent state (2) for too long before reacting to environment changes. The system is not unavailable (3) for too long while adapting, so adaptation has to be as fast as possible in order to obtain a consistent application (1). Otherwise, the system could become unstable as it may never reach state (1) before new evolutions occur in its environment (denoted by the cycle between states (2) and (3)).
Moreover, adaptation’s dynamics has to be consistent with application and/or user operation (b). In other words, it is essential that –
The system does not switch too frequently from state (1) to (3) and produces an application unstable and inconsistent with its environment.
–
The system does not lag too much; it can disrupt and divert the user from the system [9].
An adaptation cycle is similar to any self-adaptation control loop like the well-known Monitor–Analyze– Plan–Execute from the autonomic computing domain. In context-aware computing, the four operations are generally context collection, context information processing, decision or adaptation planning, and actual adaptation. Response time thus depends on each of these operations, and having it low requires all operations to be as efficient as possible. In this paper, we consider that the system can be based on mechanisms for context collection, processing, and decision that provide low response times. 2.2 Context awareness requires extensibility Widespread networked devices or robots in interaction provide applicative behaviors to their environment. These applications need to be dynamically adapted to continual and dynamic variations of their environment. Traditionally, these adaptations follow policies, established upstream by developers, that manage the dynamic alignment of the application with its environment. The whole environment and its complex variations cannot be completely identified neither at design time nor at run time [8]. Thus, adaptation policies cannot be exhaustively identified at once. An important aspect concerning the applications deployed in these environments is that it is not conceivable to stop them to introduce new behaviors [10]. So, in order to extend running applications with new policies and without stopping them, new policies should be dynamically added. Such a capability blurs the line between the traditional design time and run time since the design of an application
Ann. Telecommun.
is carried on at run time. And the durability of the application is all the more improved. 2.3 Two main adaptation mechanisms: description in terms of response times and extensibility Context exploitation can take various forms, but we will focus on dynamic adaptation [7] of applications. Dynamic adaptation modifies the behavior of an application either by changing a parameter in its existing modules (parameter adaptation) or by reconfiguring the application to replace, update, or modify the list of its modules (compositional adaptation) at run time [11]. 2.3.1 Parameter adaptation Parameter adaptation involves the modification of variables that determine a program’s behavior. By tuning a parameter, the application can be directed to use a different existing strategy. This approach is easy to use and offers low response times. Moreover, it does not require stopping or pausing the application in order to fulfill adaptation. However, the set of achievable adaptations is limited [6] and must be defined at design-time. Systems using this adaptation approach are sometimes called “closed-adaptive” [12] since adaptations are chosen among those available and cannot be added at run time. In the literature, this approach is used for contextawareness in a wide variety of approaches [6, 13, 14]. In terms of extensibility and response times, parameter adaptation provides the following benef its and drawbacks: –
–
Benef its: Response times are low. Adaptation is immediate and generally does not require pausing the application. Drawbacks: The set of achievable adaptations is limited and must be def ined at design time.
adaptation because much more instructions are required to achieve it. Moreover, compositional adaptation often involves pausing the application for the application’s coherence concerns. In terms of extensibility and responses times, compositional adaptation provides the following benef its and drawbacks: – –
Benef its: An adaptation can be designed and integrated later during execution. Drawbacks: Response times are higher than those of parameter adaptation. Adaptation often involves pausing the application.
3 Our solution: ORCA Among available mechanisms, parameter adaptation requires adaptations to be established before run time and is faster than compositional adaptation. On the contrary, compositional adaptation provides structural adaptations that can be easily extended at run time but remains slower. Structural elements can be algorithms, modules, or components. Compositional adaptation is thus required in order to react to variations of the environment that was not anticipated previously or that requires an application significant modification. ORCA is a rule-based reasoning and message interception context solution according to the classification found in [18]. Since our goal here is to react quickly to variation of the context, we use parameter adaptations (Fig. 2 (1)). To extend it, we use compositional adaptation reacting on infrastructural changes or important context changes (Fig. 2 (2)). The previously unanticipated
2.3.2 Compositional adaptation Compositional adaptation results in the exchange of algorithmic or structural parts of the system with ones that improve a program’s fit to its current environment. An adaptation can be designed and integrated later during execution. As we can see in the literature, compositional adaptation is well suited to handle infrastructural changes [15–17]. Model transformation-based adaptation requires regenerating the application [15] or recomposing it [4] and thus can be assimilated to compositional adaptation. Systems using such adaptation are sometimes called “open adaptive” [12]. Compositional adaptation cannot be as fast as parameter
Fig. 2 Low response time and dynamic context adaptation rule system using parameter and compositional adaptations
Ann. Telecommun.
variations can be thus dealt. In that way, we take advantage of compositional adaptation for extensibility and of parameter adaptation for its quick reaction to context changes. This proposition is part of a broader work in the CONTINUUM project,1 in which another part of the context management uses a knowledge base to generate unforeseen adaptation rules and infer higher level context to activate or deactivate low response time rules. In order to reduce even more the response time, the compositional adaptation enables us to internalize the whole context-processing chain into application (Fig. 2 (3)). In that way, the context-awareness concern, though remains a separate concern from application, is treated in the same process. However, the contextawareness chain has to be light enough in order to keep the application responsive. Once context is collected and processed and after the adaptation decision, the adaptation itself has to be conducted. One way to achieve adaptations in an effective manner, and that past experience impels us to consider, is to control the interactions between modules [19]. In ubiquitous computing as in ubiquitous robot environment, such control operates over interactions between devices or between robots. The control of interactions through a simple parameter enables the application behavior to be more efficiently adapted than its compositional counterpart which would require removing or adding interactions between modules or modules themselves. And in order to make the approach extensible, the interceptors between module interactions, controlled through a parameter switch, are put in place by the compositional adaptation mechanism. We present in this section our detailed proposition applied on an example. In the first section (Section 3.1), we describe how our internalized rules process context and how the adaptation decision is conducted. Then, in a second section (Section 3.2), we describe how rules are composed and internalized in the application. In Section 3.3, we finally instantiate ORCA rules used to control interaction between modules used in a scenario described on that occasion. 3.1 Context-awareness operations Context awareness requires first of all a perception of the environment. In order to react quickly to the perceived variations, the processing and decision operations have to be efficient. We describe below each of these steps.
1 http://continuum.unice.fr/
3.1.1 Collecting context: particular contexts and context observers Context is a word describing any information relevant to a user or an application [2]. We identify subsets of all context information, for example information of location and time of day, as particular contexts that will be taken into account in applications. They are manipulated as tuples, in which elements are defined by their type (integer, string, tuple, . . . ), their semantics (number of people in a room, city name, GPS information, . . . ), and their value. Each element of the tuple is provided by a context observer, a logical software entity. At run time, actual entities of the infrastructure are matched to observers, for example ports of services for devices in our implementation Eq. 4.2. An observer can provide several elements in the same and in different particular contexts. Several particular contexts are collected and processed in applications, at least one per adaptation rule. Taking into account a particular context in an application requires context observers to exist for all its elements. In that case, the particular context is said observable. In ubiquitous computing, availability of context observers is not controlled but undergone by context-aware applications, and they have to be discovered [20]. For example, sensors embedded in walls become available when users or devices enter rooms and become unavailable again when they leave. 3.1.2 Context processing Since we are aiming for a low response time, we process context information with simple operations: equalities, inequalities, and ranges of values. The list of available operators as presented in this paper is limited to these simple operators but can be extended depending on contexts that need to be expressed. An example additional operator would be the distance calculation from latitude and longitude coordinates, based on a square root of the sum of squares. However, more complex context processing operations like ontologybased mechanisms [6] are not advisable because they are likely to consume more resources than the simple operations we propose, and since they are internalized in applications, there may be side effects on its behavior. These complex operations must be done at the higher level of compositional adaptation with higher response time. Particular context processing, described by collection and processing rules in the format presented in Eq. 3.3, is made by context predicates, noted P . They return a Boolean value indicating if the evaluated particu-
Ann. Telecommun.
lar context is met or not, according to the predicate. For example, a predicate can process a particular context of a single element, a temperature information, with a threshold, and define a context as “it’s freezing.” The Boolean result of predicate evaluation will be used by the decision step and will allow for easy composition of rules. 3.1.3 Decision and the two levels of rules The decision process links the processing of a particular context to an actual adaptation of application. It is a simple process since the result of a context processing predicate is a Boolean value. Two possibilities appear: the application is adapted when the particular context is met (predicate returned true) or when it is not. The property linked to a predicate that defines this behavior is called the ef fect, taking either the allow or deny value. effect = allow =⇒ decision = P effect = deny =⇒ decision = ¬P
(1)
In summary, three main components form ORCA rules, which we represent by a triplet: . The predicate corresponds to the collection and processing of context information, the effect takes part in the decision and exploitation planning, and the adaptation component is a description of what will be adapted in the application, in our case an interaction’s interceptor. A rule thus has to be written for a specific application because of its relation to the adaptation component. However, in order to in-
Fig. 3 Internalization of context awareness and parameter for low response time using compositional adaptation
crease the reusability of rules, we will define the pair in dedicated context-processing rules and reference them in the application-linked rule. This principle of separation is equivalent to access control lists (ACL) and access control entries (ACE) used in access control systems to organize the access control matrix. The ACL indexes rules of the matrix by fixing one of the components, generally the target of the access control, for example a display or a drone. For this reason, we named C-ACE, for contextualized ACE, the context-processing rule and C-ACL the list of C-ACE linked to a specific adaptation [19].
3.2 Internalization of rules and dynamic activation using compositional adaptation We have seen how our rules manage context; we will now explain how they are internalized in existing applications and how the decision process is done, by composing the activated rules.
3.2.1 Internalization of rules Since our main concern is response time, we internalize context-awareness operations into applications (Fig. 3), using the compositional adaptation of the situation detection mechanism. Moreover, if the application is built on a component-based design, rules can be added as a subassembly of components, which intrinsically provides dynamicity and reusability of building blocks. Internalization also provides improvements in
Ann. Telecommun. Table 1 Composition policies for context-aware rules
Rule effect
Composition
Policy type
Resulting decision
Allow Allow Deny Deny
AND OR AND OR
Restrictive Permissive Restrictive Permissive
Decision = P0 ∧ P1 ∧ · · · ∧ Pn Decision = P0 ∨ P1 ∨ · · · ∨ Pn Decision = ¬(P0 ∨ P1 ∨ · · · ∨ Pn ) Decision = ¬(P0 ∧ P1 ∧ · · · ∧ Pn )
confidentiality of context information, since processed context information is not transferred on the network. Context awareness is a nonfunctional concern separately defined from adaptations of the functional core of the applications, as often recommended [15, 18]. The functional core of the application is only modified to add or tweak interceptors, if interception is the desired adaptation method. This is typically what aspectoriented programming provides [16], and we will consider it as a way to implement our model of context awareness. 3.2.2 Adapting to infrastructural context Context observers have to be discovered to be used afterwards in the context-awareness process [20]. Depending on what observers are available, definitions of the rules are used to determine what particular contexts are observable. The rules are then internalized accordingly, in a reactive way enabled by service discovery notifications. Infrastructural modifications are changes in the set of available services that provide context information and their functionalities to applications. If a device publishing a service relevant to the current situation becomes available, the compositional adaptation is triggered by the situation detection to integrate it in the application. If at least an observer defined by some of our rules relevant to the current situation is matched by a newly available service, or if a service previously matching an observer disappears, the compositional adaptation is also triggered to adapt the set of available low response time contexts.
observability of several particular contexts instead of the observability of a large particular context if there was only a single predicate. In order to calculate the decision in the case where several rules are activated, a deterministic composition policy has to be chosen. Since the predicates’ results are Boolean values, there are two obvious choices for the composition: a logical OR and a logical AND. In the case of an AND composition policy of predicates with an associated allow effect, a particular context must be evaluated to be true for ALL predicates of the list. All contexts of the list must be met. The more observable particular contexts each entity has, the more constraints it puts on the decision. Adding a rule is thus restrictive in these conditions, since it adds a mandatory condition for the targeted interaction to take place. In the case of an OR composition policy, a particular context must be evaluated to be true for ANY predicate of the list. Opposite behavior occurs when the effect is deny. The following table (Table 1) summarizes the decision result and policy in all cases. Finally, a second policy is required for cases where no particular context is observable for all predicates of a given C-ACL. We call it the default policy. Its value, true or f alse, is directly used as the decision of a C-ACL in such a case.
3.2.3 Composition policies When a particular context is not observable, the rules in which it is referenced would not be activated, internalized, and evaluated and are thus of no effect on the executing system. This is a way to free resources, required in these constrained environments [21]. To offer a higher probability of context to be observed, several predicates can be defined as targeting the same adaptation. It additionally allows more complex and flexible contexts to be defined, depending on the
Fig. 4 Airship drone
Ann. Telecommun.
Fig. 7 Example C-ACL rule: decision and adaptation
Fig. 5 See-through glasses
3.3 ORCA rule definition languages and examples To illustrate our approach for controlling interactions, we depict the following use case: a user has to receive notif ications from an information-broadcasting miniature airship drone (Fig. 4) in the central area of a building. In the case of the overall brightness is low enough, information is displayed on user’s see-through glasses (Fig. 5). Rules have to be described in order to be managed by the system and by application designers or administrators. We created a specific rule language because we found none generic enough and targeting simple processings and adaptations. This language includes all previously described operations: observers declaration, information processing, policy attributes, and interaction targeted by adaptation. It fits the type of processing we use, mainly the list of operators, and the type of adaptation targeted, all depending on the designer’s needs.
Due to space restrictions, we will directly comment an example ORCA rule based on the example previously defined to describe the language (Figs. 6 and 7). A C-ACE and a C-ACL need to be written. The C-ACE describes particular context collection and their predicate processing using two keywords: information describes context observer attributes (name and event channel), an identifier for each context information and its type; value describes how each data is processed to finally obtain the predicate result. A value entry is required for each declared context information. The C-ACL defines decision and adaptation operations. Decision is based on the composition policy, expressed by the policy keyword, and the default policy, by the default keyword. Adaptation is in our simple case an interaction interception and described by the interaction ports description prefixed by the interaction keyword (Fig. 7). Finally, the rules directive allows to list the C-ACE rules belonging to a C-ACL, using the identifier given in the ruleid line of C-ACE rules. The available keywords, the rules, and the presented application are an overview of what can be done with our context-awareness rule system. Predicates are indeed among the simplest processing to define, compose, and validate. Specific applications may require other types of context processing or different parameters to be targeted by adaptations, and ORCA can be extended to take them into account. The ORCA model aims to be generic enough to apply to many application frameworks. In this regard, we will now demonstrate a projection of the ORCA model to the dynamic service composition platform named WComp.
4 Projection on the WComp platform The WComp2 platform is a ubiquitous computing middleware implementing the Service Lightweight Component Architecture (SLCA)/Aspects of Assembly (AA)
Fig. 6 Example C-ACE rule: collection and processing
2 http://www.wcomp.fr/
Ann. Telecommun.
model [16]. We will quickly describe its main features (Eq. 4.1) before explaining how ORCA was projected on it (Eq. 4.2).
4.1 The SLCA/AA model SLCA enables dynamic Web services composition in pervasive environments using lightweight component assemblies. It uses a particular type of Web services that we call Web service for device [16], featuring a decentralized and evented discovery mechanism (standardized as WS-Discovery), and a publish/subscribe eventing communication pattern (standardized as WSEventing). Services can be integrated to SLCA applications even if they are not already previously known, thanks to their service interface description (standardized to WSDL format). The AA designer is a compositional adaptation mechanism based on aspect-oriented programming (AOP) that modifies the structure of component assemblies, like SLCAs, instead of modifying source code as AOP traditionally does. The black-box property of components is thus preserved. The AA designer operates outside component or assembly containers, as an external reconfiguration entity, taking advantage of their introspection capability. The adaptation rules of the AA designer are described in two parts, like regular AOP. Pointcut definition, the first part, matches actual assemblies of components and defines prerequisites to the weaving (application) of the AA. Advice, the second part, defines the compositional adaptation to be woven in the application. The advice part of AAs is described using a specific language constrained by a set of operators that guarantee their symmetric composition [16]. Symmetry is given by three subproperties: commutativity, associativity, and idempotency. Thanks to this property, the order in which adaptations are made, and thus rules are internalized, does not matter. Indeed, such an order cannot be defined a priori. This means that (i) the activation or evaluation order of several AA has no impact on the resulting application and (ii) conflicts, appearing when several adaptations target the same application’s part, are resolved using the semantic of the involved operators, providing a deterministic result. AA weaving is triggered by modifications in the composition of an application, which, with SLCA, reflect Web service availability on the software infrastructure. An AA can thus be woven when a service appears in order to reactively integrate its functionalities to an application.
4.2 Projection of ORCA rules on WComp We consider that an application is executing as a WComp assembly of components and that it is adapting to its changeful infrastructure of functional services using aspects of assemblies. Compositional adaptation is thus already used to maintain application’s functionalities while services appear or disappear. ORCA rules are converted to AA in order to be internalized in the applications’ component assemblies. Observers are described by AA’s pointcuts, making observers’ availability a prerequisite to AA activation. Context processing and decision are converted to subassemblies of existing components, which are described in AA’s advice. It is thus required that the framework executing the application provides the means for context management, policies implementation, and interceptors. In WComp, these are black-box components; in another application framework, it could have been done by generating the code, using MOP, any other dynamic adaptation technique [7]. In ORCA, decision is described by the composition and the default policies. We cannot directly translate them into compositional adaptations because all CACE of a C-ACL will need to share this part of the adapted assembly. AAs are independent and prevent advices from interacting with each other using created components or interactions. Fortunately, the set of advice operators is extensible, allowing us to manage this issue as a part of the AA weaver’s merging process. We thus introduced three new operators: filter_OR, filter_AND, and default_filter. They have to provide the symmetry property, required to be an AA advice operator. This property facilitates the addition of new decision rules. Indeed, since the weaving operation is deterministic and symmetrical, the rules are independent of each other. Therefore, to add a new rule, it is not necessary to know the other rules. This property can be proven quite easily since they are based on Boolean operators which are themselves symmetric. Below is the most complicated example, the merging (⊕) of two operators filter_OR and filter_AND targeting the same interaction of an application: ⊕
e1 → filter_OR(l) e2 → filter_AND(l)
=⇒ (e1 → filter_OR(l)) ∧ (e2 → filter_AND(l)) In that case, the resulting expression is not trivial, and we must see how it merges with the operators of other AAs. We see in the merge below with the
Ann. Telecommun.
filter_OR operator that two sublists are created, one for each composition policy: e1 → filter_OR(l) ⊕ (eor → filter_OR(l)) ∧
(eand → filter_AND(l))
=⇒ (e1 ∨ eor → filter_OR(l)) ∧
(eand → filter_AND(l))
Finally, when no more operator is to be merged, the resulting compositional adaptation will be the creation of an assembly of components able to compute the logic composition of all the C-ACL entries, redirected to the message interceptor of the targeted interaction, here noted filter: (eor → filter_OR(l)) ∧ (eand → filter_AND(l)) ⊕ ⊥ =⇒ eor ∧ eand → filter(l) 4.3 Example application Due to space restriction, we cannot display the fully translated AA from the ORCA definitions in Figs. 6 and 7. AA examples and full policy merging proofs can be found in the PhD thesis [22]. The important point is that the permissive policy specification is transformed to a filter_OR operator linked to the expressed interaction. The translation does not require human intervention, and thanks to the operators, there is no need to take care of any conflicts.
Fig. 8 Times of compositional (tc ) and parameter adaptation (tp )
same memory addressing space and the same thread, and they are thus too fast to be measured. However, we made two more complete experiments, taking into account, in addition, the collection of contextual information inside the application. First, we measured the time between the sending of an event by a context observer and the modification of a parameter in the application (Section 5.1.1). Most of the time is in fact spent in the emission and reception of the information through the Web service for device stack, which was WComp’s UPnP in these experiments. The second experiment (Section 5.1.2) adds a remote communication time through Wi-Fi link. This allows us to fully characterize the response time to environmental context changes and not just the response time of adaptation or context-awareness mechanisms.
5 Results: response time measurements 5.1.1 Measures of adaptation with a local observer To validate the low response time predicted by the presented approach, we made several measurements of dynamic adaptation triggered by context changes (Fig. 8). We first measured the response time tp of the parameter approach (Eq. 5.1) to validate that when the environmental context awareness is internalized, the response time is very low. We also made measurements on the compositional adaptation tc using Aspects of Assembly (Section 5.2) that react to infrastructural changes and internalize this process. 5.1 Response time of parameter adaptation to environmental context (tp ) To validate our approach, we should have measured the processing of contextual information and application parameter adaptation. We were not able to do it because these are simple operations executing in the
Technically, we measured the time between the sending of a UPnP event by a context observer and the modification of a parameter in the application. To be able to measure it accurately, the observer and the application were executing on the same host and in the same process. The system was Windows XP, and the process was executing in “real-time priority,” on one CPU core of a 3-GHz Pentium D. Figure 9 represents the probability distribution on 12,280 measures rounded to 0.1 ms. The green curve is the same than the red one but rendered using a logarithmic scale. That allows to better see that the second peak is not as sharp as it could seem and that it is nonnegligible. The first peak, near which most measured values are gathered, is at 3.4 ms. It corresponds to the nominal execution time of the information sending from the observer, collection in the application,
Ann. Telecommun.
Figure 10 represents the probability distribution on 1,213 measures rounded to 1 ms. The red curve is the raw measure distribution, and the green curve is a model we could identify from the measures. It was approximated to a simple exponential law e0.132(x−11)−1.996 , using the weighted least squares minimization. This law allows us to expect a response time lower than 25 ms in 99.40% of cases, since it represents two times the response time.
Fig. 9 Distribution of response time to internalized parameter adaptation
Response time for parameter adaptation and context processing, including Wi-Fi communication: tp < 25 ms, 99.4% of the time. 5.2 Response time of compositional adaptation (tc )
processing, and adaptation. The second peak and other values on its right are due to OS, UPnP stack, and .NET virtual machine uncontrolled operations. We were not able to remove this behavior, so we can only provide an upper bound from measured values: in 99.71% of cases, the response time is less than 12.67 ms and strictly less than 4.2 ms in 68.66% of cases. 5.1.2 Measures of adaptation with a remote observer In order to have measures of the full environmental adaptation process as it can be found in real-life applications, we measured the same adaptation than above but including the communication time with a remote observer over a Wi-Fi link. To be able to measure it, we had to make a round-trip measure, using a Web service for device (UPnP) events relay, using WComp. The resulting measures thus have to be divided by two to have the one-way communication time and processing of contextual information. Fig. 10 Distribution of time from remote (round trip) communication to parameter adaptation
Aspects of Assembly have been deeply studied with performance concern [16], as well as SLCA applications adaptability [23]. The response time of a compositional adaptation using AA unfortunately depends on several parameters and cannot be simply given: the number of components in the assembly, the number of pointcuts expressed in AA definitions, and, mainly, the number of instances of advices that have to be composed and the ratio of interferences appearing between them. In this evaluation, the only type of contextual changes that are considered are infrastructural changes. 5.2.1 Time spent in the weaver: a four-AA example application We measured the time required by the weaver to compose four AAs, taken from the example presented as a PhD illustration [22]. This will give an indication about the magnitude of the response time, in a bigger application than the one from our scenario. These four
Ann. Telecommun.
AAs include two ORCA rules, a third AA dedicated to the default (false) policy, and a fourth AA creating the base application. The AA creating the application simply links two components of the application, an information service and a message display device. When the four AAs are selected, they are composed into the application depending on the prerequisites defined in pointcuts. We consider that the two applicative components are always available and that the two AAs defining the application and the default policy are applicable. When the observers required by the first ORCA rule appear in the software infrastructure, three AAs are composed to create the application integrating the context-awareness logic. In that case, the measured response time between the reception of the notification in the weaver and the end of the computing of the resulting application, without the time required to actually modify the application, averages at 25.24 ms. When the observers required by the second rule become available, all four AAs are weaved and interferences have to be managed between the two rules, and with the base assembly too. The weaver resolves them by using the composition policy defined in the policy rule. In this case, we obtained an average response time of 33.71 ms for the same weaver operations than above. 5.2.2 Evaluation of tc The example above is based on only four AAs, targeting a simple interaction between two services of the infrastructure. A full application would more likely be a composition of 10 to 20 services, driven by 10 to 50 AAs. The weaving process ensures that the composition of instances of advices is symmetric [16] and follows a quadratic complexity in this particular composition case. This weaving process could thus undergo a large response time to the context-awareness process, up to 1,400 ms for 20 services and 50 AAs. This value was calculated from the model of weaver composition described in [16]. We added to these measures communication’s time between the weaver and the application that transmits adaptation orders. This linearly depends on the number of links and components modified in the component assembly of the application. Using the control interface of a WComp container (UPnP actions), we measured average component creation time of 2.41 ms and link creation time of 3.06 ms. These values do not provide any conclusive information because they depend too much on the implementation details. A simple optimization could be done in the AA weaver to communicate adaptation requests to containers with only one
Web service for device method invocation instead of one for each modification. Finally, discovery response time also has to be added. In [23], we measured a 140.6-ms average time required to generate a proxy component for a newly discovered Web service for device on the infrastructure. If the service provider is already known, only the component instantiation will be required, taking 2.41 ms as we already seen above. The more costly parameter for the overall infrastructural context adaptation process response time is again the network transmission. We saw in Section 5.1.2 that it could be lower than 25 ms in most cases for event notifications, but for discovery, the protocol is more packet greedy and less reliable. From our experience, it can take up to half a second on wired networks and up to 4 s on poor signal quality wireless connections. We were not able to make some measurements on this particular part because it involves two different hosts, and it is difficult to synchronize computer clocks precisely enough. Let us sum up all the explained operations for tc : discovery requires at least 500 ms, proxy component generation 140.6 ms, remote component instantiation 2.41 ms, AA weaving process which may require more than 1 s, and the compositional adaptation of the application, which can be done in more than 200 ms if it requires large modifications. We have a total response time of around 1.8 s. This value is subject to large variations, mostly due to network quality and to the complexity of the created application, including the number of rules. For example, a simple application, with a high quality network and already known service providers, would have a response time of compositional adaptation to infrastructural context changes as low as 200 ms. Response time for compositional adaptation: tc > 200 ms
5.3 Discussion of measurements As expected, using parameter adaptation and simple internalized mechanisms for context awareness is much faster than compositional adaptation. Under good execution conditions, there is one order of magnitude between the two (tp < 25 ms and tc > 200 ms). When the network is not of good quality and there are many observers and composition rules in the application, there can be two orders of magnitude as tc grows up to seconds. tp
