Colin Aygalinc

Eva Gerbert-Gaillard

German Vega

Philippe Lalanda

Stephanie Chollet
email: stephanie.chollet@lcis.grenoble-inp.fr

Autonomic service-oriented context for pervasive applications

Keywords: pervasive computing, context, service-oriented components. I

Pervasive computing promotes environments where smart, communication-enabled devices cooperate to provide services to people. Due to their inherent complexity, many pervasive applications are built on top of service-oriented platforms, providing a set of facilities simplifying their development and execution. In this paper, we present such a platform, iCasa, extended with an autonomic, service-oriented context module. This module is programmed with a domainspecific service-oriented language built on top of iPOJO, the Apache service-oriented component model. It is validated on smart home applications developed with the Orange Labs.

INTRODUCTION

Pervasive computing envisions environments where smart devices are blended into everyday objects in order to provide added-value services to people [START_REF] Weiser | The computer for the 21st century[END_REF] [2] [3] [START_REF] Atzori | The Internet of things: a survey[END_REF]. These devices are communication-enabled and can cooperate with each other in order to deliver advanced applications. Such applications have to meet very stringent requirements: they are expected to be available anytime and anywhere while remaining invisible and non-obstructive.

We believe that advanced software engineering principles and tools are needed to support the production and execution of pervasive applications. A common approach is to introduce an execution platform providing a development model and a set of technical services that can be used by the applications (also called functional services). Precisely, the platform is responsible for dealing with many non-functional properties, like security or dynamic device integration persistence, on behalf of the applications.

Several such platforms have thus been proposed in the pervasive community. For instance, the Gaia platform [START_REF] Roman | A middleware infrastructure for active spaces[END_REF] manages resources present in a pervasive space, called an active space. Gaia provides a set of services allowing application programmers to access the available devices or resources more easily. After this initial work, many platforms have been developed on top of the OSGi framework, which promotes the development of modular and dynamic applications. Indeed, pervasive platforms are usually based on the principles of service-oriented computing [START_REF] Papazouglou | Service-oriented computing[END_REF] where loosely coupled services enable the creation of flexible dynamic applications. An application is built from several services that can be distributed on different devices.

Many platforms include the notion of context, which purpose is to provide timely information about the computing and user environments. This allows applications to react to changes, like user behavior or availability of computational resources for instance. In the early days of pervasive computing, context was essentially limited to locationawareness. Since then, context has evolved towards more elaborated models, and has become a representation of any information that can be used to characterize an entity that is relevant to the interaction between a user and an application [START_REF] Dey | Understanding and using context[END_REF].

As we will see in more details in section 2, context and applications are generally kept separated. This architectural approach makes applications development and execution easier. It allows application developers to focus on implementation of business services, while delegating the complexity of context management to the pervasive platform. Context management is indeed a complex activity involving several complicated tasks, ranging from raw data acquisition (dealing with heterogeneous, dynamic and sometimes unreliable sensors) to knowledge representation and reasoning.

Many techniques and approaches have been proposed to deal with context management in pervasive settings [START_REF] Lee | Survey and trend analysis of contextaware systems[END_REF]. Most of them are based on data-centric approaches where contextual information is kept in a knowledge base (database, ontology) and explicitly retrieved by applications. Such approach is well suited to knowledge-intensive applications with no hard deadline to be met. We are targeting applications executed on Internet gateways, at the edge of the network, with real-time constraints.

In this paper, we propose a novel approach based on autonomic computing and service-oriented computing, targeting a finer integration between context and applications. Precisely, we have developed a domain-specific serviceoriented language allowing the straightforward definition of autonomic context modules. This language builds upon the iPOJO component model and is integrated in the iCasa platform [START_REF]iCasa platform and simulator[END_REF]. It is validated on several applications developed with the Orange Labs.

The structure of this paper is the following. The coming section provides background about our context and requirements. Section 3 presents the overall approach defended in this paper and section 4 provides details about it. Section 5 is about its implementation. Finally, related work is developed in section 6.

II. BACKGROUND AND REQUIREMENTS

A. Context management in pervasive computing

