Projet de fin d'études

Projet de fin d'études Gestion de ressources en environnement pervasif Brice Chardin DPt. Télécommunications Services & Usages 23/06/2008 Encadrants : Frédérique Laforest Jean-Marc Petit Yann Gripay

Remerciements Je remercie les membres de l'équipe SIP et du LIRIS que j'ai eu l'occasion de rencontrer au cours de ce PFE. En particulier : Mes encadrants Yann Gripay, Frédérique Laforest et Jean-Marc Petit, pour l'aide et les nombreux conseils qu'ils m'ont donnés tout au long de ce projet. Liya Zeng pour le travail effectué lors de son projet de fin d'étude, dont je me suis inspiré. Les personnes avec qui j'ai partagé le bureau : Romain Cuenot, Eric Dubreuil, Quang-Trung Nguyen, Ny Haingo Andrianarisoa, Romuald Thion et Julien Gossa pour l'ambiance conviviale qui y régnait. i

Table des matières 1 Introduction... 1 1.1 Contexte... 1 1.2 Le projet SoCQ... 1 1.3 Le PFE... 3 2 Analyse du cahier des charges... 4 2.1 Architecture... 4 2.2 Choix des technologies et des outils... 5 2.2.1 UPnP... 5 2.2.2 OSGi & Felix... 5 2.2.3 Maven... 5 2.2.4 Eclipse... 6 2.3 Organisation... 6 3 Gestion des ressources... 7 3.1 Objectifs... 7 3.2 Architecture... 7 3.3 Service SoCQ... 8 3.4 Gestionnaires de ressources locaux... 8 3.5 Gestionnaire de ressources global... 10 3.6 Contrôleur du gestionnaire de ressources global... 11 3.7 Conclusion... 13 4 Gestion des tables... 14 4.1 Objectifs... 14 4.2 Architecture... 14 4.3 Gestionnaire de tables... 15 4.3.1 Catalogue... 17 4.3.2 Tables... 17 4.3.3 TableProxy... 18 4.3.4 Objets Future... 18 4.3.5 Commandes... 18 4.3.6 Binding Patterns... 20 4.3.7 Gestionnaire de listes de services... 20 4.4 Contrôleur de tables... 21 4.5 Conclusion... 23 5 Expérimentations... 24 6 Conclusion... 28 7 References... 29 8 Annexes... 30 8.1 Interface ISoCQService... 30 8.2 Classe SoCQServiceDescription... 31 8.3 Classe Tuples... 32 8.4 Spécifications UPnP pour la gestion des ressources... 33 ii

1 Introduction 1.1 Contexte Les environnements informatiques tendent à évoluer vers ce qu'on appelle des systèmes pervasifs [1]. Contrairement à l'utilisation contemporaine de l'informatique où l'utilisateur interagit consciemment avec un appareil dans un but précis, un système pervasif implique plusieurs dispositifs informatiques, sans nécessairement que l'utilisateur en ait conscience. Ces systèmes, généralement destiné à des applications de la vie quotidienne, incluent de petits et peu coûteux dispositifs de traitement en réseau, intégrés et distribués dans l'environnement. L'axe Systèmes d'information communicants du Laboratoire d'informatique en Image et Systèmes d'information (LIRIS) possède une équipe traitant de ces systèmes pervasifs : l'équipe SIP (Systèmes d'information Pervasifs). Un des projets de cette équipe s'intéresse à obtenir une vision homogène des services et des données. Il s'agit du projet SoCQ : Service-oriented Continuous Queries [2,3,4]. 1.2 Le projet SoCQ Le projet SoCQ a pour objectif de proposer un cadre (framework) permettant de faciliter le développement d'applications dans un environnement pervasif. En adoptant une approche inspirée des bases de données, ce framework donne une représentation homogène des sources de données hétérogènes de l'environnement. Ces sources de données, qui peuvent être des relations dynamiques, des flux de données ou des services, sont représentées sous forme de tables relationnelles. Les applications utilisant ce framework sont alors définies avec un langage de type SQL. Pour illustrer le fonctionnement de SoCQ, on considère un scénario simple de surveillance de températures dans différentes zones. Ce scénario implique les ressources suivantes : des capteurs de température qui fournissent un flux de valeurs de température relevées dans différents lieux, et un service d'envoi de messages instantanés. La traduction de ce scénario pour SoCQ se compose de deux éléments : la description des ressources (catalogue) et la description de l'application (requête). Le catalogue est un ensemble de tables, qui correspondent à des relations (RELATION) ou des flux (STREAM) La description des ressources de ce scénario dans un langage de description de données est la suivante : CREATE STREAM Temperature ( Area CHAR, Temperature REAL ) CREATE RELATION Employee ( Name STRING(20), Address STRING(50), Messenger SERVICE, Message STRING(20) VIRTUAL, Sent CHAR VIRTUAL ) 1

