SoCQ : un système de gestion de données et de services en environnement pervasif

Transcription

1 SoCQ : un système de gestion de données et de services en environnement pervasif Yann Gripay, Le-Quyen La, Frédérique Laforest, Jean-Marc Petit Université de Lyon, CNRS INSA-Lyon, LIRIS, UMR avenue Jean Capelle Villeurbanne cedex, France {Yann.Gripay,Le-Quyen.La,Frederique.Laforest,Jean-Marc.Petit}@liris.cnrs.fr Résumé Interroger des sources de données non-conventionnelles est reconnu comme une problématique majeure dans les nouveaux environnements comme ceux de l'informatique pervasive. Un point clé est la possibilité d'interroger des données, des ux de données et des services de manière déclarative an de faciliter le développement d'applications pervasives. Le projet SoCQ (Service-oriented Continuous Queries) aborde les problématiques suivantes en s'appuyant sur les principes des bases de données : 1) la dénition d'une représentation homogène des sources de données et des services de l'environnement pervasif ; 2) la dénition d'un langage de requêtes pour ces environnements permettant d'exprimer des applications pervasives ; 3) la conception d'un système de gestion d'environnement pervasif (PEMS : Pervasive Environment Management System) supportant à la fois la représentation homogène et le mécanisme de requêtes. Cette démonstration montre notre prototype de PEMS en action, permettant à l'utilisateur de visualiser l'environnement et de dénir des applications pervasives. Mots-clés Bases de données ; Flux de données ; Services ; Requêtes continues ; Environnements pervasifs 1

2 1 Motivation The Service-oriented Continuous Query project, or SoCQ project [4], is devoted to making the development of pervasive applications easier through database principles. It aims at contributing in the area of Dataspaces [1] through a unied view of data and service spaces mandatory in pervasive environments. We proposed an approach [2, 3] to homogeneously represent such pervasive environments through database principles. The basic idea is to oer to application developers a database-like view of the environment resources, so that they can visualize this environment as a set of tables and launch declaratively-dened continuous queries involving available data sources and services. This approach is built on an extension of the relational model and uses a SQL-like query language. Through this homogeneous relational representation, the dierent operations of the Pervasive Environment Management System (or PEMS), like resource discovery and service invocations, can be translated into operations on tables: updating tables, retrieving values of virtual attributes, combining tables, etc. Pervasive applications can then be expressed using declarative continuous queries, and query optimization techniques can be applied to optimize the execution of those applications. 2 Overview of the SoCQ data model In the demo scenario, we monitor temperatures in an oce building: when a temperature exceeds some threshold in a room, an alert message is sent to the manager of this room. A photo of the room can be joined to the message. We consider an environment containing the following data sources and services: 1) two data relations: one containing some information about the rooms (manager, temperature threshold... ), the other one being a list of contacts (including contacts for the managers 2) some temperature sensors distributed in several rooms, providing data streams; 3) some cameras in the rooms, providing photo services; 4) some messenger services (mail, instant message, SMS). This environment can be represented homogeneously with relations and streams extended with virtual attributes and binding patterns [2, 3]. Virtual attributes are attributes that do not have a value: they may be provided a 2