Context is traditionally presented as a synchronized description of concepts and relationships pertaining to the execution environment. Precisely, contextual information [START_REF] Perera | Context aware computing for the internet of things: a survey[END_REF] comes from the computing environment (memory, network, etc.), the user environment (location, needs, preference, etc.) and the physical environment (temperature, noise, etc.). It can be the description of a fact, a physical object, a physical value, or even an event (discrete or continuous [START_REF] Ahn | Proactive context-aware sensor networks[END_REF]).

There are several architectural approaches to build contextaware applications [START_REF] Hu | Context-aware routing in wireless mesh networks[END_REF]. A popular solution is to use a context management infrastructure. Error-prone tasks like information gathering (context acquisition), information modeling and processing (through inferences or mediation operations), information storing and presentation lie outside the application boundaries. This pattern where context management and applications are clearly separated improves code readability, debugging and evolution. It also allows context sharing between pervasive applications. We subscribe to this latter approach where context and applications are developed and extended independently (see Figure 1). However, we readily acknowledge that building a context management infrastructure remains a daunting task, and that multiple design trade-off decisions have to be made regarding data access, synchronization mechanisms, knowledge representation, reasoning, or presentation.

There are indeed many existing available context modeling and processing approaches [START_REF] Henricksen | Modeling of context information for pervasive computing applications[END_REF] [START_REF] Preuveneers | Adaptive context management using a component-based approach[END_REF]. They mainly differ in the model used to represent contextual information and in the supported inferring techniques. However, most of them share a data-centric approach, where all context information is collected from sensors, kept in a storage facility, and made available to applications through queries. Data-centric approaches are better suited to applications requiring complex knowledge representation or reasoning facilities. This is for instance the case of knowledge-intensive applications run in cloud infrastructure. As explained here after, we target applications deployed at the edge of the network, sometimes referred as fog computing [START_REF] Bonomi | Fog computing and its role in the internet of things[END_REF], in order to perform immediate, added-value services, rather than long term, offline data processing.

B. Context management in smart homes

Our research deals with pervasive applications in intelligent environments like smart homes, smart buildings or smart manufacturing (industry 4.0). These applications are now widely distributed, from the sensors up to cloud facilities. Some code is executed at the edge of the network, in an Internet gateway for instance, while other code is run in computing farms. Depending on the code location, various forms of context are needed with different formalisms, different real-time constraints, and different interaction patterns.

To illustrate these various needs, let us consider health care applications in smart homes. More precisely, let us focus on the actimetrics application that we have been investigating for years with the Orange Labs [START_REF] Lalanda | Servicebased architecture and frameworks for pervasive health application[END_REF]. Two major functions can be distinguished for actimetrics: the first one is about early diagnosis of degenerative diseases like Alzheimer while the second one is concerned with real-time supervision of people at home.

The first function, identification of degenerative diseases, is concerned with long term evolutions spanning several months. It requires complex time-series and event correlation analysis and is based on a rich, slowly evolving context that is explicitly accessed and browsed by the analysis algorithms. This is typically a data-centric context. The second function is about real-time supervision. It deals, for instance, with fall detection or automated alerting in case of unusual events like prolonged inactivity or irregular sleep hours. This second function may use the same environmental data as the first one, but it is much less demanding in terms of knowledge representation and reasoning. On the other hand, it has to deal with stringent realtime constraints: new information should be made available very rapidly to the application. Also, interactions are bidirectional and must meet requirements of low latency and simplicity. Moreover, due to their location, they have to support all the burden of dynamism induced by the physical environment while limiting end-user administration tasks, a property known as zero administration. Here, most existing context-management frameworks would impose an unwanted overhead.

From these features, we identified the following requirements for a context management middleware adapted to applications (or code) located at the network edge:

 maintainability: zero administration requires a modularized and maintainable middleware. Most approaches neglect the bi-directional interaction (acquisition/action) aspect although it involves highly error-prone technical code from low-level synchronization to high-level mediation or enrichment operations.

 dynamicity resilience: the middleware should support dynamic discovery and opportunistic use of new context sources and elements.  autonomic management: the middleware must support dynamic configuration at runtime because application requirements, and so on context, evolve over time. For example, a service not used by application must be discarded and stopped, or synchronization frequency must be adjusted to avoid resource waste. However, managing this aspect manually is cumbersome and inefficient. We thought that this aspect should be managed in an autonomic way. We believe that a service-centric context management middleware can meet these requirements. A Service-Oriented Architecture eases application development by the composition of a modularized set of services. It infuses naturally in the application interesting characteristics like loose-coupling, resiliency to dynamism with late-binding, substitutability and location transparency [START_REF] Escoffier | iPOJO: an extensible serviceoriented component framework[END_REF].