CREATE RELATION Surveillance ( Area CHAR, Manager STRING(20), Threshold REAL, AlertMessage STRING(20) ) On remarque un style similaire aux create de tables en SQL classique. Néanmoins, deux notions nouvelles apparaissent : - Les STREAM Température représente le flux de températures provenant des différents capteurs répartis dans l'environnement. Il contient les localisations des capteurs (Area) et les valeurs des températures (Temperature). Contrairement à une relation, les tables de type flux ne stockent pas les données. - Les attributs VIRTUAL et SERVICE Employee est une table relationnelle contenant des attributs virtuels. Ces attributs n'auront de valeur attribuée qu'au cours du traitement de la requête. Elle contient les noms des employés (Name), leurs adresses de messagerie (Address), l'identifiant du service de messagerie à utiliser (Messenger), qui est un attribut de type servcie, et deux attributs virtuels correspondant au message à envoyer (Message) et à la confirmation de l'envoi du message (Sent). Surveillance est une table relationnelle classique dont chaque occurrence décrit une localisation à surveiller (Area), le nom du responsable de la zone (Manager), le seuil de température (Threshold) et le message d'alerte à envoyer (AlertMessage). Dans ce scénario, on souhaite envoyer un message au responsable d'une zone lorsque la température dans celle-ci dépasse un certain seuil. La requête SoCQ permettant de répondre à ce besoin est la suivante : SELECT Area, Manager, Threshold, Temperature, Sent FROM Temperature T, Surveillance S, Employee E WHERE S.Manager = E.Name AND S.Area = T.Area AND S.Threshold < T.Temperature AND E.Message = S.AlertMessage SoCQ compare en continu les températures, arrivant sur le flux, avec les seuils enregistrés dans la relation Surveillance. Si les valeurs sont supérieures aux seuils, SoCQ fait appel au service de messagerie pour envoyer le message correspondant. Le moteur d'exécution de requêtes SoCQ est développé parallèlement par l'équipe SoCQ, et est utilisé pour certains tests (voir section 5). Par ce langage déclaratif de haut niveau, SoCQ permet de faciliter le développement d'application pervasives. Au lieu d'écrire du code Java spécifique, le développeur peut se concentrer sur l'application. 2

1.3 Le PFE Ce projet de fin d'études "Gestion de ressources en environnement pervasif" s'intègre dans le projet SoCQ. Ce PFE a pour but de fournir une gestion de ressources pour tester et évaluer l'outil SoCQ. Cela se décompose en plusieurs parties : - Définir un modèle de service pour le système SoCQ. - Effectuer la liaison entre les tables et les services. - Gérer des tables relationnelles étendues avec les services, en vue d'une utilisation par le moteur d'exécution de requêtes SoCQ. - Implémenter et tester le système. Ce projet constitue une brique nécessaire au fonctionnement du projet SoCQ. Il permet de simplifier le développement du moteur SoCQ, mais également des services fournis par les différents éléments du système pervasif associé. Le travail demandé comprend la rédaction de spécifications, le développement et le test de la gestion de tables, de la gestion de ressources et de quelques services, notamment ceux impliqués par le scénario présenté dans la section 1.2. 3

2 Analyse du cahier des charges 2.1 Architecture L'architecture de ce projet (voir fig.1) est composée de deux parties. La première s'occupe de la gestion des ressources, tandis que la deuxième concerne la gestion du catalogue de tables mis à disposition du moteur SoCQ Les ressources pouvant être réparties sur le réseau, cette deuxième partie est également composée de deux sous-parties : un gestionnaire de ressources global, centralisé, et un ou plusieurs gestionnaires de ressources locaux. Fig.1 : Architecture globale de l'outil SoCQ Un service au sens SoCQ est une entité externe possédant des méthodes, des flux et des propriétés. Cette entité peut être le service lui-même, ou servir de proxy pour un service externe. Par exemple, le scénario de surveillance de température utilise deux services : un service de capture de 4

