Systèmes d’information pervasifs Unité d’enseignement de base Frédérique Laforest

Qui suis-je? Frédérique Laforest Maître de conférences INSA de Lyon frederique.laforest@insa-lyon.fr http://liris.cnrs.fr/frederique.laforest Maître de conférences INSA de Lyon Recherche au LIRIS axe systèmes d’informations communicants, équipe Systèmes d’information pervasifs Mots-clés Systèmes pervasifs Adaptation et context-awareness Interfaces utilisateurs Enseignement au département Télécommunications modélisation objet, java, web, bases de données, systèmes pervasifs

Plan Introduction Architectures des systèmes d’information distribués et pervasifs Trois niveaux de recherche en systèmes pervasifs matériel et système réseau système d’information découverte de services gestion de données context-awareness adaptation des données, des interfaces utilisateurs et des services Exemples de projets pervasifs Conclusion Introduction –1h def SI- définir et différencier SI dist, SI pervasif, SI ambiant Architectures des systèmes d’information distribués et pervasifs –1h ancetres, n-tier, grille, P2P pur, P2P hybride Trois niveaux de recherche en systèmes pervasifs – 6h (1h N1 & N2 + 5h N3 & liaison) N1-Système et matériel => optimisation accus, capteurs, smart tools N2-Réseau => routage, découverte N3-Application=> « tuyauterie », adaptation des applications, méthodologies service discovery, QoS, Caches et proxies Déploiement adaptatif (self adaptive application or deployment) cf SAACS workshop dans DEXA 04 Gestion de la déconnexion Plates-formes ouvertes, Architectures à base de composants, web services, XML, Agents mobiles Sécurité?? Méthodes d’analyse, conception et développement => user-centered req, DP, approches incrémentales Context-awareness, context prediction => Dey & co. + Location based services User interface adaptation, Content adaptation, services adaptation 4- difficulté de liaison entre les niveaux Exemple – 2h moins ¼ h Conclusion, perspectives et biblio 1/4h

I-Introduction Introduction

Système d’information I-Introduction Système d’information Objectif Production, collection, traitement, enregistrement et diffusion de l’information Composantes Utilisateurs et administrateurs Logiciels Machines et matériels Réseaux

Exemple de système d’information I-Introduction Exemple de système d’information Suivi de patients hospitalisés à domicile Utilisateurs et administrateurs patients, médecins de ville, infirmières, praticiens hospitaliers, pharmacien, association de suivi Logiciels dossier patient électronique, workflow, rendez-vous, imagerie, mailing, saisie de données au domicile, télésurveillance… Machines et matériels matériel médical chez le patient (dialyseur, thermomètre électronique), matériel à l’hôpital (radiologie, chimiothérapie…), terminal patient, terminaux des acteurs de santé mobiles ou fixes Réseaux Liaison réseau privé de l’hôpital, association de suivi, domicile…

Une nouvelle vision de l’informatique I-Introduction Une nouvelle vision de l’informatique Environnement informatique Avant : environnement virtuel dans lequel nous entrons pour effectuer une tâche et dont nous sortons à la fin de la tâche Aujourd’hui : espace physique amélioré de gestion de l’information Application Avant : logiciel pour exploiter un matériel Aujourd’hui : moyen pour l’utilisateur d’effectuer une tâche

I-Introduction © F. Mattern

Les ordinateurs d’hier remplissaient les pièces I-Introduction Les ordinateurs d’hier remplissaient les pièces © F. Mattern

I-Introduction Ceux de demain aussi!! © F. Mattern

Aujourd’hui, l’Internet connecte tous les ordinateurs I-Introduction Motivation Aujourd’hui, l’Internet connecte tous les ordinateurs Demain, tout objet sera « intelligent » (smart) Processeurs embarqués Et ils seront tous interconnectés Communication sans fil

L’informatique embarquée pour la coopération I-Introduction L’informatique embarquée pour la coopération Tout objet du monde réel sera enrichi de capacités de traitement de l’information Processeurs embarqués Dans chaque objet quotidien Petit, bon marché, léger Communications sans fil Réseaux spontanés Capteurs

Les objets intelligents I-Introduction Les objets intelligents Peuvent se souvenir des événements importants Mémoire Présentent un comportement dépendant du contexte Capteurs Ils sont interactifs Communiquent avec leur environnement En réseau avec les autres objets intelligents

Ces objets sont-ils vraiment smart?? I-Introduction Ces objets sont-ils vraiment smart?? Hug = étreindre, embrasser © F. Mattern

Systèmes d’information pervasifs – la genèse I-Introduction Systèmes d’information pervasifs – la genèse « Calm technology » [Mark Weiser, 1991] « A new way of thinking about computers in the world, one that takes into account the natural human environment and allows the computers themselves to vanish in the background » « The most profound technologies are those that disappear. They weave themselves into the fabric of everyday life until they are indistinguishable from it »

Systèmes d’information pervasifs – la référence I-Introduction Systèmes d’information pervasifs – la référence [M. Satyanarayanan, 2001] Étape suivante, après systèmes distribués et systèmes mobiles 4 challenges Utilisation effective des espaces intelligents (smart spaces) Invisibilité Scalabilité Transparence des inégalités d’environnements Pervasive computing environment = « one saturated with computing and communication capability, yet so gracefully integrated with users that it becomes ‘a technology that disappears’ »

Définitions Ubiquitaire Mobile Context-aware Pervasif Ambiant I-Introduction Définitions Ubiquitaire Accessible de n’importe où Mobile Qui intègre les terminaux mobiles Context-aware Qui prend en compte le contexte d’exécution Pervasif Qui associe ubiquité, mobilité et context-awareness Ambiant Qui est intégré dans les objets quotidiens

Vue « système » d’un système pervasif I-Introduction Vue « système » d’un système pervasif Adapté de [Saha & Mukherjee, 2003] Système pervasif Gestion de l’ubiquité Système mobile Système distribué Gestion de la mobilité Gestion du contexte

Devoirs des SI distribués I-Introduction Devoirs des SI distribués Persistance des données Échange de données entre applications hétérogènes Répartition des données sur des sites distants Gestion de la cohérence permanente des données Interopérabilité des plates-formes Portabilité des applications Gestion des accès concurrents Intégration des systèmes legacy Ouverture Sécurité © S. Frénot

Devoir des SI pervasifs I-Introduction Devoir des SI pervasifs Ceux des SI distribués ET Scalabilité Invisibilité Context-awareness Intelligence (« smartness ») Pro-action « all the time everywhere »

Gérer des volumes de plus en plus grands de I-Introduction Scalabilité Passage à l’échelle Gérer des volumes de plus en plus grands de utilisateurs applications appareils connectés Développer des applications dont le cœur est indépendant du volume, des utilisateurs et des appareils Utiliser des techniques d’adaptation pour pouvoir répondre à chaque cas

Nécessiter un minimum d’intervention humaine I-Introduction Invisibilité Nécessiter un minimum d’intervention humaine S’adapter seul aux changements Auto-apprentissage Par exemple, reconfiguration dynamique des caractéristiques réseau d’un appareil Accès aux ressources d’un « espace » en fonction de l’appartenance à la zone géographique de cet espace. Sortie de l’espace = définition des limites de l’espace!

Capteurs de l’environnement physique Matériels auto-descriptifs I-Introduction Context-awareness Perception de l’environnement pour interagir plus « naturellement » avec l’utilisateur Capteurs de l’environnement physique Matériels auto-descriptifs Description des personnes Méta-données sur les applications

Smart = intelligent, à l’esprit vif, malin, débrouillard I-Introduction « Smartness » Smart = intelligent, à l’esprit vif, malin, débrouillard Percevoir le contexte d’exécution ne suffit pas Il faut utiliser efficacement les informations du contexte Exemple : maison intelligente

Attention à balancer avec l’invisibilité! Sous-entend de savoir I-Introduction Pro-action Suggérer, proposer des actions correctives à l’utilisateur en fonction du contexte présent ou prédit Par exemple se déplacer de 100 mètres pour atteindre un réseau plus performant et ainsi accomplir une tâche dans un temps « correct » Attention à balancer avec l’invisibilité! Sous-entend de savoir Prévoir un événement, une situation, Évaluer une situation courante ou possible, Comparer deux situations et juger de la meilleure Que « ça vaut le coup » de transgresser l’invisibilité

References bibliographiques Introduction I-Introduction References bibliographiques Introduction M. Weiser « The computer for the twenty-first century », Scientific American, sept 1991:94-104 M. Satyanarayanan « Pervasive computing : Visions and challenges », IEEE Personal Communications, aug. 2001:10-17 D. Saha & A. Mukherjee « Pervasive computing : a paradigm for the 21st century », IEEE Computer journal, march 2003:25-31 F. Mattern. « Ubiquitous & Pervasive Computing: A Technology-driven Motivation », Summer school on ubiquitous and pervasive computing, 2002 S. Frénot « Cours Middleware », Dpt Télécommunications, INSA de Lyon, 2004

Architecture des systèmes d’information distribués et pervasifs II-Architecture Architecture des systèmes d’information distribués et pervasifs 1- ancêtres 2- middleware 3- systèmes mobiles 4- grilles de calcul 5- peer-to-peer Nos remerciements à Stéphane Frénot pour ses précieux transparents!

A démocratisé l’informatique II-1 Ancêtres Les ancêtres : le PC A démocratisé l’informatique A permis une croissance gigantesque en matière de composants matériels A permis le développement des interfaces utilisateurs graphiques N’a pas fourni le potentiel attendu en matière de traitement de l’information

A créé une culture qui a permis d’imaginer les systèmes pervasifs II-1 Ancêtres Les ancêtres : le Web Pionnier d’infrastructure de communication et d’information ubiquitaire A l’origine, n’a pas été pensé comme une infrastructure pour systèmes distribués A créé une culture qui a permis d’imaginer les systèmes pervasifs

Les ancêtres : le Client/Serveur II-1 Ancêtres Les ancêtres : le Client/Serveur C/S de présentation Client : gestion de la présentation Serveur : réalisation de l'ensemble des traitements C/S de traitement C : Gestion de la présentation + traitements applicatifs S : Gestion de l'accès aux BD C/S multi-tiers C : Gestion de la présentation Serveur applicatif : Connaissance des traitements métiers Serveur de données : gestion des accès aux BD X11 Procédures Stockées / Forms © S. Frénot

Client-serveur de présentation II-1 Ancêtres Client-serveur de présentation Déporter l'affichage sur un réseau telnet Xwindows NTTerminal Serveur Le développement est « presque » centralisé Architecture dénommée « client léger » Avantages : Déploiement facile Maintenance facile Client à faibles ressources Inconvénients Goulot d’étranglement serveur Sous-exploitation du client IHM IHM T D

Client-serveur de traitement II-1 Ancêtres Client-serveur de traitement Le poste de travail héberge l’ensemble de la gestion d’interface homme-machine et le traitement, Le serveur est un serveur de base de données Architecture dénommée « client obèse » Avantage : Mise en œuvre efficace pour un nombre réduit de clients Inconvénients Coûts de déploiement ? Coûts de MAJ ? Accès concurrents ? Hétérogénéité sur BD ? IHM T D © S. Frénot

Client-serveur 3 niveaux (3-tier) II-1 Ancêtres Client-serveur 3 niveaux (3-tier) Le poste de travail héberge la gestion de l’interface homme-machine et une partie des traitements, Le serveur d’applications gère l’autre partie des traitements Le serveur de données gère les accès aux données Architecture dénommée « traitements coopératifs » IHM T D © S. Frénot

Client-serveur 4 ou n niveaux (4-tier, n-tier) II-1 Ancêtres Client-serveur 4 ou n niveaux (4-tier, n-tier) Le poste de travail héberge un navigateur standard, Le serveur (HTTP) gère la partie présentation de l’interface homme-machine Le serveur d’applications gère les traitements Le serveur de données gère les accès aux données Architecture de collaboration IHM-D T D IHM-P IHM-D = client Web, Firefox IHM-P = serveur Web, Apache Tomcat, JSP T = Apache Tomcat Php D = SGBD, Mysql © S. Frénot