By presenting Context as a Service to the application, we benefit from all these properties and limit the context to the application needs. In addition, leaving implementation details of context services to the middleware layer frees the application developer from technical, high-error prone development issues related to context. But software engineering and tooling are still needed to ensure a maintainable and manageable context middleware.

III. APPROACH

A. Overview

Our approach is based on a clear separation between application and context and the use of service-oriented computing. As illustrated by Figure 2, the context management system publishes context services that can be used by the applications. Formally, context services form the contract between the context management layer and the applications. They are implemented as a graph of context entities, which perform data acquisition, context modeling and processing and, in the end, service publication. Context entities are implemented with iPOJO, the Apache service-oriented component model [START_REF] Escoffier | iPOJO: an extensible serviceoriented component framework[END_REF]. The integration with the environments is based on RoSe [START_REF] Bardin | Towards an automatic integration of heterogeneous services and devices[END_REF], an open source communication middleware that is able to dynamically import and export services [START_REF]RoSe framework source code[END_REF].

However, we have experienced that this approach remains hard to put in place. The implementation, provisioning and management of such context are very complex. It is highly error-prone, especially because of the need to deal with the dynamicity and heterogeneity of context sources and applications, and to ensure synchronization.

To circumvent these limitations, we have defined and implemented a service-oriented domain-specific language (DSL) for context definition on top of iPOJO. Our purpose is to provide assistance to developers for application and context development. The resulting context is autonomic in the sense that it can deal on its own with highly dynamic pervasive environments.

Precisely, our context management system can dynamically adapt the way it collects information and the way it provides contextual services to the client applications. This approach builds on a service-oriented component model to implement a flexible and maintainable representation of contextual information in order to increase integration and interoperability with pervasive applications. At design time, it allows the straightforward definition of contextual entities with a high level Java-based language. At runtime, it supports the dynamic construction of synchronized and observable entities published as services that can be used by applications. Our approach also comes with architectural and process guidelines to ease the work of designers and developers.

We have also enhanced the autonomic capabilities with an explicit autonomic manager, as illustrated by Figure 3. The purpose of this manager, using the DSL, is to create the context entities when needed by an application. Thus, only relevant concepts are built and maintained by the platform.

Context management is then structured into two modules (as shown in Figure 3):

 context module is a representation of contextual information, where entities (relevant persons, places, and objects) are modeled as components that implement context services.  context manager is in charge of building and updating at runtime the context module, based on high-level goals and the current situation. We believe that this approach is well-adapted to reactive applications (or applications parts) implemented near pervasive resources. The integration between applications and resources is straightforward: the needed services are directly proposed by the context to the applications. In addition, when some data is changed, provided services are re-evaluated and events are sent to applications so that they can call the service again.

B. Two-phase approach

Our approach naturally leads to a two-phase context development process. First, domain engineers define a context that can be used by a set of applications that are expected to run on a same platform. Second, applications developers use this context in order to simplify their code and concentrate on business logic. Context components are deployed and executed on top of a pervasive runtime platform that handles their lifecycle. Specifically, our context management system has been integrated in a pervasive platform named iCasa [START_REF] Escoffier | Lessons learned in building pervasive platforms[END_REF] that is able to host multiple components and applications written with iPOJO. The iCasa/iPOJO runtime has been extended to handle all the non-functional aspects introduced by our component DSL, while retaining its service-oriented properties. The iCasa runtime has also been extended to offer appropriate probes and touchpoints to enable autonomic management of the context module, in accordance with the application needs.

Application developers use context services defined in the first step of context development to simplify their code and concentrate on business logic (Figure 5). At runtime, context representation depends on deployed applications and available resources.

IV. DSL FOR CONTEXT

A. Overview