température qui gère un capteur branché sur la même machine, et un service de messagerie qui sert de proxy, communiquant avec le serveur de messagerie. Les gestionnaires des ressources locaux s'occupent de la découverte de services au niveau local et de la mise à disposition de ces services pour le gestionnaire de ressources global. Le gestionnaire de ressources global met à disposition du gestionnaire de tables l'ensemble des ressources du système, en masquant les problèmes réseaux. Il s'occupe de la découverte et de l'invocation à distance. Ce gestionnaire de ressources est associé à un contrôleur servant à visualiser et tester les services. Ce contrôleur de ressources n'est pas nécessaire au bon fonctionnement du système. Le moteur SoCQ sert à exécuter les requêtes fournies par un développeur d'applications pervasives. Il a pour cela besoin du gestionnaire de tables, qui lui propose un ensemble de tables relationnelles (le catalogue), et sert d'intermédiaire avec le gestionnaire de ressources global. Un contrôleur de tables est associé au gestionnaire de tables. Il permet l'administration du catalogue du gestionnaire de tables. 2.2 Choix des technologies et des outils 2.2.1 UPnP Le protocole réseau utilisé pour la gestion des ressources dans ce PFE est UPnP [6]. En effet, les systèmes pervasifs utilisant de nombreux dispositifs de traitement en réseau, UPnP permet la découverte automatique de ces éléments, ainsi que l'invocation à distance des méthodes proposés par les services. De plus, ce protocole permet la notification d'évènements, utilisé pour les flux de données. Il aurait également été possible d'utiliser RMI [7] ou CORBA [8], mais UPnP permet la découverte automatique, ce qui simplifie le développement de la partie réseau du gestionnaire de ressources. Ce protocole est de plus indépendant du langage de développement. 2.2.2 OSGi & Felix OSGi [7] est un ensemble de spécifications pour une plateforme de déploiement et d'exécution pour les applications Java. OSGi fournit une architecture orientée services permettant aux composants de se découvrir entre eux dynamiquement. Les applications peuvent alors être composées de composants réutilisables et coopératifs appelés bundles, qui sont des archives Java avec des métadonnées spécifiques. Apache Felix [9] est une implémentation open-source du framework OSGi et d'une partie des services standards selon la spécification OSGi R4. Un de ces services standards, UPnP Service, permet de faire le lien entre un périphérique UPnP et le registre de services OSGi, notamment en gérant les dépendances entre bundles, ce qui facilite le développement du gestionnaire de ressources pour le projet SoCQ. 2.2.3 Maven Maven [10] est un outil open-source de complilation pour les projets Java. Maven utilise une approche déclarative, où le contenu et la structure du projet sont décrits par un Project Object 5

Model (POM). Maven permet en particulier d'obtenir facilement des bundles OSGi, c'est la raison pour laquelle cet outil est utilisé pour ce projet. 2.2.4 Eclipse Eclipse IDE [11] est un environnement de développement libre. Grâce à son architecture développée autour de la notion de plugins, Maven et Felix peuvent être intégrés à l'ide, ce qui facilite le développement et débogage des bundles. 2.3 Organisation Ce projet de fin d'études dure un total de dix semaines et demie. L'organisation du travail est présentée dans le tableau suivant : Imprégnation du sujet et lecture de documentations S14 S15 S16 S17 S18 S19 S20 S21 S22 S23 S24 S25 S26 Conception des gestionnaires de ressource Développement et tests des gestionnaires de ressource Conception du gestionnaire de tables Développement et tests du gestionnaire de tables Rédaction du mémoire Préparation de la soutenance et Packaging Soutenance Les livrables sont : - Les spécifications du gestionnaire de ressources, fin semaine 16. - Les sources du gestionnaire de ressources, fin semaine 19. - Les spécifications du gestionnaire de tables, fin semaine 21. - Les sources du gestionnaire de tables, fin semaine 23. Cependant, la plupart des livrables, notamment les spécifications, ont évolué en fonction des remarques des encadrants grâce à des réunions hebdomadaires, et ont été livrés en version finale après les dates prévues initialement. Une première présentation du gestionnaire de ressources a été effectuée au milieu de la semaine 19. Des pré-soutenances sont également prévues en début de semaine 26. 6

3 Gestion des ressources 3.1 Objectifs Les services étant répartis dans l'environnement, le rôle des gestionnaires de ressources est de centraliser l'accès à ces services pour que le gestionnaire de tables s'affranchisse des problèmes réseau. 3.2 Architecture La découverte de services par les gestionnaires de ressources locaux s'effectue au niveau d'osgi, chaque service doit donc proposer un proxy ou bien être lui-même sous forme d'un bundle OSGi (voir exemple fig.2). Fig.2 : illustration de l'architecture choisie pour la gestion de ressources 7