Le Client / Serveur Avantages Inconvénients II-1 Ancêtres Le Client / Serveur Avantages Première infrastructure informatique pour un travail coopératif Centralisation des traitements au niveau du serveur Pas de duplication des données (état global observable, gestion plus simple de la cohérence et de l'intégrité des données) Maîtrise globale des processus Inconvénients Relation directe C/S Pas de transparence sur la localisation Augmentation de l'hétérogénéité Modèle rigide ! Ni portable ni inter-opérable © S. Frénot

Client-serveur : la distribution à "l'ancienne" II-1 Ancêtres Client-serveur : la distribution à "l'ancienne" App BD Principale Proxy Client BD de copie Service A App LAMP=Linux Apache Mysql Php Service B Exemple : application Web Mozilla + Squid + Apache + PHP/Perl/Python + MySQL (Architecture « LAMP ») © S. Frénot

Client-serveur : la distribution à "l'ancienne" II-1 Ancêtres Client-serveur : la distribution à "l'ancienne" Elle nécessite des compétences humaines précises Systèmes propriétaires Gestion de transactions Définition de queues de messages Réplication et Synchronisation de BD Gestion des pannes Sécurité des communications Développement de clients Elle pose des problèmes techniques Nécessite de nombreux serveurs pour l'équilibrage de charge Nécessite une programmation complexe pour pouvoir évoluer © S. Frénot

Du C/S au middleware explicite II-2 Middleware Du C/S au middleware explicite C/S Le client et le serveur sont développés en collaboration Objet distant Client et serveur sont liés par une interface La couche réseau est masquée au client et au serveur ==> Notion de code applicatif/code non applicatif © S. Frénot

Middleware : architectures II-2 Middleware Middleware : architectures Environnements et plates-formes d’exécution pour développer des services métiers Architecture middleware à objets distribués Services d’infrastructure Serveur middleware de composants de base Services standardisés d’infrastructure Serveur middleware de composants intégrés Infrastructure de gestion des composants

Middleware : architecture générale Services métier : Code applicatif Composants, services Application 1 Middleware : Code non applicatif Application 2

Architectures middleware à objets distribués II-2 Middleware Architectures middleware à objets distribués Services Métiers Application 1 MiddleWare Application 2 Services d'infrastructure Exemples : DCOM, CORBA © S. Frénot

Architectures middleware à objets distribués Services métier objets distribués sur différents serveurs API des objets conforme à un standard Rôle du middleware Services d’infrastructure Transparence de la localisation, de l’hétérogénéité (langages, OS, machine), de la couche transport réseau

DCOM (Microsoft) Distributed Component Object Model II-2 Middleware DCOM (Microsoft) Distributed Component Object Model Spécifications des interfaces au niveau binaire Indépendance / Langage de programmation : Assembleur, C, C++, Pascal, Visual Basic, Visual J++ Interfaces et composants ont un identifiant unique GUID (Globally Unique Identifier) Interface non modifiable, à refaire RPC (Remote Procedure Call) Multithread Appels synchrones, asynchrones, concurrence, interblocage Sécurisé Droits utilisateurs Durée de vie des objets Références sur un objet

CORBA (OMG) Common Object Request Broker Architecture II-2 Middleware CORBA (OMG) Common Object Request Broker Architecture IDL (Interface Definition Language) Indépendance / Langage de programmation. Mappé sur C, C++, Java, COBOL, Smalltalk, Ada, Lisp, Python et IDLscript. ORB (Object Request Broker) Bus de communication IIOP (Internet Interoperable Protocol) Naming Service, Trader Service, etc. http://www2.lifl.fr/~merle/corba/cours/ IIOP Impléms : Orbix, Visibroker, JBroker, Voyager ORB, etc.

II-2 Middleware .NET (Microsoft) Plateforme de développement, de déploiement, d’exécution API : .NET Framework Assembly, WebServices Indépendance / Langage : beaucoup ! Common Language Infrastructure (CLI) Common Intermediate Language (CIL) : Microsoft Intermediate Language (MSIL) Common Language Runtime (CLR) SOAP (HTTP, XML/RPC), DCOM Active Server Pages (ASP.NET), ActiveX Data Objects (ADO) Impléms : MS .net, Mono, DotGNU Assembly = bibliothèque de services semi-compilés

Serveur middleware de composants de base II-2 Middleware Serveur middleware de composants de base Services Métiers Application 1 Services standards d'infrastructure jts cycle vie Application 2 Jts = transaction service Les services métier doivent faire des appels explicites aux services d’infrastructure standardisés jdbc version Exemple : OrbixWeb © S. Frénot

Serveur middleware de composants intégré II-2 Middleware Serveur middleware de composants intégré Composants Métiers Application 1 Logique métier container infrastructure Gestion automatisée Services d'infrastructure de base Application 2 Aucun appel explicite aux services d’infrastructure dans les services métier. C’est le descripteur de chaque service (fichier externe) qui permet au Middleware de mettre en place les appels aux services d’infrastructure jdbc jts version cycle vie Exemples : Tomcat (J2EE), Felix (OSGi) © S. Frénot

Services du container d'objets métiers II-2 Middleware Services du container d'objets métiers Services internes Gestion de la charge du serveur (cycle de vie, accès client, passivation...) Service de nommage Gestion des accès aux objets métiers Services externes Gestion du mapping sur BD relationnelle Gestion des transactions Gestion des échanges de messages Fin séance 1 © S. Frénot

J2EE (Sun) Java 2 Platform, Enterprise Edition II-2 Middleware J2EE (Sun) Java 2 Platform, Enterprise Edition Multi-tier, multi-architecture plateforme API Java Composants et conteneurs : Enterprise Java Beans (EJB) (javax.ejb.*), Servlets (javax.servlet), WebServices Publications : JavaServer Pages (JSP) (javax.servlet.jsp), Java Naming and Directory Interface (JNDI) (javax.naming) Base de données et transactions : Java Database Connectivity (JDBC) (java.sql, javax.sql), Java Transaction API (JTA) (java.transaction.*), etc. RMI (Remote Method Invocation), RPC, CORBA Nombreux serveurs d’applications : JBoss, JRun, JOnAS, Weblogic, Websphere, Java System Application Server, etc. http://java.sun.com/j2ee/compatibility.html

Open Services Gateway Initiative (anciennement) II-2 Middleware OSGi (OSGi Alliance) Open Services Gateway Initiative (anciennement) Plateforme de développement, de déploiement, d’exécution API Java : bundle Environnement d’exécution (JVM), Modules, Gestion du cycle de vie, Service d’annuaire Différents niveaux d’exécution Services standardisés Niveau système : Log Service, Configuration Admin Service, Device Access Service, User Admin Service, IO Connector Service, etc. Niveau protocole : HTTP Service, UPnP Service, Jini Service, etc. Impléms : oscar, Knopflerfish, felix…

Conclusion Middleware II-2 Middleware Conclusion Middleware Avantages Interopérabilité API de développement Implantation de services standardisés Transparence, extensibilité Modifications au niveau middleware sans modification de l ’application Inconvénients Performance Un niveau de redirection en plus Difficile à évaluer Maintenance Sécurité Suivi continuel du middleware en plus de l’appli

Essor des ordinateurs portables et des réseaux sans fil II-3 Mobiles Systèmes mobiles Début des années 90 Essor des ordinateurs portables et des réseaux sans fil Assistant personnel (Personal Digital Assistant) (Palm, Pocket PC), ordinateur de poche (Handheld Computer) (Psion), ordinateur portable (Notebook, Laptops) Réseau à point d’accès (GSM, GPRS, WiFi : 802.11a/b/g/n), réseau non centralisé, ad hoc (MANET: Mobile Ad-hoc Networks), (IRDa, Bluetooth) Mobilité → non permanence du terminal portable ou de la connexion réseau Diapos 1 à 10 http://adapt.asr.cnrs.fr/reunions/20061003/slides/guidec.pdf The purpose of the MANET working group is to standardize IP routing protocol functionality suitable for wireless routing application within both static and dynamic topologies with increased dynamics due to node motion or other factors.

Systèmes mobiles Avantages Inconvénients II-3 Mobiles Systèmes mobiles Avantages « Everything, every time, everywhere » Services, données tout le temps disponibles avec soi Inconvénients Contraintes physiques Variations impromptues de la qualité du réseau Déconnexions Faibles confiance et robustesse des éléments mobiles Limitations des ressources locales (poids, taille => écran) Autonomie (batterie) Contraintes environnementales Disponibilité d’une connexion réseau

Résultats actuels → Domaine de recherche actif → Systèmes pervasifs II-3 Mobiles Systèmes mobiles Résultats actuels → Domaine de recherche actif → Systèmes pervasifs Techniques d’économie d’énergie (gestion de mémoire, rapidité processeur… en fonction de l’énergie disponible) Accès aux informations (opérations déconnectées, contrôle de la cohérence des données…) Support d’applications adaptatives (proxies, gestion adaptative des ressources système) Calcul et gestion de la localisation Systèmes d’information Wap et imode (C/S et téléchargement)

Systèmes mobiles précurseurs : Coda II-3 Mobiles Systèmes mobiles précurseurs : Coda Système de fichier Hoarding (fortement connecté) Chargement Préchargement Emulating (déconnecté) Travail en local Historique Write disconnected (faiblement connecté) Réintégration

Systèmes mobiles précurseurs : Odyssey II-3 Mobiles Systèmes mobiles précurseurs : Odyssey Accès données depuis mobile Politiques de négociation qualité/données selon les ressources Fidélité / données originales Agilité / capacité à changer Viceroy – A type independent component, responsible for centralized resource management • Warden – A warden encapsulates system level support for a client – To support a new data type, an appropriate warden has to be written and incorporated into Odyssey at each client Data-centric Adaptation – Between viceroy and wardens – It defines the fidelity levels for each data type and factors them into resource management • Action-centric – Between applications and Odyssey – It provides applications with control over the selection of fidelity levels supported by the wardens Applications communicate resource expectations (window) to Odyssey using the request system call • If availability of resource is within window the viceroy registers it and returns a unique identifier (handler) for it, else an error is returned with the available resource level to the application. an upcall to the application is generated by the viceroy when resource availability strays outside a registered window of tolerance. – Upon receiving the upcall, the application adjusts the fidelity according to its policies, and issues another request call with the revised window.

II-4 Grilles Grilles de calcul Système distribué qui permet le partage, la sélection et l’agrégation de ressources géographiquement distribuées pour la résolution de problèmes à grande échelle Système distribué = ensemble de machines (eg. Grid5000 en France=5000 CPU hétérogènes sur 9 sites)

Grilles de calcul Avantages Passage à l’échelle II-4 Grilles Grilles de calcul Avantages Passage à l’échelle Résolution de problèmes complexes (en terme de calcul, comme le décryptage de clef à X-bits, etc.) Mise à profit de toutes les ressources selon disponibilité: Ordinateurs : PC, clusters, (éléments mobiles)… Logiciels Données et bases de données Matériels spécifiques Tolérance aux fautes

Grilles de calcul Inconvénients II-4 Grilles Grilles de calcul Inconvénients Logiciels, middlewares, systèmes, standards en plein évolution Interactions difficiles entre systèmes de grille différents Applications statiques Précompilées pour un système de grille donné Non-interactives Grille pervasive : grille intégrant des terminaux mobiles et donc toutes les problématiques des systèmes pervasifs. Les terminaux mobiles pouvant être vus comme de simples clients ou comme des nœuds à part entière de la grille. pour en savoir plus : cours de recherche Grilles de données

Seti@Home : Search for Extraterrestrial Intelligence II-4 Grilles Seti@Home : Search for Extraterrestrial Intelligence University of California at Berkeley Application de traitement de données radiotéléscopiques 40G / jour Recherche de fluctuations des signaux Client : Économiseur d’écran pré compilé pour système donné http://setiathome.ssl.berkeley.edu/ Voir aussi d’autres applications : Genome@Home, distributed.net (cryptage), etc.

Globus toolkit The Globus Alliance Middleware pour la grille II-4 Grilles Globus toolkit The Globus Alliance Middleware pour la grille Basic Grid Services Implementation Web Grid Services Core (Java et C/C++) API de développement http://www.globus.org Voir aussi d’autres middlewares : JXTA, Legion, etc. http://www.gridcomputing.com/

Peer-to-peer Peer = « partenaire » II-4 P2P Peer-to-peer Peer = « partenaire » “…an entity with capabilities similar to other entities in the system.” Les applications sont réparties sur l’ensemble des peers Pas de machine « maître », pas de serveur central Client/serveur vs. Peer-to-peer Client / Serveur Certains éléments sont fournisseurs de services (serveurs) D’autres sont consommateurs (clients) Peer-to-peer Chaque élément est à la fois client et serveur

Architecture peer-to-peer II-4 P2P Architecture peer-to-peer Les ressources d’un peer sont similaires à celles des autres participants Les peers communiquent directement les uns avec les autres et partagent des ressources

Challenges Peer to Peer II-4 P2P Challenges Peer to Peer Découverte de peers et gestion de groupes Localisation et positionnement des ressources Temps de recherche d’une ressource Etat de chaque noeud Utilisation de la bande passante Sécurité, fiabilité Tolérance aux fautes Relever des infos sur chacun des elements!!!

P2P Centralisé, pseudo-P2P II-4 P2P P2P Centralisé, pseudo-P2P Passage obligé par un point central Intérêts Recherche efficace Bande passante utile faible Inconvénients point central pro- blématique Convient à faible échelle seulement Bob Alice benefits/drawbacks Judy Jane

Une demande est envoyée dans toutes les directions II-4 P2P Flooding P2P Bob Alice Jane Judy Carl Une demande est envoyée dans toutes les directions Intérêts Pas de point central Inconvénients Recherches lentes Utilisation intensive de la bande passante

Le peer demandeur prévoit le routage pour atteindre le peer cible II-4 P2P Document Routing P2P Le peer demandeur prévoit le routage pour atteindre le peer cible il a donc une connaissance de la topologie du réseau Intérêts Bande passante utile faible Inconvénients Tolérance aux fautes limitée => redondance 001 012 212 305 332 212 ?

Taxonomie d’applications P2P II-4 P2P Taxonomie d’applications P2P Systèmes P2P Calcul distribué BOINC Partage de fichiers Gnutella Collaboration Jabber Plates-formes JXTA

BOINC – grille ou pseudo-P2P?? II-4 P2P BOINC – grille ou pseudo-P2P?? Berkeley Open Infrastructure for Network Computing plate-forme logicielle pour le calcul distribué utilisant les ressources matérielles de volontaires pour des applications dont la tâche peut être décomposée en étapes indépendantes, et dont le temps de calcul local reste important par rapport au transfert des données locales sur Internet exemples : SETI@home, climateprediction.net… chaque projet a un ou n serveurs chaque volontaire installe un client, et s’abonne à 1 ou n projets. Il définit les ressources associées à chaque projet de nombreuses problématiques similaires aux réseaux mobiles : inclusion/exclusion de volontaires, déconnexions, faible puissance des clients… http://boinc.berkeley.edu/

Gnutella Partage de fichiers en P2P II-4 P2P Gnutella Partage de fichiers en P2P Installation d’un logiciel dit « client » qui sert à la fois de serveur et de client. Choix de la partie du disque local qui sera partagée sur le réseau Recherche d’une ressource par son nom en local demandée à un noeud connu s’il ne la connaît pas, le nœud la propage à 4 « alliés » etc… jusqu’à 7 hops max. le nœud qui a la ressource la retourne à l’appelant et fait désormais partie des nœuds connus par l’appelant http://www.gnutella.com/

Jabber Face émergée de l’iceberg II-4 P2P Jabber Face émergée de l’iceberg alternative Linux de messagerie instantanée comme ICQ Face immergée : protocoles de streaming fondés sur XML permet à 2 entités sur Internet d’échanger des messages et toute sorte d’information structurée en temps presque réel. Standard (Internet Engineering Task Force IETF) Décentralisé : toute machine peut être serveur et/ou client Sécurisé avec SASL et TLS Ouvert, extensible grâce à XML Flexible : outils de collaboration, syndication de contenu, partage de fichiers, gestion de systèmes à distance… http://www.jabber.com

JXTA standardise la façon dont les peers II-4 P2P JXTA (juxtapose) Ensemble de protocoles permettant à tout type de terminal de participer à un réseau P2P fournit aussi une implantation ouverte JXTA standardise la façon dont les peers se découvrent les uns les autres s’organisent en groupes communiquent entre eux de façon sécurisée annoncent et découvrent des services se supervisent http://www.jxta.org

Synthèse : framework de système pervasif II-Architecture Synthèse : framework de système pervasif 4 clés: dispositifs, réseau, middleware, applications [Saha Mukherjee 2003] « pervasive computing framework. Middleware mediates interactions with the networking kernel on the user’s behalf and keeps users immersed in the pervasive computing space » on the user’s behalf = « pour le compte de l ’utilisateur »

Références bibliographiques architecture II Architecture Références bibliographiques architecture S. Frénot « Cours Middleware », Dpt Télécommunications, INSA de Lyon, 2004 G. Gardarin et O. Gardarin « le client-serveur », Eyrolles, 1996 E. Aarts & S. Marzano « The new everyday. Views on ambiant intelligence ». Koninklijke Philips Electronics N.V., 010 publishers, Rotterdam D. Saha & A. Mukherjee. « Pervasive computing: a paradigm for the 21st century » IEEE Computer journal, march 2003:25-31 B. Yang & H. Garcia-Molina « Comparing Hybrid Peer-to-peer systems » 27th VLDB Conference, Roma, Italy, 2001 L. B. Mummert, M. Ebling et M. Satyanaranan «  Exploiting Weak Connectivity for Mobile File Access » , Proceedings of the 15th ACM Symposium on Operating System Principles (SOSP'95), p. 143155, Copper Mountain Resort, Colorado, USA, décembre 1995 B. Noble, M. Satyanaranan , J. E. Tilton, J. Flinn et K. R. Walker, « Agile Application-Aware Adaptation for Mobility » , Proceedings of the 16th ACM Symposium on Operating Systems Principles (SOSP'16), Saint-Malo, France, octobre 1997

Trois niveaux de recherche en systèmes pervasifs III-Niveaux Trois niveaux de recherche en systèmes pervasifs 1- niveau matériel et système (survol) 2- niveau réseau (survol) 3- niveau système d’information 4- synthèse : relations entre les niveaux

Niveau matériel et système (survol) III-1 Matériel et système Niveau matériel et système (survol) Limitations des ressources disponibles sur les terminaux légers Critères primordiaux : poids et taille des terminaux Contraintes sur tous les composants matériels Le plus limitant : l’énergie (batteries) Juste après : gestion de la chaleur Ces contraintes ont des répercussions sur Le système d’exploitation Les logiciels (voir niveau système d’information)

Évolution des capacités matérielles III-1 Matériel et système Évolution des capacités matérielles © T. Starner, 2002

Recherches au niveau matériel et système III-1 Matériel et système Recherches au niveau matériel et système Exemples pour la gestion de l’énergie Adaptation dépendante de l’énergie Ordonnancement du processeur à vitesse variable Gestion mémoire dépendante de l’énergie Energies alternatives (Kymissis98 ISWC “Parasitic Power Harvesting in Shoes”)

Les technologies de capteurs existent depuis longtemps, mais III-1 Matériel et système Capteurs Les technologies de capteurs existent depuis longtemps, mais Capteurs sans intelligence ni stockage Capteurs avec transmission filaire “locale” des données brutes capturées Travaux actuels Capteurs intelligents : processeurs intégrés pour le traitement local des données produites Capteurs communicants : intégration de composants de communication RF ou autre => réseaux de capteurs sans fil (wireless sensor networks)

Réseaux de capteurs sans fil III-1 Matériel et système Réseaux de capteurs sans fil Collaboration d’un grand nombre de nœuds dans un réseau dense chaque nœud a des capacités de traitement local et des capacités de communication Exemples de domaines d’application militaire : gestion des forces armées, surveillance de champs de bataille, reconnaissance de terrain, ciblage, évaluation des dommages, détection et reconnaissance d’attaques chimiques, biologiques... environnement : détection de feux de forêts, cartographie de biodiversité, détection de crues, impact des pesticides… santé : telemonitoring, localisation... autres : domotique , musées interactifs, vols de voitures...

Réseaux de capteurs sans fil (2) III-1 Matériel et système Réseaux de capteurs sans fil (2) Caractérisation, différenciation vs réseau ad hoc nombre de nœuds bien plus grand que dans un réseau ad hoc « classique » déploiement dense capteurs peu fiables fréquents changements dans la topologie du réseau On parle de capteurs agiles (à déplacements discrets) communications broadcast (vs. point à point) goulot d’étranglement = énergie consommée (vs.QoS)

exemple d’utilisation : III-1 Matériel et système The MediaCup project Une tasse de café augmentée de capacités de capture (température, mouvement), traitement et communication, et avec un ID réseau IrDA exemple d’utilisation : la smartDoorPlate indique les personnes présentes la HotClock indique la température et sonne si le café est trop chaud http://mediacup.teco.edu mediaCup smartDoorPlate hotClock

Une société commercialise le produit depuis 2002 III-1 Matériel et système SmartDust Micro-machines avec réseau sans fil et capteur (température, lumière...) . S’organisent automatiquement en réseau lorsque proches les unes des autres TinyOS : système d’exploitation open-source conçu pour les réseaux de capteurs sans fil Une société commercialise le produit depuis 2002 http://robotics.eecs.berkeley.edu/ ~pister/SmartDust/ Prototype de 2001

References bibliographiques matériel et système III-1 Matériel et système References bibliographiques matériel et système G.J. Pottie. Wireless Sensor Networks ITW 1998, Killamey, Ireland, june 98. p 139-140 S. Meyer & A. Rakotonirainy. A survey of research on context-aware homes. Workshop on Wearable, inisible, context-aware, ambiant, pervasive and ubiquitous computing. Feb 2003, Adelaide, Australia. 10 p. D. Estrin, L. Girod, G. Pottie, M. Srivastava. Instrumenting the world with wireless sensor networks. Int. Conf. Acoustics, speech and signal processing. May 2001. Autonomous Networks Research Group. A Wireless Sensor Networks Bibliography http://ceng.usc.edu/~anrg/SensorNetBib.html T. Starner « Power and heat in ubiquitous computing », Summer school on ubiquitous and pervasive computing, 2002 I.F. Akyildiz et al. Wireless sensor networks : a survey. Computer networks 38 (2002) 393-422 http://nanotechn-now.com/smartdust.htm

Niveau réseau (survol) III-2 Réseau Niveau réseau (survol) Organisation des nœuds du réseau Réseaux ad hoc mobiles Routage Routage proactif Routage réactif Multicast dans des réseaux mobiles

Nœud entrant = broadcast sur son rayon d’action III-2 Réseau Réseaux ad hoc mobiles Pour former rapidement et simplement des liaisons entre appareils mobiles sans l’intermédiaire de structures fixes Gestion du réseau répartie Réseaux dynamiques (un nœud peut le rejoindre ou le quitter à tout moment) sans erreurs ou dysfonctionnements Nœud entrant = broadcast sur son rayon d’action Communication avec un autre nœud Si dans le rayon d’action, comm directe (single-hop) Sinon, routage (multi-hop)

Exemples illustratifs III-2 Réseau Exemples illustratifs Broadcast à l’entrée dans le réseau Communication single-hop Communication multi-hop

Routage Routage proactif Routage réactif Routage hybride III-2 Réseau Routage Routage proactif Apprend continuellement la cartographie du réseau en échangeant des informations sur la topologie Gourmand en bande passante Routage réactif Route calculée sur besoin par inondation de requêtes de chemins – choix de la route optimale parmi les réponses obtenues Cache contenant les routes les plus récentes Pb si réseau chargé Routage hybride proactif en local et réactif à distance

Pour atteindre plusieurs cibles en même temps III-2 Réseau Cas du multicast Pour atteindre plusieurs cibles en même temps Exemple : téléconférence à plus de 2 Pb : pas de routeurs => les nœuds sont routeurs

TMTP (tree-based multicast transport protocol) III-2 Réseau TMTP (tree-based multicast transport protocol) Découpage topologique du réseau en domaines Un nœud par domaine se déclare gestionnaire de domaine (il crée le domaine – et le détruit lorsqu’il quitte le réseau) Les nœuds les plus proches intègrent son domaine (par broadcast) L’échange de données inter-domaines se fait via les gestionnaires de domaine Dissémination d’un message : dans un arbre dont la racine est l’émetteur, les nœuds internes sont des gestionnaires de domaine, les feuilles sont des membres des domaines.

Exemple DoDWAN (plate-forme de communication pour réseaux ad hoc dynamiques) Diapos 11 à 20

Niveau système d’information III-3 SI Niveau système d’information De très nombreuses recherches en cours Sur des domaines très divers Synthèse difficile => survol de certains points => approfondissement d’autres Plan de cette partie: découverte de services gestion de données context-awareness adaptation des données, des interfaces utilisateurs et des services

Découverte de services III-3-1 Découverte de services Découverte de services Un échange de données sous-entend de connaître la localisation des services fournissant les données Les questions Comment faire connaître les services que l’on propose? Comment trouver un service dont on a besoin? Doit-on répartir ou centraliser la connaissances sur les services? Approches Annuaires de services Inondation Routage sémantique

Découverte par annuaires de services III-3-1 Découverte de services Découverte par annuaires de services Ensemble organisé de descriptions de services disponibles Certaines machines du réseau fournissent un service d’annuaire Exemples SLP Jini Salutation Bluetooth SDP

Annuaire de services SLP (Service Location Protocol) III-3-1 Découverte de services Annuaire de services SLP (Service Location Protocol) Service Agent Représentant d’un service Directory Agent Enregistre les SA dans un annuaire LDAP Publicité multicast pour se faire connaître des UA et des SA Intermédiaire entre SA et UA pour la découverte User Agent Représentant du client pour la découverte d’un service Émet une requête multicast avec URI du service recherché

Annuaire de services Jini III-3-1 Découverte de services Annuaire de services Jini Jini Promu par Sun, technologie Java Arrivée d’un nœud fournisseur de services Le nœud broadcast son identité et son groupe L’annuaire Jini lui répond avec une interface RMI Le nœud envoie sur cette interface la déclaration de ses services L’annuaire enregistre les services du nœud avec une durée de vie, ainsi qu’un proxy d’accès pour chaque service Le nœud doit renouveler la déclaration de ses services avant la fin de durée de vie

Annuaire de services Jini III-3-1 Découverte de services Annuaire de services Jini Accéder à un service Le nœud demandeur envoie une demande en multicast Les annuaires recevant la demande répondent le cas échéant en fournissant la localisation et le proxy d’accès Le nœud demandeur accède au service par l’intermédiaire du proxy Les informations sur le service peuvent être mises en cache dans le nœud demandeur pour un accès ultérieur Technique de recherche par lookup Les nœuds possédant l’information sont connus

Annuaire de services Salutation III-3-1 Découverte de services Annuaire de services Salutation Annuaire plus réparti que Jini Chaque nœud contient un agent annuaire qui enregistre un sous-ensemble des services disponibles Ajout d’un service inscription dans l’agent annuaire local Et inscription dans les agents annuaires des nœuds voisins Recherche d’un service Recherche d’abord auprès de l’agent local Puis recherche par broadcast le cas échéant Technique de recherche par découverte Les nœuds possédant l’information ne sont pas connus

Bluetooth service discovery protocol III-3-1 Découverte de services Bluetooth service discovery protocol Permet à un système Bluetooth de découvrir les services de son environnement fournisseur de service = sdp server chaque service est décrit par un service record (liste de description des attributs du service) les services sont regroupés en classes, une classe a un attribut identifiant universel (UUID) 2 modes : recherche d’un service par UUID navigation dans l’ensemble des services d’un serveur via la liste des UUID offerts

Découverte par inondation III-3-1 Découverte de services Découverte par inondation Chaque noeud enregistre sa liste de services disponibles Exemple : uPnP (consortium industriel) ajout de noeuds avec zero configuration, communication, découverte automatique de services Arrivée d’un nouveau nœud Il demande une adresse IP (DHCP par exemple) Il envoie par multicast un message XML fournissant la déclaration de son arrivée (ANNOUNCE) et la description des services qu’il fournit (OPTIONS). Les réceptionnaires répondent au nouveau nœud pour qu’il ait connaissance de leur existence http://www.upnp.org

Découverte par routage sémantique III-3-1 Découverte de services Découverte par routage sémantique Choisir « intelligemment » les nœuds qui permettent d ’atteindre le service requis. Encore du domaine de la recherche Deux exemples Allia Clusters multi-couche

Allia : Alliance-based service discovery III-3-1 Découverte de services Allia : Alliance-based service discovery Chaque peer fournit un annuaire des services locaux annonce les services qu’il fournit à ses voisins (multicast) sélectionne parmi les annonces reçues celles qu’il gère dans son cache (avec une politique personnelle) les peers dont des services sont mis en cache font partie de l’alliance du peer gérant le cache un peer retire de son alliance tout peer qui « disparaît » Recherche d’un service dans son annuaire local, puis dans son cache puis demande à ses voisins (le voisin cherche en local ou transmet la demande si sa politique personnelle l’y autorise) Exemples de politique locale : nb max de services mis en cache intégrer dans l’alliance en fonction d’un degré de mobilité du nœud un voisin répond si sa batterie est au-dessus d ’un seuil minimal nombre de hops autorisés pour atteindre le peer mis en alliance

Clusters multi-couche III-3-1 Découverte de services Clusters multi-couche Regroupement des peers en fonction de la proximité géographique : en liaison directe (single hop) sémantique : fournissent des services similaires fondée sur une ontologie arborescente de termes

Clusters multi-couche III-3-1 Découverte de services Clusters multi-couche deux peers sont dans le même cluster feuille (niveau 1) s’ils appartiennent au même terme et s’ils sont en liaison directe cluster niveau 2 : même terme de niveau 2 et géographiquement « atteignables » atteignables : 2 nœuds des 2 clusters sont en relation directe 3 hop max entre 2 nœuds du même cluster de niveau 2 Clusters niveau 2 Clusters niveau 1

Les objets se déplacent durant le fonctionnement III-3-1 Découverte de services Objets mobiles Les objets se déplacent durant le fonctionnement e.g. équilibrage de charge serveur ou réseau Comment les atteindre? 3 façons serveur de localisation poste restante répéteurs Fin séance 2

Serveur de localisation d’objets mobiles III-3-1 Découverte de services Serveur de localisation d’objets mobiles Un serveur stocke les couples objet/localisation Chaque objet informe lui-même le serveur de sa migration Un client ayant besoin d’un accès à un objet mobile demande la localisation au serveur accède ensuite directement à l’objet

Poste restante pour objets mobiles III-3-1 Découverte de services Poste restante pour objets mobiles Un intermédiaire fixe sert de poste restante L’objet mobile interroge régulièrement l’intermédiaire pour prendre les messages Un client qui veut accéder à l’objet envoie un message à l’intermédiaire fixe communication asynchrone

Répéteurs pour objets mobiles III-3-1 Découverte de services Répéteurs pour objets mobiles Un objet quittant un site laisse derrière lui un répéteur connaissant la localisation suivante Le répéteur fait suivre les messages jusqu’à la position suivante Un client envoie sa demande à la dernière localisation connue, le répéteur transmet le cas échéant. Plusieurs migrations => une chaîne de répéteurs

Références bibliographiques Découverte III-3-1 Découverte de services Références bibliographiques Découverte O. Ratsimor, et al. Allia: Alliance-based Service Discovery for Ad-Hoc Environments, ACM Mobile Commerce Workshop, Sept 2002 M. Klein, B. König-Ries: Multi-Layer Clusters in Ad-hoc Networks - An Approach to Service Discovery. In: Proc. International Workshop on Peer-to- Peer Computing, Pisa, Italy, 2002. R. Yavatkar, J. Griffioen “ reliable dissemination for large-scale wide area information systems”. Department of computer science University of Kentucky, 2001 E. Beau et al. Synthèse bibliographique “gestion de données en milieu pervasif”, Dept Informatique INSA Lyon, octobre 2003 “Upnp, Jini and Salutation - a look at some popular coordination frameworks for future networked devices” California Software Labs, 2002 B. Siverajan et al. “ a service discovery model for wireless and mobile terminals in IPv6” Tempere University of technology (Finland), 2003 C. Lee, S. Helal, “Protocols for Service Discovery in Dynamic and Mobile Networks” International Journal of Computer Research, v.11, n.1, 2002

Gestion de données en environnement pervasif III-3-2 Gestion de données Gestion de données en environnement pervasif [Franklin 2001] Challenges pervasifs et besoins induits Adaptabilité et interaction utilisateur Interaction temps-réel avec les données distantes Flexibilité Mobilité Délivrer et recevoir des données pendant le déplacement Tolérer les déconnexions sans interrompre le service Préparation des données qui seront utiles => prédiction des besoins Location-awareness Sélectionner les données en fonction de la localisation Structures de données spécifiques à la localisation

Gestion de données en environnement pervasif III-3-2 Gestion de données Gestion de données en environnement pervasif Context-awareness Analyser des flux de données provenant de capteurs temps réel Passer d’une information brute d’environnement à une donnée de contexte qui a du sens pour l’application : interpréter les analyses Collaboration Gestion de groupes de personnes dynamiques / ad hoc Gestion de synchronisation et cohérence Actions collaboratives de création, accès, modification de données partagées par le groupe

Gestion de données en environnement pervasif III-3-2 Gestion de données Gestion de données en environnement pervasif Exemples de projets Projet Data Recharging [Franklin 2001] Data charge (plug on the net)  battery charge Plus on est connecté, plus on reçoit de données Exploiter le profil de l’utilisateur pour délivrer automatiquement des mises à jour de données et nouvelles données pertinentes Profil utilisateur = description des données pertinentes + priorités Projet Telegraph [Shah 2001] Architecture adaptative de traitement de flux de données dans des environnements très dynamiques Le plan de traitement du flux est dynamique (adaptation aux fluctuations telles que énergie et bande passante)

Gestion de données en environnement pervasif III-3-2 Gestion de données Gestion de données en environnement pervasif Exemples détaillés ci-après JavAne Gestion de réplicas MoGATU

Basé sur JavAct : plate-forme de gestion d’agents mobiles adaptables III-3-2 Gestion de données JavAne Agents mobiles pour le partage et la recherche de documents en environnement peer-to-peer Rôle serveur Publier, gérer et partager des documents Rôle client Rechercher et récupérer des documents Stocker des informations sur les serveurs qu’il connaît Naviguer de site en site Des agents mobiles qui interrogent la base de chaque site Basé sur JavAct : plate-forme de gestion d’agents mobiles adaptables

JavAne – code simplifié d’un agent chercheur III-3-2 Gestion de données JavAne – code simplifié d’un agent chercheur public class SearchBehavior extends JavAneBehavior implements Searcher, javact.util.StandAlone { public SearchBehavior(client, clientInfo, energy, queryStamp, Params) { ...} public void run() { if (energy <= 0) {suicide();return;} // Has the current place been already visited ? if (! markedPlace(myPlace(), queryStamp, client)) energy -= E_VISITED; else { // Database interrogation and sending of results to the client localResults = LocalDB.fileSelect(Params); if (localResults != null && localResults.length > 0) { send(new JAMprocessResults(place, localResults), client); energy -= E_FOUND; } else energy -= E_NOT_FOUND; } ../…

JavAne – code simplifié d’un agent chercheur III-3-2 Gestion de données JavAne – code simplifié d’un agent chercheur if (energy > 0) {// Random moving (if it remains energy) String[] places = getPlaces(myPlace()); String nextPlace = places[random.nextInt(places.length)]; go(nextPlace); } else suicide(); // Collection of meta-information String[] placesInfos = getPlacesInfos(myPlace()); send(new JAMaddPlacesInfos(placesInfos), clientInfo); }

Gestion de caches sur le web III-3-2 Gestion de données Gestion de caches sur le web Proxy-caches collaboratifs une donnée est dupliquée sur le proxy qui la demande gourmand et non « optimisé » Content Delivery Network gestion de données avec distribution à très grande échelle architecture fixe tentaculaire très coûteuse Push-caching les serveurs « poussent » les réplicas vers les proxy de leur choix en fonction d’une politique qui leur est propre le client s’adresse au fournisseur qui redirige vers le cache le plus adéquat

(Dé)placement de réplicas en environnement pervasif III-3-2 Gestion de données (Dé)placement de réplicas en environnement pervasif basé sur la théorie des small worlds (groupes d’intérêt) un réplica doit se rapprocher des small worlds qui s ’intéressent à lui A chaque demande d’une donnée, les réplicas se déplacent vers le foyer de demande R R SW1 SW2 R SW1 SW2

(Dé)placement de réplicas en environnement pervasif III-3-2 Gestion de données (Dé)placement de réplicas en environnement pervasif Apparition d’un nouveau groupe d’intérêt si autorisé, duplication du réplica et déplacement du nouveau réplica vers le nouveau groupe sinon, déplacement des réplicas existants jusqu’à équilibre entre les 2 groupes d’intérêt Disparition du groupe d’intérêt déplacement ou suppression du réplica R R R R SW1 SW2 SW1 SW2 SW3 SW3 Duplication interdite Duplication autorisée R

(Dé)placement de réplicas en environnement pervasif III-3-2 Gestion de données (Dé)placement de réplicas en environnement pervasif Le (dé)placement ne se fait qu’avec une connaissance partielle du réseau chaque peer ne connaît que les nœuds les plus proches! Notion de vecteur d’attraction d’un réplica sur chaque lien sortant du cache sur lequel il est hébergé augmenté à chaque demande provenant de ce lien Diminué avec le temps Déplacement effectif ou duplication lorsque le vecteur d’attraction dépasse la distance entre le proxy hébergeant le réplica et le nœud contenant le proxy destination Destruction du réplica quand le vecteur d’attraction reste nul pendant une durée seuil

Plate-forme de gestion de données en P2P pur III-3-2 Gestion de données MoGATU Plate-forme de gestion de données en P2P pur une couche de gestion des données une couche de communication Sur chaque peer, 3 types d’entités Information provider : source de données Information consumer : entités qui interrogent et mettent à jour les données Information manager : informations sur les peers voisins, intermédiaire entre provider et consumer, gestion de cache en fonction d’un profil

MoGATU – information provider III-3-2 Gestion de données MoGATU – information provider Gère et fournit une interface d’accès à une sous- partie locale des données Décrit son service à l’aide d’une ontologie Communique uniquement avec l’information manager local, qui « route » les messages entre ce provider et les autres peers Se déclare régulièrement auprès de l’information manager local, qui lui-même transmet la déclaration aux peers de l’entourage

MoGATU – information consumer III-3-2 Gestion de données MoGATU – information consumer Utilisateurs finaux ou autres agents S’enregistrent auprès de l’information manager local (pas d’annonce aux peers de l’entourage) Envoie ses requêtes à l’information manager local L’information manager transmet la demande aux information providers locaux ou distants correspondants, et récupère les réponses

MoGATU – information manager III-3-2 Gestion de données MoGATU – information manager Communication réseau Analyse des messages Découverte et routage des messages en multi-hop Requêtes proactives sur les autres peers Broadcast des annonces des providers (locaux et/ou voisins) des requêtes des consumers locaux Maintenance d’informations Informations sur providers et consumers locaux Durée de vie, services, restrictions sur les requêtes Informations sur peers de l’entourage Id, services fournis, types d’informations fournies (leurs annonces)

MoGATU – information manager III-3-2 Gestion de données MoGATU – information manager Profil utilisateur Préférences et besoins Cache réponses aux requêtes passées fournies par les peers de l’entourage Choix de mettre en cache en fonction du profil utilisateur et des capacités du peer 4 niveaux d’information manager selon capacité 1 : aucun cache 2 : cache les annonces distantes 3 : cache les annonces et les réponses aux requêtes passées 4 : cache annonces et réponses et les rend accessibles aux autres peers

Généralisation aux caches en général III-3-2 Gestion de données Généralisation aux caches en général Systèmes distribués de proxy-caches ensemble de services interposées entre le « client » et le « fournisseur » d ’un service effectuant un travail à la place du fournisseur ou à la place du client adaptation de contenu, délestage des serveurs, optimisation de la sécurité, traductions inter-protocoles, stockage de copies de données (réplicas)…

Références bibliographiques Gestion de données M. Franklin « Challenges in ubiquitous data management », Informatics : 10 years back, 10 years ahead. LNCS 2000, R. Wilhelm (ed.), Springer Verlag, 2001 JPArcangeli & al. Development of flexible peer-to-peer information systems using adaptable mobile agents, DEXA 04 Workshop GLOBe (Grid an dPeer-to-peer computing impacts on large scale heterogeneous distributed database systems) DEA de J. Gossa, encadré par JMPierson et LBrunie, LIRIS, 2004 F. Perish et al. On data management in pervasive computing environments IEEE transactions on knowledge and data engineering, vol 16 n°5 may 2004 Mehul A. Shah, Samuel Madden, Michael J. Franklin, Joseph M. Hellerstein. Java Support for Data-Intensive Systems: Experiences Building the Telegraph Dataflow System, SIGMOD Record,Vol 30 nb 4 dec 2001:103-114

Context-awareness M. Weiser Informatique context-aware III-3-3 Context-awareness Context-awareness M. Weiser «The most profound technologies are those that disappear» Informatique context-aware Prise en compte de l’environnement dans lequel se trouve l’utilisateur Capture et accès automatique Délivrer l’information pertinente Quand? Où? Comment?

Définition du contexte III-3-3 Context-awareness Définition du contexte [Salber,Dey,Abowd 99] « Environmental information or context covers information that is part of an application’s operating environment and that can be sensed by the application. This typically includes the location, identity, activity and state of people, groups and objects. »

Définition du contexte III-3-3 Context-awareness Définition du contexte [Winograd 01] “Something is context because of the way it is used in interpretation, not due to its inherent properties. The voltage on the power lines is a context if there is some action by the user and/or computer whose interpretation is dependant on it, but otherwise is just part of the environment."

Définition du contexte III-3-3 Context-awareness Définition du contexte Ce qui est intéressant Le concepteur de l’application décide quelles informations contextuelles sont intéressantes Dépend de l’application Le contexte est souvent constitué d’un ensemble d’informations implicites auxquelles l’application n’a pas accès rend les applications plus « smart »

De plus en plus souvent un 5ème III-3-3 Context-awareness Contenu du contexte Classiquement, 4 axes Utilisateur Profil et préférences, localisation… Terminaux et matériels Taille de l’écran, résolution, couleurs, mémoire, API… Réseau Bande passante, connectivité, Qos Méta-données de l’application Codage, langue, versions De plus en plus souvent un 5ème Activité Tâche en cours

Modélisation du contexte III-3-3 Context-awareness Modélisation du contexte Très souvent dépendante de l’application, encore peu de travaux « génériques » sur cette modélisation 3 approches principales Couples attribut/valeur Extension de CC/PP Modélisation par ontologies Très en vogue – de très nombreux travaux en cours

Modélisation du contexte par attribut/valeur III-3-3 Context-awareness Modélisation du contexte par attribut/valeur Contexte = paires (attribut, valeur) userName=flaforest userLocation = courseRoom Les paires sont indépendantes + Facilité d’implantation - Cohérence de l’ensemble - Sémantiquement pauvre

Modélisation du contexte avec CC/PP III-3-3 Context-awareness Modélisation du contexte avec CC/PP Composite Capabilities / Preferences Profile (W3C) description des terminaux et des préférences utilisateur Document RDF pour décrire les attributs Modéliser le contexte = faire des extensions + standard - extensions => complexité, lecture ardue

Exemple de document XML CC/PP III-3-3 Context-awareness Exemple de document XML CC/PP <?xml version="1.0"?> <!-- Checked by SiRPAC 1.16, 18-Jan-2001 --> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#"> <rdf:Description rdf:about="HWDefault"> <rdf:type rdf:resource="HardwarePlatform" /> <display>320x200</display> <memory>16Mb</memory> </rdf:Description> </rdf:RDF>

Modélisation du contexte par ontologies III-3-3 Context-awareness Modélisation du contexte par ontologies Une ontologie est un ensemble structuré de concepts. Les concepts sont organisés dans un graphe dont les relations peuvent être : des relations sémantiques des relations de composition et d'héritage (au sens objet) Intérêt des ontologies pour modéliser le contexte Utilisables dans des environnements d’envergure Sémantiquement riches

Modélisation du contexte par ontologies III-3-3 Context-awareness Modélisation du contexte par ontologies Exemple CoOL [Strang & al. 03] <instance xmlns=http://demo.heywow.com/schema/cool xmlns:a=http://demo.heywow.com/schema/aspects xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <contextInformation> <entity system="urn:phonenumber">+49-179-1234567</entity> <characterizedBy> <aspect name="GaussKruegerCoordinate"> <observedState xsi:type="a:o2GaussKruegerType">367032533074</observedState> <units>10m</units> </aspect> <certaintyOfObserver>90</certaintyOfObserver> </characterizedBy> </contextInformation> </instance>

Modélisation du contexte par ontologies Exemple Gco [Chaari et al. 06] Descripteurs de contexte génériques / de base User context, device context, network context, activity context, service context, location context and resource context Descripteurs de contextes spécifiques à l’application Basic context

Context element=(Subject, Predicate, Value, Time, Certainty) …Suite Gco Context element=(Subject, Predicate, Value, Time, Certainty) Subject = propriétaire de l’élément de contexte Predicate = propriété Value = valeur de l’élément Time = date du relevé de la valeur Certainty = confiance dans la valeur Exemple : (VideoService, runsOn, PDA-01, 20061013, 0.8)

…suite Gco Exemple de graphe de contexte Gco Contexte de base: les éléments reliés à la racine

Synthèse des modélisations de contextes III-3-3 Context-awareness Synthèse des modélisations de contextes + - ++ Ontologies Extension de CC/PP Paires Attribut / valeur Gestion des conflits Facilité d'implantation Expressivité et richesse sémantique

Application context-aware III-3-3 Context-awareness Application context-aware « Context-aware applications sense context information and modify their behavior accordingly without explicit user intervention » 3 types de comportement Afficher le contexte Automatiquement exécuter ou adapter des services Enregistrer et « indexer » l’information de contexte pour la retrouver au besoin

Afficher le contexte Exemples III-3-3 Context-awareness Afficher le contexte Exemples Tableau des entrées et sorties du personnel Cartes de localisation Écrans d’état (météo, activité…)

Exécuter / adapter des services III-3-3 Context-awareness Exécuter / adapter des services Sélectionner et exécuter le service pertinent parmi un ensemble de services Modifier le comportement d’un service ou son exécution Exemple : imprimer sur l’imprimante la plus proche, afficher de la documentation…

Enregistrer et « indexer » le contexte III-3-3 Context-awareness Enregistrer et « indexer » le contexte Utiliser le contexte dans le cas de recherches fondées sur le contexte Exemples Forget-me-not Assistant de conférence Guides touristiques Historique (revoir des informations « cochées » lors de la réunion, lors de la visite)

Conception d’une application context-aware III-3-3 Context-awareness Conception d’une application context-aware Sans support Spécifications Acquisition et représentation Diffusion Réception et stockage Action Avec support

Conception sans support III-3-3 Context-awareness Conception sans support Spécifications Quel contexte utiliser Quels comportements Acquisition et représentation Installer les capteurs utiles Créer ou apprendre les API des capteurs Créer les modules d’acquisition des données de capteurs ou les modules de transmission des modifications de valeurs des capteurs Stocker le contexte Interpréter / abstraire le contexte

Conception sans support III-3-3 Context-awareness Conception sans support Diffusion Mécanisme de transport de l’information des capteurs vers les services Capteurs sources d’information nombreux et hétérogènes Distribution à des services nombreux et hétérogènes Réception et stockage Requêtes ou notifications? Stocker tout le contexte? Durée de vie du contexte? Interprétation des données brutes Action Combiner le contexte reçu avec les anciennes valeurs Effectuer une action en fonction des résultats de l’analyse

Exemple de conception sans support III-3-3 Context-awareness Exemple de conception sans support Visite guidée mobile Application Afficher la liste des démos non vues Surligner les démos pertinentes Afficher une carte centrée sur la localisation de l’utilisateur Afficher de l’information sur la démo la plus proche Application mono-utilisateur

III-3-3 Context-awareness Visite guidée mobile

Visite guidée mobile Spécifications Contexte III-3-3 Context-awareness Visite guidée mobile Spécifications Contexte Liste des démos faites Localisation de l’utilisateur Orientation de l’utilisateur Comportement de l’application Cf. transparent précédent

Visite guidée mobile Acquisition Capteurs API III-3-3 Context-awareness Visite guidée mobile Acquisition Capteurs Orientation : compas électronique Localisation : badge actif Liste des démos : badge actif + application API à construire pour orientation et liste de démos À apprendre pour badge actif Stockage des données dans un fichier local Interprétation de la localisation pour savoir si près d’une démo

Visite guidée mobile Diffusion Réception III-3-3 Context-awareness Visite guidée mobile Diffusion Seul le badge actif est sans fil Écrire la couche transport (RPC par exemple) pour acquérir les données Réception Notification des changements Interprétation pour recevoir la liste des démos Ensemble de capteurs fini

Visite guidée mobile Action Modification d’orientation III-3-3 Context-awareness Visite guidée mobile Action Modification d’orientation Modification de la carte Modification de la localisation Mise à jour de la liste des démos non vues Surligner les démos pertinentes

Conception d’une application context-aware III-3-3 Context-awareness Conception d’une application context-aware Sans support vs. avec support Nécessité d’un support pour: Spécifications : Spécifier le contexte nécessaire Découverte : localiser les composants qui peuvent acquérir du contexte et agir en fonction du contexte Séparation des problèmes : séparer l’acquisition du contexte de son utilisation Stockage : importance des historiques de contexte Interprétation : pour des informations de plus haut niveau Communications transparentes Disponibilité permanente du contexte

Briques de base de la plate-forme de Dey III-3-3 Context-awareness Briques de base de la plate-forme de Dey Context Widgets Par analogie avec les widgets des interfaces graphiques Encapsulation, abstraction But Acquérir et abstraire les données des capteurs Séparer les problématiques Stockage

III-3-3 Context-awareness Context widgets

III-3-3 Context-awareness Interpretors Les données des capteurs sont rarement fournies au bon niveau d’abstraction Convertissent ou interprètent le contexte pour obtenir une information de plus haut niveau

Simplifie la conception de l’application III-3-3 Context-awareness Agrégators Rassemble des données de contexte pour les rendre pertinentes pour certaines entités Simplifie la conception de l’application

Effectue les traitements sur les données de contexte III-3-3 Context-awareness Services Effectue les traitements sur les données de contexte

Répertorie l’ensemble des composants de gestion du contexte III-3-3 Context-awareness Discoverer Répertorie l’ensemble des composants de gestion du contexte

Synthèse de la plate-forme de Dey III-3-3 Context-awareness Synthèse de la plate-forme de Dey

Autres challenges en context-awareness III-3-3 Context-awareness Autres challenges en context-awareness Killer application Besoin de quelque chose pour orienter les recherches Besoin de quelque chose de concret à mettre entre les mains des futurs utilisateurs Taxonomie Quel contexte est important? Comment représenter le contexte? Standards pour partager les composants entre groupes de recherche

Autres challenges en context-awareness III-3-3 Context-awareness Autres challenges en context-awareness Connaissances sur le monde réel Comment le monde fonctionne Protection de la personne Capture et collecte d’informations sur les gens, les lieux, les terminaux Réponses sociales et technologiques à apporter Qualité de service : méta données Cohérence, Confiance, Fréquence… « Smartness » Quand le système doit-il décider, quand l’utilisateur doit-il décider?

Autres challenges en context-awareness III-3-3 Context-awareness Autres challenges en context-awareness Ambiguité Limitations des capteurs : vue réduite de la réalité Comment réagir à une mauvaise interprétation automatique Modèle de l’environnement Relations entre les localisations : granularité de la distance, hiérarchie de composition (batiment/piece…) Relations entre les gens : famille, collègues Relations entre les équipements? Fin séance 3

Références bibliographiques Context awareness III-3-3 Context-awareness Références bibliographiques Context awareness M. Weiser « The computer for the twenty-first century », Scientific American, sept 1991:94-104 A.K. Dey « Building context-aware applications », presentation at Dagstuhl summer school, august 2003 D. Salber, A.K.Dey, G.D. Abowd «  The context Toolkit : aiding the development of context-enabled applications » ACM CHI 99 Strang & al. « Service interopérability on context level in ubiquitous computing environments » Int conf. On Advances in infrastructure for electronic business, education, science, medicine and mobile technologies on the internet, L’Aquila, Italy, jan. 2003 T. Chaari, D. Ejigu, F. Laforest and V.-M. Scuturici «Modeling and Using Context in Adapting Applications to Pervasive Environments.» IEEE Int. Conf. Pervasive Services, Lyon, France, June 2006 T. Winograd, “Architectures for Context,” Human-Computer Interaction, Vol. 16, No. 2, 3 & 4, Pages 401-419, 2001.

Principes génériques d’adaptation III-3-4 Adaptation Adaptation Principes génériques d’adaptation Statique Dynamique 3 domaines principaux Adaptation des interfaces utilisateurs Adaptation du contenu Adaptation des services

Préparer plusieurs versions d’une ressource avant son exploitation III-3-4-2 Principes d’adaptation Adaptation statique Préparer plusieurs versions d’une ressource avant son exploitation En fonctionnement, adaptation = choix de la version correspondant au contexte Beaucoup utilisée dans les débuts des applications multi-terminaux Version existante pour terminaux standards Nouvelles versions pour autres terminaux + simplicité et efficacité de fonctionnement - pb d’échelle, lourdeur de prise en compte d’une nouvelle version

Références de projets d’adaptation statique III-3-4-2 Principes d’adaptation Références de projets d’adaptation statique Eric D. Larson, Wireless Java Application Saves Women's Cancer Center $500,000 per Year, J2ME case studies, september 2002. http://wireless.java.sun.com/midp/casestudies/wcc/ V. Massé, « La société MobilePlanet Europe fournit des terminaux mobiles à la Brigade des Sapeurs Pompiers de Paris (BSPP) pour l’équipement de ses véhicules d’intervention », Mobile Planet, juin 2002. http://www.mobileplanet.fr/m_includes/press_release /2002_brigade.asp S. Benjaminsen, A. Djora « JetRek: How organisational identities slowed down speedy requisitions », BSA medical sociology conference, september 2002, York. http://ww.sv.ntnu.no/iss/Aksel.Tjora/publications/ Siri-york02-09.pdf

Transformations sur la ressource en cours de fonctionnement Exemples III-3-4-2 Principes d’adaptation Adaptation dynamique Transformations sur la ressource en cours de fonctionnement Exemples CSS : transformations à la volée de la forme d’un document XML=>HTML transformation de format de données + gain de temps pour prendre en compte une nouvelle version - complexité de l’outil (choix d’un « chemin d’adaptation » + adaptation) - temps de réponse

Références de projets d’adaptation dynamique III-3-4-2 Principes d’adaptation Références de projets d’adaptation dynamique TeraCom “Soluphone santé” 2002. http://www.soluphone.com/SoluSante.pdf T. Lemlouma, N. Layaïda, « A Framework for Media Resource Manipulation in an Adaptation and Negotiation Architecture », OPERA project, under submission, INRIA Rhône-Alpes, august 2001 G. Menkhaus « Adaptive User Interface Generation in a Mobile Computing Environment », PhD Thesis, Salzburg University,  2002.

Trois domaines principaux d’adaptation III-3-4-3 Domaines d’adaptation Trois domaines principaux d’adaptation Adaptation des interfaces utilisateurs Adaptation du contenu Adaptation des services

Adaptation des interfaces utilisateur III-3-4-3a Adaptation des IU Adaptation des interfaces utilisateur Approches cognitives Modèles utilisateur/tâche/dialogue Généralement instrumentés par des plates-formes de génération automatique ou semi-automatique Approches d’ingénierie Outils de conception et développement des IHM Question : passer d’une problématique de visualisation/mise à jour à une solution concrète (code) Généralement basé sur des modèles À la XML : UIML, AUIML, SunML, XIML, Plastic ML, USIXML,  XUL, XAML… À la UML : UMLi

[Pinheiro da Silva et Paton, 2000 ] III-3-4-3a Adaptation des IU Modèle UMLi [Pinheiro da Silva et Paton, 2000 ] Extension de UML: aspect interaction Diagrammes complexes et fastidieux

III-3-4-3a Adaptation des IU Exemple UMLi Objets graphiques

Modèle UiML [Abrams, Phanouriou 1999 ] III-3-4-3a Adaptation des IU Modèle UiML [Abrams, Phanouriou 1999 ] Spécification de la présentation Avec des balises à la XML Dépendante de la plate-forme cible Long et fastidieux! Exemple <?xml version="1.0"?> <!DOCTYPE uiml PUBLIC "-//UIT//DTD UIML 2.0 Draft//EN" "http://uiml.org/dtds/UIML20.dtd"> <uiml> <head> <meta name="Description"content="Use of templates for CreditCard entry form"/> <meta name="Author" content="Constantinos Phanouriou"/> <meta name="Email" content="uiml-editor@uiml.org"/> </head> <peers> …/…

III-3-4-3a Adaptation des IU Exemple UiML: pour chaque plate-forme, un ensemble de composants d’affichage <presentation name="WML"> <component name="Dialog" maps-to="wml:card"/> <component name="TextField" maps-to="wml:input"/> <component name="Button" maps-to="wml:DO type='ACCEPT'"/> <component name="InputEvent" maps-to="wml:event type='onenterforward'"/> </presentation> <presentation name="VoiceXML"> <component name="Dialog" maps-to="vxml:form"/> <component name="TextField" maps-to="vxml:prompt"/> <!-- Button does not have a rendering in Voice --> <component name="Button" maps-to=&QUOTE;/> <component name="InputEvent" maps-to="vxml:filled"/> <presentation name="Java-AWT"> <component name="Dialog" maps-to="java.awt.Dialog"/> <component name="TextField" maps-to="java.awt.TextField"/> <component name="Button" maps-to="java.awt.Button"/> <component name="InputEvent“ maps-to="java.awt.event.ActionEvent"/>

Exemple UiML: pour chaque plate-forme, une logique de fonctionnement III-3-4-3a Adaptation des IU Exemple UiML: pour chaque plate-forme, une logique de fonctionnement <logic name="HTTP"> <component name="CreditApp"> <method name="SendCredit" maps-to="http://<server>:port/cgi-bin/acceptCredit.pl?"> <param name="cnum"/> </method> </component> </logic> <logic name="Java"> <component name="CreditApp" maps-to="myBiz.creditApp.class"> <method name="SendCredit" maps-to="acceptCredit"> </peers>

III-3-4-3a Adaptation des IU Exemple UiML: structure de l’interface utilisateur, utilisation de template réutilisable <template name="CreditCard"> <part name="CreditContainer" class="CreditDialog"> <style> <proprety name="title">Credit Card Entry Form</property> </style> <part name="CreditNum" class="number"/> <part name="AcceptNum" class="Accept"> <style> <proprety name="content">Accept</property> </style> </part> </template> <interface> <structure> <part name="ECommerceApp"> <!-- UI description --> <part name="MyCredit" source="#CreditCard"/> </structure>

Exemple UiML: rendu de l’IU et comportement III-3-4-3a Adaptation des IU Exemple UiML: rendu de l’IU et comportement Définis dans structure et template <style><property name="rendering" part-class="MyCredit.CreditDialog"> Dialog </property> <property name="rendering" part-class="MyCredit.number"> TextField </property> <property name="rendering" part-class="MyCredit.Accept"> Button </property> <property name="rendering" event-name="InputEvent"> InputEvent </property> <property name="rendering" method-name="SendCredit"> SendCredit </property> </style> <behavior> <rule> <condition> <event name="InputEvent" part-name="MyCredit.AcceptNum"/> </condition> <action> <method name="SendCredit"> <param name="cnum"><property name="content" part-name="MyCredit.CreditNum"/> </param> </method> </action> </rule> </behavior> </interface> </uiml> Définis dans présentation Défini dans logic

Plates-formes de génération de code d’IU III-3-4-3a Adaptation des IU Plates-formes de génération de code d’IU Fondées sur plus ou moins de modèles, parmi: Domaine : description des services de l’application, modèle de BD… Tâches : graphes d’activités Utilisateur : préférences Dialogue : partie interactive de l’interface Présentation : partie visuelle de l’interface Une génération plus ou moins automatique du code Des modèles inter-reliés, long, complexes et fastidieux… il est souvent plus rapide de coder soi- même l’interface!

Interface graphique du Projet SICOM III-3-4-3a Adaptation des IU Le projet SEFAGI [Chaari 2004] Cadre applicatif projet Système d’Information COMmunicant pour la santé Adaptation des interfaces utilisateurs au terminal Interface graphique du Projet SICOM Une partie générique Des parties spécifiques dédiées à une pathologie dédiées à un type d’utilisateurs ==>Nombre de fenêtres différentes élevé ==> Temps de développement important

Génération automatique des fenêtres spécifiques III-3-4-3a Adaptation des IU Objectifs Génération automatique des fenêtres spécifiques pour des terminaux de types divers PC (J2SE) Terminaux très légers (MIDP- CLDC) Terminaux légers (CDC) Génération automatique et complète des : Affichages et leurs inter-relations Interactions avec les traitements Et de l’environnement d’exécution sur les terminaux

III-3-4-3a Adaptation des IU Architecture logique

Environnement d ’exécution sur PC III-3-4-3a Adaptation des IU Environnement d ’exécution sur PC

Description des fenêtres à générer III-3-4-3a Adaptation des IU Description des fenêtres à générer fenêtre = liste de panneaux panneau = Une représentation graphique dépendant du type de terminal Des services associés (getData / setData) Types de panneaux 6 pour l’instant, extensible Chaque type de panneau correspond à une classe dans une bibliothèque de composants graphiques 3 types de manneaux dans cette fdenetre : tableau texte multiligne commande

Panneaux tableau, texte, graphique III-3-4-3a Adaptation des IU Panneaux tableau, texte, graphique Panneau de type tableau Saisie et consultation des données Une case = un widget de base (zone de saisie, liste énumérée, cases à cocher…) Contraintes associées à chaque case Panneau de type texte Grande zone texte (commentaires ,texte multiligne) Panneau de type graphique Présentation de courbes 2D ou de graphiques bâtonnet PC standard PC de poche

Panneau de type image, vidéo et commande III-3-4-3a Adaptation des IU Panneau de type image, vidéo et commande Panneaux image ou vidéo Liste des images/vidéos Image/vidéo sélectionnée Texte descriptif associé Panneau commande Boutons pour lancer l’appel des services associés aux panneaux de la fenêtre PC de poche PC standard PC de poche PC standard

III-3-4-3a Adaptation des IU Assistant de SEFAGI

III-3-4-3a Adaptation des IU Structure XML de description abstraite des fenêtres (aucune référence aux plates-formes cibles)

Environnement de génération III-3-4-3a Adaptation des IU Environnement de génération Interface principale permettant de Choisir une description abstraite de fenêtre Générer pour un type de terminal donné le code source de la fenêtre correspondante et de son gestionnaire d’évènements Compiler le code source généré

Diagramme de classes de l'environnement de génération III-3-4-3a Adaptation des IU Diagramme de classes de l'environnement de génération Méthodes d’initialisation Entête Méthodes de traitements Constructeur Attributs Définition de classe Structure d’une fenêtre java Gestionnaire d ’événements Définitions des événements Appel des méthodes

Exemple complet sur PC et mobile III-3-4-3a Adaptation des IU Exemple complet sur PC et mobile Menu de navigation

Architecture technique de SEFAGI III-3-4-3a Adaptation des IU Architecture technique de SEFAGI

Synthèse : types d’adaptation dans Sefagi III-3-4-3a Adaptation des IU Synthèse : types d’adaptation dans Sefagi Au cours de la génération (statiques) Transformations de l’affichage (présentation) Correspondance entre les composants du modèle et ceux des cibles Transformations de disposition (présentation) Disposition des composants dans les panneaux et des panneaux sur l’écran Transformations de navigation (présentation) Facilités de navigation pour l’utilisateur Au cours de l’exécution (dynamiques) Transformations de cohérence (données) Groupage ou dissociation de données, Gestion des points de reprise Transformations de contenu (données) Modification ou substitution d’une ressource par une autre Transformations de transmission (traitements) Protocole de transmission standard Typage standard des données

Conclusion SEFAGI Simplicité Évolutivité Portabilité III-3-4-3a Adaptation des IU Conclusion SEFAGI Simplicité Avoir des interfaces graphiques spécifiques sans toucher à la programmation Un fichier XML par fenêtre très court par rapport aux autres modèles existants Évolutivité Enrichissement de la liste des panneaux Portabilité Entièrement développée en JAVA

Références bibliographiques Adaptation des IU III-3-4-3a Adaptation des IU Références bibliographiques Adaptation des IU P. Pinheiro da Silva and N. W. Paton. UMLi: The Unifed Modeling Language for Interactive Applications. In Proceedings of UML2000, volume 1939 of LNCS, pages 117-132, York, UK, October 2000. Springer M. Abrams, C. Phanouriou, “UIML: an XML language for building device independent user interfaces”, XML’99, Philadelphia, December 1999 T. Chaari, F. Laforest, A. Flory Génération automatique d’interfaces graphiques pour la saisie et la consultation de données : Application au domaine médical. Int. Conf. on Sciences of Electronic, Technology of Information and Telecommunications SETIT 2004, Sousse, Tunisie, 15-20 mars 2004 T. Chaari, F. Laforest Génération et adaptation automatiques des interfaces utilisateurs pour des environnements multi-terminaux Le projet SEFAGI : Simple Environment For Adaptable Graphical Interfaces Revue Ingénierie des systèmes d’Information, n° spécial systèmes d’information pervasifs,volume 9 - n°2/2004:11-38 P. Sukaviriya, J. Foley, T. Griffith: A Second Generation User Interface Design Environment. In: S. Ashlund, et.al. (eds.): Bridges between Worlds. Proceedings InterCHI'93 (Amsterdam, April 1993). New York: ACM Press, 1993, 375-382.

Références bibliographiques Adaptation des IU III-3-4-3a Adaptation des IU Références bibliographiques Adaptation des IU C. Märtin: Software Life Cycle Automation for Interactive Applications: The AME Design Environment. In: J. Vanderdonckt (ed.): Computer-Aided Design of User Interfaces. Namur: Namur University Press, 1996, 57-74. H. Balzert, F. Hofmann, V. Kruschinski, C. Niemann: The Janus Application Development Environment Generating More than the User Interface. In: J. Vanderdonckt (ed.): Computer- Aided Design of User Interfaces. Namur: Namur University Press, 1996, 183-205. F. Bodart, A.-M. Hennebert, J.-M. Leheureux, I. Provot, B. Sacre, J. Vanderdonckt: Towards a Systematic Building of Software Architectures: the TRIDENT Methodological Guide. In P. Palanque, R. Bastide (eds.): Design, Specification and Verification of Interactive Systems. Wien: Springer, 1995, 262-278. C. Janssen, A. Weisbecker, J. Ziegler: Generating User Interfaces from Data Models and Dialogue Net Specifications. In: S. Ashlund, et.al. (eds.): Bridges between Worlds. Proceedings InterCHI'93 (Amsterdam, April 1993). New York: ACM Press, 1993, 418-423. Guido Menkhaus, Wolfgang Pree: User interface tailoring for multi-platform service access. IUI 2002: 208-209

Références bibliographiques Adaptation des IU III-3-4-3a Adaptation des IU Références bibliographiques Adaptation des IU T. Elwert, E. Schlungbaum: Modelling and Generation of Graphical User Interfaces in the TADEUS Approach. In: P. Palanque, R. Bastide (eds.): Designing, Specification, and Verification of Interactive Systems. Wien: Springer, 1995, 193-208. P. Johnson: Human-Computer Interaction. London: McGraw-Hill, 1992. A. Puerta: The Mecano Project: Comprehensive and Integrated Support for Model-Based Interface Development. In: J. Vanderdonckt (ed.): Computer-Aided Design of User Interfaces. Namur: Namur University Press, 1996, 19-36. A. Puerta: Issues in Automatic Generation of User Interfaces in Model- Based Systems. In: J. Vanderdonckt (ed.): Computer-Aided Design of User Interfaces. Namur: Namur University Press, 1996, 323-325. F. Lonczewski, S. Schreiber: The FUSE-System: An Integrated User Interface Design Environment. In: J. Vanderdonckt (ed.): Computer-Aided Design of User Interfaces. Namur: Namur University Press, 1996, 37-56. P. Szekely, P. Sukaviriya, P. Castells, J. Muthukumarasamy, E. Salcher: Declarative interface models for user interface construction tools: the MASTERMIND approach. In: L. Bass, C. Unger (eds.): Engineering for Human-Computer Interaction. Proceedings of the IFIP TC2/WG2.7 working conference on engineering for humancomputer interaction (Yellowstone Park, August 1995). London: Chapman & Hall, 1996, 120-150.

Adaptation des données : modifier une donnée pour III-3-4-3b Adaptation du contenu Adaptation du contenu Adaptation des données : modifier une donnée pour Qu’elle soit exploitable par le terminal cible Qu’elle soit conforme aux règles de protection des données … Adaptation dynamique (à la demande) ou statique (plusieurs versions stockées) Localisation de l’adaptation sur le client : ne convient pas aux terminaux légers sur le serveur : si tient la charge Sur un proxy entre le client et le serveur Distribué

Adaptation selon le type de la donnée source III-3-4-3b Adaptation du contenu Adaptation selon le type de la donnée source Source texte Conversion de format (html -> txt, doc -> pdf…) Résumé Traduction Compression/décompression Synthèse vocale Source image Conversion de format (jpeg -> png) Modification de résolution, nombre de couleurs… Compression / décompression (e.g. sémantique jpeg ou brute zip)

Adaptation selon le type de la donnée source III-3-4-3b Adaptation du contenu Adaptation selon le type de la donnée source Source sonore Conversion de format Synthèse textuelle et reconnaissance vocale Compression / décompression (e.g. sémantique MP3 ou brute zip) Source vidéo Conversion de format (résolution, nb images/sec) Décomposition / recomposition spatiale (zoom…) Compression / décompression (e.g. sémantique MPEG4 ou brute zip)

Opérateurs pour l’adaptation de contenu III-3-4-3b Adaptation du contenu Opérateurs pour l’adaptation de contenu Codage transcodage de média (réduction nb couleurs) transformation de modalité (texte -> audio) compression (jpeg) Format (Wav->MP3) Structure (HTML ->WML) Remplacement (image par texte descriptif) Sélection (sélection d’images moins volumineuses) Intégration (données multi-serveurs)

Adaptation de contenu - RTP Mixer III-3-4-3b Adaptation du contenu Adaptation de contenu - RTP Mixer [Mory et al 2004] Adaptation dynamique par un proxy avec cache transparente à l’application : effectuée par un intermédiaire durant le transport des données utilisation d’un profil CC/PP 2 services d’adaptation redimensionnement automatique et recadrage d’images traitement de vidéos : conversion de format, distillation

Adaptation de contenu - DCAF III-3-4-3b Adaptation du contenu Adaptation de contenu - DCAF Distributed Content Adaptation Framework [Berhe 2006] Content Servers User Adaptation Services Local Proxies Content Proxies Adaptation Services Registry Context Profile Repository Internet

Adaptation de contenu - DCAF III-3-4-3b Adaptation du contenu Adaptation de contenu - DCAF Description des services d’adaptation Services d’adaptation = services Web WSDL insuffisant Pas de coût, sémantique, temps d’exécution… Utilisation d’une ontologie Adaptation Services Ontology Context Profile (e.g format, size, network) Collects Adaptation System Content Metadata & Data (e.g. format, size) Adapted Data Delivers Processes

Adaptation de contenu - DCAF III-3-4-3b Adaptation du contenu Adaptation de contenu - DCAF Local Proxy

Adaptation de contenu - DCAF III-3-4-3b Adaptation du contenu Adaptation de contenu - DCAF AD : décision d’adaptation Calcule le type et le nombre d’adaptations nécessaires Résultat : transformation prescript A R C F Z Image (JPEG, Color) Image (GIF, BW) Resizing Format-Conversion Color Reduction

Adaptation de contenu - DCAF III-3-4-3b Adaptation du contenu Adaptation de contenu - DCAF AP : planification d’adaptation : Algo MAGG Sélectionne les services d’adaptation appropriés pour implanter le transformation prescript Notion de graphe de services d’adaptation MAGG = choix du chemin optimal dans le graphe Notre exemple: choisir l’implantation pour chaque étape R={R1, R2} C={C1, C2, C3} F={F1, F2, F3}

Adaptation de contenu - DCAF III-3-4-3b Adaptation du contenu Adaptation de contenu - DCAF Graphe de services A JPEG JPEG R1 R2 JPEG BMP JPEG C1 C2 C3 F3 GIF TIF BMP JPEG JPEG F1 JPEG F2 Fn GIF GIF Z

Adaptation de contenu - DCAF III-3-4-3b Adaptation du contenu Adaptation de contenu - DCAF MAGG A JPEG JPEG R1 R2 JPEG BMP JPEG C1 C2 C3 F3 GIF TIF BMP JPEG JPEG F1 JPEG F2 Fn GIF GIF Z

Références bibliographiques Adaptation contenu III-3-4-3b Adaptation du contenu Références bibliographiques Adaptation contenu E. Mory et al. Adaptation de contenu multimédia aux terminaux mobiles. RTSI - ISI n° spécial systèmes d ’information pervasifs n°9, 2004, Hermès: 39-60 G. Behre “Accès et adaptation de contenus multimédia pour les systèmes pervasifs"  Thèse de doctorat soutenue de 25 septembre 2006, LIRIS, INSA de Lyon G. Behre, L. Brunie, J.M. Pierson "Content adaptation in distributed multimedia systems"  Journal of Digital Information Management, special issue on Distributed Data Management. Volume 3, No 2, June 2005

Adaptation des services III-3-4-3c Adaptation des services Adaptation des services Les systèmes à services adaptables ont généralement trois parties [Cremene 04] partie modifiable : le service adaptable partie monitoring : évaluation en continu du service et de son contexte partie contrôle : définit les ordres de reconfiguration en fonction d’une logique qui lui est propre Deux techniques d’adaptation habituelles Adaptation par entités externes (exemple SECAS) Adaptation par réflexivité (exemple Dynamic TAO) Adaptation mixte (exemple AeDEN)

Encapsuler une application existante avec une couche d’adaptation III-3-4-3c Adaptation des services SECAS [Chaari 2006] Encapsuler une application existante avec une couche d’adaptation sans modification de l’application d’origine Pour pouvoir intégrer toute applications existante à l’aide de services web Adaptation en fonction du contexte des services des contenus de l’interface utilisateur

III-3-4-3c Adaptation des services SECAS : architecture

SECAS : graphe de dépendances entre entités III-3-4-3c Adaptation des services SECAS : graphe de dépendances entre entités Nœuds = entités adaptables Service, avec ses données et son interface utilisateur d’entrée/sortie Liens = dépendances d’appel

Adaptation des entités III-3-4-3c Adaptation des services Adaptation des entités Adaptation des arcs et des services Règles d’adaptation Adaptation du contenu transitant vers l’utilisateur Avec les principes définis par [Behre 2006] Adaptation de la présentation du contenu Avec les principes définis par [Chaari 2004]

SECAS : règles d’adaptation III-3-4-3c Adaptation des services SECAS : règles d’adaptation <Conditions, Actions> Conditions : sur les valeurs du contexte et les caractéristiques des services Actions : opérateurs d’adaptation à appliquer sur le graphe Evaluées À la connexion de l’utilisateur À chaque modification de la situation contextuelle Appliquées sur le graphe Par un adaptateur instancié pour chaque nœud concerné Par l’adaptation manager pour les arcs du graphe => un graphe pour chaque session en cours, qui évolue avec le contexte

SECAS : opérateurs d’adaptation III-3-4-3c Adaptation des services SECAS : opérateurs d’adaptation Operateurs sur la sortie des services (modifications des transitions du graphe) projectOutput: projection (retire des colonnes du vecteur de données) selectOutput: sélection (retire des lignes du vecteur de données) joinOutput: effectue une jointure entre plusieurs vecteurs de données addOutput: ajoute des lignes à la sortie du service

SECAS : opérateurs d’adaptation III-3-4-3c Adaptation des services SECAS : opérateurs d’adaptation Opérateurs sur les instances d’un service (modifications des nœuds du graphe) selectVersion: sélectionne une version addVersion: ajoute une version Opérateurs globaux sur le modèle fonctionnel de l’application lockService: retire le chemin d’accès au service addService: ajoute un service en feuille insertService: ajoute un service comme nœud interne

SECAS : adaptation par les DP strategy+proxy III-3-4-3c Adaptation des services SECAS : adaptation par les DP strategy+proxy Un adapter applique les règles d’adaptation DP Strategy DP Proxy

Adaptation dans les systèmes réflexifs III-3-4-3c Adaptation des services Adaptation dans les systèmes réflexifs Réflexivité Capacité d'un système à se représenter, s'observer et agir sur lui-même (reflet dans un miroir) niveau méta décrivant les composants du système Introspection donne la possibilité au système de connaître son état interne (analyse psychologique) Intercession permet au système d'adapter son fonctionnement en modifiant son propre comportement

Adaptation dans les systèmes réflexifs III-3-4-3c Adaptation des services Adaptation dans les systèmes réflexifs Sujets d'adaptation entités : méthodes, objets, composants liaisons entre entités de base ou entre entités de base et entités méta ensembles d'entités Moment d'adaptation compilation : génération de code en fonction des méta- entités chargement : altération du code compilé lors de son chargement ou modification de l’ensemble d’entités exécution : accès dynamique au niveau méta, par l'intermédiaire de proxies, ou par le support d'exécution Lemouel p50

III-3-4-3c Adaptation des services RAM : système réflexif [Bouraqadi et al 01] Reflexion for Adaptable Mobility Mobilité du code = aspect non fonctionnel, donc au niveau méta cluster = unité de mobilité de code, comportant un ensemble d’objets applicatifs une méta façade fournissant l’accès aux objets de description des politiques du cluster (migration, file d’attente de messages…) références instanciées : références locales ou distantes à d’autres clusters (gérées par la méta-façade) table de références : répertorie tous les objets instanciés, assure l’unicité des références au sein du cluster Pour une mobilité forte du code

DynamicTAO : middleware réflexif III-3-4-3c Adaptation des services DynamicTAO : middleware réflexif [Kon et al. 2000] ORB réflexif se basant sur CORBA ensemble de Component Configurators chaque composant contient un Domain Configurator qui maintient des références entre le middleware et les composants dont il dépend (Servant Configurators) le middleware contient un TAO Configurator qui maintient les stratégies du middleware (concurrence, scheduling…) contient des points d’interception qui permettent de dériver les appels faits par les composants vers les implantations des stratégies les implantations des stratégies peuvent être changées dynamiquement (chargement dynamique d’implantations) pour la reconfiguration dynamique de composants

Dream : Dynamic REflective Asynchronous Middleware III-3-4-3c Adaptation des services Dream : Dynamic REflective Asynchronous Middleware [Leclerc et al. 2005] « component-based framework for constructing, statically or dynamically, resource- aware, configurable message-oriented middleware (MOM) ». Extension du modèle à composant Fractal, basé Java Assemblage et reconfiguration dynamique de composants Composants primitifs Composants composite : composition de composants Interfaces de gestion pour chaque composant BindingControler : gestion des dépendances entre composants ContentControler: ajout, retrait de composants LifeCycleControler : démarrage, arrêt des composants.

AeDEN - Adaptation d’entités logicielles III-3-4-3c Adaptation des services AeDEN - Adaptation d’entités logicielles [Le Mouel 2003] Comportement d’exécution Stratégie d’adaptation Système d’adaptation Application Environnement Agit sur Changements dans les besoins Spécialise selon les besoins au lancement Prend en compte les caractéristiques Détecte les variations P30 à 32 Le mouel Spécialise selon les besoins au lancement : l’appli donne ses besoins quand elle est lancée, le système d’adaptation se spécialise en fonction de ces besoins. Adaptation statique Changement selon les besoins : le système d’adaptation décide d’adaptations en cours de fonctionnement (adaptations dynamiques) Prend en compte les caractéristiques : système context-aware statique (pas de variations de contexte pdt l’exé – terminal fixe, profil user fixe…) Détecte les variations : système context-aware dynamique agit sur : réaction d’adaptation sur 1 des 4 cas ci-dessus

Entité = unité logicielle de conception III-3-4-3c Adaptation des services AeDEN - entité Entité = unité logicielle de conception abstraite et spécialisable Une fonctionnalité <=> une entité un service <=> une entité spécialisée 3 aspects AInteraction (communication avec les autres entités) AImplementation (métier : traitements attendus) AState (état courant interne de la partie métier) A chaque aspect correspond un ensemble d’implantations possibles Lemouel p107

Entité abstraite + spécialisations possibles III-3-4-3c Adaptation des services AeDEN - entité Entité abstraite + spécialisations possibles

AeDEN - entité adaptative III-3-4-3c Adaptation des services AeDEN - entité adaptative Entité + entité d’adaptation adaptations par introspection puis intercession 3 types d ’adaptation : sur l ’état, sur l ’implantation, sur l ’interaction

AeDEN - introspection et intercession III-3-4-3c Adaptation des services AeDEN - introspection et intercession Chaque entité et chaque entité adaptative implante les méthodes suivantes getInteraction(), setInteraction() getImplementation(), setImplementation() getState(), setState() Chaque entité adaptative implante les méthodes getFunctionalInteraction(), setFunctionalInteraction() getFunctionalImplementation(), setFunctionalImplementation() getFunctionalState(), setFunctionalState()

AeDEN - exemple d’adaptation III-3-4-3c Adaptation des services AeDEN - exemple d’adaptation Adaptation d’implantation class ImplementationAdaptation extends StateAdaptation { // Adaptation d'implantation // protected EntityAdapter entityAdapter; // héritage de la déclaration de variable ... // public AState stateTransformation(AState st, String[] args); // héritage de la déclaration de méthode public AImplementation implementationTransformation(AImplementation im, AState st, String[] args) { AImplementation tim; // transformed implementation // Création d'une nouvelle instance d'implantation tim = new Implementation(im, st); // Ici, modifications de l'implantation tim // Puis on prévient, par exemple, les entités ayant des dépendances fonctionnelles return(tim); }

AeDEN - exemple d’adaptation III-3-4-3c Adaptation des services AeDEN - exemple d’adaptation public Event applyAdaptation(String[] args) { // méthode d'application de l'adaptation AState cfs; // current functional state AState tfs; // transformed functional state AImplementation cfi; // current functional implementation AImplementation tfi; // transformed functional implementation ... // récupèration des éléments de la structure de l'entité fonctionnelle cfs = entityAdapter.getFunctionalState(); cfi = entityAdapter.getFunctionalImplementation(); // transformations de ces éléments tfs = stateTransformation(cfs, args); tfi = implementationTransformation(cfi, tfs, args); // on reprend l ’état transformé return(entityAdapter.setFunctionalImplementation(tfi)); }

AeDEN - entité adaptative et réactive III-3-4-3c Adaptation des services AeDEN - entité adaptative et réactive Entité adaptation + entité de réaction liée à un service de notification Trnasitions = ensemble des possibilités de passage de l’adaptation courante vers les autres adaptations possibles 1 possibilité de passage correspond à une notification de changement de contexte

AeDEN - exemple de stratégie III-3-4-3c Adaptation des services AeDEN - exemple de stratégie Stratégie d’adaptation pour un service de transmissions d’images compressées Bande passante <X adaptation d’implantation GIF->JPEG75% Entité fonctionnelle (In, Im, St) Im : algo de compression GIF Bande passante <Y adaptation d’implantation JPEG75%->JPEG50% Bande passante >X adaptation d’implantation JPEG75%->GIF Entité fonctionnelle (It, Im’, St’) Im’ : algo compression JPEG St’ : taux qualité 75% Bande passante >Y adaptation d’implantation JPEG50%->JPEG75% Entité fonctionnelle (It, Im’, St’’) Im’ : algo compression JPEG St’’ : taux qualité 50%

Références bibliographiques Adaptation services III-3-4-3c Adaptation des services Références bibliographiques Adaptation services M. Cremene et al. « Adaptation dynamique de services », Decor ’2004, Grenoble, octobre 2004, pp 53-64 SECAS : Modeling and Using Context in Adapting Applications to Pervasive Environments .   T Chaari, E Dejene, F. Laforest, V. Scuturici.   ICPS'06 : IEEE International Conference on Pervasive Services 2006 26-29 June 2006, Lyon   2006 RAM : N.M.N. Bouraqadi-Saadani et al. « A reflexive infrastructure for coarse grained strong mobility and its tool-based implementation. » Int. Workshop on experiences with reflexive systems. Sept. 2001 DynamicTAO : F. Kon et al. « Monitoring, security and dynamic configuration with the dynamicTAO reflective ORB » Middleware 2000 AeDEN : F. Le Mouël « Environnement adaptatif d’exécution distribuée d’applications dans un contexte mobile » mémoire de thèse de doctorat en informatique, Université Rennes I, 1er décembre 2003 M. Leclercq, V. Quma, J.-B. Stefani, DREAM: A Component Framework for Constructing Resource-Aware, Configurable Middleware, IEEE distributed systems online, vol. 6, no. 9, September 2005

Conclusion sur l’adaptabilité III-3-4-4 Conclusion adaptation Conclusion sur l’adaptabilité Des besoins généraux [Le Mouel 2003] généricité : utilisation par plusieurs types d’applications modularité : découpage et découplage prise en compte du contexte évolutivité : intégrer de nouvelles technologies et de nouvelles fonctionnalités dynamicité : réaction aux changements sans arrêt du système efficacité : performance et stabilité

Synthèse : relations entre les niveaux III-4 Synthèse Synthèse : relations entre les niveaux 3 niveaux de recherche : matériel et système, réseaux, système d’information Pour une adaptation complète et cohérente, Associer des informations provenant des trois niveaux Utiliser des techniques d’adaptation « traversant » les niveaux =>une communication inter-niveaux des informations de contexte et des services d’adaptation de chaque niveau => L’utilisation d’un découpage en niveaux est-elle toujours intéressante ou apporte-t-elle plus de problèmes qu’elle n’en résout?

La maison de l’an 2000 de Pierre Sarda Exemples de projets La maison de l’an 2000 de Pierre Sarda Aura Oxygen Sentient computing Portolano Endeavour

La maison de l’an 2000 Pierre Sarda, 1979, TF1 http://ina.fr/archivespourtous/index.php?vue=notice &from=fulltext&full=pierre+sarda&num_notice=1& total_notices=4 NB : le lien change régulièrement… aller sur le site de l’INA et faire une recherche sur P. Sarda

AURA Distraction-free Ubiquitous Computing M. Satyanarayanan, Carnegie Mellon University Aura's goal is to provide each user with an invisible halo of computing and information services that persists regardless of location. Meeting this goal will require effort at every level: from the hardware and network layers, through the operating system and middleware, to the user interface and applications. Project Aura will design, implement, deploy, and evaluate a large-scale system demonstrating the concept of a “personal information aura” that spans wearable, handheld, desktop and infrastructure computers. http://www-2.cs.cmu.edu/~aura

Aura - Mots-clés Research Examples Users Tasks Services OS/Network HCI/Agents/Speech Research Examples Task-driven computing Rapid service configuration Energy-aware adaptation Multi-fidelity computation Nomadic data access Intelligent networking Power/bw-aware devices Wearable computers Users Tasks Services OS/Network Physical Devices

Aura - Démo M. Satyanarayanan“Research Challenges in Project Aura” Keynote address at the Ninth IEEE International Symposium on High Performance Distributed Computing, Pittsburgh, PA, August 2000

Oxygen MIT http://www.oxygen.lcs.mit.edu/

Oxygen - quelques démos Visitor guide Multilingual speech Software proxy Intelligent Meeting Room - collaboration

Sentient Computing project AT&T Laboratories Cambridge http://www.cl.cam.ac.uk/research/dtg/research/wiki/Sentie ntComputing Sentient Computing : using sensors and resource status data to maintain a model of the world which is shared between users and applications Bats small (8cm long) devices, with a unique id, an ultrasound transmitter and a radio transceiver, 2 buttons and a beeper located by a central controller, and the world model stores the correspondence between bats and their owners, applying algorithms to the bat location data to determine the location of the person or object which owns it.

Sentient Computing project Objets CORBA données de localisation et d’état des ressources tout objet du monde réel (personnes, ordinateurs, téléphones..) Chaque objet fournit état + API de l’objet réel Les objets gèrent eux-mêmes les transactions, les sessions, la distribution des événements...

Sentient - Applications A browser allows a user to see what's going on anywhere in the building Phone someone by pointing at his representation on the 3D model

Sentient - Applications Follow-Me : simply teleport my desktop to another PC using my bat, and then teleport away when I'm finished. Smart Posters : create a `button' anywhere in the environment. a button can be a small space anywhere in a building .To press the button, the user just puts the bat on the label and clicks a button on the bat.

User Interfaces, new interaction modes Network Infrastructure Portolano http://portolano.cs.washington.edu an infrastructure based on mobile agents that interact with applications and users. Data-centric routing automatically migrates data among applications on the user’s behalf. Data thus becomes “smart,” and serves as an interaction mechanism within the environment. User Interfaces, new interaction modes Network Infrastructure Distributed Services

Portolano - Mots-clés Connecting the physical world to the world-wide information fabric instrument the environment: sensors, locators, actuators universal plug-and-play at all levels: devices to services optimize for power: computation partitioning, communications optimization intermittent communication: new networking strategies Get computers out of the way don’t interfere with user’s tasks diverse task-specific devices with optimized form-factors wide range of input/output modalities Robust, trustworthy services high-productivity software development self-organizing, active middleware, maintenance, monitoring higher-level, meaningful services

The Endeavour Expedition: Charting the Fluid Information Utility specification, design, and prototype implementation of a planet- scale, self-organizing, and adaptive Information Utility. ability of processing, storage, and data management functionality to arbitrarily and automatically distribute itself among Information Devices and along paths through scalable computing platforms integrated with the network infrastructure, compose itself from pre-existing hardware and software components, satisfy its needs for services while advertising the services it can provide to others, while negotiating interfaces with service providers while adapting its own interfaces to meet "contractual" interfaces with components it services. http://endeavour.cs.berkeley.edu/

Conclusion

Trois niveaux de recherche très actifs Conclusion Trois niveaux de recherche très actifs Évolution rapide des matériels et systèmes : RFID, capteurs Déploiement de réseaux : IPv6, réseaux ad hoc Systèmes d’information : middleware adaptatifs contenu et services Efforts de standardisation Approches transversales pour ces trois niveaux Effort en terme de cadre de conception et de développement

Autres domaines intéressés par les systèmes pervasifs Perspectives Autres domaines intéressés par les systèmes pervasifs Interactions homme-machine (interactions multimodales entre autres) Agents logiciels (pro-action) Intelligence artificielle (décision et prévision) L’informatique pervasive va avoir un grand impact sur notre vie de tous les jours et sur la société Conséquence économiques, sociales et culturelles?

Perspectives Améliorations Lacunes Context-awareness et adaptabilité Architectures P2P, grilles dynamiques Lacunes Outils de test – simulation – validation Pro-action