Context is a representation of the surrounding environment. As such, it can be regarded as an explicit model [START_REF] Seidewitz | What models mean[END_REF] of the environment used by the pervasive applications. We use a service-centric approach to explicit this model. Context services must be described, implemented and dynamically provided at runtime. The following steps are necessary: For each of these steps, we provide a support through a Domain-Specific Language, defined by the meta-model in Figure 6. The concrete syntax is based on Java annotations and hides the dependency between concepts and the selected SOCM. The current implementation is based on iPOJO, the Apache OSGi service-oriented component model [START_REF] Escoffier | iPOJO: an extensible serviceoriented component framework[END_REF]. We provide build time processing to map our concepts to iPOJO concepts. Other implementations of our approach can be done, as long as the selected SOCM supports late-binding and dynamic instantiation.

B. Context Service

Application development relies only on service description to reduce coupling between context implementation and application business logic code. The service description must contain enough semantic and information to be used without ambiguity by the application. As depicted in Figure 7, we extend the OSGi service definition, which relies on a simple Java interface, with our DSL. It allows to clearly identify which interface will be exposed as a context service; @ContextService; and enhanced the service definition by state properties definition; @State; that will be valued and exposed at runtime by the service implementations.

At runtime, context service use in application is greatly simplified by iPOJO injection mechanism. Application components specify their context service dependencies with specific goals. Goals can be cardinality, filtering or ranking strategies. According to these goals, iPOJO autonomically allows opportunistic use of new context services and dynamicity resilience by dynamically injecting service implementation. Additionally, simple event mechanism is handled by calling application callback each time state properties are modified.

C. Context Entity

In order to support a reliable, maintainable implementation of previous described context service and keep it as simple as possible, our approach is based on a domain-specific specialization of the iPOJO component model. We extend iPOJO meta-model, with specific concepts required to deal with context issues.

The concrete language used in iPOJO to define components is based on plain Java classes marked with annotations (see Figure 8) to declare non-functional aspects handled by the platform. We have enhanced the iPOJO design time tools with specific annotations required to declare specialized context concepts. For example, annotation @ContextEntity allows specifying a context entity that can implement context services.

Concretely, each state property declared in the implemented context service specification must be referenced, through @State.Field, in the implementation class as simple Java attribute to be easily manipulated during the service implementation. Each state property is synchronized through dedicated function:

 Functions to retrieve data from an external entity: @State.Pull/@State.Push  Function to influence an external entity: @State.Apply.

The synchronization process is bi-directional in order to enable application to act on the context. These annotations enable to specify goals, like the frequency to call a @State.Pull function if it is periodic.

In our approach, a relation represents a link between two context entities, a pointer from an instance to another. It is implemented by a service dependency. This pointer is particular: it contains semantic information on its source, target and nature. It can be used to enhance context with semantic information. As a service dependency it can be used for synchronization process. Goal can be specified like cardinality or ranking. At runtime, context entities are wrapped as iPOJO components. Component containers can be extended by iPOJO modules, called handers. The framework provides a number of off-the-shelf handlers in charge of global aspects of the platform, like service publishing or dependency injection. More importantly, it is possible to develop new iPOJO handlers to take charge at runtime of particular concerns.

We implemented two new iPOJO handlers, as show in Figure 9, dealing with specific context concerns. The handlers are described as follow:

 Synchronization Handler: It deals with the state synchronization of entity components. It keeps the state properties up-to-date by managing the synchronization functions. Different strategies can be specified to do so. For example, the handler can periodically call pull functions or just wait for push callbacks to keep the state up-to-date. Additionally, the handler is in charge of publishing state properties as service properties. This publication has two main interests: it allows processing of more advanced filters and state updates can be reported to the application without the burden of an Observer pattern, by relying on iPOJO notification mechanism.  Relation Handler: The relation handler is in charge of the dynamic service binding of relations.

D. Context Provisioning

Context service provisioning is guided by the discovery of external events, e.g. a device joining the network or a user interaction with a web dashboard. Approaches like RoSe [START_REF] Bardin | Towards an automatic integration of heterogeneous services and devices[END_REF] or MUSIC [START_REF] Rouvoy | MUSIC: Middleware support for selfadaptation in ubiquitous and service-oriented environments[END_REF] provide pattern to modularized and maintain the discovery of external event at runtime but, no support is provided for dynamic instantiation of context service provider. iPOJO runtime supports this behavior but its establishment remains highly technical, tightly coupled to the iPOJO model and de facto become less feasible for developers. Our middleware provides autonomic facilities regarding this issue, without cluttering the discovery code. As depicted in Figure 10, discovery code emits now instantiation requests (previously it was direct instantiation) and the middleware choose to process or stock the requests according to the application contextual service requirements.