3.3 Service SoCQ Un service au sens SoCQ est une entité possédant des méthodes, des flux et des propriétés. Tout service doit implémenter l'interface ISoCQService (voir annexe 1) et ainsi permettre de récupérer sa description (voir annexe 2), de s'abonner/désabonner à ses flux et d'invoquer ses méthodes. Exemples : Le service de température et le service de messagerie utilisés dans l'exemple possèdent les descriptions suivantes (pour le format des signatures, voir annexe 2) : Service de capture de température Service de messagerie Méthodes gettemperature::r sendmessage:ss:b Flux Propriétés temperature::sr location:s version:s protocol:s Le service de capture de température possède une méthode, gettemperature, n'ayant pas de paramètres d'entrée et renvoyant un réel. Il propose également un flux, non paramétrable, composé d'une chaîne de caractère (la localisation) et d'un réel (la température). Ses deux propriétés, location et version, sont des chaînes de caractères. Le service de messagerie ne possède pas de flux, mais propose la méthode sendmessage, dont les paramètres d'entrée sont le nom d'utilisateur et le message à envoyer. Ce service n'a qu'une propriété, protocol, correspondant au protocole utilisé par ce service. Les flux proposés sont des flux de Tuples (voir annexe 3). Ces flux sont paramétrables, c'est-à-dire que des paramètres peuvent être fournis lors de l'abonnement au flux, en accord avec sa signature. Un tuple est une collection ordonnée d'objets, il correspond à une ligne dans une relation. Par exemple, on pourrait imaginer développer un service de messagerie instantanée sur ce modèle. Ce service proposerait un flux qui demande comme paramètres d'entrée un login et un mot de passe. Le flux contiendrait alors les messages destinés à cet utilisateur. La signature d'un tel flux est messages:ss:s. 3.4 Gestionnaires de ressources locaux Le gestionnaire de ressources local recherche localement, dans son framework OSGi, les services compatibles SoCQ ; et effectue la conversion dans le protocole réseau utilisé entre les gestionnaires de ressources, UPnP. La figure 3 présente le diagramme de classes du gestionnaire de ressources local. La classe SoCQDiscoveryAgent permet de découvrir les nouveaux ISoCQServices se déclarant auprès du framework OSGi. Cet agent notifie le LocalRM (Local Resource Manager) par les méthodes registersocqservice(isocqservice service) et unregistersocqservice(isocqservice service). 8

Fig.3 : Diagramme de classes du gestionnaire de ressources local Lorsqu'un nouveau service SoCQ est disponible, le LocalRM crée un nouvel objet SoCQUPnPDevice, (voir annexe 4) représentant un périphérique au sens UPnP. L'API UPnP de Felix permet d'effectuer le lien entre cet objet et le protocole réseau UPnP. Un périphérique au sens UPnP correspond à un service au sens SoCQ. Un bundle proposant plusieurs services SoCQ sera donc converti en autant de périphériques UPnP. Un des avantages d'upnp est qu'il est possible de développer des gestionnaires de ressources locaux sous d'autres langages que java. Il suffit que ces gestionnaires de ressources respectent les spécifications UPnP propres à la gestion de ressources pour SoCQ (voir annexe 4). 9

3.5 Gestionnaire de ressources global Le gestionnaire de ressources global a pour rôle de découvrir les Services SoCQ UPnP mis à disposition par les gestionnaires de ressources locaux. Il sert également à effectuer la conversion inverse des gestionnaires de ressources locaux, c'est-à-dire convertir les périphériques UPnP en proxys de services SoCQ. La figure 4 présente le diagramme de classes du gestionnaire de ressources global. Fig.4 : Diagramme de classes du gestionnaire de ressources global 10

Le gestionnaire de ressources global est composé de trois parties: - La découverte de services UPnP compatibles SoCQ, effectuée par l'objet UPnPDiscoveryAgent - La création d'un objet SoCQUPnPService implémentant l'interface ISoCQService. Cet objet sert de proxy pour l'invocation des méthodes proposées par cette interface - La gestion des ISoCQServices, effectuée par un GlobalRM (Global Resource Manager). La classe UPnPDiscoveryAgent permet de découvrir les nouveaux SoCQUPnPDevices sur le réseau. A chaque découverte, cet agent crée un SoCQUPnPService implémentant l'interface ISoCQService, qui permet d'appeler les actions UPnP correspondant aux méthodes de l'interface ISoCQService. Une fois ce service créé, l'agent notifie la GlobalRM par l'appel de la méthode registersocqservice(isocqservice service) (respectivement unregistersocqservice(isocqservice service) si le périphérique UPnP disparaît). Le GlobalRM gère une liste de ces proxys de services SoCQ et les rend accessibles par les méthodes définies par l'interface IGlobalRM. 3.6 Contrôleur du gestionnaire de ressources global Le contrôleur fournit une interface graphique au gestionnaire de ressources global. Il permet de visualiser la liste des services présents dans l'environnement ainsi que leur description (fig.5). Il permet également d'invoquer leurs méthodes (fig.6), s'abonner / désabonner à leurs flux (fig.8) et récupérer la valeur de leurs propriétés (fig.9). Dans les captures d'écrans des figures 5, 8 et 9, le service concerné est un service de capture de température virtuel. Pour la figure 6, il s'agit du service de messagerie instantanée. Fig.5 : Interface du contrôleur du gestionnaire de ressources La figure 5 présente l'interface du contrôleur du gestionnaire de ressources. Sur la gauche se trouve la liste des identifiants de services du gestionnaire de ressources global. Lorsqu'un service est sélectionné, sa description s'affiche au centre. 11

