Decoupling Context Management and Application Logic: a new Framework Bachir Chihani, Emmanuel Bertin Orange Labs 42 rue des Coutures, 14066 Caen, France {bachir.chihani,emmanuel.bertin}@orange.com Noël Crespi Institut Mines-Telecom, Telecom SudParis, CNRS 5157 9 rue Charles Fourier 91011 Evry, France {noel.crespi}@it-sudparis.eu Abstract—Several frameworks have already been proposed to simplify the development of context-aware applications. These frameworks are focused on collecting and publishing contextual data, and on providing common semantics, definitions and representations of these data. This implies that applications share the same semantics, which limits the range of use cases where a framework can be used since that assumption induces a strong coupling between context management and application logic. This article proposes a framework that decouples context management from application business logic. The aim is to reduce the overhead for applications that run on resource-limited devices while still providing efficient mechanisms to support context-awareness and behavior adaptation. This framework implements an innovative approach that involves third parties in the process of context processing definition by structuring it in atomic functions, and describing it with an XML-based programming language. Its implementation and evaluation demonstrates the benefits, in terms of flexibility, of using trusted design patterns from software engineering for developing context-aware application. Keywords— Software Engineering; Context-awareness; Adaptation; XML I. INTRODUCTION Two architectural approaches [1] have been used to design context-aware applications: architectures based on a broker model and those based on a point-to-point model. Both have context providers for collecting context, and context consumers (i.e. context-aware applications) that use context to adapt their behavior. In the first model, a context broker is used to decouple context providers and consumers, limiting or eliminating direct connections. This broker is in charge of context modeling and inference [1] [2] [3] [4] [5]. However, these tasks are performed in a pre-defined way and are barely customizable by consumers. As a result, the generated information may not fully match the specific needs of consumers. In the second model, context consumers know the providers and send their requests to them directly [6]. This model is less sophisticated, as consumers need to know which provider should be addressed for a given context and should also be aware of their state (e.g. awake or asleep). In both cases, consumers continuously request contextual information from their sources (either the context broker or directly from context providers) or subscribe to be notified with context updates. Upon reception, this information must then be processed again by the context consumers to determine if it should impact their behavior. When the updating load increases, consumers are overloaded with messages, many of which are not at all relevant to them. Moreover, consumers have to store and handle context information locally to maintain a consistent vision of the user’s situation and to adapt their behavior accordingly. We have thus identified the need for a better separation within context-aware architectures. The application business logic and the context management operations should be kept separate, so that one of these logics can be modified without having to modify the other. To enable this separation, we propose to host all operations related to context management in the context broker, outside of context-aware applications. Consequently, an appropriate language is needed, in which application developers can specify which actions should be executed by the broker when a specific context is published. Our contribution is a generic framework, based on the Observer design pattern [7], which is flexible enough to be customized for building context-aware applications in different domains. Herein, flexibility refers to dynamic adaptation, customization and component reusability. The use of the Observer pattern allows the context broker to be treated as an observed component by context consumers. When the broker’s state changes as a result of processing context data, it notifies the consumers interested in these. The framework is able to process context data differently based on the specifications defined by context consumers. The rest of the paper is organized as follows. Section 2 illustrates our framework architecture and implementation details. In section 3, we present an evaluation of the proposed framework through a real case study and performance evaluation in a simulated environment. Section 4 discusses related works and the proposed framework. Finally, we conclude the paper and present future work in section 5. II. DESIGN CONSIDERATIONS The heterogeneity of contextual information (location, presence, temperature, etc.) brings a considerable complexity to their management (provisioning, distribution, use, etc.) which makes the development of context-aware applications a hard task. The pooling of certain management operations (e.g. provisioning) at a specialized element of the overall architecture could reduce complexity of the development of