E. Autonomic Execution

As depicted in previous section, each step of context development is probed with autonomic touchpoints. We will see how our context management middleware can benefit from this and provide autonomic features.

First, we assume that applications are developed following the iPOJO model. Each application can be composed of several components and relies on context services. Regarding to dynamicity, iPOJO naturally infuses autonomic behavior in the component's container. Therefore, application can benefit of late-binding and dynamic service substitutability. This level of adaption is specified within iPOJO annotation.

Secondly, when a context-aware application is deployed and executed, our context manager knows its context service dependency. Based on this knowledge, adaptation can be acted. Hence, it is possible to dynamically realize the following changes:

 Enable or disable context entity provisioning;  Modify specific synchronization parameters;  Replace context providers. This autonomic behavior allows managing fault tolerance by switching of context provider, if a new one is available. All of this adaption logic is hard coded in our context manager. We are currently investigating integration with dynamic deployment [START_REF] Günalp | Rondo: A tool suite for continuous deployment in dynamic environments[END_REF], to provide fine grained context management.

V. EVALUATION

The iCasa environment [START_REF]Pervasive Computing in Practice teaching website[END_REF] is made of three tools: an Integrated Development Environment based on an eclipse plug-in; an execution platform based on OSGi and RoSe; a smart home simulator to quickly test pervasive applications.

The execution platform is running on a home gateway, which hosts several applications and offers dynamic deployment facilities. Applications belonging to domains like safety, comfort or health care have been developed. For example, iCasa hosts part of a home care application called actimetrics which measures and analyses the motor activity of elderly. Its purpose is to track behavioral changes to early diagnosis degenerative diseases like Alzheimer [START_REF] Lalanda | Servicebased architecture and frameworks for pervasive health application[END_REF].

We provide an evaluation from a software engineering point of view, encompassing several metrics link to design time activity. We choose the following metrics: number of lines of code, cyclomatic complexity (this metric gives indication on maintainability, reliability and testability) and technical debt (evaluation of the effort needed to fix all issues). All this metrics are computed and provided by an open source quality management platform, SonarQube [START_REF] Sonarqube | an open platform to manage code quality[END_REF]. We run our evaluation on two different projects: we entirely restructured the context of the iCasa execution platform and its associated simulator; and we refactored an application on the top on the restructured platform. Graphics on Figure 11 and Figure 12 present the chosen measurement comparisons, respectively for the iCasa execution platform and the application. The first evaluation concerns the iCasa platform and its associated simulator. In the reference, contextual information in iCasa execution platform and simulator was computed in an ad hoc way. It was heterogeneously developed according developer's will and spread into the platform. It was difficult to extend the context or make it evolve since there wasn't any consistency. For the evaluation, we redesigned the context by applying our approach and we compared the two versions (Figure 11). Functionalities provided by the reference and our approach are:

 A set of abstraction for device, location and user and their implementations;  A web interface acting as a dashboard;  A script language allowing to dynamically instantiate simulated device, location and user. Thanks to the code provided by the handler and the simple event mechanism, the number of line of code decrease. By clearly identifying synchronization functions and limiting their number, cyclomatic complexity have been reduced. We also noticed that the restructured implementation presents a high percentage of duplicated lines (approach 7%, reference 3%) due to iPOJO technical limitations: it doesn't support inheritance. The number of lines could therefore be reduced more.

Our approach notably improves context development. It offers non-functional technical facilities. The context is modularized, extensible, and autonomic. The whole software is more consistent, testable and maintainable. The second evaluation compares two versions of Light Follow Me application upon the reference and the restructured platform (Figure 12). Light Follow Me turns the lights off and on depending on the presence of a user for each room of a house. This application is simple yet it encompasses all requirements presented before. It is a typical home pervasive application that doesn't need complex reasoning algorithm, facing the dynamism of the environment (light and sensor can appear/disappear) and directly influencing the user environment through switching on/off the light. In the reference implementation, the application manually processes information like presence per zone by directly reasoning over the sensors and their location. In our approach we choose to externalize the processing of this information with a dedicated presence per zone context service (blue part on Figure 12). This presence per zone service can be shared between applications and evolves independently regarding to the business code of these applications.