Fig.6 : Invocation de méthodes des services. Sur la figure 6, on a d'abord invoqué la méthode gettemperature du service 1 (capture de température), puis la méthode sendmessage du service 2 (service de messagerie). On observe dans la partie inferieur du contrôleur les résultats de ces invocations. Le résultat de l'invocation de la méthode sendmessage avec les paramètres visibles sur la figure 6 est présenté figure 7. C'est un client de messagerie Jabber ouvert en tant que brice@liris-7171.insalyon.fr, qui a reçu le message "Hello world!" envoyé par le service de messagerie. Fig.7 : Résultat de l'invocation de la méthode sendmessage. Sur la figure 8, le contrôleur s'est abonné au flux de température des services 1 et 2, correspondant respectivement à des capteurs de température virtuels dans le bureau et sur le toit. On voit dans les traces les différents tuples reçus pour les deux flux. Sur la figure 9, la propriété location du service 1 est sélectionnée. On peut ainsi visualiser sa valeur. 12

Fig.9 : Visualisation des propriétés. Fig.8 : Abonnement à des flux de température. 3.7 Conclusion L'aspect réseau était la difficulté de cette partie, d'une part parce qu'upnp est particulièrement contraignant en terme de développement, mais surtout parce que l'implémentation du service UPnP proposé par Felix n'est pas très explicite pour la gestion des erreurs, et possède quelques bugs. La partie gestion des ressources de ce projet représente un volume de 3140 lignes de code (57 classes Java) pour les gestionnaires de ressources et le contrôleur, et de 434 lignes (8 classes Java) pour les exemples de services de capture de température et de messagerie. 13

4 Gestion des tables 4.1 Objectifs Le gestionnaire de tables a pour but de fournir un catalogue de tables. Il doit s'occuper de l'accès concurrent à ce catalogue, et des opérations sur les services. Une table est un ensemble de tuples correspondant à un schéma. Dans SoCQ, les attributs d'une table peuvent être réels, c'est-à-dire que la donnée associée est stockée, ou virtuels, dans ce cas, la donnée ne possède qu'une existence logique au niveau du gestionnaire de tables et ne peut être complétée que lors de l'exécution d'une requête. Les attributs virtuels sont utilisés lors de l'invocation de binding patterns. Un binding pattern est une règle associée à une table qui décrit la relation entre les attributs de cette table et une méthode d'un service. Par exemple : On considère la table Employee suivante, dont les attributs Message et Envoyé sont virtuels et sont représentés par le caractère '*'. L'attribut Service contient l'identifiant du service à utiliser lors de l'invocation du binding pattern. Ce service possède la méthode : Boolean envoyermessage(string message, String adresse). Nom Adresse Service de messagerie Message (v) Envoyé (v) Brice brice@insa-lyon.fr 1 * * Yann yann@insa-lyon.fr 1 * * Le binding pattern permet d'associer la méthode envoyermessage à cette table. Il définit la correspondance entre les attributs Message et Adresse de cette table et le paramètre d'entrée message et adresse de la méthode envoyermessage, et celle entre l'attribut Envoyé et le paramètre de retour de cette méthode. L'attribut correspondant à l'identifiant du service à utiliser est également défini par le binding pattern. Il s'agit ici de l'attribut Service de messagerie. Le gestionnaire de tables permet les opérations suivantes : - création / suppression d'une table - lecture d'une table - ajout / suppression d'un tuple dans une table - invocation d'un binding pattern associé à une table 4.2 Architecture Le gestionnaire de tables, le gestionnaire de ressources global et le moteur SoCQ sont des modules du même framework (OSGi). 14

Fig.10 : diagramme de déploiement du gestionnaire de tables Le gestionnaire de ressources permet d'accéder à l'ensemble des services du système. Il s'occupe de la découverte et de l'invocation à distance. Le contrôleur de tables fournit une interface graphique pour visualiser et administrer le catalogue. Le moteur SoCQ s'occupe de l'exécution des requêtes SoCQ. 4.3 Gestionnaire de tables La figure 11 présente le diagramme de classes du gestionnaire de tables. Le gestionnaire de tables possède un catalogue de tables. Pour résoudre les problèmes de concurrence sur ce catalogue, l'accès à celui-ci est effectué uniquement par le thread principal du gestionnaire de tables. Pour cela, on utilise un système de commandes asynchrones. Les différentes commandes disponibles ainsi que leur fonctionnement sont détaillés dans la section 4.3.5. Lors de l'appel d'une méthode du gestionnaire de tables, une commande, correspondant à l'action demandée, est ajoutée dans une file interne. Dans son thread principal, le gestionnaire de tables peut alors exécuter cette commande. A la fin de l'exécution, l'appelant est notifié. La figure 12 présente la séquence utilisée pour la création d'une table. 15