3 RELATION surveillance ( area STRING, manager STRING, threshold REAL, alertmessage STRING STREAM temperatures ( area STRING, temperature REAL RELATION employees ( name STRING, address STRING, messenger SERVICE, text STRING VIRTUAL, sent BOOLEAN VIRTUAL ) USING BINDING PATTERNS ( sendmessage[messenger] ( address, text ) : ( sent ) Table 1: DDL description of XD-Relations for the demo scenario environment value through a query, either by direct assignments or by binding patterns that indicate their relationship with methods from services. We call such relations XD-Relations, standing for extended Dynamic Relations, and such environments relational pervasive environments. For the demo scenario, we can view a DDL representation of the schema of this environment in Table 1. For instance, the following table is an example of content for the XD- Relation employees. The constants mailer and jabber are two service references, the former for the mail server, the latter for the instant messaging server. The star (*) symbol reminds that virtual attributes have no value. name address messenger text sent nicolas nicolas@elysee.fr mailer * * carla carla@elysee.fr mailer * * françois francois@im.gouv.fr jabber * * The temperature monitoring can be declaratively dened as a Serviceoriented Continuous Query, or SoCQ query, over this relational pervasive environment. The three XD-Relations are joined (the stream temperature must be windowed) on the manager name and the area, the threshold is checked and the message body is set. The binding pattern sendmessage will be invoked in order to fetch a value for the initially virtual attribute sent. SELECT surveillance.area, surveillance.manager, employees.sent FROM WITH WHERE AND AND temperatures [now], employees, surveillance employees.text := surveillance.alertmessage surveillance.manager = employees.name surveillance.area = temperatures.area surveillance.threshold < temperatures.temperature USING employees.sendmessage This SQL-like query is a typical example of a pervasive application that is dened at the declarative level, without worrying about low-level technical considerations (programming languages, network protocols). 3

4 3 Description of the PEMS prototype The role of a PEMS is to manage a relational pervasive environment, with its dynamic data sources and set of services, along with the execution of the continuous queries over this environment. The PEMS core is composed of three modules. PEMS GUI Local Environment PEMS Client PEMS Peer Network PEMS Core PEMS Peer Query Processor Extended Table Manager Environment Local Environment Service Service Stream Database Service Stream Service The core Environment handles service discovery and remote invocations, with Local Environment Resource Managers as distributed proxies for local devices that provide services and streams. An Extended Table Manager builds a homogeneous representation as a set of XD- Relations, and the Query Processor allows to dene, optimize and execute SoCQ queries. A PEMS GUI enables to visualize existing XD-Relations and their content, to add/delete XD-Relations, and to launch/stop SoCQ queries. 4 Demonstration scenario The demonstration platform is a functional PEMS and a pervasive environment that provides services and data streams mentioned in this paper. A rst PC is used to host the PEMS and to interact with it through its GUI. Two other PCs are used to host dierent services and devices: physical or simulated temperature sensors (Thermochron ibutton DS1921, Sun SPOTs), webcams (from Logitech), instant messaging server (Openre server from Jive Software), (gateway to) SMS gateway (commercial service from Clickatell), (gateway to) mail server. Two handheld devices (1 PDA, 1 SmartPhone) are also used to host instant messaging client. A poster with illustrations and explanations is provided to help demo visitors comprehend the dierent parts of the platform and their interactions. A demo visitor can then interact with the platform in three steps: 1. Testing the demo conguration: visualize the environment through the PEMS GUI and observe the execution of the demo query while manipulating the sensors to interact with the environment, e.g. receiving messages when heating the temperature sensors in his/her hand. 4

5 2. Modifying the demo conguration: modify the data and/or the query and observe the impact on the execution of the pervasive application, e.g. by entering his own contact information to receive a SMS sent by the query on his/her own smart phone. 3. Writing new queries: discuss with demo authors and propose new queries on the complete testbed environment with additional data sources and services (RSS feeds, cameras with object detection, Sun SPOT motion sensors and LEDs, pervasive home model in Lego with electric curtains... ) in order to test the expressiveness of the proposed model. The PEMS allows an environment conguration to be saved into and loaded from a le. Demo congurations can be quickly (re)loaded into the PEMS when needed, in particular the initial one. 5 Demonstration contributions This demo allows to demonstrate the following points: 1) a homogeneous database-like view on pervasive environments containing dynamic data sources and services is possible as a set of XD-Relations, through the notions of virtual attributes and binding patterns; 2) Service-oriented Continuous Queries (SoCQ queries) over relational pervasive environment allow to dene pervasive applications combining data sources and services; and 3) declarative denitions of SoCQ queries make the denition and the evolution of pervasive applications easier. Although this model is presented in the context of pervasive environments, it can be applied to less dynamic systems that could benet from the declarative denition of applications combining data sources and distributed functionalities. References [1] M. Franklin, A. Halevy, and D. Maier. From Databases to Dataspaces: a new Abstraction for Information Management. SIGMOD Record, 34(4):2733, [2] Y. Gripay. Service-oriented Continuous Queries for Pervasive Systems. In EDBT 2008 PhD Workshop (unocial proceedings), [3] Y. Gripay, F. Laforest, and J.-M. Petit. Vers une algèbre relationnelle étendue aux services. In BDA 2008, pages 120, Oct [4] SoCQ Project. 5