The externalization of the presence service produces an overhead in terms of line of code and complexity. This is due to the fact that all the logic of provisioning the service must implemented in our solution. However, this overhead can be shared by many applications. So if we analyze only the application business code (orange part on Figure 12), it is approximately divided by 2 and de facto become easy to test, maintain and evolve.

We can summarize that externalizing the context adds an additional development task and the resulting architecture is more complicated, but this cost can be mutualized and shared among several applications. Moreover, new applications can be develop on top of more abstract services, easing their implementation.

VI. RELATED WORK

Developing context-aware applications is one of the hot research topics for the last decade. Naturally many software architectures emerged to reach this goal. We compare our proposed architecture to the existing ones: The Context Toolkit [START_REF] Dey | Understanding and using context[END_REF], COSMOS [START_REF] Conan | Scalable processing of context information with COSMOS[END_REF] SOCAM [START_REF] Gu | A service-oriented middleware for building context-aware services[END_REF] and another SOCbased context model [START_REF] Vansyckel | Extending context management for proactive adaptation in pervasive environments[END_REF]. Many more architectures are available, but these ones are representative of the global trend.

The Context Toolkit [START_REF] Dey | Understanding and using context[END_REF] promotes code-reuse through the composition of distinct artifact called widgets to build the context. These widgets are used to hide the complexity of sensors and abstract context information in a suitable way to fit applications need. These reusable blocks are explicitly linked at design time, each block deciding which blocks to use. Our approach is similar in the sense that we divide the context in individual small pieces. The key differences with our work are that we delegate the composition at runtime with more variability expressed at design time thanks to SOCM properties. Moreover our entity relation like model offers more flexibility to design complex context. COSMOS, COntext entitieS coMpositiOn and Sharing [START_REF] Conan | Scalable processing of context information with COSMOS[END_REF], is a component based context middleware. Each pieces of context is reified as a component called Context Node organized in a hierarchical structure. This approach and ours address the separation of concerns by offering several built-in mechanisms like push/pull notifications and reduce the developer's work. However, the strictly hierarchical approach of COSMOS context makes it difficult to model with horizontal relations. Moreover, component specifications are strictly defined at design time, so runtime extensibility proposed by our system of relation will be hard to achieve.

The Service-Oriented Context Aware Middleware (SOCAM) [START_REF] Gu | A service-oriented middleware for building context-aware services[END_REF] is an ontology-based context middleware. SOCAM architectures rely on several components: Context Providers (extracting context from internal and external data sources, and converting them in ontological instance), Context Interpreter (reasoning engine performing inference to extract high-level context and store it in knowledge base), Contextaware Mobile Service (application that consume context), and Service Locating Service (a registry where providers and interpreters are registered, where other components can search specific providers or interpreters to fit their needs). SOCAM envisions a highly structured context model with ontology in order to benefit from all the powerful processing tools induced by this approach, like reasoning engine. So it generates a programming model through a query language and rules, contrary to our programming model that relies on Java service specifications that we consider more adapted to develop addedvalue services.

In [START_REF] Vansyckel | Extending context management for proactive adaptation in pervasive environments[END_REF], a work dealing with proactive adaptation and context management based on a SOCM architecture is presented. It underlines the fact that context interactivity is not just about providing the most powerful modeling and reasoning engine. Indeed, applications also can deal with context in a proactive manner, with the ability to change the context through actuators. Our approach, in this sense, is very similar because previous works say little about how to influence context. However, to achieve this goal, a specific query language that generates a cost on the learning curve is provided, whereas we prefer a traditional Java programming model.

VII. CONCLUSION

In this paper we presented a comprehensive approach to build and run Context as a Service. We provide a simple way to address service description, implementation and provisioning in a modular, maintainable and autonomic way. This solution can be integrated in an enriched execution platform as demonstrated. Our work focuses on providing tools to build and execute a runtime autonomic model of context. This model is probed with autonomic touchpoint, synchronized with external entities and can be enriched dynamically by new relations or services. Applications developed using SOC paradigm upon this model can also dynamically add new elements in the context in order to better fit their needs.