Fig.11 : diagramme de classes du gestionnaire de tables. Fig.12 : diagramme de séquence de la création d'une table par l'intermédiaire d'une commande 16

Dans un souci d'optimisation de l'exécution, en particulier pour le moteur SoCQ, un autre mode d'accès au catalogue est prévu : le thread principal du gestionnaire de tables passe la main à un exécuteur de requêtes et lui donne un accès direct et exclusif au catalogue. Pour cela, le gestionnaire de tables appelle la méthode execute() de l'exécuteur de requêtes en lui donnant la référence du catalogue. Gestionnaire de tables donne la main aux exécuteurs de requêtes exécute les commandes en attente Les méthodes du catalogue et des tables sont synchrones. Elles possèdent leurs équivalents en appels asynchrones par l'utilisation du système de commandes. S'il s'agit d'une méthode du catalogue, la méthode asynchrone correspondante est fournie directement par le gestionnaire de tables. S'il s'agit d'une méthode d'une table, un proxy TableProxy est utilisé (voir 4.3.3). 4.3.1 Catalogue Le catalogue permet de : - Récupérer la liste des tables. - Récupérer un objet table. - Créer une table en fournissant son schéma de relation et ses binding patterns si nécessaire. - Supprimer une table. 4.3.2 Tables Une table est représentée par un schéma. Ce schéma décrit les attributs de la table. Ces attributs possèdent un nom, un type java (un objet Class) et une information booléenne indiquant s'il s'agit d'un attribut virtuel. Les tuples d'une table ne sont pas toujours stockés par le gestionnaire de table. S'il s'agit d'une table représentant un flux, les tuples sont transmis aux lecteurs mais ne sont pas conservés. Pour être compatible avec tous les types de tables (relation ou flux), la lecture utilise une file d'événements (liste FIFO) comme intermédiaire (voir fig.13). Lecteur Evènements Fig.13 : lecture d'une table Table 17