As limitations, we notice that our runtime implementation currently maintains a possibly large, in-memory, representation of context. Additional performance optimizations are required to cope with the needs of realistic applications, in terms of memory scalability and footprint.

Further perspectives of our work include extensions to handle more complex synchronization scenarios and provide off-the-shelf processing components like aggregation processing. Moreover, as depicted in the background section, our work focuses on integrating context in the network edge like home pervasive gateway, but as explained many applications can be divided in two parts. On one hand, these applications performed immediate action on the user environment and are located in the network edge. On the other hand, they handle complex reasoning on large historical set of data and are in most case execute in the cloud. It will be very interesting to investigate how our context model can cohabitate with a more "data-centric" context management located in the cloud.

Figure 1 .

 1 Figure 1. Separating context and applications.

Figure 2 .

 2 Figure 2. Context as a service.

Figure 3 .

 3 Figure 3. Context modules architecture.

  The first step, usually called Domain Engineering, involves several actors with different skills as illustrated by Figure4.The tasks to be performed are the following:  Application and platform developers identify and determine the necessary concepts to be included in the context, in conformance with platform capabilities. Context services are specified in a Java based description language, presented in the next section, and are directly used by applications.  Platform developers implement context services defined in the first step and additional ones useful for mediation or processing. Component development is simplified by using a Domain Specific Language, presented in the next section, with facilities to express data source's synchronization.Platform developers implement context manager components in charge of service context provisioning and configuration. The proposed component DSL also includes facilities for this task.

Figure 4 .

 4 Figure 4. Context development and deployment.

Figure 5 .

 5 Figure 5. Application development and deployment.



  Context service aims to provide a service description.  Context entity aims to provide an implementation of context services.  Context provisioning aims to provide a simple way to dynamically instantiate context entities.

Figure 6 .

 6 Figure 6. DSL meta-model.

Figure 7 .

 7 Figure 7. Java code for a context entity service.

Figure 8 .

 8 Figure 8. Java code for a context entity service implementation.

Figure 9 .

 9 Figure 9. Service-oriented component view of context model.

Figure 10 .

 10 Figure 10. Java code for a context service dynamic provisionning.

Figure 11 .

 11 Figure 11. Evaluation on iCasa platform and simulator.

Figure 12 .

 12 Figure 12. Evaluation on Light Follow Me application.


Colin Aygalinc

Eva Gerbert-Gaillard

German Vega

Philippe Lalanda

Autonomic management of pervasive context

Keywords: autonomic management, pervasive context, serviceoriented computing, health

Pervasive computing promotes environments where smart, communication-enabled devices cooperate to provide services to people. Due to their inherent complexity, many pervasive applications are built on top of service-oriented platforms, providing a set of facilities simplifying their development and execution. In this demo, we present such a platform, iCasa, extended with an autonomic, service-oriented context module. It is validated on diverse applications developed with the Orange Labs in the health domain.

I. PROPOSED APPROACH

A growing number of smart, communication-enabled devices are integrated in our living environments. This is essentially due to major advances in hardware and networking technologies, which make sensors more powerful, cheaper and smaller in size. Such digitalized environments, said to be pervasive or smart, are increasingly accepted in all places where social or professional activities take place. They support the creation of new added-value services that are delivered anytime and in a non-obstructive way. This new form of computing is raising huge economical and societal expectations in domains like manufacturing, buildings and homes, energy, commerce and even healthcare. From this last point of view, advances in pervasive computing are very promising and could, for instance, provide new services enhancing the potential of the elderly and patients to live and cope at home.

Applications integrated in such smart, pervasive environments are context-aware by essence. It means that they are able to adapt their behaviors and the provided services according to environmental conditions [START_REF] Baldauf | A survey on context-aware systems[END_REF]. The notion of environment should be taken in its broad sense here. It includes any information that can be of interest for an application like, for instance, physical quantities, locations and expectations of human beings (implied or not in the functions provided by the application), the software itself, and even remote digital resources. Applications are also able to act on their context and, say, change physical quantities to meet their objectives.