S'il s'agit d'une table représentant une relation, la lecture entraîne une phase d'initialisation de la file avec les tuples déjà présents dans la table. La file est ensuite actualisée en fonction des modifications effectuées (ajout ou suppression de tuples) jusqu'au désabonnement de la lecture. S'il s'agit d'une table représentant un flux, seuls les tuples du flux dont l'arrivée est postérieure à l'abonnement seront ajoutés dans la file, car le gestionnaire de table ne stocke pas les flux. Et ce jusqu'au désabonnement de la lecture. Pour une table de type flux, il ne peut y avoir que des ajouts. Les opérations suivantes sont également disponibles sur une table : - Lecture du contenu stocké d'une table (Abonnement avec une file d'évènements). - Désabonnement de la lecture. La table arrête alors de mettre à jour la file correspondante. - Ajout de tuples - Suppression de tuples - Invocation de binding patterns 4.3.3 TableProxy Les méthodes des tables présentées précédemment ne sont utilisables que si on a accès direct et exclusif au catalogue. Dans le cas contraire, lors de l'invocation asynchrone de la méthode gettable() du gestionnaire de tables, celui-ci renvoie un objet TableProxy qui sert de proxy pour l'invocation des méthodes d'une table. Lors de l'appel d'une méthode, le TableProxy ajoute la commande correspondante dans la file de commandes du gestionnaire de tables. 4.3.4 Objets Future Lors des invocations asynchrones, le retour de la méthode est un objet Future<V>. Cet objet, utilisant les types génériques <V> [12] et inspiré de l'interface Future<V> [13] fourni par Java, permet de notifier l'appelant lorsque la commande a été exécutée. Les méthodes utilisables par l'appelant sont : public Boolean isdone(); public V get()throws Exception; La méthode isdone() permet de vérifier si la commande a achevé son exécution, tandis que get() permet d'attendre si nécessaire la fin de cette exécution. C'est également le seul moyen de récupérer l'objet V, résultat de l'exécution de la commande. Les méthodes utilisables par le gestionnaire de tables sont : public void executioncomplete(v value); public void setexception(exception e); Elles permettent de notifier l'objet Future de la fin de l'exécution de la commande. Si l'exécution s'est déroulée normalement, l'objet V est fourni, sinon une Exception, donnée par l'appel de la méthode setexception, est levée par la méthode get(). 4.3.5 Commandes Lors de l'exécution asynchrone d'une méthode, des commandes sont utilisées pour mettre en file d'attente cette exécution. Les commandes possibles sont les suivantes : 18

Fig.14 : diagramme de classes du package commands Ces commandes représentent les méthodes du catalogue ou des tables. Elles renvoient un objet Future qui représente le résultat de cette exécution asynchrone. Voici un exemple d'utilisation : On considère la méthode suivante : Future<ITable> gettable(int key) L'objet souhaitant récupérer la table utilise le code suivant : Future<ITable> futuretable = tablemanager.getfuturetable(1); //Une commande est ajoutée dans la file de commandes du TableManager ITable table = futuretable.get(); La méthode get() bloque jusqu'à ce que la table soit disponible. Lorsque le TableManager va exécuter la commande, celle-ci va mettre à jour l'objet futuretable en appelant : futuretable.executioncomplete(uneitable); Il est également possible d'évite de bloquer sur la méthode get(). Pour cela, on peut utiliser le code suivant : Future<ITable> futuretable = tablemanager.getfuturetable(1); actions.. if( futuretable.isdone() ) { 19

//On sait que la table est disponible ITable table = futuretable.get(); } else { actions.. } 4.3.6 Binding Patterns Un binding pattern permet de faire la correspondance entre des attributs d'une table et des paramètres d'une méthode d'un service. Il permet également de savoir quel attribut correspond à un identifiant de service, et de connaitre la méthode à invoquer. L'appel de la méthode invoke() d'un binding pattern est asynchrone, cette méthode utilise donc également un objet Future<Tuple[]> pour effectuer la notification. On peut reprendre l'exemple du paragraphe 4.1 : Nom Adresse Service Message (v) Envoyé (v) Brice brice@insa-lyon.fr 1 * * Yann yann@insa-lyon.fr 1 * * Soit un binding pattern correspondant à la méthode Boolean envoyermessage(string adresse, String message). Si on souhaite invoquer ce binding pattern sur le premier tuple de la table, l'appel de la méthode invoke() sera le suivant : /* On possède un Tuple tuple correspondant à la ligne 1. * Ce tuple est complété en attribuant une valeur aux attributs virtuels * correspondant aux paramètres d'entrée de la méthode. * tuple = { "Brice", "brice@insa-lyon.fr", 1, "Ceci est un message" } */ Future<Tuple[]> futuretuples = bindingpattern.invoke(tuple); /* cela va invoquer la méthode du service possédant l'identifiant 1 * envoyermessage( "brice@insa-lyon.fr", "Ceci est un message") */ Tuple[] result = futuretuples.get(); result contiendra un seul Tuple, qui lui-même contiendra un seul élément booléen correspondant au résultat de l'invocation de la méthode envoyermessage(). 4.3.7 Gestionnaire de listes de services Le gestionnaire de listes de services est un composant du gestionnaire de tables. Il permet au moteur SoCQ ou au contrôleur de tables de créer des tables contenant des identifiants de services présents dans l'environnement. Il se charge également de maintenir à jour ces tables. Chaque table est associée à une SoCQServiceDescription (voir annexe 2) permettant de sélectionner les services en fonction des méthodes, flux et propriétés qu'ils possèdent. La table contient un tuple pour chaque service respectant ces critères. Les seuls attributs réels contenus dans ces tables sont les propriétés de la SoCQServiceDescription fournie. Les valeurs de ces attributs sont complétées avec la valeur de la propriété pour chaque 20

service. La table peut contenir d'autres attributs, mais ceux-ci doivent être virtuels car le gestionnaire de listes de services ne peut pas attribuer arbitrairement une valeur à ceux-ci. Une table créée par le gestionnaire de listes de services peut également posséder un ou plusieurs binding patterns. Par exemple, la table suivante contient des identifiants de service pour des capteurs de température, possédant les propriétés Localisation et Version. Un binding pattern correspondant à la méthode gettemperature() peut être associé à cette table, d'où la présence de l'attribut virtuel Température. 4.4 Contrôleur de tables ID Service Localisation Version Température (v) 1 Bureau 0.1 * 3 Bureau 0.1 * 4 Couloir 0.1 * Le contrôleur de tables fournit une interface graphique pour l'administration du catalogue du gestionnaire de tables. Il permet de visualiser la liste des tables (fig.15), de visualiser le contenu d'une table (fig.15 à 18) et de créer une table (fig.19 et 20). Fig.15 : Interface du contrôleur du gestionnaire de tables. Sur la figure 15, on observe sur la gauche la liste des tables présentes dans le catalogue du gestionnaire de tables. Leur nom et leur identifiant sont affichés. En sélectionnant une table, on peut visualiser son contenu. Ici il s'agit de la table surveillance. Fig.16 : Visualisation d'une table avec des attributs virtuels. La table Employee montrée sur la figure 16 possède deux attributs virtuels : l'attribut Message et l'attribut Sent. Cette table possède également un binding pattern, mais le contrôleur ne permet pas de le visualiser. 21

Fig.17 : Table associée à un gestionnaire de listes de services. La figure 7 montre la table TemperatureServices. Cette table est définie comme étant associée à la description du capteur de température du tableau section 3.3. Pour rappel : on cherche donc un service possédant la méthode gettemperature::r, le flux temperature::sr et les propriétés Location:s et Version:s. Au moment de la capture d'écran pour la figure 17, aucun service de capture de température n'est lancé. Fig.18 : Table associée à un gestionnaire de listes de services, services lancés. Deux services de captures de température sont lancés, et la table TemperatureServices est mise a jour par le gestionnaire de listes de services, avec les identifiants des services et les valeurs des propriétés présentes dans la description. Le contrôleur du gestionnaire de tables permet également de créer une table. Cette création de table fait appel à un parseur développé par ailleurs au sein du projet. Sur la figure 19, on va demander la création d'une table avec l'instruction suivante : CREATE RELATION marelation (unnom STRING, unchiffre INTEGER); Fig.19 : Création de table. On observe le résultat figure 20 : la table est créée. Fig.20 : Résultat de la création de table. Cependant, le contrôleur du gestionnaire de tables est encore à une phase préliminaire de développement. Par exemple, il ne permet pas encore d'invoquer des binding patterns, ou de mettre à jour des tuples dans une table. 22

4.5 Conclusion L'accès concurrent aux tables était la difficulté de cette partie. L'architecture du gestionnaire de tables a été en grande partie conçue autour de cet aspect. Une fois le fonctionnement du gestionnaire de table défini, le développement n'a pas présenté de difficultés particulières. La partie gestion des tables de ce projet représente un volume de 2163 lignes de code (36 classes Java) pour le gestionnaire de tables et son contrôleur. 23

5 Expérimentations Cette partie concerne l'exécution de la requête présentée dans le scénario de l'introduction : SELECT Area, Manager, Threshold, Temperature, Sent FROM Temperature T, Surveillance S, Employee E WHERE S.Manager = E.Name AND S.Area = T.Area AND S.Threshold < T.Temperature AND E.Message = S.AlertMessage Un prototype du moteur SoCQ a été développé au sein du projet SoCQ pour pouvoir exécuter cette requête. Le système comporte : - Le moteur SoCQ - Le gestionnaire de tables - Le contrôleur du gestionnaire de tables - Le gestionnaire de ressources global - Un gestionnaire de ressources local - Deux services de capture de température virtuels - Un service de messagerie - Les bundles OSGi nécessaires au fonctionnement du système : o La librairie smack [14] pour le service de messagerie o Le service UPnP de Felix Le serveur de messagerie Jabber [15] est installé sur une autre machine du réseau local. Tous ces éléments sont présents sous forme de bundle OSGi. Pour cette expérimentation, ceux-ci sont installés sur le même framework. Les tables suivantes sont créées lors d'une phase d'initialisation : - MessageServices Cette table utilise un gestionnaire de listes de services pour récupérer l'identifiant de service correspondant à un service de messagerie. - TemperatureServices De même, cette table utilise un gestionnaire de liste de services pour récupérer les identifiants de services correspondant aux services de capture de température. 24

- Employee Cette table est créée statiquement, puis complétée par une requête SoCQ annexe qui récupère dynamiquement l'identifiant de service contenu dans la table MessageServices. Un binding pattern correspondant à la méthode envoyermessage est associé à cette table. - Surveillance Cette table est créée et complétée de manière statique. - Temperature Cette table est crée de manière statique. Elle est initialement vide mais par un opérateur SoCQ spécifique, on y associe les flux de température des services inscrits dans la table TemperatureServices. Après quelques secondes d'exécution, la table possède les tuples suivants : Les capteurs de température sont des capteurs virtuels. On peut choisir la température courante grâce à un curseur. L'interface est présentée figure 21. Fig.21 : Interface d'un capteur de température virtuel. 25

Lorsqu'on augmente la température du capteur virtuel associé à la localisation Toit, on obtient la table suivante : La température dépassant le seuil défini dans la table Surveillance (27 C), la requête commande l'execution du binding pattern de la table Employee avec le message correspondant de la table surveillance. La figure 22 présente le résultat de cette exécution. Fig.22 : Résultat de l'invocation du binding pattern. Le résultat de la requête est enregistré dans une table Results. Après avoir également augmenté la température virtuelle du bureau on obtient le résultat présenté figure 23 : 26

Fig.23 : résultat de la requête. Cette expérimentation permet de vérifier le bon fonctionnement du système dans son ensemble car elle fait appel à quasiment toutes les fonctionnalités du gestionnaire de tables ainsi que des gestionnaires de ressources. 27