We readily acknowledge that building a context module is a complex task. Multiple design trade-off decisions have to be made and implemented regarding data access, synchronization mechanisms, knowledge representation, reasoning, and presentation. A common solution to alleviate these difficulties is to use a context management framework. The purpose of such framework is to deal with a number of generic features like information synchronization or publication. As will see here after, most existing frameworks suffer from major flaws with regard to our use case. In particular, many impose an unwanted overhead in terms of representation and also execution time.

In our work, we concentrate on the fog level, which means that we focus on the context-aware part of the code that is executed as close as possible to the devices. This corresponds, for instance, to short-term supervision in pervasive environments. At that level, reactivity is an essential aspect.

The supporting framework has to deal with dynamic environments where resources can appear and disappear without notice.

We have integrated an autonomic, service-oriented context module in our pervasive platform, named iCasa [START_REF] Escoffier | Lessons learned in building pervasive platforms[END_REF]. This platform was ideally suited for such extension since it is based itself on service orientation. Precisely, it is builds upon the Apache service-oriented component model, iPOJO [START_REF] Escoffier | iPOJO: an extensible serviceoriented component framework[END_REF].

Context appears as a dynamic set of services. Depending on the sources availability and the platform needs, different services are published in and withdrawn from the platform service registry. They are then opportunistically used by the pervasive applications, coded in iPOJO. As illustrated, the context module receives goals (that can be of different levels of abstraction) from the platform that are used for context selfadaptation. Another major point is that the context module tracks any contextual modifications and sends an event to alert applications using it. The overall approach is illustrated by Fig. 1. home gateway, which hosts several applications and offers dynamic deployment facilities.  A smart home simulator (see Fig. 2) that supports the execution of predefined scenario, in order to quickly test pervasive applications.

In this environment, several applications have been developed in various domains, including safety, comfort and healthcare at home. These applications differ in terms of technical requirements and needed context. In our demo, we will consider two different applications. Actimetrics is a home care application measuring through the execution platform, and analyzing, through a cloud infrastructure, the motor activity of elderly. It tracks behavioral changes to early diagnose degenerative diseases like Alzheimer. We also designed a LightFollowMe application: for each room of a house, it controls the light depending on the presence of a user, and adjusts intensity according to the current moment of the day.

For these applications, we will present how the context is defined, deployed and run on the pervasive platform. Context at runtime will be presented in a graphical form. Let us focus on the LightFollowMe application. The context needs for this application can be decomposed as it follows. First, the application relies on an appropriate abstraction of lightning devices, spatial zones and time (modeling). Such abstraction must be synchronized with the physical devices (gathering). Then, the application requires knowing which device is in which zone (enrichment). The application computes physical parameters: presence and illumination per zone (processing). Finally, the application necessitates retrieving all this information (disseminating) and applying its business logic to affect the environment. Our framework gives an understandable representation of the global context. The bottom right corner of Fig. 2 presents the graph of the model displayed on the iCasa simulator: devices are gathered by location, each room is enhanced with a physical parameter aggregating and synthesizing presence status, and an independent entity provides the moment of the day. In addition of the graph view, the simulator can display state properties and state extensions of an entity. This functionality is shown on Fig. 3 with light_A. Our framework gives significant results from application development perspective. Inevitably, building the context adds an additional development task and the resulting architecture is more complicated. However, it's easier to implement applications on the top of it. The context is shared among them, is extensible and can be adjusted to fit needs of an update. The whole software is more consistent, testable and maintainable.

Fig. 1 .

 1 Fig. 1. Overall approach. II. PROPOSED DEMONSTRATION The proposed demonstration is based on the iCasa environment, which is made of three tools:  An IDE based on an eclipse plug-in. It supports the development of iPOJO-based application.  An execution platform, based on OSGi, running on ahome gateway, which hosts several applications and offers dynamic deployment facilities.  A smart home simulator (see Fig.2) that supports the execution of predefined scenario, in order to quickly test pervasive applications.

Fig. 2 .

 2 Fig. 2. Light Follow Me application -iCasa simulator overview.

Fig. 3 .

 3 Fig. 3. Light Follow Me application -zoom on the kitchen.