HABILITATION A DIRIGER DES RECHERCHES. Une Grille Pervasive vue du coté des données

Dimension: px
Commencer à balayer dès la page:

Download "HABILITATION A DIRIGER DES RECHERCHES. Une Grille Pervasive vue du coté des données"

Transcription

1 N d ordre : HDR Année 2005 HABILITATION A DIRIGER DES RECHERCHES Spécialité Informatique Une Grille Pervasive vue du coté des données présentée devant L Institut National des Sciences Appliquées de Lyon et l Université Claude Bernard - LYON I par Jean-Marc PIERSON Soutenue le 17 Novembre 2005 Rapporteurs Mme COLLET Christine Professeure INP Grenoble M. HARING Günter Professeur Univ. de Vienne, Autriche M. PRIOL Thierry Directeur de Recherche IRISA Rennes Jury M. BRUNIE Lionel Professeur INSA de Lyon Mme COLLET Christine Professeure INP Grenoble M. COSNARD Michel Professeur Univ. de Nice Sophia Antipolis M. HACID Mohand-Saïd Professeur Univ. Claude Bernard, Lyon I M. HAMEURLAIN Abdelkader Professeur Univ. Paul Sabatier, Toulouse M. MEHAUT Jean-François Professeur Univ. Joseph Fourier, Grenoble M. PRIOL Thierry Dir. de Recherche IRISA Rennes Laboratoire d InfoRmatique en Images et Systèmes d information - UMR CNRS 5205

2 2

3 Table des matières 1 Introduction 5 2 Motivation et cas d utilisations 11 3 Briques pour la gestion de données 17 4 Se comprendre, communiquer, collaborer? L accès aux données L apport de la sémantique La gestion des réplicas La gestion des caches Confiance, ou non? Authentification Contrôle d accès Stockage crypté S adapter L adaptation au cœur du réseau Une architecture distribuée à base de services Compléments sur la notion de contexte L adaptation à une Grille Pervasive Intégration, interactions, dépendances Quels services, où, et pourquoi faire? Schéma simplifié de l architecture Illustration sur un cas d utilisation Au final, quel déploiement? Pourquoi ça n existe pas encore? Conclusions de cet essai, perspectives 73 3

4 4 TABLE DES MATIÈRES A Sélection d articles de recherche 83

5 Chapitre 1 Introduction 7 mai 2005 : je me rends en avion à Cardiff, où se tient la conférence CC- Grid 05. Je feuillette le magazine de la compagnie aérienne, et un article de Tim Berners-Lee, le père du World Wide Web, et actuel directeur du W3C, attire mon attention. Il explique pourquoi, à son avis, le web a eu tant de succès en un laps de temps relativement court, depuis le début des années S il faut retenir une chose de son propos, c est la notion de communication, d échange entre les usagers du web. Ce qui a permis l essor du web est la possibilité pour tout un chacun de pouvoir partager ses opinions, ses points de vue, ses informations, de manière facile, transparente par rapport à l infrastructure informatique et réseaux nécessaire à sa mise en œuvre. Les outils informatiques à disposition sont devenus utilisables facilement pour permettre aux personnes d assouvir leurs envies de partage, la création de communautés d intérêt a été rendue facile. En un mot, l échange d information est passé d une affaire de spécialistes (les premiers réseaux existent depuis les années 70) au grand public. Il est maintenant commun de créer sa page web, son blogue personnel, de rentrer dans une communauté, en ayant une connaissance informatique limitée. A ce point de mon propos, je me permets une petite digression personnelle. Pour ma part, je pense que la communication s est réduite, au contraire de la pensée commune. Le sens étymologique du terme communication inclut le fait d échanger (par la parole, le geste, le regard) avec un partenaire. Aujourd hui, paradoxalement, l homme moderne a de plus en plus de moyens de communications, mais il communique, il échange de moins en moins : on donne son point de vue, on offre ses idées, mais sans réelle interaction, sans réciprocité. Tout ou partie se fait dans le cyber-espace, hors des rapports humains propres à une réelle communication. Malgré tout, l information disponible s est multipliée, que ce soit pour communiquer (au sens pur) ou pas, chacun y trouvera son propos. Et c est ce point qui m intéresse. 5

6 6 CHAPITRE 1. INTRODUCTION Pour Tim Berners-Lee, une des clés de cette réussite réside donc dans l ensemble des moyens informatiques développés à cette fin (à mon sens, d autres considérations d ordre sociologique ou sociétal rentrent en jeu dans ce besoin de communication et de partage virtuel ). Le protocole HTTP, le langage HTML sont arrivés au bon moment pour canaliser ce désir. Le développement des infrastructures réseaux a été poussé par les utilisateurs eux-mêmes, forçant en quelque sorte les opérateurs de télécommunications, les fournisseurs d accès internet à ouvrir les voies de l autoroute de l information, expression consacrée en France. Il semble évident que sans les utilisateurs finaux, dont le nombre a explosé depuis 10 ans, ces autoroutes ne seraient aujourd hui que des sentiers semés d embûches. Dès 1996, le terme de Grilles de Calcul apparaît : il s agit alors de faire coopérer dans un même but des ordinateurs puissants dispersés sur le territoire. On parle alors de métacomputing. Les applications sont alors celles qui, traditionnellement, demandent beaucoup de puissance et de ressources de calcul : simulations de physique nucléaire, prédictions météorologiques, aérospatiale, astrophysique. La définition suivante de Ian Foster, considéré comme l un des pères de la Grille actuelle, reflète l envie de s affranchir à la fois des limites des frontières administratives mais aussi de la connaissance obligatoire de l infrastructure réseau sous-jacente. La première définition donnée par I. Foster et C. Kesselman date de 1998, dans le livre The Grid : Blueprint for a New Computing Infrastructure [17] : A computational grid is a hardware and software infrastructure that provides dependable, consistent, pervasive, and inexpensive access to high-end computational capabilities.. En 2000, dans l article The Anatomy of the Grid [23], avec S. Tuecke, il modifia cette définition en ajoutant des éléments sociaux et de politique d accès, écrivant alors que les grilles de calcul sont concernées par : coordinated resource sharing and problem solving in dynamic, multi-institutional virtual organisations. Après avoir partagé leurs informations, leurs résultats d analyse et de calcul (d abord par FTP, par courrier électronique), après avoir organisé des recherches à distance, les consommateurs de puissance de calcul peuvent maintenant partager ces ressources de calcul, utiliser celles des autres chercheurs, et également partager encore plus facilement leurs résultats. On peut noter qu à l origine d Internet lui-même, lorsque le Département de la Défense américain a créé ARPANET (l ancêtre de l internet actuel), c était d abord dans un souci de partage des ressources informatiques : chaque département informatique voulait la machine la plus puissante, et l agence ARPA a préféré créer un réseau entre ces centres plutôt que de dépenser

7 l argent dans des ordinateurs isolés. On peut dire qu il s agissait déjà de Grille de Calcul...(source : interview dans Newsmakers de Vint Cerf, co-inventeur de TCP/IP, considéré par beaucoup comme le père de l internet, 3 mars 1997). Cependant, aujourd hui encore, plusieurs années après le lancement des grilles de calcul, après de nombreux projets financés et aboutis, la Grille de calcul reste encore une affaire de spécialistes. Certes, les gros demandeurs de calcul cités plus haut, ainsi que des nouveaux arrivants (comme dans le domaine bio-médical par exemple) ont des activités dans les grilles et tirent régulièrement les fruits de ces usages. Malgré tout, il reste très compliqué, pour un scientifique, voire pour un informaticien non spécialiste, de rendre disponible sur la grille une application quelconque. Toutes les applications n ont pas vocation à utiliser la grille est une devise communément admise. Pourquoi? Ne serait-il pas plus facile de penser plus librement, plus largement, plus universellement, sur l usage d un ensemble de ressources interconnectées? Je crois que dans un avenir plus ou moins lointain, les utilisateurs s approprieront la Grille comme ils se sont appropriés le World Wide Web. Pourquoi faire? Parce qu elle leur apportera un moyen d échanger, de communiquer, plus facilement. De la même manière qu aujourd hui les usagers ne savent pas quelles sont les ressources matérielles (serveurs, réseaux) qui sont utilisées pour mettre à disposition leurs contenus, ils utiliseront la Grille sans vraiment s en rendre compte. 7 Les systèmes pervasifs [56] ont connu leur essor depuis quelques années avec l avènement des technologies sans-fil et des dispositifs nomades, rendant possible l omniprésence de l information. Les systèmes d information pervasifs s intéressent aux méthodes permettant d acheminer l information pertinente à l utilisateur, quand il en a besoin, où il en a besoin, d une manière non intrusive. Ces systèmes s appuient sur les technologies disponibles à l utilisateur : WiFi, Bluetooth, GPRS, UMTS,... pour les communications ; PDA, Smart-phones, ordinateurs portables,... pour les dispositifs de consultation de l information. Les sources d information exploitables dans une situation donnée (un utilisateur, un instant, un lieu, un intérêt) sont nombreuses et très hétérogènes en niveau sémantique (l information provient de capteurs de température, de localisation -GPS-, mais aussi de documents structurés ou semi-structurés -page web, documents textes-, ou de bases de données). De même, les services disponibles aux utilisateurs sont potentiellement nombreux, allant de la visualisation de documents vidéos à la traduction de documents, en passant par la production de données sonores ou la sélection d une synthèse textuelle sur un sujet précis.

8 8 CHAPITRE 1. INTRODUCTION Le contexte d utilisation de l information est au cœur des préoccupations dans les systèmes pervasifs. Il s agit bien de fournir la bonne information à l utilisateur, en fonction des paramètres de son environnement, ainsi qu en fonction de ses préférences et capacités. L information a alors une valeur très importante car elle est personnalisée. Les systèmes d information pervasifs ont toutefois encore du mal à entrer dans la vie quotidienne, pour des raisons principalement pratiques dans un premier temps : les configurations sans-fil restent un peu compliquées, les interfaces utilisateurs sont relativement pauvres et l information visualisable mal adaptée à ces supports. Je crois à terme en la convergence vers une seule utilisation, transparente à l utilisateur, des deux technologies : systèmes pervasifs et grille de calcul. Ainsi, j imagine une Grille Pervasive, intégrant les mécanismes d accès nomades, mobiles, à l information utile, disponible, et contextualisée, s appuyant sur des services de grilles de calcul pour réaliser un ensemble de traitements (au sens large, regroupant calcul et stockage). L utilisateur sera au centre de cette convergence, et la portera, la supportera (au sens de supporter, aider, appuyer) et entraînera par là même, un peu comme ce qui a été réalisé au niveau du WWW, un développement rapide et inéluctable de cette Grille Pervasive. On peut noter à ce point de mon document que la définition de I. Foster d une grille de calcul donnée plus haut inclus le terme pervasif. Pour lui, il s agissait alors de mettre les puissances de calcul à la disposition transparente des utilisateurs potentiels, à la manière dont l électricité est mise à disposition des citoyens des pays industrialisés. Ma vision de Grille Pervasive me semble plus large, incluant le contexte des utilisateurs finaux dans son utilisation, comme il sera détaillé dans le reste du document. Je vais dans ce document montrer les résultats que nous avons obtenus dans cette direction et quels sont les développements nécessaires aujourd hui à ce changement de culture et d usage. Je proposerai ainsi un certain nombre de travaux qui vont à mon sens dans cette direction. Je me focaliserai principalement du coté des données, et non des calculs. Je pense en effet que les données doivent être au centre de toute tentative d architecture commune, puisqu elles représentent la valeur intrinsèque des communications, interactions, échanges entre usagers de cette Grille Pervasive. Le plan de ce document reflète divers aspects cohérents de la gestion de

9 données dans une Grille Pervasive. Dans un premier temps (chapitre 2), j exposerai quelques cas d utilisations d une telle Grille Pervasive, en exposant les difficultés d une mise en application effective. Ensuite, je donnerai une idée générale des éléments d une Grille Pervasive en chapitre 3, puis je rentrerai dans les détails de certaines briques de bases constituant une telle Grille. Tout d abord, pour échanger, il faut pouvoir se comprendre, communiquer et collaborer (chapitre 4), avoir confiance dans le système (chapitre 5), enfin s adapter aux exigences du partenaire de l échange (chapitre 6). Finalement, je dresserai le schéma global d une telle architecture (chapitre 7) et les interactions entre les différents éléments. J exposerai alors à titre d exemple (section 7.3) comment cette architecture permet de résoudre un cas d utilisation présenté en section 2 avant d évoquer des problèmes de déploiement en section 7.4. Finalement, je parlerai brièvement de projets existants tendant aussi vers une Grille Pervasive en montrant les limites des approches en section 7.5. Enfin, je conclurai et donnerai quelques perspectives de développements personnels en chapitre 8. 9

10 10 CHAPITRE 1. INTRODUCTION

11 Chapitre 2 Motivation et cas d utilisations L idée d une Grille Pervasive a progressé depuis que je suis venu travailler à l INSA de Lyon, au laboratoire LIRIS, en septembre J ai apporté au sein de l équipe Système d Information Communicants une compétence en systèmes distribués, au moment où les grilles de calcul d une part et les systèmes pervasifs d autre part prenaient leur envol. Nous nous sommes vite aperçus que ceux-ci oubliaient la plupart du temps la gestion des données, parent pauvre des deux thèmes. Pour la grille de calcul, l important était d abord au niveau système de pouvoir lancer des travaux sur des ordinateurs distants. Les données étaient peu considérées (voire pas du tout), et un accès simple sur fichier suffisait dans les applications initiales des grilles de calcul. Pour les systèmes pervasifs, le challenge était d abord de pouvoir faire communiquer divers dispositifs, et d inventer les applications qui s en serviraient. Historiquement, le groupe de recherche que j ai rejoint avait une forte compétence en systèmes d information multimédias, et plus particulièrement dans le domaine d application médical. Nous avons participé depuis 2001 a plusieurs projets dans ce contexte particulier, qui a l avantage de regrouper un grand nombre de contraintes en matière de distribution, de sécurité, de collaboration : le domaine médical représente donc un terrain d expérimentation idéal pour nos approches et nos algorithmes. Le premier cas d utilisation d une Grille Pervasive est donc tout naturellement une Grille Pervasive Médicale. Il est issu des réflexions que nous avons pu mener dans l équipe sur ce sujet, et prolonge plusieurs projets (en cours ou terminés : ACI GRID Medigrid [32], ACI Masse de Données GGM [38], projet région RagTime [44], projet européen EGEE [15]) dans une perspective d intégration de travaux connexes. 11

12 12 CHAPITRE 2. MOTIVATION ET CAS D UTILISATIONS Monsieur Toulemonde habite à Lyon, et part quelques jours à Vienne, en Autriche. Malheureusement, sur place, une voiture heurte monsieur Toulemonde, qui reste sur la route, inconscient. Les secours arrivent. Une seule information est disponible sur monsieur Toulemonde : un identifiant numérique unique (par exemple une sorte de carte à puce de type Carte Vitale), permettant aux secours d accéder rapidement à son dossier médical (dont au moins une partie est en France, peut-être à Lyon), d y trouver les informations importantes (dans cette situation, il s agit par exemple des allergies aux médicaments, de ses antécédents opératoires -a-t-il déjà été anesthésié, avec quel produit? a-t-il eu une opération, a-t-on un compte rendu opératoire, des radiographies?) qui permettront d adapter au mieux les soins à lui apporter. Le cas présenté ici reste cependant limité et n aborde pas toutes les facettes d une Grille Pervasive Médicale (comme son utilisation en épidémiologie, en recherche bio-médicale, en médecine génique, etc...), mais suffit à illustrer un certain nombre de thèmes de recherche. Je prends l hypothèse pour l instant irréaliste (idéaliste?) que le problème de l identifiant unique est résolu (ce point particulier est un sujet politique, éthique, et qui est loin d être résolu, déjà au niveau européen ; au niveau français, le numéro de sécurité sociale ne peut pas servir à ça, pour diverses raisons : les enfants avant 12 ans partagent celui d un des parents, et de plus ce numéro ne peut-être utilisé légalement pour identifier une personne, fait réaffirmé par la CNIL pour la création du DMP, Dossier Médical Personnel). Mais revenons à notre exemple. Lorsque les secours arrivent, l ambulancier possède un terminal mobile (PDA, ordinateur portable) sur lequel il peut consulter le dossier médical de Monsieur Toulemonde. Ce dossier médical est dans un autre pays et dans une autre langue. Le contenu de ce dossier doit être accessible de manière sécurisée : seules les personnes accréditées peuvent accéder à certaines parties du dossier, et idéalement les accréditations sont données par Monsieur Toulemonde luimême. Le dossier médical doit être retrouvé à partir des différents lieux qui possèdent des informations sur ce monsieur : en effet, il a sûrement fréquenté un certain nombre de sites de soins, et son dossier médical se trouve distribué, éparpillé sur le territoire. Une fois le contenu retrouvé, filtré en fonction des droits et des besoins du secouriste, il s agit de l adapter au mieux aux capacités du terminal de consultation : par exemple ici, des parties textuelles sur les antécédents opératoires seront traduites vers la langue du secouriste, les images de radiographies seront adaptées aux capacités de consultation,... Pour mener à bien ce scénario, outre le problème évoqué de l identification, les techniques, mécanismes, protocoles existent aujourd hui, mais en ordre dispersé, et proposent des réponses partielles à l un ou l autre des problèmes évoqués.

13 Un autre champ d étude sur lequel nous avons travaillé concerne le domaine de l environnement. J ai participé à plusieurs projets de visualisation de la pollution de l air par le passé (projet Opal Air à Calais, Coparly à Lyon), et nous avons travaillé avec l AFSSE (Agence Française de Sécurité Sanitaire et Environnementale) pour la création d un Observatoire des Résidus des Pesticides. Un des buts communs à ces projets, et plus généralement dans le domaine de l environnement, est l information au citoyen (réaffirmé régulièrement par les pouvoirs publics). Ces projets nous ont amenés à concevoir le scénario suivant : représentons nous Monsieur Toutunchacun, un citoyen se promenant en ville. Il ressent une gène respiratoire, et se demande quelle est actuellement la qualité de l air qu il respire. Il se connecte grâce à son téléphone smartphone GPRS à un portail d information (l information du public est obligatoire pour un certain nombre de polluants) pour retrouver une carte lui donnant la concentration des polluants de manière continue. Dans cet exemple, les problèmes sont différents que pour Monsieur Toulemonde : d une part les données sont publiques, d autre part elles sont dynamiques. La récupération des différentes concentrations mesurées sur les capteurs est dors et déjà possible. Mais il est fort improbable que Monsieur Toutunchacun se retrouve près d un capteur (à titre d exemple, dans la Communauté Urbaine de Lyon, il y a seulement 13 capteurs). L extrapolation entre les différents points de mesures pour recréer une carte continue, reliée à la géographie urbaine (présence d immeuble, de courants aériens, de parcs) requiert une forte puissance de calcul et n est pour l instant pas disponible en temps réel sur les sites d information légaux : ils servent dans des rapports aux décideurs, a posteriori. L utilisation de la grille de calcul et de ressources supplémentaires permettrait au système de prédire en temps pertinent la carte de pollution. Je défini le temps pertinent comme le temps au delà duquel l information n est plus utile à son demandeur, principalement quand celui-ci a quitté les lieux, ou au delà du temps qu il avait imaginé pour cette tâche. L utilisation de la Grille offrirait à Monsieur Toutunchacun une information une fois encore adaptée aux possibilités du terminal (carte 3D, carte 2D, quelles taille et résolution) de consultation (ici pas très grand, typiquement 120 pixels de coté, pour la partie visible sur un téléphone). Dans cet exemple, les données brutes sont captées, elles sont analysées, manipulées, pour en sortir une vue adaptée pour l utilisateur (fonction de ses préférences, de ses capacités de consultation). De plus, ce calcul pourrait resservir à d autres citoyens dans le même environnement : les données brutes, les résultats devraient être gardés en mémoire du système dans des zones de caches afin d être accessibles plus rapidement. Une autre possibilité apparaît dans le cas où Monsieur Toutunchacun voudrait parta- 13

14 14 CHAPITRE 2. MOTIVATION ET CAS D UTILISATIONS ger ce résultat avec son voisinage connu (ses amis, ses connaissances) mais pourquoi pas également avec son voisinage inconnu (les autres citoyens passant à proximité), devenant alors lui-même fournisseur d une information, créant son propre réseau d interactions et d échanges. Ces derniers aspects nous rapprochent de la vision exposée avant sur l acception de la technologie pour échanger avec les autres. Le troisième et dernier champ d application d une Grille Pervasive que je présenterai ici est lié au tourisme. Nous avons organisé une collaboration avec l Université de Venise Ca Foscari (A. Celentano) sur la gestion et l accès à l information culturelle dans les villes d art, basée sur les systèmes pervasifs. J étends ici le cas d utilisation à la Grille Pervasive. Madame Travel planifie un voyage à Venise. Elle consulte des bases documentaires (CD/DVD ROM, sites internet,...) sur les musées, les lieux touristiques et l Histoire de la cité lacustre, informations qu elle sauvegarde (met en cache) sur la Grille Pervasive, dans un lieu de stockage qui lui est dédié. Une fois sur place, elle se rend au musée afin d admirer in situ les œuvres disponibles. Le musée est équipé en technologies sans-fil (Bluetooth, WiFI) et d un système d information géolocalisé, permettant d avoir, quand un visiteur passe devant un tableau par exemple une description du tableau. Cette description existe dans le système d information du musée en plusieurs langues (italien, anglais, japonais), et à plusieurs niveaux de détails (sur le tableau, l artiste, le courant artistique,...). Madame Travel aimerait pouvoir agréger l ensemble des documents qu elle a à sa disposition afin de pouvoir les replacer dans le contexte historique et le contexte local : les documents fournis par le musée, les documents qu elle a déjà consultés, ainsi que des sources documentaires externes accessibles par Internet. De plus, elle aimerait pouvoir consulter en français les documents, que ceux-ci soient fouillés pour en extraire des liens culturels et historiques, et qu enfin le résultat lui soit présenté sur son PDA. La fouille peut se faire potentiellement sur un grand nombre de documents et nécessite une puissance de calcul et de stockage bien supérieure aux capacités du terminal de Madame Travel. Une fois les documents analysés, une traduction externe est nécessaire, ainsi qu une adaptation aux capacités de visualisation du terminal. Une difficulté ici est la gestion de l adaptation de présentations multimédias, avec une gestion du temps de la présentation : si l adaptation transforme une vidéo en images fixes, que se passe-t-il avec la bande sonore d accompagnement, par exemple? La donnée multimédia ne suffit pas et la sémantique associée est plus importante dans ce cas. De plus, dans ce scénario, la qualité de service est importante, afin de servir sans les déformer et dans un temps pertinent les

15 informations à Madame Travel. La fouille réalisée par notre touriste peut s avérer utile à d autres touristes, et les informations glanées à l extérieur pourraient être répliquées au musée, lequel enrichirait alors sa connaissance globale : des requêtes subséquentes aux mêmes documents se feraient alors plus rapidement, et les autres visiteurs enrichiraient aussi leur expérience au musée. 15 Les besoins que nous pouvons faire ressortir de ces cas d utilisation en ce qui concerne la gestion des données sont les suivants : sécurisation de l accès aux données personnelles : les données des patients (par exemple) ne doivent pas circuler en clair, et leur accès doitêtre contrôlé nécessité de pouvoir déléguer de manière fine et souple les droits d accès sans être connecté à un système centralisé : l ambulancier doit pouvoir accéder aux données, le patient lui donne l accès immédiatement recherche efficace (et donc indexation) sur les données réparties dynamiquement : les données du patient, les informations de pollutions, les informations touristiques sont stockées ou issues de sites distribués, pas forcément sur des sites connus à l avance (apparition de nouveaux fournisseurs de données, création de nouvelles données pour un patient dans un nouvel environnement) prise en compte du contexte dans l acheminement de l information : le secouriste, le piéton, la touriste veulent pouvoir consulter sur un terminal mobile l information recueillie interaction et interopérabilité avec des services disponibles sur le réseau pour réaliser des traitements lourds, mais de manière transparente à l utilisateur enchaînement de services de nature différente (changement de langue, fouille) et localisés dans des lieux épars stockage temporaire des données calculées pour éviter des calculs redondants ou des accès coûteux en ressources création dynamique de communautés d intérêts : un touriste veut profiter de l expérience des autres visiteurs

16 16 CHAPITRE 2. MOTIVATION ET CAS D UTILISATIONS

17 Chapitre 3 Briques de base pour la gestion de données dans une Grille Pervasive Une Grille Pervasive se doit d être centrée sur l utilisateur, et plus particulièrement dans son envie d échanger, comme évoqué en chapitre 1. L idée principale est que l utilisateur final de cette grille n a pas à se soucier des technologies sous-jacentes. Il doit, de plus, ne pas être limité dans les actions qu il veut entreprendre (en terme de temps de calcul par exemple, ou de découvertes des services), ni par les capacités de son terminal d interaction actuel (stockage, affichage, calcul). Deux sortes d entités interviennent dans la réalisation d une Grille Pervasive : d une part un ensemble relativement stable de ressources de calcul et de stockage, d autre part des ressources plus volatiles, dont l utilisation est plus contrainte. Il faut noter ici que ce n est pas une question de puissance de calcul ou de stockage qui distingue les deux catégories, mais plutôt le comportement des entités au cours du temps. Ainsi, un cluster non disponible sera considéré comme instable, alors qu un téléphone GPRS/UMTS tout le temps accessible sera pour sa part stable. Toutefois, dans l idée générale, et pour simplifier, on peut considérer que l architecture stable est constituée des actuelles grilles de calcul alors que la partie instable est représentée par les dispositifs mobiles de type PDA ou Smartphone. Je n ai pas l intention ici de décrire un middleware complet car cette description m éloignerait de trop de la gestion de données, thème principal de ce document. Les idées exposées ici sont issues de discussions passionnantes dans l équipe, notamment pour la création d une plate-forme pour les systèmes pervasifs (PerSE - Pervasive System Environment [47]), ainsi que de réflexions au sein du Global Grid Forum autour de l architecture 17

18 18 CHAPITRE 3. BRIQUES POUR LA GESTION DE DONNÉES OGSA (Open Grid Service Architecture) [2] (voir chapitre 7, section sur le déploiement). A mon sens, les briques de base concernant les données dans une telle architecture sont les suivantes : (certaines d entres elles seront détaillées dans les chapitres suivants) stockage : les données disponibles sont stockées soit sur une infrastructure stable (où leur pérennité est assurée par des sauvegardes régulières), soit sur des dispositifs instables. Le service de stockage permet à un utilisateur d enregistrer des données sur le système. Cet utilisateur est la source d autorité de ses données et en contrôle l accès, la réplication,... Il est à noter que toutes les données n ont pas vocation à être stockées : par exemple, celles issues de capteurs ne sont pas forcement toutes stockées, faute de place ; d autres resteront dans des zones de stockage en dehors de la Grille Pervasive, pour des raisons de sécurité et ne seront jamais stockées sur celle-ci telles quelles. réplication : deux motivations principales plaident pour un service de réplication. Tout d abord, l efficacité du système est renforcée quand plusieurs copies d une donnée existent. En ajustant l emplacement des copies en fonction des usages de la donnée, l une d entre elle à des chances d être assez proche de son utilisateur. La seconde motivation vient pour assurer une continuité d accès, pour lutter contre l instabilité. En effet, certains dispositifs étant instables, réaliser une copie d une donnée la rend plus disponible. Par contre, faute de place, toutes les données ne peuvent pas être répliquées et un mécanisme de choix judicieux doit exister. cache : la présence d un système de cache permet d améliorer l efficacité du système en gardant temporairement certaines données accédées pour éviter d avoir à renouveler des requêtes qui peuvent s avérer coûteuses. La différence avec le service de réplication est surtout dans son caractère beaucoup plus système, caché, pour l utilisateur final. Alors que ce dernier peut contrôler le nombre de réplicas d une donnée, les données cachées lui sont inconnues. Le service de cache sert d intermédiaire entre les requêtes aux données par les utilisateurs et les données elles-mêmes. Pour être efficaces, les divers caches présents doivent collaborer, grâce à la sémantique d usage, afin d optimiser l espace de stockage disponible pour le cache, et améliorer le hit-rate (pourcentage de requêtes aux données dans le cache en rapport aux requêtes hors cache) lors des accès aux données. accès : le service d accès à deux rôles principaux. Tout d abord il récupère les données stockées dans le système (par le système de stockage), et il s interface aussi avec les données externes : les données

19 brutes, issues de capteurs, dans des fichiers plats, dans des bases de données, dans des systèmes d information externes... Il réalise la médiation entre les sources de données et les applications/utilisateurs qui en ont besoin. indexation : pour pouvoir accéder efficacement aux données, il faut être capable de les indexer correctement, notamment pour savoir où elles se trouvent. Une indexation sémantique des documents est souhaitée car elle permet deux apports essentiels. En premier lieu, elle autorise la construction d une vision sémantique des données présentes, pour éventuellement regrouper géographiquement (sur des sites proches) les données thématiquement proches (ou leurs copies). En effet, il est probable que des données proches sémantiquement seront accédées par des utilisateurs proches : les informations concernant un campus universitaire sont en priorité accédées par les usagers du campus, par exemple. En second lieu, l information sémantique permet d optimiser les politiques de remplacement de données dans les caches en ne gardant que les thèmes chauds. Enfin, elle permet de gérer la sécurité d accès de manière globale sur un ensemble de documents. recherche : ce service s appuie bien entendu sur le précédent pour les données qui sont indexées. Par contre, des requêtes plus complexes sont envisageables, où le résultat n a pas encore été calculé. La recherche hybride se fait alors à la fois sur des informations stockées et sur des résultats calculables. A titre d exemple, le citoyen peut faire une recherche de tel polluant à l endroit précis où il se trouve, agrégée sur les douze dernières heures. Dans le cas général, des calculs seront mis en œuvre pour construire une vue adéquate répondant à la requête de l utilisateur. transfert : le service de transfert s intéresse au transfert brut suivant les meilleurs protocoles de l information retrouvée. Il peut utiliser par exemple une sorte de FTP pour les fichiers, du streaming pour les documents audio-vidéos, des transferts UDP ou TCP, sur une infrastructure réseau de type GPRS, BlueTooth, WiFi, suivant la qualité de service souhaitée par l utilisateur et les conditions techniques particulières à sa disposition. sécurité : le service de sécurité se décompose en plusieurs entités. Tout d abord, il faut avoir confiance en son partenaire, et donc le reconnaître : c est l identification puis l authentification. Celle-ci n est pas triviale lorsqu on a affaire à une multitude de sites, et que l on ne veut pas que l utilisateur soit (re-)connu partout, sans toutefois le gêner dans son utilisation du système. Typiquement, un mécanisme de Single Sign On, permettant à l utilisateur d être connu par son termi- 19

20 20 CHAPITRE 3. BRIQUES POUR LA GESTION DE DONNÉES nal doit suffire. Le second aspect de la sécurité concerne l autorisation d accès aux données stockées. Un accès à grain fin, géré au plus proche des données, est nécessaire pour permettre aux sources d autorité des données d attribuer les droits minimaux aux utilisateurs concernés. Enfin, le cryptage des données stockées est souhaitée afin d éviter tout problème lié à la confidentialité de certaines données sensibles (milieu médical notamment). Le cryptage de la communication elle-même fait partie du service de transfert. adaptation : une fois les données accédées (information retrouvée, calculée, droits vérifiés), il convient d adapter les données avant de les proposer à l utilisateur final : son terminal de consultation n a pas forcement la possibilité d offrir les résultats à la requête (si le résultat est sonore et que le dispositif ne possède pas de sortie audio), l utilisateur lui-même peut avoir un profil qui nécessite une adaptation des données (par exemple la langue de consultation), le réseau de transport n est peut-être pas adapté (impossible par exemple d avoir une qualité de vidéos importante sur du BlueTooth). Se pose alors la question de qui fait cette adaptation? Des services d adaptation sont disponibles à travers le système, stockés sur une infrastructure stable (par exemple un service de traduction de type BabelFish) ou disponibles sur des dispositifs instables apparaissant et disparaissant spontanément. La combinaison, l enchaînement de divers services, suivant leur sémantique opérationnelle, permet d adapter les données au contexte d utilisation. manipulation, traitement : l adaptation décrite ci-dessus est un cas particulier de traitement pouvant être effectué sur les données. Une fois des données récupérées, l utilisateur peut vouloir exécuter des traitements dessus. Toutes les ressources de calcul disponibles sur lesquelles les traitements sont disponibles (où exécutables, c est-à-dire où l on peut déployer dynamiquement le traitement) peuvent collaborer pour résoudre le problème posé. Les infrastructures stables sont les plus sollicitées, mais rien n empêche également d utiliser au besoin (si aucune autre ressource n est accessible par exemple) d utiliser son voisinage et les ressources instables qui le composent. Il est alors nécessaire de pouvoir communiquer avec ces dispositifs pour leur envoyer des tâches, en suivre l évolution, les faire collaborer. L orchestration de ces tâches entre dans ce service. visualisation : une fois les données prêtes pour l utilisateur, il est nécessaire de choisir un mode de visualisation. Certaines données peuvent-être directement visualisées par le terminal de l utilisateur, d autres nécessitent des calculs lourds (projection, rotation, synthèse) et ne peuvent être faites sur celui-ci. Il s agit ici d un cas particulier

21 du précédent concernant le traitement des données récupérées. J ai travaillé à Calais, entre 1997 et 2001, sur le système CompoVis de visualisation distribuée [28] [27], à base de composants indépendants et combinables permettant de visualiser des données environnementales (pollution de l air). Ces travaux pourraient-être repris dans le cadre du présent projet de Grille Pervasive. interaction homme-machine : les intentions de l utilisateur et son retour quant à l utilisation du système (historique) doivent être pris en compte dans la présentation des données et des résultats de calcul. Des interfaces visuelles, sonores, tactiles doivent être développées pour permettre une interaction la moins intrusive et la plus naturelle possible avec l utilisateur. Ces différentes briques de bases devront être développées en temps que services autonomes, indépendants entre eux, mais également indépendants des systèmes sous-jacents. Nous verrons en section 7.4 quelles technologies peuvent être employées pour satisfaire ces besoins. Dans une optique de passage à l échelle, les différents services éviteront au maximum d être centralisés, pour être totalement distribués. La présence d un point d accès centralisé est un single point of failure, redouté dans toute architecture distribuée. Une distribution permet d améliorer la robustesse du système mais aussi les performances, équilibrant naturellement la charge de travail et évitant les goulots d étranglement. Aux différents services présentés ci-dessus sur l aspect données, il convient d ajouter un certain nombre d autres services utilitaires, non spécifiques à la gestion de données mais qui sont utiles dans ce cadre : on peut citer en premier lieu un service de monitoring, permettant de connaître à la fois l état des ressources (pour savoir où répliquer les données par exemple), l état des services disponibles avant de soumettre un travail, les données présentes (si elles sont dynamiques), mais aussi l état des services sollicités (en marche, arrêtés, bloqués, abandonnés). Nous avons commencé à travailler sur ce point pour nous permettre d avoir des vues globales sur la Grille Pervasive, maintenues dynamiquement, et contextualisées en point de vue pour un utilisateur particulier (thèse en cours de J. Gossa). un autre service utilitaire de ce type est celui qui permet de gérer l exécution de travaux sur une Grille Pervasive, réalisant l interface avec les différents systèmes de soumissions de travaux et en réalisant une abstraction. le troisième service est un service de découverte dynamique des services disponibles dans l environnement d un dispositif (notamment mobile). Ce service permet de construire la vision que ce dispositif possède de 21

22 22 CHAPITRE 3. BRIQUES POUR LA GESTION DE DONNÉES la Grille Pervasive, et les appels et interactions qu il peut initier. le dernier service que je souhaite mentionner est un service d historique, permettant de garder en mémoire ce qui se passe sur la Grille Pervasive. Celui-ci a deux rôles principaux : tout d abord un rôle d archivage, pour pouvoir retrouver qui a exécuté quel travail, et surtout qui a accédé à quelles données, quand, pour quoi faire,... Le but de cet archivage peut être légal ou financier (accounting), et son lien est étroit avec le service de contrôle d accès qui lui fournit des informations. Le second rôle de l historique est de permettre de reconstruire un schéma d exécution des services disponibles pour un utilisateur dans un contexte particulier, pour réaliser une action déjà vue par le passé. Ici, des techniques de fouille de données dans cet historique sont mis en place. Ce travail est commencé dans l équipe par V. Scuturici sur la plate-forme PerSE. L architecture présentée ici succinctement se différencie d une architecture de Grille de Calcul par la prise en compte dans chaque développement de service de l instabilité, de la mobilité, de la contextualisation propre aux systèmes pervasifs. De manière complémentaire, elle se distingue d une architecture pervasive classique en permettant l utilisation d une infrastructure stable pour mener à bien une partie des travaux coûteux, ou pour utiliser des ressources de stockage pérennes. Par rapport à une architecture de type Pair à Pair (P2P), chaque nœud ici ne va pas avoir la même finalité et le même rôle. Il s agit en fait d un mélange entre une architecture client-serveur et d une architecture P2P, dont les rôles sont dynamiquement distribués. On peut considérer que l existence d une partie stable de l infrastructure tend vers une architecture client-serveur, mais que la partie instable tend vers le P2P. Tous les services présentés ici participent à un moment donné à la réalisation de la gestion de données dans une Grille Pervasive. Ils ne seront toutefois pas tous utilisés comme supports de démonstration par la suite. Je vais focaliser mon propos sur trois aspects qui me semblent significatifs : le premier concerne les possibilités offertes par la collaboration lors de l accès aux données, le second porte sur les aspects sécurité, enfin le troisième s intéresse à l adaptation au contexte des données pertinentes. L approche retenue est de voir comment un certain nombre de travaux réalisés (aujourd hui et par le passé) avec des étudiants en thèse sur ces trois thèmes peuvent s adapter au contexte de la Grille Pervasive.

23 Chapitre 4 Se comprendre, communiquer, collaborer? Dans le WWW, les développeurs ont d abord appris un langage commun, le langage HTML (Hyper Text Markup Language). Celui-ci permet d exprimer une représentation des données diffusées, indépendantes de la plate-forme de création et de consultation, de manière intelligible par un navigateur adéquat (du premier, Mosaïc, jusqu à Internet Explorer et Firefox aujourd hui). C est la compréhension. Pour communiquer, le protocole HTTP (Hyper Text Transfer Protocol) a été défini, fixant les messages que chaque partie doit envoyer pour établir la communication. La collaboration est prise en compte dans l écriture avec HTML des pages web, par les liens existants entre différentes pages, différents sites. Cette collaboration, cette coopération, a rendu le web attrayant et populaire. De manière analogue, il est nécessaire de pouvoir faire se comprendre, communiquer et collaborer les utilisateurs d une Grille Pervasive. Ceci passe par plusieurs étapes, dont la première est d accéder aux données elles-mêmes, puis de définir une sémantique sur les données et les usages qui en sont faits, afin de l utiliser dans la gestion d une collaboration interne au système, réalisant une collaboration efficace et transparente à l utilisateur (pour la gestion des réplicas et des caches, par exemple). 4.1 L accès aux données Le premier challenge concerne donc l accès à la donnée. Il s agit ici de l accès brut à la donnée, c est-à-dire que la donnée est stockée dans un lieu de stockage connu, on ne cherche ici qu à appliquer des requêtes sur les systèmes de fichiers ou les bases de données. 23

24 24CHAPITRE 4. SE COMPRENDRE, COMMUNIQUER, COLLABORER? Deux principaux problèmes interviennent ici dont le premier concerne la possibilité d accéder à des données stockées dans des zones protégées, extérieures à la Grille Pervasive. Par exemple, des données stockées dans un hôpital. Les médecins sont très frileux quant à l éventualité de voir leurs données incorporées dans une Grille Médicale, où elles pourraient sortir a priori de leur contrôle (même avec des moyens de protection adéquats, comme ceux exposés en chapitre 5). Il en résulte une nécessaire mise en place d un système de mandataires (proxy), s établissant entre l hôpital et la Grille, garantissant un certain nombre de pré-requis à la diffusion contrôlée des données hors de l hôpital : par exemple la sécurité doit être assurée par cryptage ou anonymisation, la traçabilité des accès doit être journalisée,... De plus, les données sont souvent stockées dans des formats propriétaires qu il convient d exposer à l extérieur de manière standardisée et transparente de l architecture interne (par exemple, dans un hôpital, un PACS -Picture Archiving Communication System- peut être utilisé). Dans le cadre du projet ACI MediGrid [32], nous avons proposé l architecture DM2 (Distributed Management of Medical Data) [13, 33]. Cette architecture distribuée s interface entre les centres de production d images au format DICOM (Digital Images Communication) et les ressources de la grille de calcul. L architecture retenue est composée de 5 niveaux d abstraction : la première s occupe du passage de messages entre processus ; la seconde gère les transactions alors que la troisième s occupe du caractère distribué de l accès ; les quatrième et cinquième couches fournissent les interfaces (API) aux développeurs et les interfaces utilisateurs. Cette architecture est modulaire (des fonctionnalités de cache ou de contrôle d accès peuvent être ajoutées facilement -en lien avec les travaux présentés plus loin dans ce document-). Elle permet de réaliser les accès aux images d un patient, en vue d un traitement sur ces images, à travers des requêtes hybrides du type : Retrouver les traitements des patients dont l âge est proche de Monsieur Malenpoint et dont les images radiographiques des poumons présentent des similarités cancéreuses avec les radiographies de Monsieur Malenpoint. Sur cet exemple, les patients dont l âge est proche de Monsieur Malenpoint sont sélectionnés dans un premier temps, éventuellement dans plusieurs hôpitaux. Des requêtes de similarité entre les images sont exécutées sur la grille de calcul. Suivant le degré de similarité, les dossiers médicaux des patients retenus sont fournis comme résultat à la requête, après une anonymisation des données personnelles. L expérience acquise grâce à ce travail a permis de mettre en évidence l importance d une architecture modulaire et collaborative puisque tous les DM2 répartis sur les centres de production d images collaborent pour résoudre les requêtes. Les détails de DM2 peuvent être retrouvés dans l article [13] présent en annexe A et dans la thèse d H.

25 4.2. L APPORT DE LA SÉMANTIQUE 25 Duque [14]. Le second problème pour l accès aux données concerne l hétérogénéité des sources et la nécessaire médiation entre les sources. Dans le premier cas, les différents lieux de stockage étaient cohérents et répondaient tous au protocole DICOM pour le stockage de leurs images médicales. Lorsque les sources de données ne sont pas gérées dans le même format (par exemple des fichiers plats côtoient des bases de données), une requête aux données touchant a priori plusieurs sources requiert une médiation entre l utilisateur et les sources pour y répondre. Les travaux sur cette voie sont en cours de réalisation dans la thèse de N.H Andrianarisoa, et sont étudiés plus particulièrement dans le cadre de données environnementales. Dans un projet de création d un Observatoire de Résidus de Pesticides, l AFSSE (Agence Française de Sécurité Sanitaire et Environnementale) est au centre d un réseau de collecte de données, issues de capteurs relevant de plusieurs administrations différentes. L idée est de pouvoir ensuite faire de la fouille de données sur l ensemble des données agrégées. Chaque administration possède ses propres méthodes de stockage et de désignation des éléments polluants. Une réconciliation entre toutes ces sources est nécessaire dans un premier temps. Ce travail est d abord un travail non purement informatique puisqu il consiste à discuter avec les divers partenaires pour comprendre la structure de leurs informations. Une fois celle-ci comprise et acquise (ce qui peut s avérer assez coûteux en temps, problème souvent éludé), plusieurs solutions s ouvrent pour réaliser une médiation entre les différentes sources. Une médiation basée sur une négociation entre les différents acteurs semble être la plus prometteuse. Elle évite une mise en place d un schéma global en privilégiant la connaissance locale aux données. De plus, elle permet à chaque entité de garder le contrôle sur ce qui sort de son domaine administratif. Ces travaux sont en cours, et quelques premières pistes sont évoquées en section 4.2. Fort de ces expériences, je propose, pour l accès aux données externes à la Grille Pervasive, un mécanisme de mandataires réalisant l interface avec les lieux de production. Leur rôle principal est d exposer les données disponibles et de réaliser, de manière collaborative, une unification des diverses vues proposées. Les mandataires collaborent donc entre eux pour la gestion des accès et pour la négociation nécessaire à la médiation. 4.2 L apport de la sémantique Manipuler des données brutes n est pas très efficace et assez complexe. Lorsqu un sens est ajouté aux données, lorsqu on est capable d ajouter de la sémantique à la donnée, le système de gestion s en trouve renforcé. Il

26 26CHAPITRE 4. SE COMPRENDRE, COMMUNIQUER, COLLABORER? s agit alors d utiliser des métadonnées liées aux données. Les métadonnées consistent en des données sur les données : c est une valeur ajoutée par rapport aux données elles-mêmes. Deux techniques existent pour associer des métadonnées. La première consiste à utiliser les métadonnées associées aux données, lors de la création ou l enregistrement de celles-ci. Par exemple, une image brute issue d une radiographie du poumon et une issue d une radiographie du genou n offrent a priori qu un ensemble de niveaux de densité de matière, mais le praticien ayant effectué l acquisition de l image aura sûrement ajouté le type de radio, ainsi que d autres renseignements comme le nom du patient, la date d acquisition de l image, etc... La seconde technique consiste à extraire automatiquement un ensemble de métadonnées caractérisant un aspect des données. Par exemple une analyse de texte permet de retrouver les mots clés du texte, des traitements sur une image permettent d en retrouver des caractéristiques (histogramme de niveaux de couleurs, objets présents,...). Ces métadonnées sont fort utiles lors de l indexation des documents (elles peuvent servir directement pour cette indexation), et pour certains algorithmes de gestion. Par exemple, sur les caches multimédias collaboratifs, nous avons montré [37] comment cette sémantique pouvait améliorer le fonctionnement du cache, en privilégiant les documents présents dans les caches qui seront les plus chauds : la température d un document est liée à l usage qui est fait des documents qui lui sont sémantiquement proches. Ainsi, un document restera plus longtemps dans le cache si lui-même est accédé, ou si des documents voisins thématiquement sont accédés (dans le cache luimême, et dans un réseau de caches voisins, collaborant dans cette tâche). Ainsi, l intérêt partagé par un certain nombre d utilisateurs pour un sujet particulier permet de favoriser sa présence (les documents traitant de ce sujet) dans les caches. Dans ce travail, la sémantique, sous forme de concepts, est extraite automatiquement des pages web textuelles à partir des mots-clés, des titres, des éléments mis en valeur dans les pages (gras, italique, retrait,...). Les travaux sur le Web Sémantique permettra d accroître encore cette connaissance afin d associer à un document une sémantique plus riche. Ces concepts permettent de placer les documents dans un arbre d indexation, comme présenté sur le schéma 4.1 Les liens entre les concepts et les documents sont représentés par une branche dans cet arbre. Les documents à indexer sont les feuilles de l arbre. Les liens internes représentent des spécialisations/généralisations de concepts. Dans l utilisation pour la gestion de caches où l on suppose que les requêtes ne sont pas complètement indépendantes les unes des autres, un poids est associé aux branches : il s agit de la probabilité qu une requête pour

27 4.2. L APPORT DE LA SÉMANTIQUE 27 Root Politics 5% 5% Recreation and Sports 15% 15% Sports Games 40% 40% 20% Baseball Soccer Skiing 70% 50% 60% web documents Fig. 4.1 Représentation graphique de l arbre d indexation un document situé en dessous d un nœud fils arrive après une requête pour un document situé en dessous d un nœud père. Il s agit de la corrélation entre un nœud et ses frères dans l arborescence. Ceci permet de lier sémantiquement de manière plus ou moins forte les documents situés aux feuilles de l arbre. Les méta-données extraites permettent également de caractériser l usage du web qui en est fait par les internautes. En effet, en analysant les températures des différents concepts des données présentes dans les caches, on peut ainsi classer les centres d intérêt des utilisateurs. Un second niveau d utilisation de la sémantique concerne les sources de données, et de la médiation qui est nécessaire entre ces sources. Nous travaillons à négocier des rapprochements entre diverses sources hétérogènes en utilisant cette sémantique. En effet, comment peut-on savoir qu un champ NOM d une base de données est sémantiquement équivalent au champ NAME d une autre base de données, sinon en exécutant une négociation entre les deux. Il convient de décrire la sémantique des champs pertinents des diverses bases, soit en plongeant ces bases sur un schéma commun (GAV - Global As View), soit en rapprochant localement (LAV - Local As View), voire par une approche hybride (GLAV). Ce rapprochement est soit fait de manière manuelle par un administrateur des bases et nécessite un consensus sur un

28 28CHAPITRE 4. SE COMPRENDRE, COMMUNIQUER, COLLABORER? schéma commun, soit en utilisant une sémantique locale, exprimée par le concepteur de la base, sur une sémantique qu il connaît. Ensuite, il suffit de rapprocher les diverses descriptions des bases (les schémas) entre elles pour obtenir une correspondance globale. Un langage de description d ontologies (comme OWL - Ontology Web Language) permet de faciliter cette étape. La négociation intervient pour adapter la réponse à une requête sur une base locale en fonction du contexte de l utilisateur. Celui-ci peut en effet ne pas avoir accès directement à une source de données (problème de droit d accès à une source, problème de connaissance de l existence même d une source), et une négociation collaborative entre plusieurs sources s opère pour obtenir l accès. Cette négociation est basée sur le contexte de l utilisateur (quels droits présente-t-il, où se trouve-t-il?...). Enfin le troisième niveau sémantique est celui de la description des services dans la Grille Pervasive. En effet, pour répondre à une requête utilisateur, une composition de services peut s avérer nécessaire. La manière de composer les services disponibles prendra bien entendu en compte des possibilités sémantiques d enchaînements de ces services. Pour l instant, un langage de description de cette sémantique n existe pas dans le cas général (le langage WSDL est trop pauvre pour cela), et nous avons proposé dans le cadre de l adaptation (voir chapitre 6) notre propre langage de description dans le cas particulier de l adaptation de contenu. Cet aspect est aussi étudié dans l équipe pour la mise en place de la composition de services dans une plateforme d accueil de services pervasifs, appelée PerSE [47] (Pervasive Services Environment). Nota : si l apport de la sémantique est indéniable dans de nombreuses applications, elle ne peut résoudre tous les problèmes liés aux écarts culturels ou technologiques trop importants entre les interlocuteurs. Par exemple, certains concepts n existent pas dans certaines civilisations : en Chine, le concept d Être ou de Néant ne trouve pas de correspondance. Au Groënland, les Eskimos possèdent plusieurs mots différents pour parler de la neige et les concepts associés sont très différents pour eux. Sur un plan technique, des pays ne possèdent pas certaines technologies, et ne les auront jamais : par exemple, en Éthiopie, la majorité des habitants est passée directement au téléphone portable, le téléphone filaire n ayant jamais été (et ne sera jamais) installé partout.

29 4.3. LA GESTION DES RÉPLICAS La gestion des réplicas La gestion de réplicas dans un système distribué permet d accroître sa robustesse et d équilibrer la charge de travail sur l ensemble des ressources disponibles. Si une donnée est stockée à un unique endroit, son contrôle en est simplifié, mais sa disponibilité est celle de la ressource de stockage associée. Aussi, il est préférable de dupliquer la donnée sur plusieurs ressources afin d être sûr de pouvoir disposer d au moins une. (cette idée sera reprise pour la gestion de clés de décryptage en partie 5 sur la sécurité). L autre aspect positif de la réplication de données est l équilibrage naturel qui en découle, plusieurs ressources pouvant être interrogées pour accéder à la même donnée. L approche que nous avons suivie [20] est basée sur une simple constatation : les utilisateurs intéressés par un même sujet parcourent les mêmes documents. Indépendamment du réseau physique sous-jacent, ils construisent des communautés d intérêt. On voit ainsi l apparition de Small Worlds [25], où la plupart des échanges se font entre les membres d une communauté, et peu d échanges se font en dehors de la communauté. Il y a donc, dans cette configuration, possibilité d optimiser à la fois le nombre de réplicas présents et leur localisation : nous répliquons une donnée une fois dans chaque communauté, et non de manière anarchique sur l ensemble du système distribué. La dynamique des communautés est très importante (la volatilité des sujets d intérêts l est pour un utilisateur donné), aussi il est nécessaire d avoir un mécanisme dynamique qui ajuste automatiquement l emplacement des réplicas sur le réseau, en fonction des demandes des utilisateurs. Les réplicas de données sont attirés vers les lieux de forte demande et disparaissent des zones où ils sont peu demandés. Un algorithme distribué dérivé de l algorithme original centralisé des k- serveurs, de Borovin et Yakin [5], a été développé. Il est basé d une part sur les demandes des réplicas par les utilisateurs et d autre part sur la volonté du propriétaire de la donnée originale concernant le nombre de réplicas et les localisations qu il autorise. Cet algorithme gère la création, le mouvement (attraction-répulsion) et la disparition des réplicas sur le réseau, de manière autonome. Lorsqu une donnée est demandée, les réplicas les plus proches se rapprochent (virtuellement dans un premier temps) en direction du site demandeur, mais un seul répond à la requête de l utilisateur. Lorsque la somme des déplacements virtuels d un réplica dans une direction (son attraction dans une direction) atteint le coût pour aller sur le site adjacent dans cette direction, alors le réplica peut soit se déplacer sur ce site adjacent, soit s y dupliquer (tant que le nombre total de réplicas présents n excède pas la volonté du propriétaire de la donnée originelle). L attraction dans une direction décroît avec le temps, pour refléter le changement d intérêt des utilisateurs.

30 30CHAPITRE 4. SE COMPRENDRE, COMMUNIQUER, COLLABORER? Nos travaux futurs concernent la prise en compte d une prédiction permettant d anticiper sur les demandes des utilisateurs et de faire bouger les réplicas, non plus en fonction des demandes réelles, mais plutôt en fonction des demandes supposées pour la suite. Ce point fait l objet d une collaboration avec l Université de Vienne en Autriche (K. Hummel). L idée est de caractériser les schémas de mobilité des utilisateurs afin de prédire leurs situations futures (par des modèles stochastiques). Le caractère fortement distribué et autonome de notre approche de gestion des réplicas la rend compétitive pour une utilisation dans une Grille Pervasive. 4.4 La gestion des caches Les caches dans les systèmes informatiques stockent en mémoire temporaire les données susceptibles d être ré-utilisées dans un futur proche. La principale différence entre une donnée répliquée et une donnée stockée dans un cache est la pérennité de cette donnée. Alors que l utilisateur peut compter sur la disponibilité d un réplica, il ne peut compter sur sa présence dans le cache : la plupart du temps, l utilisateur n est pas au courant de l existence du cache, et ne voit pas la différence avec la donnée originale. La présence d un cache sur la Grille Pervasive est nécessaire, comme dans beaucoup de systèmes distribués. La première fonction d un cache est d accélérer l accès à l information, évitant des requêtes éventuellement lourdes quand leurs résultats peuvent se trouver déjà présents. Le problème principal avec un cache est sa taille limitée qui oblige à choisir le (ou les) documents qu il faut effacer afin de laisser place à une nouvelle donnée. Nous proposons un mécanisme de gestion de caches collaboratifs [37] pour les documents multimédias (notamment le web), dans le cadre de la thèse de D. Coquil. Le mécanisme proposé se base sur l usage des documents, favorisant la présence dans les caches des documents les plus intéressants (pour les usagers des caches). Comme je l ai déjà mentionné dans la partie 4.2, des concepts clés sont extraits des pages qu un cache doit gérer et les documents sont placés dans un arbre d indexation. A chaque nœud de l arbre est associée une température, reflétant l intérêt de cette partie de l arbre (le nœud et ses descendants) pour les utilisateurs du cache. A chaque accès à un document, sa température augmente. A intervalle régulier, les différents nœuds irradient leur voisinage. Ainsi, un document placé dans le même sous-arbre qu un document fortement accédé verra sa température augmenter. Cette température sert directement dans la gestion du cache pour savoir quels sont les documents qui doivent être éliminés (les plus froids) et ceux qui doivent

31 4.4. LA GESTION DES CACHES 31 être gardés (les plus chauds). De plus, nous proposons de mutualiser la connaissance des différents caches présents dans la Grille Pervasive. Les caches communiquent pour s échanger leurs arbres d indexation tempérés afin d améliorer globalement les performances du système en ne gardant que les documents les plus chauds. Un niveau hiérarchique permet d agréger la vue sur les différents arbres d indexation dans des caches collectifs. Nous avons montré qu une hiérarchie à plus de deux niveaux n apporte pas d amélioration de performances. Les algorithmes employés ont montré leur efficacité, principalement dans la gestion des caches web, à la fois en terme quantitatif (amélioration du hit-rate, reflétant le pourcentage d accès aux caches plutôt qu aux données originelles), mais aussi qualitatif (il est possible de caractériser les accès en fonction des thèmes). Les détails de cet algorithme et des résultats associés se retrouvent dans l article [37] en annexe A de ce document. Toutefois, dans une Grille Pervasive, tous les acteurs peuvent ne pas s entendre sur une politique de gestion de caches, comme celle décrite ici. En effet, il serait limitatif d obliger les utilisateurs à s accorder sur cette politique. Ainsi, les différentes entités constituantes d une Grille Pervasive peuvent gérer de manières indépendantes un cache, avec des politiques de remplacement différentes. De plus, la proposition précédente s intéresse à améliorer de manière locale le fonctionnement d un cache grâce à une connaissance globale. Nous proposons d aller plus loin, principalement pour apporter de nouvelles fonctionnalités globalement. Par exemple, la taille limitée des caches reste un problème qui est géré localement. Même si un cache possède de la place alors qu un autre est saturé, un document sera effacé du second cache alors qu un déplacement vers le premier aurait pu être plus efficace. Enfin, un autre aspect concerne la recherche d un document dans les caches, qui doit pouvoir se gérer au niveau global. Notre proposition ( [7], annexée à ce document) pour la thèse de Y. Cardenas, est basée sur l idée suivante : plusieurs caches distribués offrent une vue globale sur un cache uniforme virtuel. Celui-ci s appuie sur les caches locaux chez les différents partenaires de la Grille Pervasive pour donner l illusion aux applications de la grille de posséder un espace de cache très important (la somme de tous les espaces de cache). Le cache uniforme permet ainsi de stocker des fichiers trop volumineux pour rentrer dans un seul cache, et il permet aussi d uniformiser les différentes politiques de caches distribués (certains caches peuvent suivre une politique de cache basée sur la température,

32 32CHAPITRE 4. SE COMPRENDRE, COMMUNIQUER, COLLABORER? comme expliqué auparavant, d autres des politiques LRU - Least Recently Used ou LFU-Least Frequently Used,...). Le cache uniforme s assure que les données sont cachées dans les caches dont la politique leur correspond au mieux. Éventuellement, certaines données peuvent être déplacées d un cache à l autre si la politique globale le nécessite (par exemple pour laisser de la place localement à un document, sans perdre pour autant le document caché). De plus, un document trop gros peut ne pas entrer complètement dans un cache, même si celui-ci est vide : nous proposons de gérer un découpage de ce document afin de pouvoir le stocker de manière répartie entre plusieurs caches locaux, par morceaux. Enfin, le service de cache uniforme permet de gérer de manière transparente à l utilisateur l accès aux données dans les institutions : il sert de passerelle entre l intérieur et l extérieur pour l accès aux données. L architecture proposée pour cette gestion de caches est ainsi à deux niveaux : les caches locaux, et les caches collectifs (voir schéma 4.2). COLLECTIVE GRID CACHE LOCAL GRID CACHE LOCAL GRID CACHE API SRM API OGSA DAI API MCS API SRM API OGSA DAI API MCS Metadata Catalog Service MCS OGSA DAI Storage Resource Manager SRM GridFTP GridFTP Storage Resource Manager SRM OGSA DAI Metadata Catalog Service MCS DB DB DATA Data Tranfer DATA DB DB Fig. 4.2 Deux niveaux de caches : local et collectif Le rôle des caches locaux est ainsi de : servir de passerelle entre une organisation et l extérieur servir de point d accès unique à plusieurs zones de stockage de données (par exemple OGSA-DAI, SRM) gérer l accès à une zone de stockage où sont stockées les données (le cache proprement dit) gérer le remplacement des données présentes dans le cache (en utilisant -ou pas- une politique dite de température )

33 4.4. LA GESTION DES CACHES 33 gérer un index des données présentes (par exemple sous la forme d un arbre d indexation) communiquer l index local au cache collectif recevoir du cache collectif des demandes de stockage ou d effacement de données envoyer et recevoir des données/requêtes des autres caches locaux rejoindre un cache collectif (abonnement) Le rôle des caches collectifs est de : gérer un ensemble de cache locaux, suivant des politiques de remplacement éventuellement différentes construire et maintenir un index global des données gérées dans les caches locaux rattachés établir des choix de remplacement des documents présents dans les caches locaux en fonction de la connaissance globale gérer le stockage réparti de fichiers trop gros pour entrer dans un seul cache local, et donc les liaisons nécessaires entre les différents morceaux répondre à des recherches sur une donnée dans le cache uniforme (en collaborant éventuellement avec d autres caches collectifs) gérer l arrivée de nouveaux caches dans le système (adhésion) vérifier la présence des caches (déconnexion, résiliation) Cette approche intégrée s adapte parfaitement dans la Grille Pervasive, plus particulièrement sur l infrastructure stable de celle-ci (en tout cas en ce qui concerne le niveau de cache collectif). Le premier obstacle à la mise en œuvre de cette technique sur une Grille Pervasive est l extraction des concepts dans un cas général, pour des documents qui ne sont pas forcement textuels et structurés comme le sont les pages web, et la structuration en arbre de concepts des résultats générés. Néanmoins, les progrès actuels dans le domaine du Web Sémantique permettent d envisager pouvoir définir des ontologies permettant, pour des domaines particuliers, de leur associer plus facilement des arbres d indexation. La seconde grosse difficulté réside dans la gestion de l instabilité des dispositifs. Un document mis en cache dans un dispositif dont la pérennité n est pas un minimum assurée sera perdu, et donc le travail nécessaire à la gestion du cache uniforme est en partie vain. De plus, si un document a été lui-même découpé et réparti entre plusieurs caches, alors la perte d une seule partie entraîne la perte du document entier et rend obsolète l ensemble des autres parties : en effet, il est peu probable que le serveur originel du document accepte la récupération d une petite partie de celui-ci. Cet aspect n a pas encore été étudié et fera l objet de travaux futurs.

34 34CHAPITRE 4. SE COMPRENDRE, COMMUNIQUER, COLLABORER?

35 Chapitre 5 Confiance, ou non? Pour être accepté par le plus grande nombre, une Grille Pervasive doit inspirer la confiance. Ce ne doit pas être à mon sens la cinquième roue du carrosse que l on met en place à la fin, lorsque tout marche. Beaucoup d autres services sont dépendants de la manière dont s exerce cette sécurité. Par exemple, la réplication n est possible que si les droits alloués aux réplicas sont les mêmes que ceux alloués aux données originales. Il convient donc de prendre en compte dès le début des réflexions les possibilités de sécurisation du système. Une Grille Pervasive présente le double inconvénient de cumuler les appréhensions des utilisateurs des Grilles de calcul et ceux des utilisateurs des Systèmes Pervasifs. Dans les Grilles de calcul, les utilisateurs finaux craignent que leurs données soient diffusées en dehors de leur contrôle, éventuellement de l autre coté de la planète. Dans les Systèmes Pervasifs, les technologies sans fil utilisées sont souvent synonymes pour les utilisateurs de la perte de la confidentialité de leurs informations, dès lors que celles-ci circulent dans les airs. La sécurité informatique regroupe beaucoup de problématiques différentes. Je ne vais pas les détailler toutes, mais uniquement celles qui me paraissent les plus importantes pour l accès aux données : l authentification et le contrôle d accès. Tout d abord, je m attacherai à l authentification : comment s assurer de l identité du partenaire d une communication, surtout quand les partenaires ne se connaissent pas a priori et ont une confiance réciproque limitée. Ensuite viendra le contrôle d accès. Alors que le WWW permet à ses usagers de partager les données qu ils souhaitent, contrôlant l origine des données (eux-mêmes) et également le processus de publication (chacun est le directeur de publication de son propre contenu), ce contrôle a priori est beaucoup plus lâche dans les systèmes distribués et les grilles : en effet, les données produites par simulation ou calcul intensifs le sont sur des 35

36 36 CHAPITRE 5. CONFIANCE, OU NON? sites éventuellement distants, leur stockage peut-être fait par la grille sur un site également distant. Le propriétaire intellectuel de ces données voit donc son contrôle s exercer de manière plus diffuse. Il convient donc de le rassurer, à la fois en s assurant que personne ne pourra accéder à ses données (contrôle d accès), mais aussi que si une telle chose arrive finalement, le malveillant ne puisse en faire usage (cryptage des données). 5.1 Authentification Le problème de l authentification dans un système distribué est assez complexe. Pour être identifié sur un site distant, l utilisateur doit posséder soit un compte informatique sur ce site, soit prouver par un certificat signé qu un organisme de confiance le connaît et atteste de son identité (une autorité de certification, comme dans les PKI par exemple). Le site distant fait alors confiance à cette autorité pour autoriser l accès à ses ressources. Le problème que nous voyons à cette approche est que soit l utilisateur doit être connu à l avance (cas du compte local), ce qui en général n est pas le cas dans un environnement pervasif, soit il doit avoir avec lui le certificat approprié qui lui sera demandé par le site distant. Ceci implique qu il sait quelles sont les autorités de certification sur lesquelles le site distant s appuie, et qu il a fait une demande préalable à ceux-ci pour se présenter muni d un bon certificat. C est la méthode communément utilisée dans les implémentations de grilles de calcul actuelles. Cette méthode nous semble inadaptée dans le domaine pervasif où l utilisateur nomade ne sait pas forcément où il va et qui contrôle le site distant. Avoir une autorité de certification universelle à laquelle croient tous les site simplifierait la tâche quelque peu, mais pas totalement. Un autre enjeu apparaît en effet : quel degré de confiance accorder à un utilisateur venant sur un site? Qu il soit connu par une autorité de certification lui permet d être connu localement, mais aucun renseignement sur son origine ne permet de restreindre ses droits. Il nous apparaît nécessaire de pouvoir mesurer la confiance que l on place dans autrui. Le travail de thèse de R. Saadi porte justement sur l authentification par la confiance, où plutôt par la méfiance, sans autorité centralisée de certification. L article [45] présent en annexe A explique son fonctionnement. L idée est basée sur la transitivité graduée de la relation de confiance. Si le site A fait confiance au site B, et que B fait confiance à C, alors A fait confiance à C, jusqu à un certain degré. Un utilisateur Uc de C peut donc être authentifié par A, qui lui donne accès à certaines ressources, selon le niveau de confiance accordé. La relation de confiance se transmet donc du site C où Uc est reconnu formellement (il possède un certificat d appartenance du site C),

37 5.1. AUTHENTIFICATION 37 vers le site B (qui lui accorde temporairement un certificat de confiance, car Uc vient du site C auquel B accorde un certain niveau de confiance). Le site A calcule à partir du certificat de confiance établit par B, et de sa propre confiance envers les utilisateurs venant de B, un degré de confiance qui lui permet d accorder des droits à Uc. La confiance se gère ici directement entre les sites et non pas entre les utilisateurs et les sites. Pour l utilisateur Uc, l utilisation du mécanisme est assez simple, puisque son seul travail consiste à demander un certificat d appartenance du site C sur lequel il est connu localement. Lorsqu il se présente sur un site distant A, il présente ses certificats d appartenance et de confiance glanés au cours de ses déplacements. Si l un deux a été établi par un site auquel A fait plus ou moins confiance, le degré de méfiance envers Uc est calculé et un accès temporaire lui est délivré (sous la forme d un certificat de confiance, qu il pourra de nouveau utiliser pour accéder vers d autres sites). Du coté système, la contrainte est l existence d une relation de confiance graduée entre les sites concernés. Toutefois, cette relation ne se construit qu une seule fois et est beaucoup plus stable qu une relation épisodique avec des utilisateurs. Les sites entre-eux peuvent même utiliser une autorité de certification pour se faire confiance et valuer cette confiance, indépendamment des utilisateurs finaux. Une valeur ajoutée à cette approche est la présence dans les certificats du niveau d accès sémantique accordé dans un site. Ainsi, le site C peut mettre dans le certificat d appartenance de Uc une information sur ses droits d accès locaux : par exemple, Uc a un niveau d accès 5. Lorsque B construit le certificat de confiance, il peut affecter un nouveau niveau d accès, par exemple 3 (une correspondance est nécessaire entre les niveaux d accès des différents sites ; comme vue précédemment, cette correspondance se fait entre sites et n a pas vocation a évoluer souvent). Lorsque A voit ce certificat de confiance, il accorde à son tour un degré 2 d accès, restreignant les possibilités offertes à Uc. Cette partie du travail est en développement actuellement. Pour mener à bien cette correspondance, il est nécessaire de connaître la sémantique des différents niveaux d accès, pour chaque paire de sites concernés. Dans notre exemple, B doit savoir ce que représente un niveau 5 chez C, et A doit savoir ce qu est un niveau 3 chez B. Par contre, A n a pas à connaître ce qu est un niveau 5 de C (A ne connaît pas C, de toutes manières). Une possibilité pour décrire cette correspondance sémantique est l utilisation d un langage de description ontologique comme OWL. Dans une Grille Pervasive, l infrastructure stable constitue des points entre lesquels la confiance réciproque peut facilement être graduée. Elle évolue peu au cours du temps, et l on peut se baser sur elle pour être des points d ancrage de la politique globale d accès. En revanche, pour l infrastructure instable, et plus encore pour les dispositifs mobiles, la confiance

38 38 CHAPITRE 5. CONFIANCE, OU NON? qu ils peuvent accorder au système et celle que le système peut leur accorder est limitée : il n est pas toujours possible d avoir avec soi le certificat de confiance qu un site ami aurait pu fournir au site auquel on essaie de se connecter. Il faut donc pouvoir généraliser l approche que nous avons initiée à une confiance de gré à gré, sans reposer sur une connaissance et une confiance a priori entre les hôtes d appartenance des dispositifs voulant communiquer. L existence même d une autorité supérieure (tacite, ou informatique) doit être remise en cause. Une solution possible à ce problème est l auto-évaluation des partenaires, non pas en fonction des certificats qu ils ont pu glaner, mais plus par l historique de leurs actions et déplacements. En sachant ce qu un utilisateur a fait sur un site distant, il est possible d en déduire le degré de confiance que celui-ci lui accordait. Par exemple, si A fait confiance à B, et que C a exécuté une tâche sur B, alors A peut peut-être faire confiance à C dans une certaine mesure. La gestion de l historique me semble être une voie prometteuse. 5.2 Contrôle d accès Pouvoir authentifier un utilisateur est une étape nécessaire, mais non suffisante. Pour pouvoir contrôler l accès qu il pourra faire du système par la suite et quelles données (et ressources en général) lui seront disponibles, il faut mettre en œuvre entre les ressources et leurs consommateurs un logiciel réalisant ce contrôle. Nous pensons de plus que les propriétaires des données sont les seuls habilités à délivrer les permissions d utilisation de leurs données. Ce sont donc eux les sources d autorité (SOA - Source Of Authority) qui doivent donner ces permissions, et donner la permission d en permettre l accès (que l on appelle la délégation), tout en restreignant la longueur acceptée de la chaîne de délégation. En outre, il peut s avérer utile de pouvoir associer une autorisation d accès à un ensemble d utilisateurs, organisé en hiérarchies (modèle RBAC -Role Based Access Control, hiérarchique), pour un ensemble de données (et non pas donnée par donnée). Enfin, le système doit pouvoir être complètement dissocié de la présence d un serveur de permission accessible par le système. Dans une Grille Pervasive, il est possible qu un utilisateur nomade veuille accéder à des données présentes sur un dispositif instable, non connecté à l infrastructure stable. L. Seitz s est attaqué à cette problématique dans sa thèse [50] dans le cadre des Grilles Médicales. Nous avons proposé Sygn [52] [49], un système de contrôle d accès distribué. L architecture générale de Sygn se retrouve sur

39 5.2. CONTRÔLE D ACCÈS 39 le schéma 5.1. Avec Sygn, le mécanisme de gestion des droits d accès aux Sygn meta data Resource owner Sygn admin client 1) Stores resource and Sygn SOA metadata 2) Issues AC(s) for resource Sygn user client Sygn meta data Sygn PDP Sygn PEP 3) Uses AC(s) to access resource Sygn meta data Resource server Fig. 5.1 Schéma général de Sygn Resource consumer ressources distribuées est assez simple : en premier lieu, le propriétaire d une ressource la stocke sur un serveur de ressources, contrôlé par le logiciel Sygn. Seule la correspondance entre la ressource et un identifiant unique de son propriétaire est gardée (il s agit de sa clé publique dans l implémentation). Lors de la première phase (phase 1 sur le schéma), le SOA de la ressource l envoie à un serveur de ressource. Le logiciel Sygn enregistre la ressource et le lien entre celle-ci et le SOA. Lorsque le SOA d une donnée veut en donner l accès à un utilisateur quelconque, il fournit à ce dernier un certificat dans lequel il stipule l action autorisée sur la donnée, la période de validité, la longueur de délégation acceptée (phase 2 sur le schéma). Le logiciel Sygn client, sur la machine de cet utilisateur, sauvegarde ce certificat pour un usage ultérieur. Quand l utilisateur veut faire une action sur la ressource (phase 3), il contacte le serveur de cette ressource (le PEP de ce serveur, en fait), et envoie le certificat récupéré précédemment. Le logiciel Sygn, coté serveur est composé de deux entités : le PEP (Policy Enforcement Point) et le PDP (Policy Decision Point). Le PEP interface le PDP avec la Grille de calcul, le rendant indépendant de la Grille. Il vérifie que l action présente dans la requête de l utilisateur est la même que celle dans le certificat. Ensuite, il

40 40 CHAPITRE 5. CONFIANCE, OU NON? teste l identité de l utilisateur de la Grille avec l identité présente dans le certificat pour éviter qu un utilisateur non enregistré puisse utiliser un certificat émis pour quelqu un d autre. Si aucun problème n apparaît, les certificats de l utilisateur sont envoyés pour vérification au PDP (Policy Decision Point), qui décide des droits d accès. Le PDP vérifie les listes noires, la validité des certificats, puis la validité de l accès. Dans le cas d un accès simple par un utilisateur à une ressource, il suffit que le SOA de la ressource ait donné un certificat d accès valide à l utilisateur pour que l accès soit autorisé : le PDP vérifie que le SOA de la ressource demandée est bien celui qui a créé le certificat, que les droits sont respectés, et autorise alors l accès à la ressource. Cette autorisation d accès est renvoyée au PEP qui effectue l accès proprement dit. Un avantage de cette approche est la possibilité de tracer toutes les tentatives d accès aux données, ainsi que de réaliser de la non-répudiation de ces accès (options du PDP). Toutes les informations d accès restent avec la ressource elle-même. L algorithme se complique sérieusement dès lors que l on considère les hiérarchies de groupes d utilisateurs et de groupes de ressources. Il faut alors enchaîner la vérification d un ensemble de certificats pour connaître la décision finale de Sygn, et plus particulièrement de son PDP (Policy Decision Point). En effet, dans un système de contrôle d accès de type RBAC, il y a aussi des SOA pour les rôles attribués. Afin de vérifier les autorisations d accès à une ressource particulière, pour un utilisateur particulier, il peut s avérer nécessaire de vérifier de longues chaînes de certificats mentionnant l appartenance d une ressource à un groupe de ressources (et ce de manière hiérarchique), ainsi que le cumul de rôles particuliers pour l utilisateur. Enfin, tout ceci est dynamique. La source d autorité d un rôle ou d un ensemble de ressources peut ajouter ou enlever dynamiquement des éléments. Nous avons donc conçu un algorithme général permettant, à partir d une chaîne de certificats présentés par l utilisateur, d autoriser ou non l accès à une ressource. L algorithme étant assez complexe (et long), le lecteur peut le retrouver dans un rapport de recherche décrivant Sygn[52], disponible en annexe A. L idée générale est de parcourir une chaîne de certificats, où chaque certificat va soit activer un rôle, soit mettre la ressource dans un groupe. L utilisateur de la chaîne de certificats est autorisé à accéder à une ressource : si il est le SOA de la ressource (cas le plus simple), ou si le SOA lui a donné (directement ou indirectement, par délégation à un tiers) le droit d accès à la ressource (ou à un groupe dont la ressource fait partie, éventuellement hiérarchiquement), ou si il peut activer un rôle autorisé à accéder (éventuellement hiérarchiquement) à la ressource (ou à un groupe dont la ressource fait partie, éventuellement hiérarchiquement). A chaque étape de l algorithme, un certificat de la chaîne est utilisé, soit donnant

41 5.2. CONTRÔLE D ACCÈS 41 l accès, soit l interdisant, soit changeant le rôle présenté (si l utilisateur n a pas pu produire de certificat d accès, un de ses rôles peut peut-être en obtenir un), soit changeant la cible de la vérification de l accès (par exemple quand la ressource est mise dans un groupe, l algorithme vérifie alors l accès au groupe). Cet algorithme a été implanté de manière indépendante de toute infrastructure de Grille de calcul. Une interface avec la grille expérimentale µgrid développée par J. Montagnat (Creatis/I3S) a été réalisé [48], montrant la faisabilité technique de notre proposition. Le point fort de notre approche est la totale distribution du mécanisme, sans intervention d un système centralisé. Les permissions sont données directement entre les sources d autorité et les utilisateurs de ces permissions, de manière complètement hors-ligne. De même, l utilisateur voulant accéder à une ressource présente ses certificats d accès à la ressource directement, sans présence d une tierce partie. En ce sens, cette proposition me semble adaptée à une Grille Pervasive. Il n est pas nécessaire de reposer sur une infrastructure stable, avec un serveur de contrôle d accès disponible en ligne. Une simple connexion entre deux dispositifs (par exemple en Bluetooth) permet à un utilisateur de donner un certificat d accès à un autre : la taille des certificats est petite (quelques kilobits au maximum) et peut aisément entrer en mémoire dans toute sorte de dispositifs de consultation. Un autre aspect concerne la résistance de Sygn aux attaques extérieures. Le système étant décentralisé, une attaque réussie sur un site n engendre pas de répercutions sur les autres sites : les éventuels certificats récupérés sont inutiles car ils sont signés par leurs utilisateurs. Comme cela a déjà été mentionné, seul le PEP interagit avec la Grille de Calcul. Dans le cadre d une Grille Pervasive, seule cette partie devra être ré-écrite, afin de réaliser l interface entre l authentification présente dans les certificats produits par les utilisateurs et celle gérée par la Grille Pervasive (par exemple en utilisant le mécanisme décrit en section précédente). Enfin, la réplication de données comme celle expliquée en chapitre 4 reste cohérente avec le contrôle d accès. En effet, les droits d accès ne sont pas stockés avec la donnée, mais seule l association entre le SOA et l identifiant du fichier est conservé par Sygn. Ainsi, si les droits d accès évoluent, c est la responsabilité du SOA de la donnée de fournir des certificats de manière adéquate. De même, si l identifiant de la donnée change, Sygn considère qu il s agit d une nouvelle donnée, et les anciens certificats seront donc invalides (car l identifiant de la donnée réside dans les certificats d accès).

42 42 CHAPITRE 5. CONFIANCE, OU NON? 5.3 Stockage crypté Afin de rassurer davantage les utilisateurs d une Grille Pervasive, il est nécessaire d offrir également des possibilités de stockage de données sûres (en terme de confidentialité). Au delà des appréhensions concernant les techniques de contrôle d accès et leur fiabilité, il y a réellement un danger à stocker des données sur des supports physiques non sécurisés. En effet, rien n empêche que l administrateur d un site (ou une entreprise de maintenance) n ait un accès direct sur le site de stockage, et donc qu il puisse lire les données, en passant outre le système de contrôle d accès présent. Ceci est encore plus crucial lorsque les dispositifs sont petits et portables, facilement dérobables par des personnes malveillantes. L ensemble de ces faits motive directement les travaux effectués sur ce thème. Le système Cryptstore proposé dans la thèse de L. Seitz [50] aborde cette problématique et y apporte une solution convaincante. Un algorithme de gestion décentralisée des clés de cryptage basé sur le partage de secret de Shamir [53] permet d empêcher la divulgation des clés de décryptage. Cet algorithme se retrouve dans une publication [51] en annexe A du présent document. L idée principale est de crypter un fichier avec une clé, puis de découper la clé de décryptage en morceaux et de distribuer ces morceaux sur un ensemble de serveurs en ligne. Le paramétrage de l algorithme permet de choisir le nombre de morceaux à créer et distribuer (N) ainsi que le nombre de morceaux nécessaires pour pouvoir décrypter les données cryptées (m). Pour l utilisateur final, le système est ici aussi relativement simple : le propriétaire d une donnée la fournit au système de stockage avec les paramètres de l algorithme (le couple (N, m), N >> m). Ce dernier crypte la donnée, choisit les serveurs de clés où seront stockés les N morceaux de clés, envoie la donnée sur le serveur de stockage avec le nom des serveurs de clés (metadonnées associées), puis envoie les N morceaux de clés aux serveurs de clés. Un utilisateur qui récupère la donnée récupère aussi les noms des serveurs de clés, sur lesquels il peut demander le nombre m, nécessaire et suffisant, de morceaux de clés de décryptage pour accéder à la donnée décryptée. Il est à noter que dans cette solution, ce travail de décryptage est à la charge de l utilisateur de la donnée. Le schéma 5.2 résume le fonctionnement du stockage crypté. Tout d abord, le SOA de la donnée la crypte et crée les N morceaux de clés (phase a). Puis il stocke ces morceaux sur les serveurs de clés (phase b) et stocke sa donnée cryptée et l adresse des serveurs de clés utilisés (phase c) sur une zone de stockage. Ensuite, de manière indépendante, il donne (phase d) l autorisation d accès à la donnée et aux clés pour un utilisateur (par exemple si Sygn est mis en place, il lui fournit des certificats d accès). Cette autori-

43 5.3. STOCKAGE CRYPTÉ 43 Storage Server c.) Stores data and addresses of Data administrator the key servers on the storage server e.) Retrieves data and addresses of the key servers User or user group d.)gives permissions to user or user group a.) Encrypts data and creates key shares b.) Stores key shares on different key servers f.) gets key shares from the key servers g.) Reconstructs key from key shares and decrypts data secure transfer optional: secure tranfer mandatory: Key Servers Fig. 5.2 Mode opératoire de CryptStore sation permet à l utilisateur de récupérer la donnée cryptée et l adresse des serveurs de clés possédant des morceaux de clés (phase e). (on peut noter que les phases det e ne sont pas reliées au cryptage et peuvent être réalisées par n importe quelle méthode). Il ne reste alors plus à l utilisateur qu à récupérer m morceaux quelconques de la clé (phase f), pour la reconstruire et pouvoir effectuer le décryptage (phase g). Ce système a été développé de manière indépendante de la Grille de Calcul et des mécanismes de contrôle d accès. Dans notre prototype, l accès aux clés de décryptage est géré par le logiciel Sygn décrit précédemment. Dans une Grille Pervasive, les serveurs de clés seront plutôt placés sur l infrastructure stable, pour être plus accessibles. Le problème principal serait ici de pouvoir connaître les serveurs de clés qui possèdent une partie de la clé nécessaire. Il n est pas envisageable d avoir une connaissance totale des serveurs de clés disponibles a priori, et donc un mécanisme d indexation dynamique de ces clés est à envisager. On peut à cet égard ré-utiliser le travail exposé en chapitre 4 sur la recherche et l indexation des documents : ici, les documents sont les clés, indexées selon les métadonnées associées au fichier crypté. Ainsi, la recherche d un fichier entraîne aussi la recherche des

44 44 CHAPITRE 5. CONFIANCE, OU NON? clés de décryptage de ce fichier. Un autre aspect concerne le décryptage proprement dit. La charge du décryptage peut s avérer lourde pour un dispositif léger. Aussi il serait intéressant d avoir la possibilité de faire ce décryptage sur l infrastructure stable et plutôt sur une machine puissante (voire sur un ensemble de machines). De tels services de cryptage/décryptage doivent donc exister sous forme de services sur l infrastructure de la Grille Pervasive. Un problème apparaît cependant, concernant la sécurité des données transmises à de tels services : comment être sûr que le service distant est bien sûr, qu il n a pas été modifié, et qu on peut lui faire confiance? Un utilisateur particulièrement paranoïaque peut faire tout en local, avec ses propres services de cryptage/décryptage (deux services suffisent ici). La solution exposée ici est adaptable à l environnement, en changeant les paramètres de l algorithme de Shamir. Le nombre de morceaux de clés peut changer entre deux utilisateurs, ou deux instances de l environnement. Une solution avec quelques morceaux de clés nécessaires pour décrypter, et un grand nombre de morceaux créés au total, est adaptée à une infrastructure instable, où le nombre et la disponibilité des serveurs est aléatoire : si peu de morceaux de clés sont nécessaires, la probabilité de trouver des serveurs dans son voisinage est importante. Toutefois cette solution est moins sûre, puisqu un attaquant n aura qu à retrouver un nombre limité de morceaux de clés pour accéder à la donnée décryptée.

45 Chapitre 6 S adapter Un autre aspect de la gestion de données distribuées dans une Grille Pervasive est l adaptation des données avant de les fournir aux utilisateurs. Adapter des données peut se faire suivant plusieurs modalités. Cependant, l utilisateur doit être au centre de nos préoccupations. Celui-ci se décline tout d abord par ses centres d intérêts, ses capacités de consultation (handicap -muet, sourd?-, langages compris,...). Je nomme ici l ensemble de ces préférences sous le terme générique de profil. Ensuite un utilisateur interagit avec son environnement grace à un dispositif particulier, mobile ou fixe, dont les caractéristiques techniques varient grandement (présence d un écran, taille de l écran, nombre de couleurs, présence d un haut parleur, qualité du son, présence d un micro,...). D autre part, l utilisateur agit au sein d un système distribué où interviennent de multiples matériels et réseaux, avec là aussi des caractéristiques physiques différentes en termes de bande passante, de gigue ou de latence. De même, l environnement lui-même peut agir sur l utilisateur, ou plutôt sur la perception que celui-ci peut avoir sur le système. Ainsi, de manière pro-active, l environnement peut envoyer des données adaptées à l utilisateur, sans que celui-ci ne fasse une requête particulière au système d information. L ensemble de ces points représentent le contexte d utilisation. Selon Dey [12], Context is any information that can be used to characterise the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves. Cette définition du contexte est très large, et les thèmes de recherche autour de cette notion de contexte sont très nombreux. Ceux-ci vont de la récupération du contexte, à son intégration dans une application en passant par sa modélisation, sa représentation et son stockage. Créer une application qui s adapte automatiquement en fonction de son contexte d utilisation se- 45

46 46 CHAPITRE 6. S ADAPTER rait de trouver le Saint Graal. De manière moins ambitieuse et plus réalisable (réaliste?), je m attacherai principalement à l adaptation des données en particulier, dans un contexte d utilisation reprenant les hypothèses décrites dans le paragraphe précédent. De plus, dans un souci d illustration, je prendrai les données multimédias plus précisément. Je reviendrai sur la notion de contexte dans la suite de ce chapitre. Lorsque l on évoque l adaptation de données, la première chose à se demander est l endroit où doit se faire cette adaptation. Plusieurs choix sont en effet possibles : sur le serveur de données, près du consommateur, ou quelque part au milieu. Dans la première solution, le serveur de données prépare généralement un certain nombre de modalités différentes de consultation d une même donnée (par exemple un document sera décliné en plusieurs versions, pour des dispositifs de consultation différents). L inconvénient de cette technique est que le serveur de contenu doit prendre en compte la totalité des différentes plate-formes de consultation, et est donc très peu réactif à des situations nouvelles. La seconde solution, sur le dispositif du consommateur, oblige le téléchargement d une donnée qui sera adaptée après. Cette situation n est pas optimisée, voire impossible : par exemple, la bande passante existante entre le consommateur et le serveur n est peut-être pas suffisante pour proposer le document et l adaptation locale n est pas possible dans de bonnes conditions. C est le cas avec une liaison par BlueTooth et un dispositif de type téléphone mobile. La troisième solution consiste à réaliser l adaptation entre le serveur de contenu et le consommateur de la donnée. C est l approche que nous avons retenue, et que nous avons déclinée selon deux directions. 6.1 L adaptation au cœur du réseau Tout d abord, nous avons proposé d utiliser les routeurs actifs pour faire l adaptation au cœur du réseau. Ces travaux se font en collaboration avec l équipe RESO du laboratoire LIP à l ENS-Lyon (L. Lefèvre), et avec la société 3DDL (3 Degrés De Libertés). L idée, basée sur le logiciel Tamanoir, et de modifier les flux de données au fur et à mesure de leur traversée du réseau. Le consommateur de la donnée demande la donnée brute, celle-ci est modifiée par le réseau lui-même avant d être délivrée au consommateur. Cette solution est complètement transparente à l utilisateur et est extensible relativement facilement sous forme de modules Java ajoutés à Tamanoir pour traiter d autres flux. Le champ d application actuelle de cette technologie est la conversion de vidéos en direction des téléphones mobiles.

47 6.2. UNE ARCHITECTURE DISTRIBUÉE À BASE DE SERVICES Une architecture distribuée à base de services La seconde direction que nous avons retenue constitue le cœur du travail de thèse de G. Berhe. Il s agit de proposer une architecture distribuée réalisant l adaptation pour le compte de l utilisateur. Le consommateur s adresse à un mandataire (proxy) qui, lui, s occupe de l adaptation effective de la donnée. Pour réaliser cette tâche, les mandataires doivent connaître l ensemble des adaptations possibles : les divers services disponibles sont retrouvés à partir d un annuaire de services. De plus, les caractéristiques des données originales doivent être connues, sous forme de meta-données : quelle est la langue du document, quelles sont les dimensions de l image, quel est le débit de la vidéo. Enfin, les mandataires doivent connaître le contexte d utilisation (voir section 6.3). A partir de ces différentes informations, un mandataire construit un chemin d adaptation faisant intervenir un ensemble choisi de services extérieurs. L enchaînement des divers services est construit en fonction de leur compatibilité au niveau des entrées/sorties. Le premier point est donc de pouvoir trouver les services d adaptation disponibles, puis de trouver une description pertinente de ces services, en terme de fonctionnalités et d interface d entrée-sortie. Un graphe est alors construit pour l enchaînement des divers services trouvés, puis un chemin en est extrait selon le contexte d utilisation. Le mandataire lance ainsi les services d adaptation sur la donnée originale qui se trouve peu à peu adaptée au besoin de l utilisateur. La présence d un cache (voir chapitre 4) permet d améliorer les performances et d éviter de refaire des adaptations déjà réalisées par le passé. Le schéma 6.1 donne l architecture générale d adaptation. On retrouve en annexe A l article [4] présentant l architecture et les algorithmes associés. Dans cette architecture, les clients mobiles se connectent sur des mandataires d adaptation (proxies) pour y faire une requête vers un document. Ceux-ci ont accès tout d abord aux métadonnées du document (les Content Proxies stockent les caractéristiques des documents), au profil de l utilisateur (le Client Profile stocke les caractéristiques du dispositif de l utilisateur ainsi que ses préférences) et aux services disponibles (l Adaptation Service Registry possède la liste des services enregistrés et une description à la fois sémantique -ce que fait le service- et fonctionnelle -quelles sont ses entrées/sorties). Il construit alors un graphe de services disponibles et nécessaires, puis extrait un chemin d adaptation. Enfin, il contacte les différents services d adaptation en envoyant le document qui s adapte peu à peu, puis renvoie le document adapté à l utilisateur.

48 48 CHAPITRE 6. S ADAPTER Fig. 6.1 L architecture d adaptation DCAF Au niveau du prototype réalisé dans cette thèse, les services sont des services web tiers, accessibles par internet. Ce choix est motivé pour favoriser l extensibilité de la plate-forme et l utilisation de services développés par d autres équipes, réalisant une partie de l adaptation (par exemple, un tel service est le service de traduction Babelfish accessible par internet). La description WSDL (Web Service Description Language) des services web est malheureusement trop pauvre en terme de sémantique (que fait le service?), et nous avons proposé un langage descriptif des adaptations possibles, afin de pouvoir associer à haut niveau un service tiers à un type d adaptation (par exemple, s agit-il d un service de traduction?). Ces descriptions sont utilisées en premier lieu par le mandataire pour construire le graphe d interaction. Le contexte d utilisation ainsi que la description des données sont exprimés en langage XML, afin de le rendre facile à étendre, à lire et interpréter par des machines. Pour l instant, la gestion des métadonnées est manuelle dans le prototype. Nous avons amorcé une collaboration (co-encadrement de masters) avec l Université d Addis-Abeba (Ethiopie) pour notamment automatiser l extraction de métadonnées à partir des données brutes, et également construire l architecture distribuée de gestion de ces métadonnées.

49 6.3. COMPLÉMENTS SUR LA NOTION DE CONTEXTE Compléments sur la notion de contexte L adaptation présentée ci-dessus est basée sur la contextualisation des données. Je vais m attarder dans cette section sur cette notion de contexte. Trois points me semblent plus particulièrement importants : la récupération, l expression et l utilisation du contexte. La récupération du contexte se fait par l interrogation dynamique ou passive de capteurs, senseurs et logiciels fournissant des données utiles pour l adaptation des modes de consultation de l utilisateur. Il peut s agir de matériels donnant des informations sur l environnement physique de l utilisateur : par exemple la température (certains téléphones cellulaires peuvent le faire), le degré d hygrométrie (est-ce qu il pleut?), la vitesse de déplacement (l utilisateur mobile est-il vraiment mobile ou simplement déconnecté?), le taux de pollution à l ozone, etc. Il peut également s agir de logiciels de monitoring présents sur l infrastructure permettant de connaître l état du réseau (bande passante disponible, temps de latence, nombre d accès concurrents aux serveurs de données), ou des services de positionnement (par GPS, par étude des propagations des signaux WiFi,...). Nous travaillons dans l équipe à cette récupération du contexte sur deux voies différentes : d une part, par la caractérisation de lieux/locaux en analysant la puissance des émetteurs WiFi dont les emplacements sont connus (dans le cadre de la plate-forme PerSE) ; d autre part par le monitoring de Grille (thèse de J. Gossa). Dans ce dernier travail, nous proposons de créer et de maintenir des vues sur les ressources disponibles (machines de calcul, de stockage, réseau, services...). Ces vues regroupent des informations issues de différents capteurs (au sens large) et elles sont maintenues à jour par le système, et ce à plusieurs niveaux de détails (réseau local, organisation virtuelle, grille). Des points de vue sont créés à la volée pour les utilisateurs du service (administrateur de sites, développeurs, clients), en fonction de leur profil d utilisateur (droits d accès, préférences), et de la requête qu ils fournissent. Ainsi, ces points de vue sont optimisés pour offrir la meilleure qualité de service possible. Par exemple, faire une diffusion dans une communauté d un fichier peut-être plus ou moins efficace (pour l utilisateur et le système) suivant la taille du fichier et la méthode choisie : inondation sur un réseau local, arbre couvrant minimum pour un réseau maillé. Une fois les outils disponibles pour récupérer le contexte, il faut pouvoir l exprimer dans un langage commun permettant son utilisation. Je ne travaille pas spécifiquement dans cette direction (mais des étudiants de l équipe en sont chargés), mais je pense ici qu il faudra exprimer le contexte en langage XML, en utilisant des ontologies (pour avoir un vocabulaire commun) et des services de médiation permettant de reconnaître et de faire interopérer

50 50 CHAPITRE 6. S ADAPTER les différentes sources de contexte. On se trouve alors dans un cas similaire à la problématique étudiée en chapitre 4. Enfin, l utilisation du contexte dans des services passent par la mise à disposition d une interface commune d extraction d information du contexte. Cette information peut-être utilisée sur place, par un service local, pour être prise en compte lors de l exécution de ce service. Cette partie de contexte peut également être envoyée à un service distant qui adaptera alors son fonctionnement. Se pose alors le problème de la confidentialité de ce contexte. En effet, l information présente dans le contexte est personnelle à son utilisateur, qui n a pas envie de la voir diffusée à des services tiers : la localisation géographique, certaines préférences utilisateurs ont un caractère privatif indéniable. Elles ne devront être envoyées qu après accord explicite entre l utilisateur et le service distant (connaissance préalable, échange de secrets), surtout dans le cas où le service distant peut-être porté par l ordinateur portable de son voisin immédiat. Des mécanismes (analogues à ceux du chapitre 5) de sécurisation de l accès au contexte (où à des parties du contexte), et de cryptage peuvent être utilisés. Une autre solution consisterait à ne faire les adaptations qu en local (comme le cryptage/décryptage dans la section 5.3), une fois les données récupérées. Toutefois le nombre inconnu de services à intégrer (potentiellement important pour une adaptation) et leur absence potentielle sur la plate-forme locale rendent cette solution inadaptée (sans compter que les services devraient alors être tous garantis contre une utilisation malveillante...). 6.4 L adaptation à une Grille Pervasive Les travaux réalisés sur l adaptation peuvent être en partie ré-utilisés dans le cadre d une Grille Pervasive. Toutefois, il est nécessaire d y apporter quelques modifications ou adaptations. La principale adaptation de l architecture concerne la procédure de sélection des services disponibles pour effectuer l adaptation. Dans la Grille Pervasive, un dispositif peut n avoir accès qu à un sous-ensemble de dispositifs autour de lui, et par conséquent qu aux services que ceux-ci embarquent. On ne peut pas se baser sur la présence obligatoire de services web tiers disponibles tout le temps. Toutefois, il ne faut pas se couper de ces services obligatoirement, la connexion d un dispositif à l internet étant souhaitée le plus souvent possible. Il faut donc imaginer un mécanisme souple de découverte des services utilisables, par exemple en interrogeant son environnement immédiat. La co-existence de services stables et de services instables doit être prise en compte lors de la construction du chemin d adaptation, par exemple en pondérant les arcs du graphe en fonc-

51 6.4. L ADAPTATION À UNE GRILLE PERVASIVE 51 tion de leurs disponibilités attendues. Dans le cas où une architecture stable est disponible, les mandataires effectuant l adaptation seront embarqués dans le cœur du réseau, sur des routeurs actifs. Notre expérience avec Tamanoir nous a montré qu une telle approche était envisageable. Il faudra tout de même étudier plus précisément la montée en charge supportée par ces dispositifs, notamment en terme de nombres de services et surtout en terme de flux traversant le nœud actif : les paquets traversant le nœud ne doivent pas le saturer, son rôle de routeur devant être préservé. Un autre aspect concernant l adaptation et qui n est pas du tout pris en compte dans nos travaux précédents est la prise en compte de la sécurité. Je vois deux sous-aspects bien différents : d une part, il est nécessaire d assurer une certaine confidentialité afin que les données ne soient pas divulguées (envoyées pour adaptation sur un site malveillant). Pour cela, les données elles-mêmes doivent pouvoir donner d une manière ou d une autre les services qui peuvent les utiliser (les services qui apportent une certaine garantie). Je pense que cette tâche ne peut pas être déléguée au consommateur de la donnée. Elle met en jeu la notion de contrôle d accès dans un workflow, et donc une étude préalable de la notion de workflow, actuellement absente de nos préoccupations orientées données. Le second sous-aspect s intéresse à préserver les sites distants qui fournissent des services en n envoyant pas à ceux-ci des données dans lesquelles se propagent des virus et qui porteraient atteinte au système distant. Ce vœu pieu est difficile à réaliser lorsque les données sont envoyées vers des services tiers. Il faut avoir une confiance mesurée dans chacun des acteurs du système (chaque service, chaque site accueillant des services), et ainsi mettre en œuvre les mécanismes sur la gestion de la méfiance étudiés plus tôt dans le document au moment de l authentification. Comme il est difficile de se préserver totalement de ces problèmes, il est de toute manière obligatoire de pouvoir faire de la traçabilité. Et ainsi de pouvoir remonter à la source du problème.

52 52 CHAPITRE 6. S ADAPTER

53 Chapitre 7 Intégration, interactions, dépendances Je vais donner dans ce chapitre des pistes pour une architecture de gestion de données dans une Grille Pervasive. Après avoir abordé les divers services la composant en chapitre 3, puis en avoir détaillé quelques uns dans la perspective d une Grille Pervasive, il convient maintenant de définir réellement l architecture d une Grille Pervasive, qui va donner les liens entre les différents services proposés. Ces liens représentent les protocoles d échange de données et donc d interaction qu il faudra définir entre les services, de manière intégrée dans une architecture distribuée. Les points clés de cette architecture distribuée seront : transparence à l utilisateur, partage facilité de données, adaptation au contexte, modularité. La modularité me semble un point important pour la mise en place d une Grille Pervasive. L hétérogénéité des dispositifs manipulés, la diversité des usages et des usagers rendent la construction de l architecture difficile : on ne peut en effet pas se baser sur une architecture connue, stable et figée dans notre proposition. L adaptation au contexte joue au niveau de la fourniture adaptée des données aux utilisateurs mais aussi sur la présence ou non d une infrastructure stable sur laquelle des services pourront être retrouvés. Le partage facilité des données passe par la prise en compte de mécanismes de sécurisation qui n empêche pas d accéder à des données alors même que l infrastructure gérant cet accès est en partie instable. Enfin, la transparence à l utilisateur interdit une interaction trop poussée avec celui-ci. Le système doit réagir à son environnement, s adapter au contexte de manière autonome. Je propose tout d abord de reprendre les services proposés dans les chapitres précédents, en indiquant ce sur quoi ils se basent, et ce dans le cas 53

54 54 CHAPITRE 7. INTÉGRATION, INTERACTIONS, DÉPENDANCES hybride de l existence ou non d une infrastructure stable. Je donnerai alors une vue globale sur l architecture proposée. Ensuite, je reprendrai un cas d utilisation du chapitre 2 et j indiquerai sur cet exemple les interactions existantes entre les services et leur enchaînement. Enfin, j exposerai quelles technologies peuvent être mise en œuvre aujourd hui pour réaliser cette architecture. 7.1 Quels services, où, et pourquoi faire? Dans la Grille Pervasive, comme je l ai déjà mentionné, plusieurs infrastructures cohabitent, d une stabilité plus ou moins importante. Après avoir exposé les requis d une telle architecture, il convient de se poser la question en terme de localisation des différents services mentionnés. Cette localisation dépend de plusieurs facteurs : l importance du service dans l architecture, l importance de la vitesse de réponse, de la qualité de la réponse... De plus, les caractéristiques de ces facteurs sont dynamiques et évoluent avec l infrastructure disponible. A titre d exemple, si un dispositif est connecté à Internet, il peut utiliser des services web distants alors que sinon il ne peut utiliser que les services disponibles dans son entourage. Afin d esquisser l architecture du système, je vais commencer par m intéresser aux données originelles, centre de nos préoccupations. Il semble important tout d abord de pouvoir décrire les données, et ce à deux niveaux : tout d abord décrire la structure des données (utilisée pour la médiation entre les sources de données), et décrire les données elles-mêmes (pour l indexation des données et pour l adaptation). La description des données est modélisée sous la forme de métadonnées associées aux données : il est donc nécessaire d avoir une base de métadonnées associée aux données. J opte ici pour une base de métadonnées par source de données, par exemple sur la machine de stockage des données elles-mêmes : l accès à ces métadonnées (en terme de disponibilité et de droits d accès) est alors directement corrélé avec l accès aux données elles-mêmes, rendant plus cohérente leur gestion. De plus, ces métadonnées sont la plupart du temps de taille réduite et n ajoutent pas de charge de stockage. Les métadonnées sont extraites soit manuellement, soit automatiquement, en s appuyant alors sur des services disponibles sur la Grille Pervasive. Si le dispositif de stockage de la donnée possède peu d espace, ou que le choix de l utilisateur est de ne pas garder les métadonnées extraites, cette deuxième solution permet de reconstruire dynamiquement les métadonnées (moyennant le coût de reconstruction). L un des utilisateurs de ces métadonnées est le service d indexation. Ce service est distribué sur la Grille Pervasive, afin de répartir la charge, de

55 7.1. QUELS SERVICES, OÙ, ET POURQUOI FAIRE? 55 le rapprocher des données elles-mêmes, et aussi pour augmenter la robustesse du système. Un service d indexation sera responsable d un ensemble de sources de données qui lui seront rattachées (de manière non exclusive, une source pouvant être rattachée à plusieurs service d indexation). Les services d indexation présents s échangent alors leur connaissance afin d avoir une vue à plus large échelle, dans une limite raisonnable de taille de l index local. Le rattachement d une donnée à un service d indexation particulier peut se faire soit manuellement (par inscription explicite d une source de données à un service d indexation), soit dynamiquement. Nous avons travaillé par exemple dans la mise en place d index dans le cœur du réseau, au niveau des routeurs actifs [29]. Dans ce travail, l index des données est construit dynamiquement en fonction des requêtes et des transits de données dans le réseau. Cette solution basée sur l espionnage de l activité des données n indexe malheureusement que les données accédées, et ne peut être utilisée seule. De plus, cette localisation au cœur du réseau n est possible que si l index réparti reste de petite taille (la zone de stockage de l index dans le routeur actif doit rester de petite taille), donc en utilisant des techniques de compressions des informations de l index. Les données étant indexées, la recherche d une donnée est facilitée puisqu il suffit de s adresser au service d indexation. Les services présents ne contenant pas chacun l ensemble de l index, il faut maintenir une collaboration entre eux et définir des protocoles de requêtes. Les travaux engagés dans le cadre des caches collaboratifs peuvent être utilisés ici. Une fois les données décrites et indexées correctement, et leur recherche facilitée, il convient maintenant de s intéresser à l accès à ces données proprement dit. Le premier problème concerne les mesures de sécurité prises. Tout d abord, il faut pouvoir accéder au site sur lequel se trouve la donnée. La mise en œuvre de l authentification telle que décrite précédemment nécessite la manipulation de certificat d appartenance à un organisme, et la création de certificats de confiance pour les utilisateurs entre les sites. Chaque site doit donc posséder un service créant les certificats d appartenance, et les certificats de confiance, en fonction de la connaissance qu il a de son environnement et des autres sites. Une solution par défaut, donnant des droits restreints, doit être implémentée lorsque l utilisateur se présente sans certificats reconnus. Le service d authentification qui, à partir des certificats, prend une décision d accès au site doit être déployé sur chaque machine : ainsi, un dispositif doit donc embarquer un service d authentification au site auquel il appartient, de manière à pouvoir authentifier des visiteurs en étant mobile dans l environnement, et leur affecter un niveau d accès, fonction de leur profil. Pour pouvoir être embarqué sur un dispositif mobile, il doit donc rester très simple, effectuant la vérification des certificats présentés (ce qui est peut

56 56 CHAPITRE 7. INTÉGRATION, INTERACTIONS, DÉPENDANCES coûteux). Sa deuxième fonction, effectuant la correspondance entre profils étant plus coûteuse, celle-ci doit être également déployée sur l infrastructure stable pour les dispositifs ne pouvant l embarquer. Pour la fonction de cryptage décrite précédemment, il faut un service de cryptage et de décryptage utilisable sur la Grille Pervasive. Ces opérations peuvent s avérer coûteuses en temps de calcul, et difficiles, voire impossibles, à exécuter sur un dispositif mobile. Un autre avantage est la possibilité pour un utilisateur de choisir lui-même les algorithmes de cryptage et de décryptage, rendant la divulgation de l information encore plus difficile. Il faut aussi un service de partage de clés, qui, en fonction de la localité, de la disponibilité des serveurs de clés, partagera de manière adaptée la clé de décryptage. A noter qu il faut alors aussi des serveurs de clés, c est à dire des machines qui permettent de stocker et de récupérer des parties de clés, et ce de manière sécurisée. Enfin, il convient d avoir, dans la base de métadonnées associées aux données, l ensemble des adresses des serveurs de clés utilisés. L accès à ces serveurs de clés est contrôlé sur le même mode que l accès aux données elles-même : on utilise le logiciel Sygn et il faut donc, sur le lieu de stockage de la donnée (et sur celui des parties de clés), un service qui vérifie les autorisations (PDP/PEP) en fonction des certificats présentés par l utilisateur. Il faut associer à la donnée dont on veut contrôler l accès un identifiant unique, par exemple la clé publique ou le certificat d appartenance du propriétaire de la donnée. On peut noter que les mécanismes d authentification et de contrôle d accès proposés manipulent de nombreux certificats. Les certificats d un utilisateur sont stockés avec celui-ci, par exemple sur un dispositif mobile. Cette solution est préférable à un serveur de certificats, centralisé. On peut tout de même proposer sur l infrastructure stable un service de mandataire pour l utilisateur, auquel l utilisateur va éventuellement déléguer la gestion de ces certificats : afin d éviter de stocker les certificats sur ce service (et donc sur la machine associée au service), celui-ci agira comme un cache. Quand l utilisateur enverra un certificat, ce service le récupérera pour un usage ultérieur. Il est aussi envisageable d avoir un site de stockage de ces certificats, pour une question de robustesse ou de place mémoire : toutefois, cette solution n est pas souhaitable car elle introduit une tierce partie et un single point of failure dans le système. Concernant la journalisation des accès (pouvant donner lieu à de l accounting), d une très grande importance dans beaucoup de domaines dont le médical, il faut paramétrer Sygn pour le prendre en charge : ainsi, à chaque accès à une donnée, la base de métadonnées associée s enrichira de l identifiant du demandeur et de l action qu il en a fait. D autres modules peuvent être ajoutés à Sygn pour gérer par exemple

57 7.2. SCHÉMA SIMPLIFIÉ DE L ARCHITECTURE 57 l anonymisation de parties de documents. Cette fonctionnalité peut s avérer importante, notamment dans le cadre de données confidentielles comme les données médicales. Une fois la donnée récupérée, il peut être intéressant d en faire un réplica, ou tout simplement la cacher. Le service de réplication nécessite des services de monitoring de la Grille Pervasive, afin d optimiser l emplacement des réplicas, comme présenté plus haut. Le service de cache collaboratif a besoin quant à lui du service d indexation sémantique pour catégoriser les données et mettre en œuvre une politique de remplacement adaptée aux usages. De plus, il utilise des métadonnées pour mettre en place sa politique globale, donc une base de métadonnées doit lui être accessible. La donnée récupérée va subir des traitements avant d être envoyée à l utilisateur : adaptation, calculs intensifs, visualisation,... Ces services sont présents sur la Grille Pervasive, et nécessite l interaction avec un intergiciel de grille qui prendra en charge le lancement des travaux nécessaires. En outre, le service d adaptation s appuie sur la description des services disponibles et du contexte d utilisation. Des services de récupération et de représentation de contexte sont nécessaires. De manière générale, des méthodes de découverte et de répertoire des services disponibles (quels services sont disponibles, et où?) doivent être accessibles : pour ce faire, un dispositif mobile embarque un service local de découverte et de répertoire, qui fait appel à des services similaires sur l infrastructure stable (si celle-ci est disponible) et qui interroge son environnement pour découvrir les services présents sur les dispositifs environnants. Du point de vue de l utilisateur final, qui consulte les données, il faut au maximum minimiser les logiciels et informations qu il doit transporter (attendu qu il peut avoir un dispositif peu puissant et/ou avec peu de mémoire). Aussi, il faut lui permettre d utiliser les services extérieurs. Dans les services déjà mentionnés, le seul service nécessaire est celui de découverte des services extérieurs, et sa seule information nécessaire est une base de données contenant l ensemble des certificats qu il a pu glaner au cours de ses déplacements (au moins un certificat d appartenance, lui servant d identifiant unique sur le système). La combinaison du service de découverte et de l identifiant de l utilisateur lui permet de reconstruire peu à peu sa vision de la Grille Pervasive. 7.2 Schéma simplifié de l architecture Cette section se propose de donner sur le schéma simplifié 7.1 l organisation de l architecture, et donc de reprendre les services pour les associer

58 58 CHAPITRE 7. INTÉGRATION, INTERACTIONS, DÉPENDANCES visuellement dans la Grille Pervasive. Sur ce schéma, on retrouve la Grille Pervasive entourée par un trait pointillé. Ici, elle est composée d un certain nombre de ressources de calcul, de stockage, de stations de travail, de PDAs et de Smartphones. Ces divers matériels sont regroupés en trois Organisations Virtuelles, comme sur les Grilles de calcul de type OGSA : le partage de ressources se fait au sein d une même organisation virtuelle. Des matériels peuvent appartenir à plusieurs organisations virtuelles : c est le cas d une ressource de stockage partagée entre les organisations virtuelles B et C. D autres peuvent ne pas appartenir à une organisation virtuelle, comme c est le cas du serveur de stockage D au centre du schéma. L appartenance des divers matériels à des institutions n est pas représentés, par souci de simplification du schéma, mais chaque matériel peut se trouver dans n importe quelle institution. Sur le schéma sont aussi représentés des services extérieurs à la Grille Pervasive (accessibles sous forme de web services), une ressource de stockage extérieure (le stockage externe S) et un client externe à la Grille Pervasive (le PDA). Les services déployés sont indiqués dans les cadres reliés aux diverses ressources. Par souci de simplification, tous les services ne sont pas repris sur toutes les ressources. De plus, chaque ressource n a pas vocation à héberger tous les services. L organisation virtuelle A abrite une ressource de calcul : ce peut-être un ordinateur seul, ou une grappe de PC, ou une machine parallèle : il s agit ici d une ressource stable. Sur cette ressource sont lancés plusieurs services : un service d indexation qui va répertorier des données disponibles ; un service de cache collectif, qui agrégera la vue de plusieurs caches de l organisation virtuelle A ; un service de contrôle d accès à la ressource de calcul ; et enfin un mandataire d adaptation, qui réalisera l adaptation des données vers les clients consommateurs (par exemple le SmartPhone). Sur ce téléphone, on retrouve un service de décryptage (pour décrypter les données cryptées) ; un service de stockage des certificats récupérés lors des déplacements ; des services de visualisation de résultats et d interaction avec l utilisateur ; un service de contexte, permettant de recueillir et communiquer le contexte de l utilisateur ; un service de découverte des services disponibles : ce téléphone agira en tant que client de la Grille Pervasive. Le PDA possède un service de calcul, et sera potentiellement utilisé par des clients qui devront s authentifier et être autorisé (ici les services d autorisations et d authentification sortent d une utilisation purement donnée de la Grille Pervasive). Enfin, une ressource de stockage est présente sur laquelle on retrouve les services de sécurité pour le contrôle de l accès à cette ressource ; un service de stockage crypté ; et enfin un service de réplication. Dans l organisation virtuelle B, on trouve une ressource de calcul qui possède, outre les services déjà mentionnés auparavant, des services de calcul,

59 7.2. SCHÉMA SIMPLIFIÉ DE L ARCHITECTURE 59 GRILLE PERVASIVE Organisation virtuelle B LAPTOP Ressource de calcul indexation cache collectif decryptage encryptage/ Ressource de stockage de calcul autres services stockage des descriptions des services disponibles stockage des profils utilisateurs stockage de l historique d utilisation Ressource de stockage D Station de travail indexation cache collectif mandatataire d adaptation contrôle d accès Ressource de calcul décryptage stockage de certificats visualisation IHM Contexte Découverte de services Smartphone Organisation virtuelle A PDA Organisation virtuelle C Ressource de stockage Smartphone Station de travail LAPTOP Ressource de calcul PDA Ressource de stockage service de calcul contrôle d accès Authentification contrôle d accès réplication stockage crypté Authentification Indexation Service de metadonnées descriptive des données Contrôle d accès Authentification Cache local Anonymisation médiation Mandataire d accès Ressource de stockage Stockage externe S indexation contrôle d accès service de métadonnée pour l adaptation réplication Services web extérieurs à la Grille Pervasive (pour l adaptation) PDA Fig. 7.1 Schéma simplifié d une Grille Pervasive, vue du coté des données

60 60 CHAPITRE 7. INTÉGRATION, INTERACTIONS, DÉPENDANCES ainsi qu un service de cryptage/décryptage utilisable par les clients qui n ont pas les ressources nécessaires. La ressource de stockage possède un service de description des services disponibles (un annuaire) ; elle stocke aussi les profils des utilisateurs ; enfin elle stocke l historique d utilisation de la Grille Pervasive : quelle action demandée par l utilisateur, quel enchaînement de services, quel résultat. L organisation virtuelle C accueille un PDA possédant une zone de stockage mise à disposition de la Grille Pervasive, où sont stockées des informations. Un service de réplication est présent, ainsi qu un service description des données présentes (cette description est utile pour réaliser l adaptation). Un mandataire réalise l interface entre la ressource externe S et la Grille Pervasive. Outre les services classiques de sécurité, on trouve un service de cache local évitant les requêtes à la source de la donnée ; un service d indexation répertoriant les données présentes sur cette ressource ; un service de description des données présentes ; un service d anonymisation (si les données sont des données médicales, il convient de les anonymiser avant stockage sur la Grille Pervasive) ; un service de médiation réalisant l intégration de cette ressource et en facilitant l accès. Enfin, le PDA extérieur, voulant accéder à la Grille Pervasive, le fera en tant que client ou en tant que fournisseur. Dans le premier cas, il doit donc pouvoir s authentifier quelque part, et suivant les politiques d accès des diverses ressources, il pourra alors y accéder, peut-être par rebond : l organisation virtuelle A peut avoir confiance en lui, mais B pas directement, mais B fait confiance à A. Ainsi, l utilisateur du PDA pourra utiliser une partie des ressources de l organisation virtuelle B. Sinon, il devra se contenter des ressources acceptant les utilisateurs sans authentification (comme par exemple la ressource de stockage D). On peut noter que cette réflexion est aussi vrai lorsqu un utilisateur d une organisation virtuelle veut accéder aux ressources d une autre organisation virtuelle. Si le PDA fournit des services, il devra s enregistrer sur un service de répertoires des services disponibles, et éventuellement installer des services disponibles de contrôle d accès, de stockage crypté, etc... Tous les services ne sont pas répétés sur toutes les ressources, par souci de simplification du schéma, mais aussi car l administrateur de la ressource peut choisir ou pas de déployer tel ou tel service. Par exemple, le service d authentification et celui de contrôle d accès peuvent être présents partout (au choix des administrateurs des sites). Toutefois, un cœur minimal d interaction avec la Grille Pervasive devra être déployé partout, par exemple tout simplement pour découvrir les services disponibles. Certains services seront dupliqués pour augmenter la robustesse et éviter les surcharges (comme par exemple l indexation, les répertoires de services,...) au sein d une orga-

61 7.3. ILLUSTRATION SUR UN CAS D UTILISATION 61 nisation virtuelle, ou au niveau global de la Grille Pervasive. De plus, sur ce schéma, de nombreux services ont été omis, simplifiés, et il manque les protocoles d échange de données entre les différents services, ainsi que les détails des structures de données. Néanmoins, il permet de fixer quelque peu les idées sur une architecture de Grille Pervasive. 7.3 Illustration sur un cas d utilisation Je vais reprendre le cas d utilisation d une Grille Pervasive dans le domaine médical évoqué en chapitre 2, et mettre en lumière les différents services utilisés. En premier lieu, je précise un peu les conditions du cas d utilisation. On suppose tout d abord que Monsieur Toulemonde possède une carte vitale étendue, sur laquelle est indiqué son identifiant. Ensuite, ses données médicales sont stockées dans son dossier médical partagé (mis en place dans la Région Rhône-Alpes dans un réseau de soin composé d un certain nombre de centres de soin, actuellement en fonctionnement réel), et dans une clinique privée non raccordée à ce réseau. Tous les documents de santé existants sont écrits en langue française. Dans la clinique, les documents sont stockés sous format audio (compte rendu opératoire, d anesthésie,...). Le secouriste autrichien dispose d un Palm, possédant une liaison WiFi. La borne WiFi se trouve dans l ambulance et permet au secouriste de consulter le dossier médical des patients à travers le réseau de l hôpital. L intervention du secouriste commence sur le lieu même de l accident et se poursuit lors de son acheminement vers l hôpital. Lorsque celui-ci veut récupérer les informations allergiques à certains produits concernant le patient, il lui faut en premier lieu savoir où elles se trouvent. A partir de l identifiant de Monsieur Toulemonde et de la requête elle-même (allergies?), le système recherche grâce au service d indexation les centres de stockage susceptibles de posséder des informations intéressantes. Le secouriste doit alors entrer en contact avec ces centres. Il lui faut donc obtenir des autorisations pour rentrer sur les systèmes d informations médicaux français : il les obtient à partir de son certificat d appartenance au système de santé autrichien. Des certificats de confiance sont établis pour le secouriste pour l accès au réseau de soin, et pour l accès à la clinique (par forcément les mêmes certificats de confiance, car il n y a pas forcement les mêmes politiques de méfiance envers le système de soin autrichien). Ces certificats sont employés pour accéder aux centres de soin (on suppose qu ils ont le niveau requis pour accéder aux allergies aux médicaments). Le service de médiation transforme la requête du secouriste vers les

62 62 CHAPITRE 7. INTÉGRATION, INTERACTIONS, DÉPENDANCES schémas des bases de données dans les centres de soins, et négocie, en fonction du profil et de la requête présentée par celui-ci, les morceaux de la base qui lui seront accessibles. La requête du secouriste est exprimée en utilisant un vocabulaire commun (ontologie du domaine médical) gommant les problèmes de langue. Ce travail est déjà réalisé dans le réseau de soin, qui a déjà fait ce travail en interne lors de la création du réseau et qui présente donc un schéma cohérent pour l ensemble de ces informations patients. La liaison entre le réseau de soin et la clinique se fait à partir des schémas des bases, et un rapprochement automatique est fait (si le rapprochement automatique n existe pas, le secouriste ne pourrait pas être d un grand secours, les schémas des bases étant probablement exprimés en français). Pour accéder aux données proprement dites, le secouriste doit présenter au contrôle d accès (Sygn) les certificats nécessaires à la lecture. Or, ces informations sont contrôlées par Monsieur Toulemonde, qui doit délivrer un certificat d accès à ces données lui-même (c est le principe de Sygn). Ici, il est inconscient, donc il ne peut pas. Monsieur Toulemonde doit donc avoir créé au préalable des certificats d accès standards à ses données : par exemple, les personnes pouvant endosser le rôle secouriste peuvent lire les allergies aux médicaments. Un répertoire des certificats standards de Monsieur Toulemonde doit être accessible en ligne. Celui-ci est accédé par le secouriste à partir de l identifiant du patient pour les retrouver. Muni de ce certificat d accès, le secouriste se présente à Sygn qui autorise l accès et renvoie les données. Ces données sont cryptées, et le secouriste n a malheureusement pas de service de décryptage sur son Palm. Il récupère dans un premier temps les morceaux de clés de décryptage nécessaires au décryptage, suivant le même cheminement que la donnée elle-même. Puis il recherche un service de décryptage en ligne, et y envoie les documents. Ce service de décryptage peut aussi bien se trouver sur Internet que sur un dispositif mobile voisin du secouriste. Les métadonnées des documents décryptés sont analysées pour connaître la nature des documents retrouvés et voir comment ils peuvent être exploités par le Palm. Un mandataire d adaptation est alors recherché en ligne, puis utilisé pour créer une chaîne de transformation des documents originels (en français, écrit et parlé) vers des documents exploitables par le Palm du secouriste dans un environnement bruité où l on ne peut que lire, pas écouter une bande son : un service de changement audio vers texte, un service de traduction textuel français-allemand. Finalement, le secouriste accède aux données pertinentes dont il avait besoin pour soigner Monsieur Toulemonde et peut lui administrer les premiers médicaments. Pendant le transport du patient vers l hôpital, le secou-

63 7.4. AU FINAL, QUEL DÉPLOIEMENT? 63 riste transmet à l hôpital les informations dont il dispose (médicaments administrés, allergies connues, identifiant du patient). Sur place, avant même l arrivée de l ambulance, un chirurgien peut récupérer, sur le même principe, mais avec des conditions différentes (terminal de consultation moins contraint, rôle dans le système de soin plus élevé,...) des informations plus complètes (antécédents opératoires, scanner,...) afin de pouvoir intervenir judicieusement au plus vite. 7.4 Au final, quel déploiement? On peut finalement se poser la question de la mise en œuvre effective de cette architecture sur une infrastructure réseau. Cette architecture ressort à la fois de l architecture de Grille de calcul OGSA [2] (Open Grid Services Architecture), et de réflexions dans la mise en place de la plate-forme d accueil de services pervasifs PerSE [47] que nous avons dans l équipe, tout en étant spécialisée sur l aspect gestion de données. OGSA est développé au sein du Global Grid Forum (GGF). Il s agit d une architecture à base de services pouvant exécuter des traitements sur une Grille de Calcul. OGSA fournit les fonctionnalités désirées des composants et des protocoles de l architecture, l infrastructure étant aujourd hui assurée par WSRF (Web Service Resource Framework). WSRF constitue en quelque sorte une extension des Web Services pour les rendre stateful, c est à dire à état : un service WSRF est persistant et retrouve l état de l appel précédent lors d un nouvel appel, contrairement au service web classique qui s exécute indépendamment chaque fois, sans effet mémoire. Les fonctionnalités d OGSA ont été découpées en 6 champs d études : services de gestion de l exécution des processus, services de données, services de gestion de ressources, services de sécurité, services d auto-gestion, services d information. A propos de la gestion des données, l architecture OGSA ne prévoit rien d intégré à ce niveau, mais plutôt un ensemble d outils permettant de gérer l accès aux données (OGSA-DAI, pour Data Access and Integration), les réplicas (RMS), le transfert de données (GridFTP),... De plus, certains services bénéficieraient de connexions plus étroites avec des services en dehors de leur champ : par exemple, le service d information (qui traite les informations sur les sources de données, les ressources de stockage, de calcul, réseau,...) est utile directement pour l accès aux données par exemple, mais fait partie d un champ d étude différent. Un autre problème que je vois avec OGSA/WSRF est la lourdeur des protocoles manipulés et de l architecture. Dans WSRF, les appels de services sont encapsulés par le protocole SOAP, qui a l avantage d être standard mais qui ajoute une enveloppe très

64 64 CHAPITRE 7. INTÉGRATION, INTERACTIONS, DÉPENDANCES verbeuse au message original. Ceci n est pas un souci lorsqu on a affaire à une infrastructure stable dont les connexions réseaux possèdent des débits importants, mais qui le devient dans le cadre d une infrastructure sans-fil à bande passante éventuellement limitée. De plus, OGSA repose sur la présence obligatoire d un certain nombre de services. Une expérience que nous avons menée avec le laboratoire CITI au sein du projet ACI Darts [43] a montré que la modularité (sur le papier) de l architecture OGSA était limitée, et qu il était en pratique difficile de limiter la taille du cœur d OGSA : le but de ce projet était de créer un OGSALight et d embarquer seulement un sous ensemble des services OGSA nécessaires (en partant de l implémentation Globus Toolkit 3.2), au sein d une plate-forme d accueil de composants de type OSGi [34] (Open Services Gateway Infrastructure). La complexité de OGSA provient du nombre de problèmes traités qui vont au-delà de la simple gestion des données. L approche retenue dans OGSA est très modulaire, et en ce sens mérite toute notre attention. De plus, OGSA repose sur des standards (comme par exemple les certificats X509 pour l authentification, SSL pour le transport sécurisé) et propose des spécifications pour l implémentation des divers services la composant. Cette standardisation permet un ralliement plus large à la norme de-facto OGSA, surtout pour les industriels. Malgré tout, la volonté de traiter beaucoup de problèmes en une plate-forme la rend difficile à appréhender. De plus, OGSA ne s intéresse pas spécifiquement aux problèmes liés aux environnements pervasifs, comme la mobilité, la localisation, les contraintes de l environnement et de l utilisateur. Aussi, même si OGSA pourrait sembler être une base intéressante pour déployer une Grille Pervasive (voir notamment Mobile OGSI.NET dans la section suivante), il faudrait d une part reprendre chaque service et y ajouter des fonctionnalités pour les adapter aux besoins spécifiques ; d autre part, il faudrait travailler globalement sur la modularité effective de l implémentation. PerSE [47] est une plate-forme d accueil pour les services pervasifs. Elle est orientée utilisateur, et repose sur le principe de la composition de services pour l exécution d une action voulue par l utilisateur. L utilisateur exprime son intention par une action partielle (comprendre partiellement définie ). Le système propose alors une action complète à l utilisateur, en consultant l historique des actions effectuées dans le même environnement (deux utilisateurs passant au même endroit ont des chances d effectuer la même tâche), ainsi que l ensemble des services disponibles dans son environnement. Une action est ainsi un enchaînement de services, qui est géré par une base PerSE pour le compte de l utilisateur de cette base. Chaque service peut être construit indépendamment de PerSE (l idée étant de réutiliser des services existants par ailleurs). L appel à des services (éventuellement extérieurs à la base) se fait selon le protocole réseau le plus adapté, en suivant l interface

65 7.4. AU FINAL, QUEL DÉPLOIEMENT? 65 des services. Celle-ci n est pas modifiée pour être connue par PerSE, seulement une déclaration de mise en œuvre dans la base PerSE est nécessaire : l inscription dans le registre local de la base, une description sémantique de ce que fait le service, ainsi que la description des entrées/sorties du service -plus tard, il est envisagé de décrire non seulement les entrées/sorties mais aussi le fonctionnement interne du service). La sécurité est gérée comme un ensemble de services externes appelés au besoin par la base PerSE pour l authentification et le contrôle d accès (suivant les modèles décrits en chapitre 5) ainsi que le transport sécurisé (TLS/SSL). De même, la journalisation est un service externe qui peut être activé au choix de l utilisateur de la base PerSE. Dans PerSE, l efficacité a été le maître mot dès le départ du projet, et un accent a été mis pour optimiser les algorithmes de découverte et d enchaînements de services, les protocoles de communication. Ainsi, les communications se font au plus proches du système sous-jacent, avec une interopérabilité des divers protocoles assurés manuellement, mais offrant des performances inégalables. De plus, le taille du projet en terme d ambition n a rien à voir avoir OGSA, et permet une meilleure efficacité. Le code de la base est développé en C++ dans le système Windows, les communications entre services utilisent DCOM si possible, sinon directement les sockets IP. Les services périphériques sont développés en C++ (la journalisation par exemple) et Java (les services de sécurité). Les services utilisateurs de la base PerSE sont écrits dans le langage au choix du programmeur. Alors que le problème pour OGSA est de faire fonctionner divers systèmes ensembles, et donc un accent très important sur l interopérabilité, PerSE a été conçu en travaillant d abord sur les performances individuelles des modules puis en adaptant au fur et à mesure à plusieurs types de dispositifs/protocoles. Cette seconde vision a l avantage de pouvoir être utilisée réellement en environnement contraint par les capacités des terminaux et celles des réseaux de communication. Dans notre réalisation de Grille Pervasive, nous empruntons aux deux approches, puisque nous prévoyons la souplesse de l architecture PerSE pour la construction de services et leur enchaînement, et l ambition d OGSA dans le nombre de problème traités et la standardisation de-facto. Je vais m intéresser maintenant aux contraintes de réalisation de la partie données de la Grille Pervasive. Les certificats gérant les aspects sécurité dans la Grille Pervasive sont de taille réduite (quelques centaines d octets chacun). Les algorithmes utilisés sont peu coûteux en temps et en espace, et les informations stockées dans les bases de métadonnées sont de taille limitée (ou limitable, comme c est le cas pour le cache par exemple). A titre d exemple, prenons le service d indexation sémantique 4.2. Celui-ci construit un arbre d indexation, qui peut, suivant sa profondeur et sa largeur, tenir

66 66 CHAPITRE 7. INTÉGRATION, INTERACTIONS, DÉPENDANCES dans un espace relativement restreint (un service d indexation n a pas à gérer l ensemble des documents présents dans le système, mais seulement un sous-ensemble). L algorithme employé en section 4.4 afin de gérer le remplacement des éléments dans le cache à partir de cet arbre d indexation est basé sur quelques opérations élémentaires (addition, soustraction), sur un sous-ensemble de l arbre (où des changements de température ont eu lieu) et est donc peu coûteux. Cependant, au niveau global de l ensemble des services, seule une implémentation effective de l architecture intégrée permettrait de mesurer réellement les choix et les optimisations nécessaires. Au niveau des communications entre les divers services, il faut éviter au maximum d utiliser les protocoles verbeux comme SOAP/XML/WSDL, et limiter leur utilisation aux fonctions de découverte et de répertoire de services dans le système, mais que les requêtes entre services doivent se faire de manière plus légère. Par exemple, les services disponibles sur une plateforme peuvent s annoncer aux autres plate-formes en utilisant une description WSDL étendue afin de décrire leurs fonctionnalités dans un répertoire. Une fois celle-ci décrites, les autres services peuvent les utiliser directement sans passer par une couche d encapsulation de la transmission réseau. Ici aussi, des comparaisons en termes de volume de messages manipulés devra être faite in-vivo après une première phase d expérimentation. Je ne me suis intéressé ici qu à la gestion de données dans cette architecture de Grille Pervasive : sa réalisation peut s avérer assez simple et directe. Toutefois, elle repose sur une architecture plus complète restant à définir réalisant d autres traitements que la gestion des données, principalement la gestion des calculs. C est pourquoi une adaptation d une architecture de type OGSA n est pas à exclure, et doit au moins mériter une étude approfondie. 7.5 Pourquoi ça n existe pas encore? On peut légitimement se poser la question. En fait, il existe peu de travaux à ma connaissance de réponse globale pour une Grille Pervasive telle qu elle est comprise dans ce document, en tout cas rien qui adresse le problème de la gestion de données. Il existe, pour chacune des parties évoquées dans ce document une littérature riche, que le lecteur retrouvera pour les plus importantes dans les travaux cités dans les publications jointes en annexe A. Davies, Storz et Friday [11, 55] sont dans les premiers à avoir introduit la notion de Grille Ubiquitaire, qui se rapprochent de notre vision de la Grille Pervasive. Leur propos est de comparer les notions de Grille de Calcul (définition de I. Foster [18]) et celle de Systèmes Pervasifs (vision de M. Weiser [56]). Ils identifient de manière générale plusieurs points de similitude :

67 7.5. POURQUOI ÇA N EXISTE PAS ENCORE? 67 hétérogénéité et intéropérabilité, passage à l échelle, adaptabilité et tolérance aux fautes, gestion des ressources et composition de services, découverte de services, sécurité, communication, audit, paiement. Ils présentent alors un cas d utilisation d une telle grille ubiquitaire (dans le domaine médical) et passent rapidement sur leur réponse en utilisant Globus toolkit 3. Le manque de détails d implémentation et le nombre important de points laissés flous ne permettent pas de se faire une idée de la complexité de la tâche. Un point important de leur propos est qu ils pensent qu une telle grille ne verra le jour que par l harmonisation et l intégration, passant par l adoption de mécanismes de communications entre réseaux standardisés et par l identification des services du coeur de l architecture, ayant des interfaces bien connues. En ce sens, j adhère complètement à cette vision. Malheureusement, les auteurs ne se sont pas penchés sur la gestion de données proprement dite, la noyant dans le reste de leur propos. Hingne et al. [22] proposent une approche multi-agent pour la réalisation de la Grille Pervasive. Ils s intéressent à la communication, l hétérogénéité, la découverte et la composition de services, ainsi qu à l ordonnancement de tâches entre les divers dispositifs. Pratiquement rien n est dit sur les données dans ceet article. McKnight et al. [31] introduisent la notion de grille sans fil ( Wireless Grids. Ils s intéressent principalement à la notion de mobilité et de nomadicité, et comparent leur approche avec les grilles de calcul traditionnelles, les réseaux Pair à Pair et les services Web. Un point important de cet article est la mise en lumière des relations entre ces différents acteurs et leur nécessaire prise en compte dans l achèvement d une Grille sans fil. Les auteurs focalisent leur propos sur l intergiciel et les services qui leur semblent les plus importants : description et découverte de ressources, coordination, établissement de la confiance et contrôle des accès. Ces deux derniers points font l originalité de leur approche puisqu ils s intéressent à la sécurité. Dans [54], S.H. Srinivasan introduit une architecure de Grille Pervasive sans fil. Dans cette approche, l auteur découpe sa Grille en deux parties : une connecté physiquement (backbone grid), et une autre sans fil (access grid). Des agents réalisent l intermédiaire entre les deux grilles et agissent pour le compte des périphériques mobiles de l access grid sur la backbone grid. Le point intéressant de cet article est la prise en compte de la proactivité (l environnement anticipe les besoins de l utilisateur) et de la contextualisation de la présentation des résultats pour les utilisateurs. De manière complémentaire et orthogonal, des travaux existent pour prendre en compte certains aspects des systèmes pervasifs dans les Grilles de Calcul. Les algorithmes et l architecture de grille actuels ne prennent pas en

68 68 CHAPITRE 7. INTÉGRATION, INTERACTIONS, DÉPENDANCES compte en général la mobilité : la raison principale en est qu il est considéré que les dispositifs mobiles ne participent pas à la grille. La plupart des travaux s intéressent à l aspect consultation, c est-à-dire comment présenter l information disponible sur la grille sur un dispositif mobile, réalisant l interface entre l utilisateur et la grille. Quelques travaux intègrent la mobilité dans la construction de la solution d intergiciel de grille, d autres s intéressent à la façon dont les intergiciels existants peuvent s adapter. Un exemple d interface entre des services de grilles et des dispositifs mobiles est donné au sein de projet européen GridLab [41]. Dans [21], Graboswki et al. montrent comment certains services sont des enveloppes à des services de grilles quand d autres sont développés spécifiquement pour être exécutés sur les mobiles. Ces services sont des clients de la Grille, et ne participent pas à la résolution des problèmes. Gonzalez-Castano [19] donnent une solution pour la soumission de travaux et les requêtes sur ces travaux en environnement mobile sur l intergiciel de grille Condor [10] : les mobiles agissent ici en tant qu interfaces clientes vers l intergiciel de grille. Akogrimo (Access to Knowledge Through the Grid in a Mobile World) [40] est un projet européen qui s intéresse à la manière dont OGSA peut bénéficier de l internet mobile IPv6. Sur le même plan, Jiang et al [24] ont abordé les bénéfices qu apporte IPv6 pour les Grilles de calcul. Parmi les avantages, les auteurs s intéressent entre autres à la prise en compte de la mobilité dans le protocole IPv6, rendant plus facile son utilisation dans la Grille. Par exemple, IPv6 rend plus facile (qu avec IPv4) le déplacement entre réseaux différents, avec une notification globale lors de la sortie et l entrée dans un nouveau réseau. Cette fonctionnalité permettrait de faciliter la résolution du problème de la déconnexion en environnement mobile. De manière analogue, le projet koréen KGrid [42] s intéresse à la mise en place d une grille mobile, basée sur des PDA et LAN sans-fil. Clarke et Humphrey [9], après avoir donné quelques implications sur la Grille de calcul du monde sans-fil et mobile, exposent comment l intergiciel Legion [30] peut gérer de manière convaincante la présence de dispositifs mobiles pour les intégrer à la Grille : l idée de base est que Legion peut adapter son comportement en étant réflexif, pouvant modifier son implémentation et les caractéristiques de son exécution en cours de route. Les points importants de Légion qui facilitent cette mise en œuvre sont pour les auteurs, l espace de nom persistant et indépendant de la localisation des ressources, le passage à l échelle (grâce à la décentralisation complète du système), la possibilité d adapter les protocoles réseau, la flexibilité de la gestion de la sécurité (en utilisant ou pas PKI-Public Key Infrastructure) et enfin de gérer les déconnexions intempestives (grâce notamment à l espace de nom persistant). Malheureusement, aucune mise en pratique n est donnée, ni le coût

69 7.5. POURQUOI ÇA N EXISTE PAS ENCORE? 69 d installation de Legion sur un dispositif mobile. Phan et al. proposent dans [36] une solution appelée LEECH (Leveraging Every Existing Computer out there). Après une étude intéressante sur le développement des dispositifs mobiles dans le grand public, ils montrent comment un système de mandataire peut réaliser la passerelle entre les dispositifs mobiles et la Grille de Calcul. La Grille ne connaît que des interlocuteurs, ceux-ci se chargeant de distribuer le travail entre les dispositifs mobiles qui leur sont rattachés, et de gérer l ordonnancement et l exécution des tâches. Ils gèrent ainsi l hétérogénéité des mobiles, les déconnexions, le manque de ressources de calcul, de stockage, de réseau ou d énergie des mobiles. Enfin, un système économique poussant les utilisateurs à venir sur cette plate-forme et fournir leurs capacités à la grille est abordé. Aucune implémentation n est donnée, il s agit d un article de position sur le thème, et des questions importantes comme le nombre de dispositifs rattachés à un interlocuteur n est pas suffisamment discuté. Dans [35], Park et al. s intéressent tout d abord à définir les nouveaux services dus à la mobilité dans les Grilles de Calcul. Ils focalisent leur propos sur le problème de la déconnexion et l ordonnancement de tâches, et ils proposent un algorithme d ordonnancement adapté. L approche est similaire à [36] dans le sens où une passerelle interface les dispositifs mobiles à la Grille, masquant les déconnexions. Des agents spécifiques à chaque mobile sont déployés sur les mobiles pour gérer les soumissions et récupérations de travaux à travers une file d attente des travaux. Dans le même ordre d idée, Sample et al. [46] proposent une solution d ordonnancement répondant aux difficultés inhérentes à l incertitude des environnements pervasifs. Litke et al. [1] présentent un article de position sur la gestion de ressources dans les environnements mobiles. Les auteurs répertorient les principales difficultés concernant la soumission de travaux, leur migration, leur monitoring, la découverte et la sélection de ressources et la gestion des réplicas. Bruneo et al. [6] étudient plusieurs paradigmes de communications et caractérisent les situations propices à une solution à base d agents mobiles (comparativement au client/server ou à l appel à distance), et ce dans un environnement de Grille mobile. Dans le même ordre d idée, Baude et al. [3] montrent comment la plate-forme ProActive [39] peut être utilisée pour gérer la migration transparente d objets entre sites. Il faudrait voir comment ces solutions se comportent lorsque les sites sont eux-mêmes des dispositifs mobiles, à capacité de traitement et de stockage limités. Kurkovsky et al. présentent dans [26] une solution basée uniquement sur des dispositifs mobiles pour créer un environnement pour la résolution de problèmes (Problem Solving Environment). Un mobile peut ainsi initier une tâche et l exécuter en local, ou solliciter d autres mobiles alentours pour l ai-

70 70 CHAPITRE 7. INTÉGRATION, INTERACTIONS, DÉPENDANCES der dans cette tâche. L architecture est basée sur deux serveurs : le serveur de courtage, qui connaît l ensemble des mobiles, leurs caractéristiques, et la distribution des tâches, et le serveur de communication, qui gère les communications entre les mobiles. Chaque mobile embarque une application légère gérant les communications avec l extérieur. Lorsqu une tâche nouvelle doit s exécuter, l initiateur envoie le code source et les paramètres au serveur de courtage qui compile et distribue le travail. Cette solution adhoc est bien adaptée aux problèmes qui se découpent facilement et régulièrement, mais n est pas généralisable. Mobile OGSI.NET [8] présenté par Chu et Humphrey étend la plateforme de Grille OGSI.NET vers le monde mobile. C est le premier effort de la prise en compte de la mobilité dans l infrastructure normative OGSI. Pour les auteurs, la difficulté de la mobilité provient des ressources limitées des dispositifs ainsi que des déconnexions fréquentes. La migration de tâches est possible, et la distribution suit le modèle maître/esclaves, où un mobile peut distribuer ses sous-tâches à d autres mobiles. L implémentation repose sur Compact Framework.NET, et a été testée sur un petit parc de PocketPC (3!) avec diverses versions de Windows CE comme systèmes d exploitations. L infrastructure de déploiement.net prend beaucoup de place (4 MB), la partie mobile ne rajoutant que 187 KB (avec des services mobiles inclus). Ce travail préliminaire montre la possibilité d utiliser les mobiles comme ressources de calcul, tout en utilisant une plate-forme standard. Toutefois, des expériences en termes de passage à l échelle et de réelle prise en compte de la dynamique sont absentes de cet article. Zhang et Parashar s intéressent dans [57] au contrôle d accès en fonction du contexte dans les environnements de Grille. Ils proposent SESAME, un système de contrôle d accès à base de RBAC dynamique. Cet article est intéressant car il présente une prise en compte du contexte dans la prise de décision concernant l accès à des ressources. Enfin, Yamin et al. [16] présentent une solution basée sur le concept maitre/esclaves pour une architecture de grille de calcul adaptable au contexte et à la mobilité. L architecture ISAM propose un langage de programmation (ISAMADAPT, qui permet de décrire les alternatives d exécution), un environnement d exécution (qui vérifie les changements de contexte et en informe l application) et un serveur de reconnaissance du contexte. L application et le système collaborent pour adapter le fonctionnement général au contexte : cette prise en compte n est pas transparente à l application, qui doit avoir été écrite pour cela. L intérêt de cette approche est sa généricité, permettant l adaptation du comportement d une application en général, et pas dans un contexte d utilisation particulier. La nécessité d avoir a priori l ensemble des adaptations possibles au développement est à

71 7.5. POURQUOI ÇA N EXISTE PAS ENCORE? 71 mon avis un problème majeur de cette proposition. Tous les travaux présentés ici s intéressent à une partie du problème, à savoir soit la mobilité, soit le contexte, et généralement pas pour la gestion de données. Cet état de l art n a pas vocation à être exhaustif, mais plutôt à montrer les différentes voies qui ont été entrevues pour la prise en compte de l environnement pervasif dans les grilles de calcul. Beaucoup de travaux sont récents et toujours en cours de développement ; il est certain que les prochaines années verront arriver d autres solutions plus matures sur ce thème convergent. C est dans cette dynamique que s inscrit la proposition élaborée dans ce document.

72 72 CHAPITRE 7. INTÉGRATION, INTERACTIONS, DÉPENDANCES

73 Chapitre 8 Conclusions de cet essai, perspectives Nous avons présenté dans ce mémoire une approche intégrée pour la gestion de données en environnement de Grille Pervasive. Nous avons tout d abord identifié un certain nombre de services relatifs à la gestion des données nécessaires à celle-ci. Notre proposition s appuie sur un ensemble de travaux réalisés dans l équipe de recherche depuis quelques années. L architecture proposée prend en compte la mobilité, l imprédictibilité et le contexte de l utilisateur voulant profiter d une infrastructure de stockage et de calcul environnante. Après avoir montré les fonctionnalités attendues d une telle architecture, trois aspects ont particulièrement été abordés et ont servi de démonstration à l approche : la collaboration, la sécurité et enfin l adaptation des données. L articulation des divers services proposés au sein d une même architecture a été enfin présentée dans une vision globale de l architecture, avec des pistes pour un déploiement et une implémentation réels de la proposition. L essor de la prochaine génération de Grilles de Calcul passe à notre avis par son adoption par le plus grand monde, de manière transparente, ubiquitaire et pervasive. Cette Grille Pervasive sera au service des utilisateurs finaux qui n en percevront pas la présence. Le web offre aujourd hui un moyen de communication qui permet un réel échange. On partage déjà à travers l infrastructure réseau existante des idées (des données, des résultats de calcul), mais aussi des méthodes (algorithmes, services), des moyens (calcul, stockage, réseau) et des cheminements de pensées (des combinaisons de services, des historiques sur les actions passées). Ce qu il manque encore est la facilité d agir de manière intuitive sur une architecture intégrée. L utilisateur final doit pouvoir échanger dans tous les contextes. Il ne doit pas être contraint dans une architecture donnée, où des serveurs connus fournissent des services 73

74 74 CHAPITRE 8. CONCLUSIONS DE CET ESSAI, PERSPECTIVES et données figés pour un contexte d utilisation particulier. L échange en sortira alors renforcé, dès lors que les utilisateurs n auront pas à consacrer du temps et de l énergie à la gestion de la communication. En ce qui concerne les perspectives à moyen et long terme, elles sont nombreuses, et touchent à la fois à des prolongations directes de travaux entamés dans l équipe jusqu à des perspectives plus globales. Dans chaque partie, nous avons essayé de donner des pistes de réflexion sur la mise en place des approches retenues dans le cadre de la Grille Pervasive. Nous en résumons ici quelques-unes, organisées sur trois axes : la pro-activité, la sémantique et la distribution. Tout d abord, le premier challenge concerne la prise en compte effective de la pro-activité, qui doit être au cœur de la Grille Pervasive. La pro-activité consiste à anticiper les besoins des utilisateurs pour offrir globalement une meilleure qualité de service. La connaissance du contexte de l utilisateur et de la Grille Pervasive en est un des points importants. Sur le contexte, deux aspects retiennent mon attention : le premier concerne l interopérabilité des contextes, ce qui rejoint l interopérabilité des sources de données vues dans le chapitre 4 car il est fort probable que plusieurs façons de décrire un contexte co-existeront dans cette grille très hétérogène. Le second concerne la sécurité du contexte utilisateur : des informations personnelles peuvent s y trouver et l utilisateur veut en garder l aspect privatif. Il convient donc d apporter des solutions transparentes à cette protection, par exemple en s assurant de la confiance que l on peut faire au service/site/utilisateur qui requiert les informations du contexte. Pour l accès aux données, prédire l avenir des requêtes utilisateurs améliore la gestion du cache et celle des réplicas, permettant de garder et de déplacer les bonnes données au bon endroit, anticipant les mouvements et requêtes des utilisateurs. Sur le contrôle d accès et Sygn, l utilisateur de certificats qui doivent s enchaîner pour permettre un accès doit construire lui-même cette chaîne de certificats : avoir un mécanisme de découverte automatique du bon enchaînement et une construction transparente pour l utilisateur de cette chaîne de certificats est nécessaire pour la pro-activité. Cette dernière passe également par une gestion sémantique des droits associés aux certificats. La gestion avancée de la sémantique est donc tout naturellement le deuxième axe qui me semble nécessaire à la Grille Pervasive. Elle permettrait de décrire les services, les données, les droits de manière plus précise et de plus haut niveau. Cette sémantique est déjà utilisée dans la gestion de cache et dans la négociation entre sources. Son utilisation doit s intensifier pour entrer dans l ensemble de la Grille Pervasive. Par exemple, pour l adaptation, la sémantique permet de décrire les services disponibles, ainsi que les données des serveurs de contenus. Pour le moment, ces descriptions sont ma-

75 nuelles et ad-hoc dans notre approche : une représentation standardisée et une extraction automatique de métadonnées décrivant la sémantique restent à faire. Ces travaux se rapprochent de ce qui se fait aujourd hui sur le Web Semantique. Concernant les services disponibles, il est nécessaire de prendre en charge les autorisations d accès (et donc d étendre le contrôle d accès aux services) mais également d assurer aux utilisateurs de la Grille pervasive la sûreté de fonctionnement des services qu ils utilisent : leurs données ne doivent pas être utilisées par ces services sans le savoir, elles ne doivent pas être altérées,... Se pose alors le problème de la confiance que l on met dans les services distants et dans la sémantique qui leur est associée. Dans notre approche, la gestion de la confiance pour l authentification nécessite d être connu par au moins un site auquel le site où l utilisateur souhaite se connecter croit, directement ou indirectement. L utilisateur acquiert des accès au fur et à mesure de ses déplacements, une confiance lui étant attribuée sur chaque site. Une extension de ces travaux vers une confiance qui se modifie dynamiquement par l historique des actions réalisées par l utilisateur et ses interactions avec d autres utilisateurs/services/sites permettra de s affranchir de la notion de site de rattachement principal, et donc de décentraliser complètement l algorithme de décision d accès. Concernant cette idée de décentralisation, plusieurs algorithmes et structures de données mériteraient d être plus complètement distribués. Par exemple, sur l algorithme Cryptstore, des travaux pourraient s engager sur l indexation des morceaux de clés distribuées, ainsi que sur leur placement dynamique. En l état actuel, l utilisateur connaît l emplacement des serveurs de clés qui possèdent des morceaux de clés pour pouvoir décrypter un document, cette information étant stockée avec le document. Cette connaissance a priori interdit le déplacement dynamique ou la réplication des clés entre serveurs, par exemple pour gérer la tolérance aux fautes. Toutefois, le plus grand challenge concerne à mon avis la mise en place effective de cette architecture, c est-à-dire la prise en charge de la conception avancée des idées ici énoncées, à un niveau de détail plus important, ainsi que leur intégration dans une seule architecture. Chaque point abordé (qu il ait servi de support d explication ou non) devra être tout d abord creusé individuellement dans une perspective de Grille Pervasive, en parallèle à une réflexion générale sur l architecture de Grille Pervasive, intégrant d autres aspects que la gestion de données. En effet, seule une démarche cohérente sur les calculs et les données pourra apporter des résultats tangibles. Parallèlement, une phase importante d ingénierie (une fois les problèmes de recherche levés) devra être mise en œuvre, à l image de ce qui se passe aujourd hui dans les Grilles de Calcul et des efforts d implémentation autour de l architecture OGSA. 75

76 76 CHAPITRE 8. CONCLUSIONS DE CET ESSAI, PERSPECTIVES

77 Bibliographie [1] Theodora Varvarigou Antonios Litke, Dimitrios Skoutas. Mobile grid computing : Changes and challenges of resource management in a mobile grid environment. In PAKM 2004, 5th International Conference on Practical Aspects of Knowledge Management, Vienna, Austria, December [2] OGSA : Open Grid Services Architecture. [3] Francoise Baude, Denis Caromel, Fabrice Huet, and Julien Vayssiere. Communicating mobile active objects in java. In Roy Williams Marian Bubak, Hamideh Afsarmanesh and Bob Hetrzberger, editors, Proceedings of HPCN Europe 2000, volume 1823 of LNCS, pages Springer, May [4] Girma Berhe, Lionel Brunie, and Jean-Marc Pierson. Content adaptation in distributed multimedia systems. Journal of Digital Information Management, special issue on Distributed Data Management, 3(2), June [5] A. Borodin and R. El-Yaniv. Online Computation and Competitive Analysis. Cambridge University Press, [6] Dario Bruneo, Marco Scarpa, Angelo Zaia, and Antonio Puliafito. Communication paradigms for mobile grid users. In CCGrid 03, page 669, [7] Yonny Cardenas, Lionel Brunie, and Jean-Marc Pierson. Uniform distributed cache service for grid computing. In Proceedings of DEXA 05, Copenhagen, Danemark, August [8] D. Chu and M. Humphrey. Bmobile ogsi.net : Grid computing on mobile devices. In Grid Computing Workshop (associated with Supercomputing 2004), Pittsburgh, USA, November [9] B. Clarke and M. Humphrey. Beyond the device as portal : Meeting the requirements of wireless and mobile devices in the legion grid computing system. In 2nd International Workshop on Parallel and Dis- 77

78 78 BIBLIOGRAPHIE tributed Computing Issues in Wireless Networks and Mobile Computing (associated with IPDPS 2002), Ft. Lauderdale, USA, April [10] Condor Team of the University of Wisconsin. Condor, high troughput computing. http ://www.cs.wisc.edu/condor/, [11] Nigel Davies, Adrian Friday, and Oliver Storz. Exploring the grid s potential for ubiquitous computing. IEEE Pervasive Computing, 3(2) :74 75, [12] A.K. Dey, G.D. Abowd, and D. Salber. A conceptual framework and a toolkit for supporting the rapid prototyping of context-aware applications. In Human-Computer Interaction, volume 16, pages , [13] H. Duque, J. Montagnat, J. Pierson, L. Brunie, and I.E. Magnin. Dm2 : A distributed medical data manager for grids. In Cluster Computing and the Grid, pages IEEE, [14] Hector Duque. Conception et mise en oeuvre d un environnement logiciel de manipulation et d accès à des données réparties. Application aux grilles d images médicales : Le système DSEM/DM2. PhD thesis, INSA de Lyon, July [15] EGEE. Enabling grid for e-science in europe. [16] Yamin et al. Towards merging context-aware, mobile and grid computing. International Journal of High Performance Computing Applications, 17(2) : , [17] I. Foster and C. Kesselman, editors. The Grid : Blueprint for a New Computing Infrastructure. Morgan Kaufmann Publishers, Inc., [18] I. Foster, C. Kesselman, J. Nick, and S. Tuecke. The physiology of the grid : An open grid services architecture for distributed systems integration, [19] Francisco J. Gonzalez-Castano, Javier Vales-Alonso, Miron Livny, Enrique Costa-Montenegro, and Luis Anido-Rifo. Condor grid computing from mobile handheld devices. SIGMOBILE Mob. Comput. Commun. Rev., 7(1) : , [20] Julien Gossa, Jean-Marc Pierson, and Lionel Brunie. (dé)placement de réplicas dans un environnement pervasif. In Conférence Francophone Ubiquité et Mobilité 2004 (UbiMob 04), Nice, France, June ACM Digital Library publications. [21] Piotr Graboswki, Bartosz Lewandowski, and Michael Russell. Access from j2me-enabled mobile devices to grid services. In Proceedings of Mobility Conference 2oo4, Singapore, 2004.

79 BIBLIOGRAPHIE 79 [22] Vipul Hingne, Anupam Joshi, Tim Finin, Hillol Kargupta, and Elias Houstis. Towards a pervasive grid. In International Parallel and Distributed Processing Symposium (IPDPS 03), page 207, [23] Steve Tueke Ian Foster, Carl Kesselman. The anatomy of the grid : Enabling scalable virtual organizations. In International Journal of Supercomputing Applications, [24] Sheng Jiang, Piers O Hanlon, and Peter Kirstein. Moving grid systems into the ipv6 era. In Lecture Notes in Computer Science (LNCS) 3033, editor, Proceeding of Grid and Cooperative Computing 2003, pages Springer-Verlag Heidelberg, [25] J. Kleinberg. The small-world phenomenon : An algorithmic perspective. In Proceedings of the 32nd ACM Symposium on Theory of Computing, [26] Stanislav Kurkovsky, Bhagyavati, Arris Ray, and Mei Yang. Modeling a grid-based problem solving environment for mobile devices. In ITCC (2), pages 135. IEEE Computer Society, [27] W. Lefer and JM. Pierson. Visualization components on the internet. In Visual2000, Mexico City, Mexico, September [28] W. Lefer and JM. Pierson. A software component platform for web computing. In Internet Computing 2001 (IC 01), pages , Las Vegas, USA, June [29] Laurent Lefevre, Jean-Marc Pierson, and Sid-Ali Guebli. Deployment of collaborative web caching with active networks. In International Workshop on Active Networks, IWAN 2003, pages 80 91, Kyoto, Japon, December Springer Verlag, LNCS [30] Legion Research Group of the University of Virginia. Legion, a worldwide virtual computer. http ://legion.virginia.edu/, [31] Lee McKnight, James Howison, and Scott Bradner. Wireless grids, distributed resource sharing by mobile, nomadic and fixed devices. IEEE Internet Computing, 8(4) :24 31, July [32] MEDIGRID. Medical data storage and processing on the GRID. http ://creatis-www.insa-lyon.fr/medigrid, [33] J. Montagnat, JM. Pierson, L. Seitz, H. Duque, L. Brunie, and al. Medical images simulation, storage and processing on the european datagrid testbed. Journal of Grid Computing, 2(4) : , [34] OSGi. Open system gateway infrastructure. [35] Sang-Min Park, Young-Bae Ko, and Jai-Hoon Kim. Disconnected operation service in mobile grid computing. In First International Conference

80 80 BIBLIOGRAPHIE on Service Oriented Computing(ICSOC 2003), Trento, Italy, December [36] Thomas Phan, Lloyd Huang, and Chris Dulan. Challenge : : integrating mobile wireless devices into the computational grid. In MobiCom 02 : Proceedings of the 8th annual international conference on Mobile computing and networking, pages , New York, NY, USA, ACM Press. [37] Jean-Marc Pierson, Lionel Brunie, and David Coquil. Semantic collaborative web caching. In Web Information Systems Engineering 2002 (ACM/IEEE WISE 2002), pages 30,39, Singapore, dec IEEE CS Press. [38] JM. Pierson, L. Brunie, M. Miquel, A. Tchounikine, C. Dhaenens, N. Melab, EG Talbi, A. Hameurlain, and F. Morvan. Grid for genomedicine : A glimpse on the project. In BioGrid 05 (en conjonction avec ACM/IEEE CCGRID 05), Cardiff, UK, May IEEE CS Press. [39] ProActive. INRIA, http ://www-sop.inria.fr/oasis/proactive. [40] Akogrimo Project. [41] GridLab Project. [42] The K*Grid project. gridcenter.or.kr/mobilegrid. [43] Le projet ACI Darts. darts.insa-lyon.fr. [44] RagTime. Rhone-alpes grille pour le traitement de l information medicale. [45] Rachid Saadi, Jean-Marc Pierson, and Lionel Brunie. Apc : Access pass certificate, distrust certification model for large access in pervasive environement. In Proceedings of International Conference on Pervasive Services IPCS 05, Santorini, Greece, July [46] Neal Sample, Pedram Keyani, and Gio Wiederhold. Scheduling under uncertainty : Planning for the ubiquitous grid. In COORDINATION 02 : Proceedings of the 5th International Conference on Coordination Models and Languages, pages , London, UK, Springer- Verlag. [47] Vasile-Marian Scuturici, Jean-Marc Pierson, and Lionel Brunie. Perse : Pervasive services environment, research report, [48] L. Seitz, J. Montagnat, JM. Pierson, D. Oriol, and D. Lingrand. Authentication and authorisation prototype on the mgrid for medical data management. In Third International Conference on Healthgrids (Healthgrid 2005), pages , Oxford, UK, April IOS Press, ISBN I X.

81 BIBLIOGRAPHIE 81 [49] L. Seitz, J. Pierson, and L. Brunie. Semantic access control for medical applications in grid environments. In Euro-Par 2003, LNCS2790, pages , Klagenfurt, Autriche, August Springer Verlag. [50] Ludwig Seitz. Conception et mise en oeuvre de mécanismes sécurisés de partage de données confidentielles : application à la gestion de données biomédicales dans les grilles de calcul. PhD thesis, INSA de Lyon, July [51] Ludwig Seitz, Jean-Marc Pierson, and Lionel Brunie. Encrypted storage of medical data on a grid. Journal Methods of Information in Medicine, 44(2) : , [52] Ludwig Seitz, Jean-Marc Pierson, and Lionel Brunie. Sygn : A certificate based access control in grid environments. Technical Report , LIRIS, July [53] A. Shamir. How to share a secret. In Communications of the ACM, volume 22, pages , [54] S.H. Srinavisan. Pervasive wireless grid architecture. In Second Annual Conference on Wireless On-demand Network Systems and Services (WONS 05), [55] Oliver Storz, Adrian Friday, and Nigel Davies. Towards ubiquitous ubiquitous computing : an alliance with the grid. In First Workshop on System Support for Ubiquitous Computing Workshop (Ubisys 2003) in association with Fifth International Conference on Ubiquitous Computing, Seattle, Washington, U.S., October [56] Mark Weiser. The computer for the 21st century. Scientific American, 265(3) :66 75, February [57] G. Zhang and M. Parashar. Dynamic context-aware access control for grid applications. In 4th International Workshop on Grid Computing (Grid 2003), pages , Phoenix, AZ, USA, IEEE Computer Society Press.

82 82 BIBLIOGRAPHIE

83 Annexe A Sélection d articles de recherche Les articles présentés dans cette annexe apportent des éclairages complémentaires aux descriptions succinctes des travaux exposés dans le document. Ils sont proposés dans l ordre d évocation dans le document. Les articles sont : H. Duque, J. Montagnat, JM. Pierson, L. Brunie et I.E. Magnin. DM 2 : A Distributed Medical Data Manager for Grids. BioGrid 03 - First International Workshop on Biomedical Computations on the Grid (atelier de IEEE CCGrid03), Tokyo, Japon, mai 2003, pp L. Brunie, D. Coquil et JM. Pierson. Semantic collaborative web caching, Web Information Systems Engineering 2002 (ACM/IEEE WISE 2002), Singapore, décembre 2002, IEEE CS Press, pp Y. Cardenas, JM. Pierson and L. Brunie. Uniform Distributed Cache Service for Grid Computing, Globe 05, DEXA, Copenaghe, Danemark, août R. Saadi, JM. Pierson, L. Brunie. APC : Access Pass Certificate, Distrust Certification Model for Large Access in Pervasive Environement, ICPS 05, IEEE International Conference on Pervasive Services 2005, Santorini, Greece, juillet L. Seitz, JM. Pierson et L. Brunie. Sygn : A certificate based access control in Grid environments. Rapport de recherche. LIRIS (en cours de soumission à la revue ACM Transactions on Information and System Security) L. Seitz, JM. Pierson et L. Brunie. Encrypted Storage of Medical Data on a Grid. Journal Methods of Information in Medicine, volume 44 (2), 2005, pages , Schattauer 83

84 84 ANNEXE A. SÉLECTION D ARTICLES DE RECHERCHE G. Berhe, L. Brunie et JM. Pierson. Content adaptation in distributed multimedia systems. Journal of Digital Information Management, special issue on Distributed Data Management. volume 3 (2). Juin 2005.

85 DM 2 : A Distributed Medical Data Manager for Grids H. Duque ab, J. Montagnat a, J.-M. Pierson b, L. Brunie b, and I.E. Magnin a a CREATIS, CNRS UMR 5515, b LISI, INSA de Lyon EA 629, INSA, Bât. B. Pascal, 7 av. J. Capelle, Villeurbanne Cedex, France Abstract Medical data represent tremendous amount of data for which automatic analysis is increasingly needed. Grids are very promising to face today challenging health issues such as epidemiological studies through large image data sets. However, the sensitive nature of medical data makes it difficult to widely distribute medical applications over computational grids. In this paper, we review fundamental medical data manipulation requirements and then propose a distributed data management architecture that addresses the medical data security and high performance constraints. A prototype is currently being developed inside our laboratories to demonstrate the architecture capability to face realistic distributed medical data manipulation situations. 1 Medical applications on computational grids Recently, computational grids [7, 8] achieved a large success among the distributed computing community. Many technical developments aim at providing a middleware layer allowing to submit remote jobs [2, 5, 9], store data [4], and get information on a distributed system [15]. But most importantly, from the user point of view, grids should allow transparent access to distributed resources and enable easy data and algorithms sharing. Medical data analysis is a domain where grid technologies are very promising. Health centers are using an increasing number of digital 3D sensors for medical data acquisition [1], representing tremendous amount of data for which automatic analysis is needed. Grid technologies offer: (i) an increased computing power This work is partly supported by the IST European DataGrid project (http://www.edg.org/), the French ministry for research ACI-GRID project (http://www-sop.inria.fr/aci/grid/public/) and ECOS- Nord Committee (action C03S02). for complex modeling and simulation algorithms, (ii) a distributed platform with shared resources for different medical partners with similar data processing needs, (iii) a common architecture to access heterogeneous data and algorithms for processing, and (iv) the ability to process very large amounts of data ( e.g. for epidemiological studies). However, to remain transparent from the user point of view, a middleware layer should take into account the particular needs of medical applications. Although weakly structured, medical data have a strong semantic and metadata are very important to describe data content (such as images). Furthermore, medical data are sensitive and should only be accessible by accredited users, which makes data manipulation over a wide area network difficult. In this paper, we address the medical data management related issues for grid computing. We first detail in section 2 medical data requirements. In section 3, we propose a novel data management architecture that is currently being investigated in our laboratories. 2 Medical data and security issues 2.1 Medical data Although there is no universal standard for storing medical images, the most established industrial standard is DICOM (Digital Image and COmmunication in Medicine) [6]. DICOM describes both an image format and a client/server protocol to store and retrieve images on/from a medical image server. Most recent medical imagers implement the DICOM protocol. They play the role of acquisition device and image server communicating with their clients over a TCP/IP hospital network. The DICOM file format is made of a header containing metadata followed by one or several image slice(s) in a single file. The metadata contains two kinds of information:

86 sensitive patient-related metadata such as the patient name, sex, age, the radiologist name, the hospital, etc. image-related metadata such as the image acquisition device, constructor, and parameters, the acquisition date, the number of images stored, the size of images, the field of view, etc. To the patient information can be added all clinical metadata that are not originally part of the image acquisition such as notes by medical experts. Although patient metadata is the most sensitive part of the data, no medical data, including the image content, should ever be accessible to unauthorized users. Today, medical data are often stored and archived inside each medical image producer (hospitals, clinics, radiology centers...). The medical record (image files and metadata) of one patient is distributed over the different medical centers that have been involved in his healthcare. Medical data are usually disconnected from the outside world to solve security issues. Several Picture Archiving and Communication Systems (PACS) [10] have been developed to provide data management, visualization, and, to some extent, processing. However, they are restricted to data management inside each hospital and hardly address the problems arising when considering a global system with communication of sensitive data between sites. 2.2 Requirements for medical data on the Grid Data management and replication mechanisms [14] proposed by grid middlewares mainly deal with flat files. Data access control is handled at a file level. In the DataGrid project for instance, user authentication relies on the asymmetric key-based Globus Grid Security Infrastructure layer (GSI) [3]. This infrastructure does not take into consideration metadata and does not address patient record distribution. Therefore, we investigate the creation of a Distributed Medical Data Manager unit (abbreviated as DM 2 later in this document) that interfaces with the grid middleware. It should provide: Reliable and scalable storage for images and metadata produced by medical imagers. This includes connection to the grid file replication mechanism and a metadata location service granting access to distributed medical records (see section for details). To face scalability and reliability issues in a wide area environment, replication of metadata also appears necessary. Data and associated metadata should be synchronized by the information system as they are semantically connected (they should have the same lifetime, same access patterns...). Through a proper query service, metadata should describe a dataset and allow it to be processed. This implies a proper interface between the grid job submission service and the data/metadata manager. Encryption is needed to restrict access to authorized users. A fine user identification mechanism should control access rights to the data. Finally, medical data traceability is an important feature: a medical doctor is often interested in knowing from where a computed data originates, and conversely, it may be useful for optimization reasons to remember which computations have already been carried out a given data set and what results were produced. Processing or querying data over a grid raise problems of confidentiality and confidence that the user may have in the grid security infrastructure. Ideally, medical data should not be accessible by any unaccredited user, including system administrators of sites where the data are transported for computation. To ensure a reasonable confidentiality level, we plan to decouple the sensitive metadata from the image data. The metadata will only be stored on a limited number of trusted sites, where administrators are accredited, and can only be sent to accredited user stations. The image data can be stored, replicated, and manipulated on standard grid nodes given that it is encrypted to make its content retrieval difficult. 3 Managing distributed medical data 3.1 A sample usecase To illustrate our proposal for a DM 2, we will consider the following usecase. A cardiologist looks for heart images similar to a case of one of his patients to confirm his diagnosis. He want to rank existing images through a similarity score resulting of a computation involving his patient image and an image database. Once the images are ranked, he need to visualize the most similar cases and their attached diagnoses. The diagnosis he makes for his patient can be recorded in the information system for improving the existing database. In technical terms, the cardiologist needs to: Access a large data set made of comparable heart images that are distributed over different hospitals. 2

87 Make computations (similarity measurements) on a large number of images in a very limited time. The grid can help on both aspects by providing a very large distributed image database and the computing power needed. However, this implies that there is a full and secured interface between the grid computation services, the medical data servers, the associated metadata, and the user interface. 3.2 Key issues in designing the DM 2 A distributed system is made of several interconnected computers and a shared state describing the cooperation of these computers [11]. To respond the requirements described in section 2.2 the DM 2 is designed as a complex system involving multiple grid service interfaces and several interacting processes geographically distributed over an heterogeneous environment. It is a gate to the grid as well as an intermediary (proxy) between the grid and a set of trusted medical sites. Its complexity has motivated us to first propose an architecture describing the DM 2 components and second to implement our system as one possible instance of this architecture. To tackle the DM 2 complexity, we propose the multi-layers architecture outlined in section We also need to interface the DM 2 with underlying grid services as detailed in section DM 2 layered architecture The DM 2 needs to interconnect with existing services on the internals of which we have no control. We will refer to engines to designate the DM 2 services that we develop to avoid confusions. Each engine is composed of a set of independent processes which interact by exchanging messages. We design each Distributed System Engine (DSE) through a layered architecture that takes into account the requirements for high performance and data integrity. The architecture increases in semantic significance through five layers (see figure 1). At the lowest level, DSE 0, the system is made of processes that can communicate through a message passing kernel. The DSE 1 level brings atomic operations (transactions) to process complex requests composed of many messages. The upper layer DSE 2 deals with distribution over several engines. On top of the distribution layer come the application (DSE 3 ) and user interface (DSE 4 ). DSE4: user DSE3: application DSE2: distribution DSE1: transaction DSE0: message passing Figure 1. DSE layers Semantic Level Interfacing medical data servers with the grid middleware The European DataGrid (EDG) middleware proposes a standard storage interface to the underlying mass storage systems. Through this interface, the middleware may access files on distributed and heterogeneous storage pools. Grid-enabled files are handled by a Replica Manager (RM): to ensure fault tolerance and provide a high data accessibility service, files are registered into the RM and may be replicated by the middleware in several identical instances. The first file registered into the RM is a master file. Other instances are replicas. When a file is needed, the grid middleware will automatically choose which replica should be used for optimizing performances. Having multiple instances of a file also increase its availability since connection errors are likely to happen in a wide scale distributed system. To solve coherency problems, replicas are accessible in read only mode and modifying a master file invalidates all its replicas. To ease files manipulation, grid wide Logical File Names (LFN) are used to identify each logical data (i.e. a master and all its replicas). In the hospital, each image can be made up of one or several DICOM files representing portions of the imaged body. The DM 2 plays a double role to interface DICOM servers with the grid middleware as illustrated in figure 2: It makes an interface between the grid RM and the DICOM servers. It provides a standard storage interface allowing to exchange files with other grid services. For each new DICOM image or set of DICOM images (depending on the semantic of the DICOM series) produced by an imager, a LFN is created and registered into the RM. The DICOM files thus becomes, from the grid side, a master file. There is not necessarily a physical file instance behind this LFN but rather a virtual file made up of a set of DICOM files, that can be reconstructed on the fly by the DM 2 if a request for this LFN comes in. For efficiency reasons, assembled files are cached on a scratch space before being sent outside. The DM 2 also stores metadata and establishes a 3

88 link between an LFN and its patient- or image-related metadata. The DM 2 storage interface ensures data security by anonymizing and encrypting on the fly images that are sent to the grid. Replicas of a medical image may exist on any grid storage node, given that encryption forbid data access without encryption keys. These keys are stored with the patient-related metadata on trusted sites only. In order to ensure data integrity, the grid storage interface does not allow the master files stored on the DICOM server to be deleted. Hospital DICOM Server Imagers Encryption Header blanking 2 DM Scratch Space storage interface Metadata manager LFN param 1... par n... Grid Middleware Replica Manager Job Submission Service... storage interface Figure 2. DM 2 interface between the medical imagers and the grid 3.3 DM 2 layers Grid mass storage system As mentioned earlier, we decomposed the DM 2 architecture in 5 layers to tackle its complexity. This section further describes each layer s role DSE 0 : message passing The core of the DSE 0 is a message passing kernel in charge of the efficient transmission of messages between the DM 2 processes. Our kernel implementation is based on Inter-Process Communication (IPC) services. The DSE 0 transmits messages between the IPC kernel and the external network for access to both local and remote services DSE 1 : transactions On top of the simple message transportation layer, DSE 1 implements atomic operations (transactions) made of multiple sub-operations. A transaction succeeds if and only if all sub-operations succeed. If a failure occurs the system is left in a coherent state. It offers the ACID properties: Atomicity, Consistency, Isolation and Durability [11]. A transaction involves multiple requests to external services and internal engines. To deal efficiently with complex transactions, we introduce the notion of tasks. Tasks are sets of sequential requests and transactions are sets of sequential and/or concurrent tasks (to shorten the processing time). We implemented transactions, tasks, and requests through four kinds of specialized processes that we will refer to as drivers: The TRransactions Drivers (TRD) are processes which can manage a whole transaction made up of a set of sequential or parallel tasks. A transaction could imply having access to different external services (tasks). The TasKs Drivers (TKD) are processes in charge of doing a specialized part of a transaction, which could imply getting sequential access to an external service or to a set of request drivers. The ReQuest Drivers (RQD) are in charge of accessing the remote components such as other engines and external servers. They solve low level issues such as connection management. These drivers transmit messages and receive responses that they route to the calling processes. The TOol Drivers (TOD) are processes which perform internal operations for debugging support or improving the efficiency. Examples of such processes are the caching of requests and results, logging, security checking, and tracing operations. A DM 2 engine works as follows: (i) A message arrives at a transaction driver and a transaction is initiated. (ii) The transaction starts different concurrent tasks, using independent processes (TKD). (iii) Each task get access to the requests drivers (RQD) so that it can reach the external services. (iv) The request drivers (RQD) opens connections and send messages to the external services. (v) Each driver uses the tools it needs (TOD). See section for a concrete example Upper layers DSE 2 brings additional distributed facilities on top of the two lowest levels. It is in charge of localizing data and services, transmitting request to proper hosts, etc. It may take advantage of completely decentralized Peer-to-Peer (P2P) techniques or to semi-hierarchical tree structures such as LDAP for distributed data localization. DSE 3 is the application layer, offering a programming interface (API) so that an application can be built on top of the underlying distributed system. 4

89 DSE 4 is the user layer. It offers high level access to data, metadata and algorithms registered in the system. It can be implemented as web portals or graphical applications. For instance, a user might have access to similarity algorithms published by the DM 2 architecture (through this portal) that he wants to apply to a subset of images (according to its access rights) Extensibility and Interfaces The architecture allows external applications to interact with the distributed system, and to execute locally on the same node or remotely. The system can access other servers offering additional services (e.g. grid services) or be accessed by clients trying to take advantage of the DM 2 services. In this way additional functions such as cache, security, file transfer and encryption, database access, etc, can be easily interfaced, and designed as independent modules for easing software development. 3.4 Using the DM 2 in real applications A prototype is currently under development to demonstrate the relevance of the proposed architecture in realistic medical applications. At the moment, we have implemented the interface to a DICOM server (Central Test Node), metadata handling through SQL tables with a secured access interface, but we do not have a fully secured and distributed system yet. Our prototype is therefore an assembly of DSE 0 and DSE 1 processes (message passing and basic transactions) following the above architecture DM 2 software components Let us consider the usecase described in section 3.1. In order to set up this application we implemented: A set of request drivers for issuing requests to and getting results from the grid services. The DICOM RQD accesses the DICOM server where medical images are stored and the metadata RQD is a driver for the database service where image metadata are stored. Each one of these services has an associated multiprocess task driver which is able to execute concurrent demands. The DICOM TKD can make parallel transfer of DICOM files for instance. In addition, a communication daemon TRD has been implemented in order to receive messages from the network side and to start the execution of transactions Detailed usecase First, the cardiologist enters a query (e.g. find the MRI of Mr X acquired yesterday in this hospital) through the DM 2 user interface. The DM 2 sends a query for retrieving metadata to the grid metadata interface through the metadata RQD and TKD. The user authorizations to access the data are checked by the external metadata service and the patient file logical identifier and its associated parameters (imaging modality, region of interest, dynamic sequence, MR acquisition parameters, etc) are returned to the user interface. A request is made to find all images comparable to the image of interest (same body region, same acquisition modality...) and for which a medical diagnosis is known. The DM 2 layer 2 should be used to distribute the request on all hospitals with metadata services. In the current implementation, the single metadata service is queried through the metadata RQD and TKD again. The logical identifier of all images matching the patient source file parameters are returned. A request is then made for computation of a similarity measure [12, 13] between the patient image and each image resulting from the previous query. The job submission service of the grid middleware is used to distribute computations over available working nodes. For each job started, the grid replica manager triggers a replication of the input files to process onto grid computation nodes. When requesting files to the DM 2 storage interface, the DM 2 queries the DICOM server, assembles MR images on the fly onto its scratch space and returns images to grid nodes. Figure 3 details this operation: on top, the grid middleware triggers a DM 2 transaction for getting an image. (1) It first makes security checks. (2) It then accesses the database (metadata TKD) to locate the DICOM files. (3) A cache TOD (when available), can be used to improve the latency transfer. (4) Assuming the cache does not contain the requested file, it should be copied from the DICOM server. The DM 2 queries the DICOM server through the DICOM RQD and retrieves in parallel a set of DICOM slices that are assembled onto scratch space to produce the 3D image requested. (5) Finally, the image is stored into the cache and returned to the grid calling service. 4 Conclusions Medical image processing over the grid opens new opportunities for applications involving large medical datasets. However, full deployment of medical applications require medical sites to be interconnected and grid middlewares to provide secure and efficient access 5

90 Security TOD Cache TOD ipc 1 tcp/ip DICOM RQD GRID RQD Metadata RQD DICOM GRID 3 DM2 TRD 2 GRID 4 5 tcp/ip Metadata ipc DICOM TKD GRID TKD Metadata TKD Figure 3. DSE 1 usage example: retrieving a medical image from the DICOM server. to the distributed and sensitive medical data. The semantic content of medical data should also be taken into account by developing grid-wide tools to manage associated metadata. The architecture proposed in this paper allows us to build a complex distributed system, taking advantage of classical theory (transactions concept) and proposing solutions to implement a high performance data manager (decomposition of transactions in concurrent tasks and requests). The DM 2 system allows the physicians to get secure access to their patients images and to send hybrid requests over huge databases. We implemented a first prototype to demonstrate the relevance of the DM 2 for realistic medical applications. On-going work concerns data security and distribution. Many other aspects related to medical data management could not be addressed in this short paper including the need for tracking data origin and logging data processing, optimization procedures such as data and request caching. References [1] R. Acharya, R. Wasserman, J. Sevens, and C. Hinojosa. Biomedical Imaging Modalities: a Tutorial. Computerized Medical Imaging and Graphics, 19(1):3 25, [2] F. Berman, R. Wolski, S. Figueira, J. Schopf, and G. Shao. Application-level Scheduling on Distributed Heterogeneous Networks. In Supercomputing, Pittsburgh, PA, USA, November [3] R. Butler, D. Engert, I. Foster, C. Kesselman, S. Tuecke, J. Volmer, and Welch V. A National- Scale Authentication Infrastructure. IEEE Computer, 33(12):60 66, [4] A. Chervenak, I. Foster, C. Kesselman, C. Salisbury, and S. Tuecke. The data grid: Towards an architecture for the distributed management and analysis of large scientific datasets. Journal of Network and Computer Applications, 23(3): , July [5] Karl Czajkowski, Ian Foster, Nick Karonis, Carl Kesselman, Stuart Martin, Warren Smith, and Steven Tuecke. A resource management architecture for metacomputing systems. Lecture Notes in Computer Science, 1459:62, [6] DICOM: Digital Imaging and COmmunications in Medicine. [7] I. Foster, C. Kesselman, and S. Tuecke. The Anatomy of the Grid: Enabling Scalable Virtual Organizations. International Journal of Supercomputer Applications, 15(3), [8] Ian Foster and Carl Kesselman. The Grid: Blueprint for a New Computing Infrastructure. Morgan Kaufmann, July [9] Francesco Giacomini, Francesco Prelz, Massimo Sgaravatto, Igor Terekhov, Gabriele Garzoglio, and Todd Tannenbaum. Planning on the grid: A status report. ppdg-20, particle physics data grid collaboration., October [10] H. K. Huang. PACS: Picture Archiving and Communication Systems in Biomedical Imaging. Hardcover, [11] Sape Mullander, editor. Distributed Systems. Addison Wesley, [12] G.P. Penney, J. Weese, J.A. Little, P. Desmedt, D.LG. Hill, and D.J. Hawkes. A Comparison of Similarity Measures for Use in 2D-3D Medical Image Registration. In Medical Image Computing and Computer- Assisted Intervention (MICCAI 98), volume 1496 of LNCS, pages , Cambridge, USA, October Springer. [13] A. Roche, G. Malandain, X. Pennec, and N. Ayache. The Correlation Ratio as a New Similarity Measure for Multimodal Image Registration. In Medical Image Computing and Computer-Assisted Intervention (MICCAI 98), volume 1496 of LNCS, pages , Cambridge, USA, October Springer. [14] H. Stockinger, A. Samar, B. Allcock, I. Foster, K. Holtman, and B. Tierney. File and object replication in data grids. In 10th IEEE Symposium on High Performance and Distributed Computing (HPDC2001), August [15] B. Tierney, R. Aydt, D. Gunter, W. Smith, V. Taylor, R. Wolsky, and M. Swany. A grid monitoring architecture. tech. rep. gwd-perf-16-2, global grid forum, January

91 Semantic collaborative web caching Lionel Brunie, Jean-Marc Pierson and David Coquil LISI, INSA de Lyon 20 avenue A. Einstein, Villeurbanne cedex, FRANCE Abstract Too much information is no information. When the quantity of data becomes too large, users need help and tools to find their path in the information space. Nowadays, any user can browse through Terabytes of data and more. The difficulty is to find the best way among all possible documents. Our feeling is that a user is not generic and has always some particular interests. Thus, the percentage of relevant documents is small, the time to access these documents must be reduced at most. We propose in this paper a collaborative proxy architecture, close to the user, based on hot relevance topics, and the dynamic construction of virtual communities. In this framework, the temperature of a document or a subject reflects its current interest among a community. We propose an architecture that allows proxies not only to manage efficiently cached documents but also to exchange documents with other proxies. Furthermore, these proxies manage meta-data about their partial views of the information space. We show how such an approach fits to enhance the global efficiency of the Web both in terms of access time to relevant documents and in terms of Web content indexing, adding semantic value where raw byte arrays are often considered. Keywords: Semantic web cache, distributed information systems, proxies. 1 Introduction Information systems have to face now a big challenge: interconnection challenge. Indeed, new network facilities (high performance LAN, Intranet, Internet) allow proposing new services based on the integration of distributed information systems into a single virtual entity. However information system interconnection poses several issues. The first evident issue is the necessity to use or develop a common representation of the target application. In this framework lie the works concerning ontologies[1], federations, agents or mobile agents [2], wrappers, brokers, etc. Another important issue is the performance of the global interconnected system. Indeed interconnecting information systems increases the data servers load, the network load, and may also cause severe query answer delays. This issue is becoming more and more crucial since, on one hand, when more users are connected to the network, the transactional load becomes more important ; and on the other hand, queries concern now heavy documents integrating images, scripts, videos. Finally, and this is the main key issue : too much information is no information. When the quantity of data becomes too important, users need help and tools to find their way in the information space. In this paper we propose to use collaborative proxy architectures to address these issues. Proxies are commonly used to improve the efficiency of data servers and to reduce the latency (i.e., the delay faced by the user before he gets the document) by using local copies of the most requested documents (which allows one to avoid sending requests to the servers repeatedly). However, most of the current technologies base the collaboration between proxies on operational information (like the last access date or the number of accesses over a certain period) and do not consider semantic information (i.e. related to the content of the documents) nor contextual information (related to the users and their queries). Oppositely, we believe that semantic and contextual proxy collaboration strategies should provide a better efficiency and offer users pertinent tools for searching documents. Thus we discuss below how correlating operational information with semantic and contextual information allows both optimizing proxy management heuristics (e.g. document replacement, document prefetching, document exchanges) and providing users with adaptive and personalized search indexes. The remaining of this paper is organized into six 1

92 sections. Section 2 presents an overview of proxy technologies. Section 3 describes a novel model of collaborating proxies based on the monitoring of semantic and contextual information while section 4 details the modules of our architecture. Section 5 discusses how this proxy architecture can be used to provide users with pertinent information on the information space and the user activity and introduces the notion of virtual community. Section 6 exhibits some quantitative and qualitative results of the use of our platform. Finally section 7 concludes this paper. 2 Proxy technologies: an overview Caching techniques, on which proxies are based, have been used in many domains of computer science for several decades. Basically, caches copy data delivered by a server in order to answer to data requests later in place of the server. The main expectations are the reduction of the data server load and the improvement of the latency time. These caching techniques are used in computer hardware, operating systems, distributed applications, visualization, etc. Proxies implement caching techniques in the framework of distributed applications. Located between servers and users, proxies act as data or document caches. Thus, a proxy covers a set of users (e.g. University campus, company site, clients of an ISP (Internet Service Provider), etc.). Requests issued by users are actually sent to the proxy instead of being sent to servers. If the proxy owns a copy of the requested data or document, it immediately delivers it to the user. If not, the proxy forwards the request to the target server, copies the response document for future uses, and delivers it to the user. Thus, proxies can both reduce the servers load, reduce the network load, and improve the latency time, on condition that consistency problems between copies and original documents are well managed and that the so-called hit rate (i.e., the number of requests that concern documents yet held by proxies) is reasonable. One of the key issue in the design and management of a proxy is the cache replacement policy. Indeed, the size of the cache is not unlimited. So proxy caches cannot hold all the available documents 1. As a consequence, it is mandatory, when the cache is full, to suppress some document(s) to get enough disk space to store the new ones. Numerous proxy implementations have been proposed [3]. Thus, as one proxy can serve a limited 1 In the remaining of this paper we will use the word document (and will not refer to data ) as in emerging applications data are usually integrated within multimedia documents. number of users (for evident bottleneck reasons), collaboration protocols between proxies have earlier been proposed [4](e.g. hierarchical caches like Harvest [5] or Squid [6], or distributed caches including prefetching, hash-based caches [7] and directory-based systems [8]). Proxies can be configured as a hierarchical tree: bottom (i.e. navigator cache), institution, national level and even international level. In such an architecture, if a proxy cannot answer a request, it recursively forwards it to the proxy of the higher level. Finally, when the document is found, either at a proxy level or at the document server level, it goes down the hierarchy, leaving a copy in each of the proxies along its path [4]. Proxies can oppositely be flatly distributed, with institution proxies only (and of course navigator caches). In this framework, each proxy maintains metadata about the documents stored in the other proxies. Thus, when a document is requested, a proxy does not need to forward the request to all other proxies: instead, it queries the metadata to check if a copy of the document is available in the cache of another proxy. This allows reducing the network traffic and optimizing the latency time. An intermediate solution between hierarchical and flat architectures consists in implementing, apart from classical proxies, metadata collectors, to gather information about the document availability in the proxies [4] ; Finally, the location of the proxies over the network is of key importance. Basically, proxies can be either located close to the servers (in which case, they mainly act as server mirrors) or close to end-users in order to reduce the latency time as much as possible ([2, 4]). In this paper, we propose new directions for improving the service delivered by proxies. Basically, we propose to monitor the semantic content of the caches and to use contextual (i.e. user centered) information to: improve the cache management policies, develop new collaboration schemes between proxies, including user proxies located on the users computers, and provide users with adaptive and enhanced search indexes. 3 Towards a new concept of proxy In an interconnected information system (the Web can be seen as such a system), proxies do not store rough bytes: they store documents. These documents hold information which can be synthesized by descriptors or metadata. These latter can be either attached 2

93 to the document or extracted from the document content. For instance, keywords, language and authors can be attached to an html page. Similarly, information systems are not queried by isolated or autistic users but by users sharing some special interest or some experience or some common objective or behavior with other users. In that sense and from the information system perspective, similar users de facto constitute what we will call below a virtual community. For example, all the clients of an ISP that are interested for football constitute a virtual community. Finally, users of the Web do not live in a rigid world. The queries they issue are strongly connected to the actual state of their domain of activity or to the fashion or to current events. Conversely, this means for instance that documents can be hot (i.e. often requested) one day and never more used later. All these information (descriptors, user profiles, virtual communities, fashionable data) constitute what we called above semantic and contextual information. We argue in this paper that: this semantic and contextual information can be of great value to optimize proxy management policies and proxy communication protocols, and monitoring this semantic and contextual information can be of great value for users to optimize their use of the information system by giving them a more adapted and pertinent view of the document space (i.e. the available data). Next sections discuss these two points. Proxy architecture for semantic and contextual collaboration Our global architecture is actually based on three levels, two being mandatory (see figure 1): User Proxy (UP): at the bottom level, one finds proxies located on user computers, where documents are normally cached. Oppositely with classical navigator caches which can be seen as a file warehouse, we implement here a true collaborative proxy mainly to be able to catch the user profile and behavior as well as context information. An added value of this is its non proprietary characteristic. User proxies collaborate on a peer to peer way to exchange documents and attached semantic and context information : each user proxy also collaborates with one Aggregate Proxy to inform it about the content of its cache; AGGREGATE PROXIES DISK CACHE META PROXY USER PROXIES OPTIONAL DISK CACHE Figure 1. Proxy architecture COLLABORATION OPTIONAL COLLABORATION Aggregate Proxy (AP): this kind of proxy aggregates semantic and contextual information from User Proxies connected to it and maintains the directory of all the documents cached at User Proxy level (i.e. it acts as a directory of a partial virtual space). An Aggregate Proxy can collaborate with other Aggregate Proxies (if they exist), in order to enrich its knowledge of the entire cached document space. Optionally, if this Aggregate Proxy is deployed on an architecture offering disk space, it can cache documents in a hierarchical-like approach ; Meta Proxy (MP): this optional level allows a concentrated view of several Aggregate Proxies. No data is actually cached here, but only an aggregate of semantic and contextual information and a directory of the actually cached documents at lower level (i.e. it acts as a directory of the entire virtual space). 3

94 4 Modules of the architecture 4.1 Indexing document The information attached to a document is commonly related to one or more theme(s) of interest : politics, sport, economy, etc. The task of identifying these themes is called indexing. By recursively dividing themes into sub-themes, one can build an indexing hierarchy for the whole document collection. At a given time, some themes are more popular than others (i.e. their documents are more frequently requested than others). These themes are called hot themes. For example, in Europe, in late May 2002 a hot sport theme is clearly the football (soccer) world championship. Politics Root 5% 5% Sports 15% 15% Recreation and Sports Games We associate a weight to these edges. This weight is the probability of a request for a document located under the child node to be next requested after 2 a document under the parent node in the hierarchy was requested. In other words, this weight represents the correlation (in terms of access patterns) between the target node and its brothers : the more brother nodes are semantically related, the heavier the weight attached to arrows issued from the parent node to these nodes is. So, children of the root node (representing large themes like politics, sports, education, tourism... ) are weakly co-related so weights issued from the root node are small. Oppositely, brother nodes close to the leaves represent concepts which are closely related, like Zidane and the French soccer team, so the probability that after a document related to the French soccer team has been accessed, a document related to Zidane will be soon accessed, i.e. the weight attached to the edge soccer-zidane, is high. Edges from a concept to a document represent an indexing relation between the concept and the document. We also associate a weight to these edges. This weight represents the percentage of requests for this document among those indexed by this concept. Note that if a document is related to two concepts, then we duplicate the node representing this document and link the two created nodes to the two related concepts. This is done in order to avoid border effects Temperature Baseball 40% 40% Soccer 70% 50% web documents 60% 20% Skiing Figure 2. Graphical representation of the theme structure We propose to use a data structure for representing semantic links between documents and indexing concepts. This data structure is a single-rooted n-ary tree. Internal vertices of this tree represent concepts, and leaves representdocuments (see figure 2). Internal vertices are connected by edges which represent a generalization / specialization relation between the parent and the child nodes Definition The temperature is a numerical value specific to each document. It represents the probability for the given document to be requested in the near future. More precisely, it is the synthesis between the number of requests for this document in the last time interval and the semantic links represented by the data structure. A temperature value is also associated to internal nodes of the data structure. It is mostly used for intermediate computation purposes Temperature computation The algorithm for temperature computation is outlined in table 1. Temperature computation occurs at regular requests intervals, every freq requests. The number of accesses 2 I.e. in a defined time interval after the first request. 3 Suppose a document is related to sports and politics. If this document were represented by a single node linked to the two parent concepts politics and sports, then the temperature (see next paragraph) of the politics would influence the temperature of the sports which does not really make sense. 4

95 to each document between two consecutive computations is stored in an access table. During this process, documents that have been requested at least once since the last temperature computation are subject to warming, whereas other documents are subject to cooling. In the first stage (line 02 to 09 of the algorithm), the temperature of warm documents is increased by their corresponding value within the access table. This value is pushed in a stack to be used in a hypothetical future cooling of the document. The temperature of cold documents is indeed decreased by an amount equal to their last increase in temperature. In the next stage (line 10 to 18), the temperature variation for each document ( Θ) is diffused along the edges of the data structure. More precisely, for each (document, concept) couple where there exists an edge of weight W between document and concept, the temperature of concept increases or decreases by W* Θ. The resulting temperature variation for concept may be further diffused to its parent node as long as the overall weighted variation remains greater than a given threshold. Finally (line 19 to 27), the temperature variations for concepts is then conversely diffused from the concepts to the documents. Thus, note that a document that has been seldomly accessed can nevertheless see its temperature increase if its related concept has become hot. Indeed, this means that users are now interested by documents related to this concept, so there is a real chance that that document will be soon accessed. 4.3 Temperature, indexing, and its benefits We summarize here the previous sections and outline the main points of interests. Basically: we first propose that proxies use metadata and keywords dynamically extracted by a content analysis of the documents to classify all the documents proxies process. Most documents are not delivered with comprehensive metadata and descriptors. Consequently it can be necessary to analyze and extract descriptors on the fly (i.e. at the time they are stored in the cache). Then they can be classified using a classical directory as the ones used in web search engine (we use the Yahoo classification). Thus, documents can be related to one or more topic(s) or subject(s) ; A proxy can estimate the temperature of a document as the number of hits, i.e. the number of user requests that concern this document. The temperature of a subject can, on its side, be evaluated by integrating the temperature of all the documents that are related to it. Some temperature dispersion heuristics can be used to propagate the temperature from a subject to the correlated subjects. The aim of this procedure is to track the hot subjects. The temperature function is being used in four ways: to optimize the document replacement policy implemented by a proxy. Clearly, a document that is related to a hot subject should not be removed from the cache, even if its operational parameters (e.g. last access date) are not good ; to implement prefetching heuristics i.e. to pre-load documents before they are actually queried by users ; to optimize collaboration procedures. For example when a subject becomes hot in some proxy, another proxy can decide to prefetch a copy of the related documents from the first proxy. Similarly, proxies can exchange temperature information to optimize their cache management policies; finally, temperature can be used to inform users about the currently hot subjects. Note that we propose to compute this temperature both at the Aggregate Proxy level and also at the User Proxy level. 4.4 Navigator caches vs User Proxies We propose to attach proxies to the user computer. Currently, browsers propose to use proprietary local caches. Unfortunately, none of them implements advanced features (except basic prefetching i.e. the downloading of all the documents linked to the currently displayed page). Furthermore, browser caches cannot communicate with proxies. So, there is a real need for developing a non-proprietary model of advanced collaborating User Proxy. Apart from the fact that they will allow the global proxy architecture to deliver a better service (reduced network load, reduced latency time, reduced intermediate proxy load), User Proxies constitute the entrance door to customize and tailor the proxy system to user profile and demand. That is, user proxies: can get the user profile either by using a form filled by the user or by analyzing the way the user browses the information system ; currently, the user profile is statically determined by a form filling 5

96 can count the number of times a document is loaded from its cache. This information (lost by traditional browser caches) can be used both for the computation of the temperature and, after transmission to the original server, for document access statistics ; can filter and customize the semantic and contextual information to the user profile (see section 5) 5 Communities 5.1 Virtual communities Users with the same static profile (e.g. people using the same Intranet, students from the same University, ISP clients that declare to be interested by the same subject, etc.) or the same dynamic profile (e.g. people browsing documents related to the same subject) define a virtual community. One can assume, from our proxy point of view, that they have the same interests (both in terms of proxy management policies and in terms of semantic and contextual information demands). As noted in [9], this notion of virtual community can be used: to optimize Aggregate Proxies by associating each proxy to a restricted number of communities. Thus we believe to have more specialized proxies handling mainly related documents allows to optimize the whole community resources management; to provide users with pertinent information about the content of the proxy cache. With a simple browser, the user has a look to the content of an Aggregate Proxy where the temperatures of the documents are present, giving him the most possible accurate view of the interests in its community; to monitor the evolution of the interest of the community (which can be used both by proxy management heuristics and by users); to monitor the document usage and the links between documents. This monitoring can be done both at the Aggregate Proxy level and at the User Proxy level; to share browsing experiences in order to improve future requests; to allow users exchange their opinions about documents (if a user considers that a document he accessed is interesting, it can notify it to the search engine connected to his/her proxy) which can lead the community to de facto build their specific (adapted to their needs) map of the part of the information system that interest them. 5.2 Setting communities The subscription of a user to a community is decided by the user himself. A user may subscribe to several communities. As soon as a user is related to a community, its User Proxy is put in relation to the Aggregate Proxy in charge of the community. By this way, it enters in relation with the User proxy of other members of the community. In a hierarchical structure, administrators should organize the proxy collaboration structure in order to reflect the community structure and to deliver the best service. A user may dynamically choose to withdraw from a community (either definitively, or for the session time). He can also choose, when browsing the community proxy cache indexes, to suppress information coming from one community in order to narrow his/her view of the information space. 6 Experiments and discussion In this section, we present the implementation options, we give results corroborating the adequacy of the temperature notion, and we discuss some qualitative benefits of the use of our platform hardly measurable in terms of speedup or hit rate. 6.1 Prototype implementation The whole software is implemented using the Java language, for portability reasons. In a first stage and for experiment issues, the indexing tree implements the first three to four levels of the Yahoo! hierarchy, which gives us a limited number of concepts and a limited hierarchy level. This latter point is a real drawback, as discussed previously in 4. Thus, we have coupled our software with the ThoughtTreasure platform for commonsense reasoning [10], which is used when no relevance is found in our Yahoo-like hierarchy. ThoughtTreasure consists of a hierarchy of 27,093 atomic concepts with 35,020 English words and phrases and 21,529 French words (this bilingual feature is important for us as we aim to deploy the software in the french community as well). The weight of the edges between concepts are statically defined for the moment; we plan to automatically compute these from an analysis of the behavior of the users in a community. To index the web documents, concepts are extracted with a simple heuristic mixing the meta-tag keyword of the 6

97 document (if present), the number of times a word is referenced in the document, the title of the document and the reference links to other web pages. Today, the core parts of the prototype are developed : indexing, temperature computation and update, cache management policy and collaboration scheme. The integration part is now finished and we plan to make a bundle for evaluation in a few weeks. The evaluation of our platform is difficult to achieve, much more difficult than other traditional proxies [11], i.e analysing log files and deducing the hit rates related to any document cache policy. Indeed, log files are not enough for the evaluation of our strategy, since we have to examine the document in order to place it somewhere in the indexing tree. That means we have to visit all urls found in log files in order to know to which concepts it belongs. This hasn t been done today (see future works) and we plan to add a little module to the web cache of our campus to get and store this information together with the accessed urls, so that to be able to simulate real users data. 6.2 Simulation platform for temperature relevance We wanted first to experiment the temperature notion in itself. We conducted several experiments on simulated data to compare hit-rate with and without the temperature use. In our simulation platform, temperature was used: firstly, to determine the coldest elements in the cache to delete to make room for new incoming documents, and secondly to prefetch hot documents not already in the cache. The settings for the experiments were: number of documents in the document space: number of low level categories for the indexing: 100 number of documents in each category: all documents in a category are related to others by a weight of 50 % number of super-categories: 10, thus containing 10 categories each all documents in a super-category are related to others by a weight of 25 % 4 I.e. we use an even distribution. From the temperature point of view, an even distribution is not a favorable distribution ; uneven distributions, which are more realistic, are usually more favorable since hot categories usually embrace more documents. However we did not want to influence the experiments in any directions. Buffer hit nbcache Temperature LRU Figure 3. Buffer hit for varying number of documents in the cache number of requests to the documents: 5000 requests were randomly generated assuming that: 1) at a given time, some topics are more popular than others (hot themes); 2) if a document on a topic is being requested, documents related to the same one are likely to be requested in the near future; We have tried to figure out the effect of the cache size on the final hit-rate of our algorithm, as compared with a LRU policy. Results (see figure 3) show that, for a significant number of documents in the cache, our methods outperformed LRU, giving a 26% hit-rate for 600 documents in the cache (1300 hit rate out of 5000 requests). This is due to the fact that the more documents are stored in the cache, higher is the probability that these documents belong to the same concepts, thus taking advantage of our temperature policy. We have also demonstrated that, if the distribution of requests follows a hot topic distribution (half the generated requests fall on a small number of hot topics (20), our approach outperform LRU by up to 100% on small cache (less than 100 documents) and 20% on large cache. Some other experiments corroborate the idea that our algorithm offers in most cases a better hit-rate than LRU when requests have semantic links. Since one of the originalities of our platform is the extensive use of the temperature notion, the above experiments show the pertinence of the approach for caching data semantically linked. First experiments of a prototype of the whole platform show us that the temperature is well suited for a collaborative cache management policy. However, some benefits are not 7

98 clearly measurable (difficulty to have a wide experimental platform) nor can they be reduced in a comparison of speedup or hit-rate: next section offers an overview of such benefits. 6.3 Discussion In addition to the performance issue illustrated earlier in the document with the use of the temperature, we can outline several other interests from our platform, which are more qualitative than quantitative. In [11], the authors describe the impact of the collaborative scheme for the benefit of the hit rate, through real proxy data analysis and an analytic model of web behavior. They conclude that effort does not need to be spent anymore in the design and implementation of highly cooperative and scalable cache systems. Although we agree with a majority of conclusions the author describe, we disagree on the benefits one could expect from these proxies when users sharing interests share their proxies. We argue that the semantic value added in a simple cooperative proxy architecture outbreaks the limitations outlined for performance and hit rate related issues. We exhibit in the following five particular points of interest of our architecture. The first interest is the size of the cumulative virtual cache we obtain. Each User Proxy holds documents in its cache that is shared with others proxies. For example, our campus is composed of more than hosts. If they all implement an User Proxy of 100 MegaByte, we are in front of a 1.8 TeraBytes virtual disk space. A second point is that we pushed the computation of the indexing algorithm and the temperature update to the end-user s CPU. Indeed, such a resource is largely unused on most computers while the user browse the web. While he reads a downloaded document, some local computations and either communications with AP (to update temperatures) and other UP (for prefetching for instance) can occur without disturbing him in most cases. Let s imagine two Aggregate Proxies located one in New York City, the other in Los Angeles, related to sports: it caches locally meta data and documents about Salt Lake Olympics Games. On a typical day, because of jet lag, the users in New York have browsed the web before users in L.A. Some documents have been downloaded, the NYC Aggregate Proxy has been updated accordingly. While people in L.A. are still sleeping, one can imagine a communication between the two proxies, L.A. s uploading locally the hot topics (U.S gold medals for example) mentioned by NYC s, as well as the temperature map. Thus, when the user in L.A. browses the web, documents are already in its Aggregate Proxy: the download will be faster, and even he can use the information in its Aggregate Proxy to have a quick look to hot topics. This is relevant if people from both coasts share the same interests in their community. To offer this service, AP must have a cache space big enough to store retrieved documents, since it is not possible nor reasonable to push documents directly on User Proxies where computers might be sleeping (and even shut down). Another point of concern is the fault tolerance inherent to the system, since documents may be duplicated. A kind of mirroring is offered at no extra cost. Let s imagine a call for participation for a U.S located conference in a scientific community. If one user from U.K. has downloaded the information (final program, registration forms, hotel and tourist information,...), the probability that the same documents being downloaded also in Italy is high. The original U.S server might be down or highly loaded, thus if the two users subscribed to the same community, the Italian guy shall use the U.K. copies of the documents instead. The last point of interest is more a semantic value than a performance issue. The content of a proxy cache (actual content + previously stored documents) de facto provides a partial view over the global information system. This view has a real added value since it is related to the actual interest of the users. Indeed, trivially, if a document is or was cached it means that this document was requested by some user(s). This information is not sufficient to consider that this document is highly interesting nor to estimate that the user(s) that got it found it interesting. However, it means that this(these) user(s) at least had the feeling that this document could be interesting. Clearly, if 100 users had this feeling (i.e., requested the document) the probability that the document is interesting becomes higher. If they spent a reasonable time before they requested another document (tending to prove that they actually got a look on it), this probability becomes even higher, etc. Consider the Web. The key issue is not that the web does not offer enough resources but that there are so many documents available that finding out the right document is becoming more and more difficult. So, suppose Louis follows a distance learning course and that he wants to get a tutorial on multimedia information systems: it may be valuable for him to check if some other students in the group found out such teaching materials. In another context, if Jacques is interested by tennis, it may be interesting for him to know what are the web sites that are today the most accessed by tennis fans. If Paul requests a document, he may be interested to know what documents have 8

99 been accessed by other users after they got the one he is reading (indeed, these documents may be correlated with this latter). So, we believe that document classification (i.e. proxy cache indexing), as it was described in section 4.2, and apart from its operational interest, may really be valuable to users to find their way in the jungle of large decentralized information systems 5. Furthermore making this information accessible only requires adapting a simple search engine at the top level proxy and making it operational through a classical web interface or a specific GUI. However, if one can expect from people interested by politics that they are interested by in-depth information about the documents available in proxy caches that actually refer to this subject, there is no evidence that they are also interested by information about sport. In other words, information about document related to sports may be noise for them. In the proposed architecture, bottom proxies, as they have a direct and simple access to the user profile and to his current browsing session, can adapt, tailor the cache indexes to the user needs. Future works We have started a project to analyse the behavior of our proxy implementation, mainly to provide a test platform for it. These tests are intended to show the correctness of our indexation schema from real web users, as well as the relevance of the cache management policy together with the communication schema of the architecture (in terms of performances and tuning). Another point is mainly a performance and implementation issue. In the preceding description, the User Proxy opens a communication with the remote User Proxy to fetch the document: for some reasons (network workload, remote overload,...) it may be more suitable to ask directly the original server of the document. We plan to add this soon with the help of the Network Weather Service for instance (NWS, [12]) which allows to predict the transfer delay for a file from one point of the network to another. We plan also to add this information onto Aggregate Proxies to maintain information about multiple copies of the same document in the local virtual space with a cost associated with it. Concerning the subscription of a user to a community, we will add an automatic subscription by the system, after considering the user profile and/or the user browsing session. 5 For privacy reasons, the anonymity of user requests must be preserved ; furthermore indexing may be restricted to the only subjets that the proxy administration considers pertinent... 7 Conclusion In this paper we discussed a new architecture for semantic cache of web documents. This paradigm is based on the use of a set of collaborating proxies. The collaboration is based on the classification of the documents stored in the proxy caches and on the computation of the temperature of documents and the subjects of interest. We discussed the pertinence of the temperature. We then presented how this concept of collaborating semantic proxies can be used to provide the user with valuable information about the information system and the current use context. Based on this concept, we also proposed the notion of virtual community that associates users with a common interest to a dedicated proxy. This notion could allow both enhance the system performance and improve the semantic and contextual services provided to the users. References [1] M. Uschold and R. Jasper, A framework for understanding and classifying ontology applications, in IJCAI99 Workshop on Ontologies and Problem-Solving Methods(KRR5), Stockholm, Sweden, August [2] M. Wooldridge and N. R. Jennings, Agent theories, architectures, and languages: A survey, in Proc. ECAI-Workshop on Agent Theories, Architectures and Languages, M. J. Wooldridge and N. R. Jennings, Eds., Amsterdam, The Netherlands, 1994, pp [3] J. Wang, A survey of web caching schemes for the internet, ACM Computer Communication Review, vol. 29(5), pp , october [4] G. Barish and K. Obraczka, World wide web caching: Trends and techniques, IEEE Communications Magazine Internet Technology Series, vol. 38(5), pp , May [5] Anawat Chankhunthod, Peter B. Danzig, Chuck Neerdaels, Michael F. Schwartz, and Kurt J. Worrell, A hierarchical internet object cache, in USENIX Annual Technical Conference, 1996, pp [6] D. Wessels, Squid internet object cache, August [7] David R. Karger, Eric Lehman, Frank Thomson Leighton, Rina Panigrahy, Matthew S. Levine, 9

100 and Daniel Lewin, Consistent hashing and random trees: Distributed caching protocols for relieving hot spots on the world wide web, in ACM Symposium on Theory of Computing, May 1997, pp [8] R. Tewari, M. Dahlin, H. Vin, and J. Kay, Beyond hierarchies: Design considerations for distributed caching on the internet, in Technical Report CS98-04, Department of Computer Sciences, UT Austin Austin, Texas, USA, may [9] Lionel Brunie, David Coquil, and Serge Simon, Software architectures for collaborative proxies in wide area information systems (position paper), in Fourth International Workshop on Parallel and Distributed Databases : innovative applications and new architectures (PaDD 2001), IEEE Computer Society Press, Ed., Mnich, september [10] Erik T Mueller, Natural language processing with ThoughtTreasure, Signiform, New York, [11] Alec Wolman, Geoffrey M. Voelker, Nitin Sharma, Neal Cardwell, Anna R. Karlin, and Henry M. Levy, On the scale and performance of cooperative web proxy caching, in Symposium on Operating Systems Principles, 1999, pp [12] Richard Wolski, Dynamically forecasting network performance using the network weather service, Cluster Computing, vol. 1, no. 1, pp , Table 1. Temperature computation algorithm Variables and data types: Tree: the data structure Acces[]: access table document Stack: stack for storing temperature variations Parent: pointer to parent node Internal node: Parent: pointer to parent node Child[]: table of pointers to child nodes Delta: temperature variation in this computation Temp\_modif[]: table of temperature variation due to each child 01 For each document D do 02 If acces[d] == 0 03 Delta=Pop(D.Stack); 04 D.Temp -= Delta; 05 Else 06 Delta=Acces[D]; 07 D.Temp += Delta; 08 Push(D.Stack, Delta); 09 Endif 10 P=Parent(D); 11 While (P!=Root and Delta*Weight(P,D) >Threshold) 12 Delta *= Weight(P,D); 13 P.Temp_modif[D]=Delta; 14 P.Delta += Delta; 15 D=P; 16 P=Parent(P); 17 EndWhile 18 EndFor 19 While ((N=BreadthFirstTraversal(Tree)) is not leaf) 20 For each child C of N do 21 if ( N.Delta*Weight(N,C)-N.Temp_modif[C] >Threshold) 22 if (C is a leaf) 23 C.Temp+=N.Delta*Weight(N,C)-N.Temp_modif[C]; 24 else 25 C.Delta+=N.Delta*Weight(N,C)-N.Temp_modif[C]; 26 N.Delta=0; 27 EndWhile 10

101 1 Uniform Distributed Cache Service for Grid Computing Yonny Cardenas, Lionel Brunie, Jean-Marc Pierson LIRIS, CNRS UMR 5205 INSA de Lyon, bât B. Pascal, 7 av. Jean Capelle, Villeurbanne cedex, FRANCE {yonny.cardenas,lionel.brunie, Abstract The uniform cache system, suggested in this paper, illustrates an approach for high level grid data access. It aims of optimizing the use of grid data resources and increasing the access performance. The system is based over the grid caching concept, where applications share and reuse data semantic information (metadata and data-content). The generated information for this activity is analyzed and applied to manage the system dynamically. Therefore the uniform cache system applies the techniques of collaborative caching for data management in ensemble of the grid. Keywords: grid caching, collaborative caching, grid data access I. INTRODUCTION The grid concept is the result of the evolution of distributed system [1]. It makes possible for several institutions to establish virtual organization supported by computing infrastructure. It provides access to distributed computing power, scientific data repositories, experimental facilities on demand and allow labs to share computing resources between users[2]. For instance, projects like Globus enable integration and sharing of distributed resources between different domains [3]. An hypothetic example is the possibility for several health research center and hospitals around a geographical region to develop a breast cancer study: Researchers want to retrieve relevant data and use it to determine the impact of environment and life style on the development of breast cancers, such as to propose new treatments. Basically some health research centers have analytic computer applications while others have experimental facilities. Often the hospitals have vast database of digital images. In such a case, a computing grid can be established to allow remote access to the databases and expensive scientific instruments, permitting scientists to collaborate and share easily information and tools. The grid provides the facilities on demand and allows labs to share computing resources that researchers can use when needed. The management of very large data amounts requires to improve the performance of grid data access. Additionally, users need particular mechanisms for efficient data access to specific information. This work is supported by the Région Rhône-Alpes project RAGTIME. There are diverse mechanisms to manipulate data in the grid environments, e.g. GridFTP for file transfers [4], RLS replica location services [5], access to relational databases [6], etc. But it does not exist any mechanism enabling an efficient level of cooperation between different applications and services for reuse and data sharing. A consequence is an uncontrolled proliferation of copies in grid ensemble, which has negative impact in the grid data resources usage. Although, Caching and Replication are traditional mechanisms to manage data copies in distributed systems, they tend to consider mainly data-content activity for data reuse and sharing. The semantic tendency of grid needs systems based on datacontext or metadata [7]. We propose an architecture on a grid infrastructure, which applies collaborative cache techniques for data access and management in grid computing. This system aims at optimizing an efficient use of grid data resources and increasing data access performance. Our system is composed on a distributed set of caches which work cooperatively for exchanging information related with data-content and data-context (metadata) activity of grid applications. II. METADATA AND DATA ACTIVITY Applications in grid environments need to determinate the appropriate data involved in resolving a particular problem. They need to know as well the meaning or semantic of data entities (i.e. they need the data properties which describe raw data). Metadata are semantic labels used to describe data properties. They can be used to indicate basic characteristics as type, size, format, etc. Furthermore they can be used to enrich data descriptions such as origin, creation parameters, algorithms provenance, and annotations : This permits to establish data nature and life cycle. Our idea is based on the importance of this data activity notion. The interesting data are those that are moving or that have some activity (creation, update, retrieve, etc). Grid applications aim at finding and retrieving metadata. Metadata increases the probability that data has more activity, data with more activity are thus data with rich descriptions. In this work, we assume that a virtual community [2] has a common interest and has a tendency to use similar data and computing process. For example, a breast cancer research

102 2 project uses a set of delimited health data and computing process. Data is often moved for computation, i.e, there is data transfer between organizations that participate to the grid. Agreements to exchange data are based on schemes, mapping, or ontologies. Moreover there is an explicit interest to share and reuse data and processing. In this context, applications in virtual community are likely to use data with more activity. However data with more activity is only a part of the total data in the grid. Data activity must be registered and managed as part of associated metadata. It permits to establish dynamic and historic evolution of data in the grid. Applications request to execute hybrid queries, which include to find and retrieve data and metadata. Moreover, metadata can enrich the data description itself after computation. For example, an application in medical grid considers to find similar images to a given image. This operation includes the computation of similarities on images with particular characteristics. This computations can be registered by a cache system as metadata for future reuse and share. Some properties to include in the metadata are: Provenance, data origin or ancestor Localization, physical storage system and relative in distributed system. Access permissions, rights granted to collections, groups, and communities. Time to live Parameters, calibration, algorithms, mechanisms, software version. Objective or use. Additional descriptions or annnotation. The Metadata Catalog (MCAT) associated to Storage Resource Broker[8], supports basic metadata operations for data description. It uses metadata for logical and physical name spaces for data management. However, it does not support queries over data computation, data activity and evolution of metadata. Metadata Catalog Service (MCS) associates metadata with logical names for data entities [9]. MCS is used to manage unstructured data entities (files). It stores metadata to specific data instances. It does not address descriptive metadata. III. COLLABORATIVE CACHING AND GRID CACHING Caching is a technique that allows managing copies of frequently accessed data. Applications often use data which are expensive to collect, to access or to transport. These data have a lifetime during which they can be reused. The cache permits these data to be easily and quickly available for use by the same or other applications. Caching can be used as a way to allow applications to share data without the need to get them directly from original source. Each application interacts with a nearby cache to give and to get data. In a distributed system as the grid, the individual caches can work cooperatively for sharing data in a more efficient way. Different cache collaboration schemes have been proposed [10]. They are mainly oriented towards inter-cache protocols for data resolution, i.e. finding a data in a set of distributed caches. Furthermore, these protocols have been designed for web traffic [11], which has different data access patterns in comparison with grid computing. Our team showed that semantic processing could be applied to improve collaborative web caching [12]. A. Motivations Grid data community has expressed the need to define and specify a standard grid cache service. This task requires establishing initial grid caching particularities, problematic and opportunities. Traditionally inter-cache protocols have been oriented only to data resolution, i.e. mechanisms used to find the requested data object in a set of caches. Our main motivation is to extend inter-cache capacities to cache management, i.e. to develop mechanisms for dynamic cache decisions and collective collaboration. Grid and collaborative caches are both distributed systems composed by independent entities. Grid computing aims of addressing the synergy of concepts such as collaboration, autonomy and dynamism, with industrial developments as web services. The most interesting grid challenges are related to the coordination of multiple entities. Our objective is to design and develop a grid cache as a collective service. B. Objectives Our objectives consist in : Optimizing efficient use of grid data resources with collaborative caching, e.g. minimizing the proliferation of data copies for a better use of stored resources. Increasing data access performance and reducing access time. Improving the data resolution and increasing the data found ratio by allowing caches to share metadata information about the description and localization of data. Developing dynamic mechanisms for adjusting the protocols to specific requirements (e.g. biomedical grid). Developing federation mechanisms for heterogeneous distributed caches and following grid principles of autonomy, collaboration and virtualization. Developing a distributed cache system with searching in insights and transparency. C. Problematic The proliferation of copies is presented in several ways, such as caches, replicas, and snapshots, which are not managed in

103 3 a coordinate way. This increases the risk of redundancy and inefficient resources use. The copies of data are created and maintained by isolated applications such as data bases and file systems, which use unrelated mechanisms and policies of management. There are difficulties to establish mechanisms to obtain metadata, which are indispensable for grid caching. No policies or mechanisms exist for caching data distributed in different administrative systems. The effects of appling the same mechanisms in different environments are unknown, e.g. a cache system used simultaneously for grid and Internet traffic. D. Requirements Discovery Capability: A Grid caching service should describe and localize the data in the distributed caches. The description must include the information for caching management such as the structure of the cache network and the status and resources of the data maintained by caches. Registry Capability: Grid caching must get metadata information from caches since the collaboration process is based on data-context sharing between participants. Thus, local caches act as metadata providers. Access Support: Grid caching must allow application access to metadata information. This extracted information can be used for both data resolution, and cache management. Flexibility Management: Grid caching must apply different coordination policy and methods, i.e. management mechanisms can be changed dynamically on need. Furthermore, different placement methods can be tried to improve the efficiency of the system. Local Cache Independence: Local cache management must be autonomous. The administrators should be allowed to apply independent cache politicies and mechanisms. Optionally, the caches can incorporate collective management decisions. Distributed Coordination: Grid caching coordination should not be centralized; all caches should participate in the management, and all decisions should be taken collectively. Data-context or Metadata Based: Grid caching policies must be based on metadata shared among participating caches. Grid Interoperability Grid caching must interact with the grid infrastructure, i.e. be interoperable with the data management, discovery, security, resource scheduler and monitoring services. IV. RELATED WORKS In this chapter, we study the main data services used in grid middlewares for data access and management. GridFTP is a service to transfer very large unstructured data entities. It is based on the FTP protocol and supports various extensions: security, parallel data channels, and progress monitoring [4]. This is a basic service for data transfers. GridFTP can be managed by high level or collective data service. Replica Location Service (RLS) is a distributed registry for localizing distributed data copies. RLS supports queries to find the replicas. RLS does not guarantee the consistency among replica data [5]. RLS is a basic service, it does not apply mechanisms for data management. RLS allows registering metadata it does not use these metadata for its own management. Furthermore it needs to be coordinated by another collective service to have a global view of the grid structure. Metadata Catalog Service (MCS) is a catalog that associates metadata of data-content entities with logical names used for identifying this entities [9]. MCS is used to manage unstructured data entities (files). It stores logical metadata that describe contents and physical metadata that describe particular instances. OGSA-DAI Database access and integration middleware [6] defines and develops grid data services for structured data stored in relational database management systems, as well as semi-structured data stored in XML repositories. SRB provides uniform access to distributed storage in SRB servers. It supports descriptive metadata and file replication [8]. Its main limitation is being addressed to unstructured data entities (files). Such data entities are typically used in some scientific communities such as physics and astronomy but less in domains like medicine where structured data stored in databases and XML repositories are more frequently used. V. PROPOSITION We suggest the Uniform Distributed Cache Service for Grid Computing that is managed according to the data activity. This data activity is generated by semantic use of metadata. Therefore, the Uniform Distributed Cache Service supports grid data access from applications using semantic descriptions. This descriptions correspond to metadata associated to data-content. The Cache Service is enlarged in all grid using a architecture of cooperative caches. The Uniform Distributed Cache Service is based in three main functionalities: Registry, Access, and Management. The functionalities are applied in three levels: Organization level, Grid Local Level, and Grid Collective Level. Finally the service architecture is composed by two types distributed elements deploys the functionalities in different levels: the Local Grid Cache and the Collective Grid Cache.

104 4 A. Service Functionalities Registry Functionality Applications use this functionality to provide information (metatdata) to the cache. With this functionalities, the cache can offer a service to receive and store information from several sources. Access Functionality Applications use this functionality to retrieve information (data and metadata stored in the cache catalog) from the cache. Management Functionality This is the central functionality of our Grid Cache System. It analyses the registry and access activities to take local and global cache management decisions. It applies different administration policies and mechanisms from individual caches to whole cache group. It works mainly at the organization and collective levels. The functionalities are applied in three levels: Organization Level, Local Grid Level and Collective Grid Level GRID CACHE SERVICE FUNCTIONAL LEVELS Fig. 1. Organization Level Grid Local Level Organization Level Grid Local Level Collective Grid Level Grid Local Level Organization Level Grid Cache Service - Functional Levels Grid Local Level Organization Level Local Grid Level This makes reference to the deployment of cache functionalities at the virtual community level, i.e. the cache works as a local service for users and applications of the grid. Collective Grid Level This makes reference to the deployment of cache functionalities for a group of local cache services in the grid, i.e. the cache works as a collective service for users and applications of the grid. C. Local Grid Cache The Local Grid Cache implements the cache functionalities at the organizational and Grid Local levels. This characteristics gives it the possibility to work as a gateway between the internal organization and the grid. It models a uniform basic cache service for grid and non-grid environments. Features : It implements conventional interfaces inside the organization and grid interfaces for external interactions. It offers cache functionalities to the entities where it is deployed, e.g. An health research center deploys a local grid cache, which offers cache functionalities (registry, access and management) that can be used by the hospital internal applications. It offers cache functionalities to the virtual organizations that the local entity participates to, e.g. A health research center that deploys a local grid cache will offer cache functionalities (registry, access and management) to the members of the organizations it belongs to. It translates standard data grid operations to operations supported by organizational cache systems and vice versa. It implements the roles of client metadata provider and server. Grid Inter-cache Message System It implements an intercache message system. This mechanism permits to exchange metadata that describe the data activity between Local Grid Caches. It uses underlying messaging systems available in the grid such as SOAP [13] B. Service Deployment Levels Organization Level This makes reference to the deployment of cache functionalities within the organization (or administrative) domain, i.e. cache service works as an internal service for users and applications of the organization. 1) Registry Functionality: At the organization level: It manages a local cache catalog for metadata and cache data information. It applies or implements consistency mechanisms for catalog information. It registries data security permissions.

105 5 At the grid local level: It maps the local data references with grid references, i.e. it translates local name space references to grid name space references. It shares metadata and cache information with other caches to implement grid collective functionalities. 2) Access Functionality: At the organization level: It maps the logical references (metadata) with physical references (data storage) i.e. it can establish relations between catalog metadata and data content. It manages data storage resources for data content storage. It manages data transfer services for data content transmission. It coordinates data query resolutions. At the grid local level: It translates grid access operations to organization level functionalities. It applies data security permissions and policies to grid operations. It coordinates grid storage resource managers [14] and grid data transport service [4] for remote data retrieval. 3) Management Functionality: In the organization level: It applies methods and mechanisms of local resource management: data-content replacement, local placement in cache, data storage. It applies methods and mechanisms for monitoring, tracing, billing and accounting the cache system. At the local grid level: It translates management operations between the organization level and the collective level, e.g. data-content replacement and data placement. It shares cache management information with other caches to implement grid collective functionalities. It manages an inter-cache message system. It applies grid inter-cache protocols. It implements three management modes: Optional Mode The collective grid level decisions can be refused by the organization level. Mixed Mode The collective grid level decisions are mixed with the organization level management policy. Subordinate Mode The collective grid level decisions are mandatory and so always implemented by the organizational level. D. Collective Grid Cache The Collective Grid Cache implements cache functionalities at the collective grid level, it has a global view of the set of distributed caches it manages. 1) Registry Functionality: It manages a distributed catalog of information provided by local grid caches. It applies or implements consistency mechanisms on the distributed cache catalog information. It applies global security permissions on the information stored in the distributed cache catalogs. 2) Access Functionality: It processes retrieval queries of data stored in local caches. 3) Management Functionality: It applies collective or global cache management policies. It analyses global cache information, including monitoring, tracing and accounting, to take collective decisions. It divides a global cache space in subspaces for management proposes. It implements collaboration or cooperation mechanisms between caches. It applies methods and mechanisms for collective resource management. It manages grid inter-cache protocols. VI. USING GRID CACHE SERVICE Our Uniform Distributed Cache Service offers classical functions to grid applications: the applications provide data and metadata to cache service, which in its turn manages the access to this data since other applications. The applications make requests of data to cache service, which resolves this requests using the mechanisms of collaboration between the caches. Fig. 2. APPLICATION (ORGANIZATION) (Produce) METADATA (XML) Registry Storage Resource Manager (SRM) DATA Organization Interface (API) Use of Local Grid Cache LOCAL GRID CACHE API API API SRM OGSA DAI MCS OGSA DAI DB Grid Interface (Web Service) Retrieve Metadata Catalog Service (MCS) DB APPLICATION The Uniform Distributed Cache Service is designed to work as grid service. It can be used by applications or other grid services. It is flexible in quantity and quality of metadata registered. But the cache efficaciousness depends of quality of metadata registered by users and applications. The uniform grid cache service has an essential role as data access gateway between administration domains. The applications use our cache service for sharing data through (GRID)

106 6 Fig. 3. API SRM Metadata Catalog Service MCS DB LOCAL GRID CACHE API OGSA DAI OGSA DAI DB API MCS Storage Resource Manager SRM DATA COLLECTIVE GRID CACHE GridFTP Data Tranfer GridFTP API SRM Storage Resource Manager SRM Local Grid Cache and Collective Grid Cache LOCAL GRID CACHE API OGSA DAI OGSA DAI API MCS Metadata Catalog Service MCS DATA DB DB grid resources in transparent way. The grid uniform grid cache service coordinates necessary grid services and resources (storage services, transfer services, etc.) for all operations. User and applications have a perception of a cache uniform, the data distribution, grid interactions and heterogeneous sources are hidden by the service. interactions are done using grid data discovery services. Indirectly with basic grid resources services: the use of metadata is very limited, because basic grid services do not work with metadata. Data Consistency Mechanisms Provider application defines the consistency mechanism for managing state of information registered in the cache service. consistence information is given to cache service as metadata using the Registry Functionality. Local Grid Caches can implement basic consistency mechanisms for data-content managed directly by cache. Local Grid Caches support external consistency mechanisms, i.e. specialized third party services or mechanisms can register state of information, they can use cache registry functionalities. The information about data consistency is propagated to caches using the cache messages system. Prototype Data Query Resolution The application contacts to Local Grid Cache, then submits data queries. The cache resolves data queries looking local registry or collaborating with other caches in the grid. This queries are processed by the cache service. It analyzes the metadata held by registry functionalities. Inter-cache Collaboration Management The caches use inter-cache message system for inter-change cache management information. The are organized in two hierarchical levels respectively composed of Local Grid Caches and Collective Grid Cache. The Collective Grid Cache work as federator of the set of Local Grid Caches. The inter-cache protocol establishes how they exchange data metadata information for data query resolution, par example, each Local Grid Caches sends a summary of local metadata catalog to Collective Grid Cache. The Collective Grid Cache searches in the collective metadata catalog that cache can has the data asked and translates the request to Local Grid Cache, data transfers are done only between Local Grid Caches. The Collective Grid Cache compares information in collective metadata catalog to establish that Local Grid Caches storage the same data entities. The goal of the Collective Grid Cache is reduction of data copies, it places Local Grid Caches in rank order from data activity of this data copies, them it sends messages to Local Grid Caches with less data activity of this data copies to remove them. The Local Grid Caches supports three interactions modes with applications : Directly by user applications: the application must invoke cache service explicitly. Indirectly by other high level data grid services: the We have developed a first prototype version of the Local Grid Cache. It implements Registry, Access and Mangement functionalties at the Organization Level such as it is showed in figure 4. Fig. 4. APPLICATION (ORGANIZATION) (Produce) METADATA (XML) Registry LOCAL GRID Management Functionality Access Functionality DATA CACHE The Local Grid Cache Prototype Registry Functionality Catalog (Metadata) Grid Interface (Web Service) Retrieve APPLICATION The Local Grid Cache service is compliant with OGSA service specifications. It is implemented over Globus middleware version [3]. The prototype supports all interactions and operations that involve metadata. It only supports files as data entities. The clients applications invoke directly the cache service The prototype implements three replacement mechanisms: Least Recently Used (LRU), Least Frequently Used (LFU) and Size (based in data entity size) [11]. The replacement ploicy can be changed dynamically. The prototype supports two kind of interaction with client applications: (GRID) Interactions to retrieve data Interactions to provide metadata about data activity.

107 7 Interactions to provide metadata about data activity. The client applications invoke the Local Grid Cache to registry metadata about data activity. For example when a data entity is produced: The client application sends to the Local Grid Cache a file that contains metadata about the data activity in XML format. The Registry Functionality processes the file to extract the medatata above the data activity and updates the metadata calatalog. The Manager Functionality analizes the cache state (e.g. it checks if the cache capacity is exceeded) and decides if it needs to apply replacement mechanisms[11]. [9] G. Singh, S. Bharathi, A. Chervenak, E. Deelman, C. Kesselman, M. Manohar, and S. Patil, A metadata catalog service for data intensive applications, in Proceedings of the ACM/IEEE SuperComputing 2003 Conference, (Phoenix, AZ, USA), pp , IEEE Computer Society Press, [10] G. Barish and K. Obraczka, World wide web caching: Trends and techniques, [11] M. B. Jean-Marc Menaud, Valrie Issarny, A scalable and efficient cooperative system for web caches, July [12] J. Pierson, L. Brunie, and D. Coquil, Semantic collaborative web caching, in Web Information Systems Engineering 2002 (ACM/IEEE WISE 2002), (Singapore), pp. 30,39, IEEE CS Press, dec [13] N. M. J.-J. M. Martin Gudgin, Marc Hadley and H. F. Nielsen, Soap simple object access protocol, June [14] J. U. I Foster, S Tuecke. Interactions to retrieve data. The client application invokes the Local Grid Cache to retrieve data from the Cache : the client application issues metadata based queries to the Access Functionality (e.g. Retrieve all lung X-rays of Mr Dupont ). The Access Functionality transmits the query to the Metadata Catalog and decides if there are data to return to client application. The Access Functionality sends the requested data to the client application. VII. CONCLUSIONS In this paper we present a uniform distributed cache service for data grid environments where applications we specific mechanisms for efficient access to data resources. We propose an architecture for Grid Cache Service. This architecture is composed of distributed set of caches which work cooperatively using grid mechanisms. Our goal is to optimize the efficient use of grid data resource and improve data access performance to large data amounts. REFERENCES [1] D. Baker and J. Shadbolt, The evolution of the grid, in Grid Computing: Making The Global Infrastructure a Reality, pp , John Wiley and Sons, [2] I. Foster, C. Kesselman, J. Nick, and S. Tuecke, The physiology of the grid: An open grid services architecture for distributed systems integration, [3] Globus Project, The globus project [4] Globus Project and European Data Grid, Universal data transfer for grid [5] L. Guy, P. Kunszt, E. Laure, H. Stockinger, and K. Stokincker, Replica management in data grids, tech. rep., Global Grid Forum Informational Document, GGF5, Edinbourg, Scotland, July [6] Globus Project and e-science Grid Core Project, Open grid services architecture data access and integration [7] N. R. S. N. De Roure, D. Jennings, The semantic grid: A future e- science infrastructure, [8] San Diego Supercomputer Center (SDSC), Storage resource broker (srb)

108 !! "! # # # $% &! # % ' # ()* () +,! -!$ ()!-. *! + * +/ # % 0 #, #!! 1!! %! " #! $% "!& # '! # (! #! %#) # %# # %" *") # +,- #)% $ #! % " #! # ". % " " " $"! "# / 0* " #"!"&!#" #0!1!%# 2%3!!! #'(! "! ! " /!! "# $ * :") # 9 " '; # ( +7- # % " 0 # # # " " ) " " $! " &! )

109 1! ()' ("80(A #; # +,3- " B# CB # # # * 0 +,1- CB # # " ) * #" CB $! CB" #0!"& B! ## +1- % # # #' +,4-( # " +,6- #" # $ & # % & '' ( B # D! #!"# &! % E! #! #0! &! $! " *!! #0 # " " /! " % )( ' 5 "! *!!"!" ' EF "3 * *%!F EF EF F 5 # 4#) " 34 4) ) **E 5 # 5 # G! # " F" H" '( 9, '( ' 4( = =! 5 G # 5 /% F '( = = F '( =,= F#,= '( = 1= F#1= #!F. "3 *# + = 5 #4 "3 *#4+ = *4# + = 4) " I '( =, ' 4) ( = 1 '( = '( '(= EF 2F",,= 9,1= 9, =, + 1! *%!<J K! G'<J(L9, #G'K(L9,G'K(L9, %!<J K! G'<J(L9, 5 % "!! " # ' %#(

110 3 %! )( %! )('! # # 'E(#!F "!! "# #"G # " #"! 5! ' #,( <FE EF )* +, *+ = { 6 "3*6+} )* & +, 7 *+ = { 6 "36+} / )1 * 2 0. ". #!"%! F "! ""'"( #: " E 9 # *&! " #! " # / 0. )1& *2 0)()* " &! " 5!F #" # " #"! % # "! / % #!!&! %!'#1(* % "!G'( G'( G'( # $ %#*! ""'"( # #! % 2 5!%#F (( # -(( # (( # G! ""!9, -((% # % # % 0 # ( # = (!" )1& *+., 2. 0!)()'

111 4 / (( % " % #$$ α* % + """!=, ) " 8 % # α * %+ '#3( *%+ = F E + 9 α *%+ % + E * 4+. *)+ 0 F# / % F 1= 6== "! #! % 4% ) " & *#4+ = ; * 4% )+ = 1, ;= ;:= ; %% *#)+ = *#4+ *4#)+ = : ; + 9! 4 )!#% # = *#0*%++ 4 0%)((( 9 "!# " F *K * '( G K#"" G K ;""" ) )(1 '# ; " 'K(*! G'( # ). = % ) = 34 ) = 54 G'(L46 G'(L1 G'K(L,= G'K(L ,86+7, 6+7, 849+!5:54,; ,86+.7, 6+7, 8!9+35:5,;% ,86+7., 6+.7, 8<59+55:%,;3483%% * α 4 = 6 = 3 = ( 4 =?= +?= 3 = 6 =,?6 ", % $ =,?33 4 =,?6 ) = 5 %!! )( '' 5! "! # # * # " # # # '9( # " " # "! /% F "#(!! # "!)' " # #! ( )( +, $ ' ( *! #0"#:# # "! ""!!F # 9" #9 #! $ E! 9

112 6 %% 1 " 9 "$ " # " ## F &#! &'#4( 0<)( )( ( "1! E )' # ! E & &! $ ' )!)(( )( '* " # $ "$ IE'#( " & 0 $ (! # " 'K" (/# #"""# # "$ %%! 1) 9!& '#6(F.!!' ( <.!! * +,! +!! 05)(- *#0& "!!)"!*!"'"# ( ' "# ( ) "# $" " 9 $ "9% "! *#9" #

113 7 9 #! 9! #&% " " # 4! F 9 " # '*K *KE( ##'#( #"!! # "# # # " # %< (! " " F E!!M B " " # % F! "&!! " %< " ( # D &9 " & # $ "'# ( %<! ( " 9!# # &" # '( #!! D "" < & ( 3 K ' #7( 0= )( ( <. -#,,,'. B KF 2. " K!"F $ " "#9 $ " "#9.*#)" K!"F *" $ ""! $# "&"9 ''. " #F #! "# #

114 <! )( #"!!# F )( 2 # % "! F # # &# )(! "!! 99 )( F#!! " # " % "&% *K % *IF% E E E * % * &F% ON#'%( #!%$ "& 9 # '( "! & ) (($ <%! 4.)* "! F *$ 8.F! %# $ "&'*(& " %# $ F :'"('<6=> ( /%P B%# 4 ##. "! $ " # ""# # 5!!! F'(!# F 1 )&F /0, %#/%*$." 1. * ) 9*"F0, %*$ N / 0, % #/23% *$." 1. /0, %#/*%*1.!1 9B"0, %*$ N %1 # # $ " # #$ #K B"! FB"! F 1 /0, %#/%*$." 1.!1 * ) 9B"0, %*$ N F /0, %#/23%*$ " 1. %1 9*"0, %*$ N F /0, %#/*%*1. <1 # # $ " # #$ #K & 1 "'9(! $ 1 :4 % F#:!!1 49 %1 " <1 # "$ # 51 9F >0,"%#/*"4%,!/!%,/$%5#1 $* 0 6 %7 1?*+,?

115 @ 5# #1'#?(!( "!#! F # " " "!"" #.=. # & # ()<""# 8 A 1 "!1 E "$ # $ "$ %1 " <1 # E K ()<" % 8)1) A 51 &F = *". % *",! < 9 *",! *! #0"!# # #3'#?K( % '' 5 "!#0 E # # # '9( "Q! "'(! F * ) # 1 E&&!1 E& % *)$!! %1 : #" 0*","%*",!%*",% *"*%*1 <1 '!!&P( -#, 0-%*>%*%?1 <* (2 * " #0 % 4 %! # Q & # " #'#?( 1 #0#)&8A /0 %#/!%, 5! %*"," *",!%*"*%*".%51.5! * L &EL# E*K E F*KE!1 E & E9 %1 *E & E #0()<"ON=F 9 & 0/ %,! /, 5! 1 "'( "9 #& /0 %#/!%, 5! %*","% *",!%*"*%*".%561.5! <1 * E & 51 *E & E #0()<" F 9 % 39!( # '( ( '#ON9,( "9!& F *!"&#L9,F /0 %#/!: &!: ' %*/, 5! %./61.5! 9"F /0 %#/!: %*/, 5! %*%./;5!%*",! *".1.5! 9"F ; 3'#0( "= >"= - "= $ >"=$* >;+ "= 7 >"=7? =1 *E & E/ & #* " /0 %#/!: &!: ' %*/*<, 5! %,./61.5! &/0 %#/!: %*/*<, 5! % *%./. ;5!%*! 1.5! 31 * &$ &' E/(% 3 =. % *! 9 *!

116 >.! 03*( ' 5 #0!##!9#6'#?1( 5& 1) 1 4## F7!149 %1/!# "# <1 9F >()# <">< 4 #<7>< 4 A /7 *7<"#4+A,.>7 ; #D A?*+., =" * ' # P( & 7 0%# "!! 1 E ) & 8CA?/0, EC & '*9(9* %1 5 C& $ 0, %*","%*"5#1 5 ' " < 0A(B '! F '#:!(!'#9 9(: # " F!'"&6,1,=14( '#*!" (: = 9 E 9 :,!: = 5! :, 9/9!: 1 & #":1:, #!!# F!" # %! / 9 " #" *!!! " *! = B! "# " #F #&!# " #" #" $D # " D$ D # ) # "% = " ".

117 ,= ""!## ##'( # # *##! # /#!!# " 5 # K " #! # # K +,=- < +,,-/ % F "" SKS S2SSS%#!# ## #" " 2 "' F* #(#&! #"# #'###( 3 0$ " 9 ") #*!!! " # 5!""! #! &!&!! '( # # 5 #'. # #! &## " & "' (* ". "! /! #! " # ) * *A ' FIIITI(! " +,- 2 & 5 "# 7 /&)*#5 & :") #=1 +1- *:9 <6=>'1===( *BI* KF/!& +3-"9E * # 5 & 2!# +4- = ) ) K:#>4 +6-#VE!- * # 'B*$>4(2BC>4 +7-W 7(8(/ 18 *"#:>6 +?-V#/ * #,64,6?K=, 4:$ * # 7* '*Q=3(B=3 +>-V#/J# 4 0 < # # * *9=, 5 & K# F +,=-! = 4 3<30 0 K:1==4 +,,- <" & ## '<(,= B* / =3 FII!!!9 #II% +,1-5 C/* V &), 8) * # * 3 * 5 & K" 2!& :2=1 +,3- C 5 / "*/ V 0.&!& ;! V & 8 * #!* E# K" #'EK9,1+ :2=3 +,4-/ 0 ; (0. ( 0 0 < 7 $ # * # 5& '( :;=4 +,6-E!2J #E# )4 0 ( ) * # / * * # '*Q=4( 7>39?== =4

118 Sygn: A certificate based access control in Grid environments Ludwig Seitz, Jean-Marc Pierson, and Lionel Brunie LIRIS, CNRS UMR 5205, INSA de Lyon 7, av. Jean Capelle, Villeurbanne cedex, FRANCE {ludwig.seitz, jean-marc.pierson, Abstract. In this paper we study the problem of Grid access control in environments with high confidentiality requirements and a large number of users. We propose a novel access control mechanism, Sygn, that implements decentralized permission storage and management. All permissions in Sygn are encoded in certificates, which are stored by their owners and used when required. Sygn allows for decentralized administration of dynamically changing resources and permissions. Sygn also supports role based access control. Prmissions can be created on demand without the need to contact a central permission storage system. The Sygn access control servers store only minimal security critical information to minimize the impact of a successful attack. Sygn has been successfully integrated in a lightweight grid middleware. Keywords: role based access control, distributed access control, Grid access control, certificate based access control 1 Introduction Applications such as particle physics, terrestrial observation or biomedical research require lots of computing power and disk storage space. Users working on such applications often face the problem that their organization does provide them with the resources required for processing their data. Moreover projects to share resources between different partners are often confronted with the fact that heterogeneous resources require great effort to be used together. Computational Grids [1] strive to solve these problems by providing a middleware that transparently manages the various resources (data, storage capacity and processing power), hiding the heterogeneity to the end-user. Grids have been identified as a possible approach for health-care networks. Indeed in health-care increasing amounts of computerized patient data is produced and used. This data requires storage and processing. Furthermore, availability of medical data stored at remote sites can be crucial for successful treatment of a patient. Due to legal liability such networks will be of no practical use without privacy protection of the medical data, as they will not be accepted by their intended users, as long as this problem has not been dealt with. This work is partly supported by the Région Rhône-Alpes project RAGTIME and the French ministry of research ACI-GRID MEDIGRID project

119 A part of this protection has to be provided by a data access control mechanism. Members of the medical staff have different access rights to the data of the patients they are treating. These rights are typically specific to the functions they perform (doctor, nurse, secretaries etc) and not to the person herself. Some of the functions have a hierarchical permission structure (e.g. the rights of a nurse are a subset of the rights of a doctor). Consequently role based access control (RBAC)[2] is ideally suited to manage this kind of permission structure. Classical RBAC mechanisms often do not provide data access control at a finegrained level. However since the sources of authority for data are legally responsible for the privacy of the data they control, they should be in charge of access control permissions to their fine-grained data. The Grid environment creates additional challenges that have not been addressed by classical RBAC mechanisms. Grids assemble heterogeneous resources from different providers. The physical storage location of data is transparent to the users and data may be automatically replicated by the Grid infrastructure for a more effective access. Therefore a user who stores sensitive data on a Grid wants the access control to be effective for all its replicas, no matter who owns the actual storage devices. To allow users to selectively share data using the Grid, and to enable proxying the access control system must allow them to delegate access rights to other entities. The possibility to delegate access rights also makes the system more scalable, since it allows to distribute the burden of access control administration. In Grids, services have a dynamic availability. This means that a service (e.g. a storage device) may spontaneously connect to and disconnect from the Grid. This can cause consistency problems in access rights of replicated data. Furthermore precautions must be taken to deal with the case of the access control service itself becoming unavailable. Administrators of storage and computing resources want to be able to control the access to the resources they offer, or they will be reluctant to provide them on the Grid. In the case of the medical Grid, it is also necessary to be able to grant ad-hoc permissions to access data. As these permissions can be needed in emergency situations, they should not involve any time consuming administration procedures. Finally when dealing with medical data it is a legal requirement to log all accesses to these data, so that misuse can be traced and liabilities can be assigned. We can therefore summarize the requirements for an access control system in a medical Grid environment as follows: It must support role based access control. It must permit fine-grained access control on data, where the sources of authority (SOA) that may issue permissions are individual users owning the data. It must support delegation of access rights. It must keep access rights consistent for all data including all replicas of some piece of data. Rights must remain consistent even if a change occurs while replicas are unavailable. It must handle outages of the access control service itself gracefully. It must enable administrators of disk space and computing power to control access to their resources.

120 It should support ad-hoc permission granting. It must provide the traceability of all accesses to data. MEDIGRID 1 is a project funded by the french ministry of research. Its objective is to investigate the use of Grid infrastructures for health-care networks. Within this project one topic of research is the security infrastructure for medical Grids. The creation of the access control service presented here has been a part of this work. The rest of this publication is organized as follows. We present current access control systems in section 2. We then argue why these systems do not fulfill the requirements for a medical Grid access control. In section 3 we propose Sygn, an access control system designed according to above requirements. Then we discuss the Sygn approach in section 4 and finally conclude and present future work in section 5. 2 Related Work The Community Authorization Service (CAS)[3] from the Globus Alliance and the Virtual Organization Membership Service (VOMS)[4] provide conceptually similar access control services for Grids. In both approaches Virtual Organizations (VOs) are granted bulk rights to various Grid resources. Each VO uses a central server that issues subsets of the VO s rights to the VO members. Whereas the CAS server stores all authorizations concerning the VO members, VOMS only stores the group/role memberships and the local resources are expected to maintain access control lists that attribute various access rights to these groups/roles. The fact that both services centralize unprotected access control information makes them trusted third parties and potential bottlenecks. They can therefore become single points of failure, e.g. if an attacker compromises a CAS server he has access to all resources granted to the community that this CAS manages. Furthermore the fact that both services are centrally managed and that resources grant bulk rights to the VOs make fine grained data access control and ad-hoc granting of rights very difficult to manage. Akenti [5] extends the VO model of CAS and VOMS by providing a way to express and enforce access control policies without requiring a central service that administrates them. Aktenti uses signed certificates to store authorization information. This protects the information against unauthorized modification and makes it possible to store it on less secured sites. Currently Akenti uses a proprietary authorization certificate format. Similar to Akenti, the PERMIS [6] authorization infrastructure uses certificates to securely store permissions. In contrast to Akenti PERMIS relies on the X.509 attribute certificates (AC) [7] as authorization certificate format. The X.509 AC specification has some serious limits, since it discourages the use of certificate paths, which are considered too complex to administrate and process. Therefore delegation using X.509 AC paths is not supported. Furthermore, the specification states that, for each particular set of attributes, only one source of authority (SOA) may exist. These limitations make the 1

121 use of X.509 ACs questionable with respect to distributed access control of dynamic resources. Shibboleth[8] is an access control solution for web services, that uses the permission pull approach like Akenti and PERMIS. Our concern with Shibboleth is that its design assumes that the source of authority for authorizations concerning a specific user is always his home organization. Such an assumption is not necessarily true in Grids, where users may be granted different permissions from multiple sources of authority. A further general concern with Akenti, PERMIS and Shibboleth is that their Policy Decision Points (PDP) use the pull approach [9] to retrieve the necessary information for authorization decisions. In the pull approach, the PDP retrieves (i.e. pulls) the necessary authorization information itself, upon receiving an access request. It is therefore difficult for the user to enforce the principle of using the least privilege for each operation. Badly configured or malicious PDPs may pull more authorization information than necessary for a request and the user would be incapable to notice this. Shibboleth handles this problem by introducing permission release policies that can be configured by the users. However we deem this approach to be more cumbersome and less intuitive to handle than just selecting the permission you want to use for a specific request. Another drawback of the pull model is that it puts the load of retrieving the authorization information upon the PDP and does not allow to temporally decouple the authorization assertion from the actual request. We therefore think that the push approach, where the request issuer provides the necessary permissions to the PDP is more appropriate for handling ad-hoc permissions in an environment with dynamically changing resources. Cardea [10] is an access control solution for distributed systems. It is based on the standard policy language XACML [11] and the standard assertion language SAML [12] to certify authorization information. Since XACML is based on the pull model, the same concerns as for Akenti and PERMIS apply. Furthermore neither the current SAML nor the current XACML standard consider delegation of access rights. Due to this limitations we have the same concerns as for X.509 ACs with regard to XACML and SAML based systems. PRIMA [13, 14] is a Grid access control system that specifically supports ad-hoc permission granting. PRIMA is a hybrid push/pull architecture, where attributes are pushed to the PDP and general policies are pulled by the PDP. PRIMA uses XACML as policy language and X.509 ACs for authorization. However the designers of PRIMA have created a workaround to enable delegation within those standards. PRIMA maps the data access permissions of a user to local POSIX.1E file system access control lists or Grid Access Control Lists[15]. This approach makes it more difficult to realize the Grid paradigm of integrating heterogeneous systems, since it requires one of those specific systems to be deployed at operating system level on all hosts participating in the Grid architecture. SPKI[16] is an IETF proposal for a simple public key infrastructure focused on authorization. It introduces a simple format for authorization certificates. An access control list (ACL) that is co-located with each resource specifies the public keys of the sources of authority (SOAs) for this resource. These SOAs may issue permissions on

122 the resource and authorize other users to delegate them. SPKI uses public keys as a means to identify entities and to create unique namespace identifiers. Furthermore it specifies a delegation mechanism through chains of certificates and details tuple reduction rules to produce an authorization decision out of such a certificate chain. Work on SPKI standardization has ceased since 2001 and thus important questions such as implementation of standard RBAC using SPKI have not been addressed. Our proposal takes up several ideas of SPKI as described in 3. None of the presented systems specifically addresses our requirements of traceability and consistency of access rights for replicated data. 3 System design This section presents the design of Sygn 2. It is subdivided as follows: Subsection 3.1 presents the fundamental design approaches of Sygn. Subsection 3.2 explains the structure of a Sygn permission certificate. The semantics of a permission certificate are explained in subsection 3.3. In subsection 3.4 we present how a Sygn server is set up. Finally subsection 3.5 describes how the system processes a request to generate an access decision. 3.1 Fundamental design approaches Sygn supports the concept of roles based on the NIST standard for RBAC [17]. A role is a collection of permissions, that are required to perform a task. Roles are assigned to entities that may activate them selectively to make use of the role permissions. Sygn leaves the semantics of a role (i.e. the task it allows to execute) to the discretion of the role SOA. Any user can create new roles and to select the SOA for this new role in Sygn. An entity that is SOA for a specific permission can assign it to any existing role without intervention of the role s SOA. When a role is created in Sygn it must specify a repository, where the permissions assigned to the role are stored for review purposes. These repositories are used to support the review functions required by standard RBAC. Sygn also supports the concept of hierarchical roles. A role may be assigned to be hierarchically inferior to some other role by its SOA. This means that the superior role inherits all permissions given to the inferior role. To permit a separation of duties, Sygn allows to specify restrictions on each roleto-user assignment. These restrictions specify other roles that may not be activated in the same request together with this role. As the verification of these restrictions is done during the access request, this corresponds to what the RBAC standard calls Dynamic Separation of Duties. 2 Sygn is a name that comes from the Nordic mythology. It designs a goddess of truthfulness but also of doors and locks

123 In order to allow an individual fine-grained access control, Sygn uses authorization certificates (AC) for permission granting and delegation. SOAs can thus grant access to their resources by issuing digitally signed ACs. To allow permission consistency in presence of replicas we have opted for a permission push model, where the users store all their permissions themselves. This allows users to use the same permissions on any replica of a file, provided that the replica identifier is the same as the one of the original file. Furthermore, this architecture supports ad-hoc granting of permissions. SOAs can directly give permissions to users, without intervention of any third-party permission storage system. However the push model requires a permission revokation scheme. Thus every Sygn access control server maintains a list of revoked ACs. These lists are updated regularly by consulting redundant certificate revocation services. To prevent failures of the access control due to service outages, our design deploys the access control services locally on the resource sites. Therefore the access control for a site will only be unavailable when the site itself is also offline. Sygn allows local administrators of resource sites providing storage space and computational capacity to control the access to their resources. This requires some externally measured metric that evaluates the resource usage. The Sygn system also allows local administrators to set up blacklists of entities that may not access their resources, regardless of their permissions. To provide traceability, Sygn can be configured to create non-repudiable logs of all access requests. In this configuration, users are required to digitally sign all the requests they submit. Since our system is intended to be a scientific proof of concept we have decided not to implement standard policy languages such as XACML [11] or standard certificate formats such as SAML [12] or X.509 Attribute Certificates [7]. The justification for this choice is that these standards make the permissions hard to create, manage and read. In X.509 this is due to the ASN.1 encoding of the certificates. XACML and SAML are based on XML, provide a lot of functions and are very generic. This makes them very verbose and adds a lot of overhead to the most simple permissions. Our current proprietary permission encoding is based on XML and could be replaced by a standardized encoding format without modifying the general functionality of Sygn. Figure 1 shows the deployment and interaction of Sygn modules. In a first step a resource s SOA installs or stores a resource on a (possibly remote) resource server. Using his administration client, he contacts the resource server and registers himself as source of authority for this resource in the metadata-base of the local Sygn policy decision point (PDP). For each resource, the Sygn PDP stores only its SOA identifier. To grant access to a resource consumer (step 2) the SOA issues ACs that allow access to the resource. Note that this process involves only the SOA and the consumer(s), and can be done offline. The user stores and retrieves ACs as needed. To access the resource, the user contacts the corresponding resource server (we assume that the localisation of the correct server is realised by the Grid middleware) and submits the request that contains the required ACs as shown in step 3.

124 Fig. 1. Deployment of, and interaction between Sygn modules on a Grid. The resource server needs two different Sygn modules. The Sygn Policy Decision Point (PDP) that produces an access control decision based on the Sygn request provided by the user and a Sygn Policy Enforcement Point (PEP). The PEP interfaces the PDP with the Grid middleware and thus makes the PDP independent of specific Grid implementations. The PEP has two functions: First it has to make sure that the Sygn request corresponds to the actions the user tries to perform on the Grid (otherwise a user could submit valid ACs for one resource together with commands initiating Grid actions that concern another one). Second it uses the Grid authentication mechanisms to make sure the request issuer is the owner of the accompanying ACs. The Sygn request submitted by the user to the server contains the target resource the user wants to use and ACs authorizing access to this resource. Based on this information, the Sygn PDP decides if the Sygn request is correct and if the ACs correctly authorize this request. Sygn traceability is configured at the PDP level. If turned on, all requests are logged in the Sygn metadata-base. Non-repudiation of those logs can be achieved by another PDP configuration option, that requires timestamping and digital signature of requests by the issuer. 3.2 Structure of a Sygn permission We chose XML to represent the data structures used in a Sygn AC. The reason for this is that XML is human readable (as opposed to binary encodings such as ASN.1) which makes creation and understanding of certificates in this format easier for the users that have to deal with them. The use of XML is further facilitated by the fact that a large variety of tools supporting the use of XML exist. Basically a Sygn permission consists of: an identifier generated by calculating the SHA1-hash of the other AC data. an AC creator, an AC owner (also called the subject of the permission),

125 a capability that is given to the owner by the creator, consisting of an object and an action, validity period limits in the form of two timestamps. restrictions on the use of the permission, a delegation depth limit and an electronic signature that makes unauthorized modifications of the permission detectable 3 Figure 2 shows an example Sygn permission certificate encoded in XML. Please note that the creator of this AC is not the SOA of the file it authorized access to. Therefore to be usable in a certificate path, other ACs must be present in which the file s SOA allows the creator of this AC to delegate read permissions on the file. 00 <AUTHORIZATION_CERTIFICATE> 01 <ID>bA1lxGTYDd3eHT/gr/6B1N4dCWU=</ID> 02 <CREATOR><USER_ID>MIG...aQIBEQ==</USER_ID></CREATOR> 03 <OWNER> <USER_ID>MIG...wdUQIBEQ==</USER_ID></OWNER> 04 <CAPABILITY> 05 <CAPABILITIY_ID>8k9AiT4a...br8U=</CAPABILITIY_ID> 06 <OBJECT><UNIQUE_FILE_ID> 07 <FILE_SOA> 08 <USER_ID>MIGdMA0...j4jQIBEQ==</USER_ID> 09 </FILE_SOA> 10 <LOGICAL_FILENAME>+/A...88=</LOGICAL_FILENAME> 11 </UNIQUE_FILE_ID></OBJECT> 12 <ACTION>read</ACTION> 13 </CAPABILITY> 14 <NOT_BEFORE> T10:23:02Z</NOT_BEFORE> 15 <NOT_AFTER> T12:22:03Z</NOT_AFTER> 16 <NOT_WITH>...</NOT_WITH> 17 <DELEGATIONS>1</DELEGATIONS> 18 <SIGNATURE>qcIiRan3kpDEPi...eOtc1OV5Byw=</SIGNATURE> 19 </AUTHORIZATION_CERTIFICATE> Fig. 2. An example of an AC where the creator (line 02) grants read access (line 12) on a file (lines 06-11) to the owner of the AC (line 03), with the right to delegate this capability one step (line 17). Creator The creator of a Sygn permission must be a user identified by a public key. The corresponding private key is used for the signature of the certificate. A public key representing a user is called a user identifier (UID) in Sygn. Note that the public key is considered sufficient as unique identifier. Sygn does not associate a distinguished name 3 We currently use the RSA signature algorithm with SHA-1 hashing and PKCS1v15 padding.

126 to public keys for user identication such as it would be the case in X.509[19] certificates. Given the size of the namespace (valid public/private-keypairs) it is extremely improbable that two users will accidentially be assigned the same Uid. The concept of using public keys to represent user identities follows the SPKI approach. Sygn subjects Subjects in Sygn are users and roles. They are identified by subject identifiers (SID). SIDs are used either as owners of an AC or as SOA s of Sygn objects. A Sygn subject can either be a user represented by a UID or a role which is represented by a role identifier (RID). A RID consists of three elements: A role name, which can be any string and should describe the role in question. A role SOA of UID type, who initially is the only person that can activate the role. This implies that the SOA of a role can always use the role permissions. The third element of each role is a review repository, which specifies a repository where all permissions concerning that role should be stored. Sygn objects Objects in Sygn are always part of a capability. An object can either be a file identifier (FID), a file set identifier (FSID) referring to a collection of files, a role-object identifier (ROID) which is actually a wrapper that allows to use roles as permissions objects, or a resource identifier (RESID) that identifies a specific hardware resource (e.g. some storage device). Sygn is designed to make it easy to add new types of objects. An object is identified by two elements: An object name and the object s SOA. For file identifiers, file set identifiers and resource identifiers any type of Sygn subject can be used as SOA. Role object identifiers require the SOA to be of UID type. Sygn actions Actions are identifiers for possible actions with respect to an object. Sygn currently supports read, write, add-to-set and remove-from-set for files and file sets, activate for roles and grant for hardware resources. The grant action has an additional parameter specifying a scalar value measuring the amount of the hardware resource that is granted. New actions can be easily added if required. Sygn capabilities The capability is a compound structure, consisting of an object and an action. To be allowed to grant a capability a user must either be the object s SOA or be authorized by a valid delegation chain from the SOA. Each capability gets an identifier that is generated by calculating a SHA1 hash of the object and action data. A special type of capability allows SOA s of files or file sets to add those to another file set. Master set is specified as secondary object, after the file or set that is added to it, in this special capability type. Sygn restrictions Sygn permissions support restrictions in form of a list of RID s that may not be used in together with this AC. This makes it possible to enforce Dynamic Separation of Duties (DSD) as specified in the RBAC standard.

127 Delegation The delegation depth limit is an integer value, that specifies how many steps the AC s capability may be delegated. A limit of zero means the capability may not be delegated at all. Any limit greater than zero allow the AC owner to delegate this capability with a delegation depth limit reduced by at least one. 3.3 Semantics of a Sygn permission The meaning of a Sygn permission is mostly straightforward. If the owner of an AC is a UID then the user corresponding to the UID can use the AC s capability. However some details must be explained for the correct usage of the more powerful functions of Sygn. If a role is the SOA of an object, any user able to activate that role can act as that object s SOA. If an AC has a ROID as object, it gives the AC owner the permission to activate that role and use its permissions. If the owner of an AC is a role this means every user being able to claim activation of this role (through use of another AC) can use the AC s capability. Combined together, these two semantics implement hierarchical RBAC. This means that if a role A is subject and role B object of an AC, role A can use all permissions of role B. Role A is said to be hierarchically superior to role B. The following example illustrates this. Consider the following ACs: AC 1 permits read access on file I to role B AC 2 permits read access on file K to role A AC 3 permits activation of role B to role A Then role A is said to be hierarchically superior to role B since users who can only activate role B can only read file I while users who can activate role A can also activate role B and thus read file I and write file K. Permissions can grant file actions on file sets. Such permissions are then applicable to any file that is member of the set. In order to use such a set permissions on a specific file, the certificate adding this file to the set has to be presented. 3.4 Sygn server meta-data In this subsection we describe the necessary steps for the deployment of a Sygn server. The server relies on a database for efficient meta-data storage and access. The meta-data are critical, therefore great care should be taken when setting up the database to avoid introducing a weakness through insecure database access. Sygn servers are designed to be deployed locally at the resource sites. There Sygn server needs to have the subject-id of each SOA that has some file or hardware resource on this site. The Sygn servers provide meta-data storage to record hardware resource usage. Hardware resource SOAs can specify a value for the allowable use of their hardware resource by a user. The definition and measurement of this metric must be implemented in the Sygn PEP.

128 The server meta-data also provides storage for the ids of revoked certificates, together with their expiration date. A Sygn command permits to erase revoked certificates that have expired from the meta-data base. This function can be used to implement a certificate revocation list (CRL) mechanism to allow SOAs to invalidate ACs they issued before expiration. Finally the Sygn meta-data includes a blacklist for banning UIDs. This function can be used by the Sygn administrator to exclude users who have abused the local systems resources. Requests from a blacklisted UID will inevitably be refused, no matter what other permissions are submitted. Having set up the required meta-data the last step to make the system work is to set up the Sygn PEP that matches requests for Grid operations against the requested Sygn permissions and interprets the responses of the Sygn PDP. 3.5 Access decision process As mentioned before, Sygn is a push architecture. The ACs supporting a request must be sent to the Sygn server together with the request. The structure containing a chain of ACs supporting one request is called a path. A path grants access to a resource called the path s target. The certificates in a path must trace a valid connection from the SOA of the target to the user who issued the request. To be valid, a path must satisfy multiple conditions: All certificates in the path must be valid. A certificate is valid if it has a valid signature, it has not expired and it is not revoked. Delegation depth limits must be respected all along the path. This applies to both the delegation depth limit of the target and the delegation limits of roles granted in subpaths. The path must form an uninterupted chain from the SOA of the target resource to the user requesting access to the resource. Within this chain, there may be subchains, that activate roles to which the resource was granted or that add the resource to some set. We now explain the complex example of a path shown in figure 3. Bob is the SOA for the file document.txt. Therefore granting the target capability CAP = read document.txt to the Role A in AC 1 does not require any other supporting certificates. Carol, who is the SOA for Role A, can now use CAP. CAP is automatically transferred to Role B in AC 2. This is because in AC 2 Carol grants activation of Role A to Role B, thereby making Role B hierarchically superior to Role A. All permissions of Role A are inherited by Role B. Dave, who is the SOA for Role B grants activation of that role to Edgar in AC 3. This has the following effects: Edgar can now activate Role B. He can subsequently also activate Role A and may consequently use CAP. Edgar can now grant CAP to someone else. He does so in AC 4 granting CAP to Alice.

129 Fig. 3. A complete, correctly linked path of certificates. See explanations in section 3.5 for details. The path consisting of AC 1, AC 2, AC 3 and AC 4 therefore grants the target capability to Alice, provided that the delegation depth limits of all ACs are sufficiently highṭhe Sygn request structure permits to submit multiple paths in a single request. Such a request will be honoured if all paths turn out to be valid (regardless of the fact if it is needed or not). Using this mechanism complex operations requiring multiple permissions can be supported by the Sygn system. 4 Discussion The following points must be considered when using Sygn: Since all users store their own access permissions, there is no central access control service that could be the target of a general denial of service attack. Furthermore since the Sygn access control server runs locally on each storage site, a successful attack on such a server only deactivates access control to the local data. This minimizes the impact of such an attack comparatively to solutions like CAS or VOMS where the access control servers store a relevant amount of permissions. The decentralization of permission storage and access control servers also make Sygn more scalable by spreading the load onto multiple services. Access control decisions require no third party. Only the user and the storage site are involved. This speeds up the access decision process and eliminates the danger of corrupted third parties. Permission granting does not involve a third party either (except for storing rolerelated permissions on the review repository). The granting can be done directly between the permission issuer and the AC owner. If such a personal relation does not exist, a second possibility for distribution of Sygn ACs exists: A service like VOMS could be used to distribute Sygn ACs to members of a virtual organization. Since Sygn ACs are protected against tampering and bound to a specific entity, the former concerns against VOMS would no longer apply.

Architectures web pour la gestion de données

Architectures web pour la gestion de données Architectures web pour la gestion de données Dan VODISLAV Université de Cergy-Pontoise Plan Le Web Intégration de données Architectures distribuées Page 2 Le Web Internet = réseau physique d'ordinateurs

Plus en détail

Chacun est conscient qu il sera souvent nécessaire de mobiliser les notions abordées en première et, parfois, de les reprendre.

Chacun est conscient qu il sera souvent nécessaire de mobiliser les notions abordées en première et, parfois, de les reprendre. UE Atelier B Deux groupes de stagiaires ont suivi les exposés sur les séquences pédagogiques. Les échanges ont principalement porté sur les apports notionnels (quelles notions aborder), le bornage (jusqu

Plus en détail

Comment marche le Web?

Comment marche le Web? Comment marche le Web? Sara Alouf Chargée de Recherche, INRIA 6 décembre 2012 Lycée Henri Matisse, Vence Comment marche le Web? Introduction du Web et de l Internet Aperçu historique Comment marche le

Plus en détail

2. MAQUETTAGE DES SOLUTIONS CONSTRUCTIVES. 2.2 Architecture fonctionnelle d un système communicant. http://robert.cireddu.free.

2. MAQUETTAGE DES SOLUTIONS CONSTRUCTIVES. 2.2 Architecture fonctionnelle d un système communicant. http://robert.cireddu.free. 2. MAQUETTAGE DES SOLUTIONS CONSTRUCTIVES 2.2 Architecture fonctionnelle d un système communicant Page:1/11 http://robert.cireddu.free.fr/sin LES DÉFENSES Objectifs du COURS : Ce cours traitera essentiellement

Plus en détail

Page 1 2 La présente invention concerne le domaine des architectures informatiques, et en particulier un procédé pour le développement d applications destiné à un fonctionnement en réseau, par exemple

Plus en détail

Généralités sur les bases de données

Généralités sur les bases de données Généralités sur les bases de données Qu est-ce donc qu une base de données? Que peut-on attendre d un système de gestion de bases de données? Que peut-on faire avec une base de données? 1 Des données?

Plus en détail

REPUBLIQUE ISLAMIQUE DE MAURITANIE HONNEUR FRATERNITE JUSTICE INSPECTION GENERALE D'ÉTAT TERMES DE REFERENCE

REPUBLIQUE ISLAMIQUE DE MAURITANIE HONNEUR FRATERNITE JUSTICE INSPECTION GENERALE D'ÉTAT TERMES DE REFERENCE REPUBLIQUE ISLAMIQUE DE MAURITANIE HONNEUR FRATERNITE JUSTICE INSPECTION GENERALE D'ÉTAT TERMES DE REFERENCE POUR LA MISE EN PLACE D UN SYSTEME DE GESTION DES MISSIONS DE L IGE Liste des abréviations IGE

Plus en détail

Internet. PC / Réseau

Internet. PC / Réseau Internet PC / Réseau Objectif Cette présentation reprend les notions de base : Objectif, environnement de l Internet Connexion, fournisseurs d accès Services Web, consultation, protocoles Modèle en couches,

Plus en détail

Cloud Computing et SaaS

Cloud Computing et SaaS Cloud Computing et SaaS On a vu fleurir ces derniers temps un grands nombre de sigles. L un des premiers est SaaS, Software as a Service, sur lequel nous aurons l occasion de revenir. Mais il y en a beaucoup

Plus en détail

Partie Réseaux TD 1 : Théorie des réseaux

Partie Réseaux TD 1 : Théorie des réseaux Partie Réseaux TD 1 : Théorie des réseaux 1 Les réseaux 1.1 Qu est-ce qu un réseau? Un réseau est un ensemble d ordinateurs pouvant communiquer entre eux. 1.1.1 Types de réseaux Il y a deux types de réseaux

Plus en détail

3A-IIC - Parallélisme & Grid GRID : Définitions. GRID : Définitions. Stéphane Vialle. Stephane.Vialle@supelec.fr http://www.metz.supelec.

3A-IIC - Parallélisme & Grid GRID : Définitions. GRID : Définitions. Stéphane Vialle. Stephane.Vialle@supelec.fr http://www.metz.supelec. 3A-IIC - Parallélisme & Grid Stéphane Vialle Stephane.Vialle@supelec.fr http://www.metz.supelec.fr/~vialle Principes et Objectifs Evolution Leçons du passé Composition d une Grille Exemple d utilisation

Plus en détail

Créer et partager des fichiers

Créer et partager des fichiers Créer et partager des fichiers Le rôle Services de fichiers... 246 Les autorisations de fichiers NTFS... 255 Recherche de comptes d utilisateurs et d ordinateurs dans Active Directory... 262 Délégation

Plus en détail

L INFORMATION GEOGRAPHIQUE

L INFORMATION GEOGRAPHIQUE Champs sur Marne ENSG/CERSIG Le 19-nove.-02 L INFORMATION GEOGRAPHIQUE Archivage Le Système d information géographique rassemble de l information afin de permettre son utilisation dans des applications

Plus en détail

RECOMMANDATIONS DE SECURITE

RECOMMANDATIONS DE SECURITE PREMIER MINISTRE Secrétariat général de la défense et de la sécurité nationale Agence nationale de la sécurité des systèmes d information Paris, le 14 février 2013 N 524/ANSSI/SDE RECOMMANDATIONS DE SECURITE

Plus en détail

PLATEFORME MÉTIER DÉDIÉE À LA PERFORMANCE DES INSTALLATIONS DE PRODUCTION

PLATEFORME MÉTIER DÉDIÉE À LA PERFORMANCE DES INSTALLATIONS DE PRODUCTION PLATEFORME MÉTIER DÉDIÉE À LA PERFORMANCE DES INSTALLATIONS DE PRODUCTION KEOPS Automation Espace Performance 2B, rue du Professeur Jean Rouxel BP 30747 44481 CARQUEFOU Cedex Tel. +33 (0)2 28 232 555 -

Plus en détail

Programmation Internet Cours 4

Programmation Internet Cours 4 Programmation Internet Cours 4 Kim Nguy ên http://www.lri.fr/~kn 17 octobre 2011 1 / 23 Plan 1. Système d exploitation 2. Réseau et Internet 3. Web 3.1 Internet et ses services 3.1 Fonctionnement du Web

Plus en détail

D une part, elles ne peuvent faire table rase de la richesse contenue dans leur système d information.

D une part, elles ne peuvent faire table rase de la richesse contenue dans leur système d information. PACBASE «Interrogez le passé, il répondra présent.». Le Module e-business Les entreprises doivent aujourd hui relever un triple défi. D une part, elles ne peuvent faire table rase de la richesse contenue

Plus en détail

Architecture N-Tier. Ces données peuvent être saisies interactivement via l interface ou lues depuis un disque. Application

Architecture N-Tier. Ces données peuvent être saisies interactivement via l interface ou lues depuis un disque. Application Architecture Multi-Tier Traditionnellement une application informatique est un programme exécutable sur une machine qui représente la logique de traitement des données manipulées par l application. Ces

Plus en détail

Principes de fonctionnement d Internet

Principes de fonctionnement d Internet 1 Principes de fonctionnement d Internet L usage d Internet et des services associés s est particulièrement développé au cours de ces dernières années. En l espace d une dizaine d années, le débit, c est-à-dire

Plus en détail

Les serveurs applicatifs et les architectures Java

Les serveurs applicatifs et les architectures Java 03 Lucas Part 02 Page 179 Lundi, 20. août 2001 2:58 14 Chapitre 15 Les serveurs applicatifs et les architectures Java Nous avons vu jusqu ici, dans les chapitres précédents, que les utilisateurs accèdent

Plus en détail

Logiciels serveurs et outils d'administration pour le Web

Logiciels serveurs et outils d'administration pour le Web Introduction Le World Wide Web ou WWW, littéralement «toile d'araignée mondiale», est un système d'informations ouvert qui a été conçu spécifiquement pour simplifier l'utilisation et l'échange de documents.

Plus en détail

Je travaille à la Télé-université ou la TÉLUQ. Je crois que c est bien là toujours son nom officiel.

Je travaille à la Télé-université ou la TÉLUQ. Je crois que c est bien là toujours son nom officiel. Permettez-moi de me présenter brièvement. Je travaille à la Télé-université ou la TÉLUQ. Je crois que c est bien là toujours son nom officiel. J appartiens à la direction des Services d édition. J y ai

Plus en détail

de survie du chef de projet

de survie du chef de projet KIT de survie du chef de projet 01 1 2 3 4 5 6 04 03 07 07 03 03 LE SERVEUR LE CLIENT TECHNOLOGIE WEB CLIENT LE SERVEUR WEB TECHNIQUES & CADRE DE TRAVAIL APPLICATIONS 101 LE SERVEUR Un serveur informatique

Plus en détail

Pentaho Business Analytics Intégrer > Explorer > Prévoir

Pentaho Business Analytics Intégrer > Explorer > Prévoir Pentaho Business Analytics Intégrer > Explorer > Prévoir Pentaho lie étroitement intégration de données et analytique. En effet, les services informatiques et les utilisateurs métiers peuvent accéder aux

Plus en détail

Guide du contributeur Jahia 6.6

Guide du contributeur Jahia 6.6 DOCUMENTATION Guide du contributeur Jahia 6.6 Jahia, le CMS open source de nouvelle génération apportant à vos projets la convergence applicative (web, document, social, recherche et portail) unifiée par

Plus en détail

Les solutions décisionnelles : Ce que tout responsable informatique doit savoir concernant les besoins réels des professionnels

Les solutions décisionnelles : Ce que tout responsable informatique doit savoir concernant les besoins réels des professionnels Les solutions décisionnelles : Ce que tout responsable informatique doit savoir concernant les besoins réels des professionnels Janvier 2011 p2 Les entreprises et leurs utilisateurs ont besoin de pouvoir

Plus en détail

1 Introduction à l infrastructure Active Directory et réseau

1 Introduction à l infrastructure Active Directory et réseau 1 Introduction à l infrastructure Active Directory et réseau Objectifs d examen de ce chapitre Ce premier chapitre, qui donne un aperçu des technologies impliquées par la conception d une infrastructure

Plus en détail

La gestion du poste de travail en 2011 : Panorama des technologies

La gestion du poste de travail en 2011 : Panorama des technologies La gestion du poste de travail en 2011 : Panorama des technologies François Clémence C.R.I Université Paul Verlaine Metz UFR Sciences Humaines et Arts clemence@univ-metz.fr Olivier Mathieu C.R.I Université

Plus en détail

Groupe de travail Infrastructures de recherche

Groupe de travail Infrastructures de recherche Groupe de travail Infrastructures de recherche Note sur les particularités des infrastructures pour une recherche dans le numérique Version internet - 30/04/2015 Les plates- formes numériques, outils et

Plus en détail

Claudie Maurin GSI 09/2013 1

Claudie Maurin GSI 09/2013 1 1 2 Internet : une architecture client/serveur Le serveur : fournisseur de données Les données sont fournies par un ensemble de postes serveurs interconnectés qui abritent la base de données répartie à

Plus en détail

CONNECTIVITÉ. Options de connectivité de Microsoft Dynamics AX. Microsoft Dynamics AX. Livre blanc

CONNECTIVITÉ. Options de connectivité de Microsoft Dynamics AX. Microsoft Dynamics AX. Livre blanc CONNECTIVITÉ Microsoft Dynamics AX Options de connectivité de Microsoft Dynamics AX Livre blanc Ce document décrit les possibilités offertes par Microsoft Dynamics AX en terme de connectivité et de montée

Plus en détail

Besoin de concevoir des systèmes massivement répartis. Comment tester le système? Solution. Évaluation de systèmes répartis à large échelle

Besoin de concevoir des systèmes massivement répartis. Comment tester le système? Solution. Évaluation de systèmes répartis à large échelle Besoin de concevoir des systèmes massivement répartis. Évaluation de systèmes répartis à large échelle Sergey Legtchenko Motivation : LIP6-INRIA Tolérance aux pannes Stockage de données critiques Coût

Plus en détail

Glossaire. www.themanualpage.org ( themanualpage.org) soumises à la licence GNU FDL.

Glossaire. www.themanualpage.org ( themanualpage.org) soumises à la licence GNU FDL. Glossaire Ce glossaire contient les termes techniques et de spécialité les plus employés dans cette thèse. Il emprunte, pour certaines d entre elles, les définitions proposées par www.themanualpage.org

Plus en détail

23 mars 2005. Dossier de Presse Association Nantes-Wireless

23 mars 2005. Dossier de Presse Association Nantes-Wireless 23 mars 2005 Dossier de Presse Association Nantes-Wireless Table des matières 1 Brève présentation 1 2 Le WiFi 1 2.1 Présentation............................. 1 2.2 Légalité...............................

Plus en détail

Petite histoire d Internet

Petite histoire d Internet À la base, Internet est défini par des ordinateurs qui sont reliés entre eux grâce à des câbles, du WiFi ou encore des satellites, créant ainsi un réseau à échelle mondiale. Les ordinateurs communiquent

Plus en détail

LES OUTILS DE LA MOBILITE

LES OUTILS DE LA MOBILITE L évolution du marché des assistants personnels, ainsi que la baisse des prix, permettent désormais à un plus grand nombre d entreprises de s équiper avec des outils technologiques performants. Avec l

Plus en détail

EXIN Cloud Computing Foundation

EXIN Cloud Computing Foundation Exemple d examen EXIN Cloud Computing Foundation Édition Septembre 2012 Droits d auteur 2012 EXIN Tous droits réservés. Aucune partie de cette publication ne saurait être publiée, reproduite, copiée, entreposée

Plus en détail

Classes virtuelles : Un nouvel avantage concurrentiel pour les organismes de formation professionnelle. Rédigé par. Contact : didierb@akuter.

Classes virtuelles : Un nouvel avantage concurrentiel pour les organismes de formation professionnelle. Rédigé par. Contact : didierb@akuter. Classes virtuelles : Un nouvel avantage concurrentiel pour les organismes de formation professionnelle Rédigé par Didier Bourgeot Président du groupe Akuter Technologies Contact : didierb@akuter.com Révisé

Plus en détail

Architecture des calculateurs

Architecture des calculateurs Chapitre 1 Architecture des calculateurs 1.1 Introduction Ce paragraphe n a pas la prétention de présenter un cours d informatique. D une manière générale, seuls les caractéristiques architecturales qui

Plus en détail

Il existe actuellement plusieurs méthodes pour accéder à un serveur de contenu proche du client.

Il existe actuellement plusieurs méthodes pour accéder à un serveur de contenu proche du client. Yan Chen, Randy H. Katz, John D. Kubiatowicz. Dynamic Replica Placement for Scalable Content Delivery. In Peer-to-Peer Systems: First International Workshop, IPTPS 2002. Le domaine abordé par l article

Plus en détail

FICHE N 10 SÉCURITÉ DES DONNÉES

FICHE N 10 SÉCURITÉ DES DONNÉES L article 34 de la loi «Informatique et Libertés» impose à un responsable de traitement de prendre toutes les précautions utiles pour préserver la sécurité des données dont il est responsable, en fonction

Plus en détail

Service combinators for farming virtual machines

Service combinators for farming virtual machines Master d Informatique Fondamentale École Normale Supérieure de Lyon Sémantique du parallélisme Chantal Keller Service combinators for farming virtual machines K. Bhargavan, A. D. Gordon, I. Narasamdya

Plus en détail

Séminaire INTERNET. Nom de votre société. Séminaire Votre entreprise et INTERNET 1

Séminaire INTERNET. Nom de votre société. Séminaire Votre entreprise et INTERNET 1 Séminaire INTERNET Nom de votre société Séminaire Votre entreprise et INTERNET 1 Présentation du séminaire Introduction Historique Définitions Quelques chiffres Présentation d INTERNET Les composantes

Plus en détail

BABEL LEXIS : UN SYSTÈME ÉVOLUTIF PERMETTANT LA CRÉATION, LE STOCKAGE ET LA CONSULTATION D OBJETS HYPERMÉDIAS

BABEL LEXIS : UN SYSTÈME ÉVOLUTIF PERMETTANT LA CRÉATION, LE STOCKAGE ET LA CONSULTATION D OBJETS HYPERMÉDIAS Quatrième colloque hypermédias et apprentissages 275 BABEL LEXIS : UN SYSTÈME ÉVOLUTIF PERMETTANT LA CRÉATION, LE STOCKAGE ET LA CONSULTATION D OBJETS HYPERMÉDIAS Anne-Olivia LE CORNEC, Jean-Marc FARINONE,

Plus en détail

Sauvegarde coopérative entre pairs pour dispositifs mobiles

Sauvegarde coopérative entre pairs pour dispositifs mobiles Sauvegarde coopérative entre pairs pour dispositifs mobiles 1 Sauvegarde coopérative entre pairs pour dispositifs mobiles Ludovic Courtès, Marc-Olivier Killijian, David Powell, Matthieu Roy Sauvegarde

Plus en détail

LIVRE BLANC GÉREZ LE CONTENU ET LES DOCUMENTS DE VOTRE ENTREPRISE GRÂCE À VOTRE CRM

LIVRE BLANC GÉREZ LE CONTENU ET LES DOCUMENTS DE VOTRE ENTREPRISE GRÂCE À VOTRE CRM LIVRE BLANC GÉREZ LE CONTENU ET LES DOCUMENTS DE VOTRE ENTREPRISE GRÂCE À VOTRE CRM LIVRE BLANC GÉREZ LE CONTENU ET LES DOCUMENTS DE VOTRE ENTREPRISE GRÂCE À VOTRE CRM 2 À PROPOS Il existe deux grands

Plus en détail

«Les documents référencés ci-dessus étant protégés par les droits d auteur et soumis à la déclaration au Centre Français d exploitation du droit de

«Les documents référencés ci-dessus étant protégés par les droits d auteur et soumis à la déclaration au Centre Français d exploitation du droit de 1 2 «Les documents référencés ci-dessus étant protégés par les droits d auteur et soumis à la déclaration au Centre Français d exploitation du droit de Copie, seules les références bibliographiques peuvent

Plus en détail

INTERNET, C'EST QUOI?

INTERNET, C'EST QUOI? INTERNET, C'EST QUOI? Internet, c'est quoi? «Internet est le réseau informatique mondial qui rend accessibles au public des services variés comme le courrier électronique, la messagerie instantanée et

Plus en détail

CORBA. (Common Request Broker Architecture)

CORBA. (Common Request Broker Architecture) CORBA (Common Request Broker Architecture) Projet MIAGe Toulouse Groupe 2 1 CORBA, introduction (1/4) Les systèmes répartis permettent de créer des applications basées sur des composants auto-gérables,

Plus en détail

Rapport d activité. Mathieu Souchaud Juin 2007

Rapport d activité. Mathieu Souchaud Juin 2007 Rapport d activité Mathieu Souchaud Juin 2007 Ce document fait la synthèse des réalisations accomplies durant les sept premiers mois de ma mission (de novembre 2006 à juin 2007) au sein de l équipe ScAlApplix

Plus en détail

LES AVANTAGES DU CLOUD

LES AVANTAGES DU CLOUD 1 INTRODUCTION Toutes les entreprises ont un point en commun : la volonté d accroître leurs revenus et leur productivité. Mais beaucoup d entreprises ne profitent pas des ressources à leur disposition

Plus en détail

Introduction aux concepts d ez Publish

Introduction aux concepts d ez Publish Introduction aux concepts d ez Publish Tutoriel rédigé par Bergfrid Skaara. Traduit de l Anglais par Benjamin Lemoine Mercredi 30 Janvier 2008 Sommaire Concepts d ez Publish... 3 Système de Gestion de

Plus en détail

Introduction aux Systèmes Distribués. Introduction générale

Introduction aux Systèmes Distribués. Introduction générale Introduction aux Systèmes Distribués Licence Informatique 3 ème année Introduction générale Eric Cariou Université de Pau et des Pays de l'adour Département Informatique Eric.Cariou@univ-pau.fr 1 Plan

Plus en détail

INTERSYSTEMS CACHÉ COMME ALTERNATIVE AUX BASES DE DONNÉES RÉSIDENTES EN MÉMOIRE

INTERSYSTEMS CACHÉ COMME ALTERNATIVE AUX BASES DE DONNÉES RÉSIDENTES EN MÉMOIRE I N T E RS Y S T E M S INTERSYSTEMS CACHÉ COMME ALTERNATIVE AUX BASES DE DONNÉES RÉSIDENTES EN MÉMOIRE David Kaaret InterSystems Corporation INTERSySTEMS CAChé CoMME ALTERNATIvE AUx BASES de données RéSIdENTES

Plus en détail

TD séance n 12 Réseau Linux

TD séance n 12 Réseau Linux 1 Introduction Avant de nous lancer dans la compréhension des réseaux informatiques, nous allons essayer de prendre un peu de recul quant à la notion même de réseau. En effet, les réseaux sont omniprésents

Plus en détail

La sécurité informatique dans la petite entreprise Etat de l'art et Bonnes Pratiques (3ième édition)

La sécurité informatique dans la petite entreprise Etat de l'art et Bonnes Pratiques (3ième édition) Généralités sur la sécurité informatique 1. Introduction 15 2. Les domaines et normes associés 18 2.1 Les bonnes pratiques ITIL V3 18 2.1.1 La stratégie des services (Service Strategy) 19 2.1.2 La conception

Plus en détail

Réalisation d Applications Web Statiques

Réalisation d Applications Web Statiques Université Abdelmalek Essaâdi Faculté Polydisciplinaire - Tétouan Réalisation d Applications Web Statiques Mr. AZZOUZ Karim azzkimo@gmail.com 2013-2014 1 Plan Cours TP Exercices et TD Évaluation : * Devoir

Plus en détail

LE LIVRE BLANC Le Cloud, nouvelle source de performance pour votre entreprise. [ NetExplorer, partage de fichier et travail collaboratif ]

LE LIVRE BLANC Le Cloud, nouvelle source de performance pour votre entreprise. [ NetExplorer, partage de fichier et travail collaboratif ] LE LIVRE BLANC Le Cloud, nouvelle source de performance pour votre entreprise. [ NetExplorer, partage de fichier et travail collaboratif ] LE CLOUD, UNE NOUVELLE SOURCE DE PERFORMANCE POUR VOTRE ENTREPRISE.

Plus en détail

Les Fiches thématiques Jur@tic. Services et Logiciels à distance Cloud Computing, ASP, SaaS

Les Fiches thématiques Jur@tic. Services et Logiciels à distance Cloud Computing, ASP, SaaS Les Fiches thématiques Jur@tic Services et Logiciels à distance Cloud Computing, ASP, SaaS Les Fiches thématiques Jur@TIC 1. Le principe du «Cloud» Qu on les appelle Application Service Provider (ASP),

Plus en détail

RAPPORT FINANCIER SEMESTRIEL AU 30 JUIN 2015

RAPPORT FINANCIER SEMESTRIEL AU 30 JUIN 2015 RAPPORT FINANCIER SEMESTRIEL AU 30 JUIN 2015 Société anonyme au capital de 538 668 euros. Siege social: 5-9, rue Mousset Robert 75012 Paris. RCS Bobigny 440 014 678 Activité : Services de Télécommunication

Plus en détail

Conception des systèmes répartis

Conception des systèmes répartis Conception des systèmes répartis Principes et concepts Gérard Padiou Département Informatique et Mathématiques appliquées ENSEEIHT Octobre 2012 Gérard Padiou Conception des systèmes répartis 1 / 37 plan

Plus en détail

UltraBackup NetStation 4. Guide de démarrage rapide

UltraBackup NetStation 4. Guide de démarrage rapide UltraBackup NetStation 4 Guide de démarrage rapide Table des matières 1 Fonctionnalités... 3 1.1 Ce qu UltraBackup NetStation permet de faire... 3 1.2 Ce qu UltraBackup NetStation ne permet pas de faire...

Plus en détail

Media Streaming avec Windows 7

Media Streaming avec Windows 7 Media Streaming avec Windows 7 Après avoir parlé des nouvelles possibilités réseaux de Windows, notamment des «Homegroups», pardon, des «groupes résidentiels, voyons comment ont été intégrées les possibilités

Plus en détail

VMWare Infrastructure 3

VMWare Infrastructure 3 Ingénieurs 2000 Filière Informatique et réseaux Université de Marne-la-Vallée VMWare Infrastructure 3 Exposé système et nouvelles technologies réseau. Christophe KELLER Sommaire Sommaire... 2 Introduction...

Plus en détail

Documents musicaux à la Médiathèque de l Ircam Michel Fingerhut Directeur de la Médiathèque de l Ircam

Documents musicaux à la Médiathèque de l Ircam Michel Fingerhut Directeur de la Médiathèque de l Ircam Michel Fingerhut Directeur de la Médiathèque de l Ircam La numérisation de documents principalement sonores a débuté à l Ircam en interne et sur ressources propres lors de l établissement de sa Médiathèque

Plus en détail

Notre métier Concevoir pour les entreprises des solutions de gestion de l information sur mesure

Notre métier Concevoir pour les entreprises des solutions de gestion de l information sur mesure Présentation ISI Développement Communiqué de presse ISI Développement s.a.s. est éditeur de logiciels et développeur de solution logicielle. [re]source est une solution de gestion d Entreprise. L entreprise

Plus en détail

Guichet unique : Aperçu des nouvelles technologies au service du Citoyen (particulier et entreprise)

Guichet unique : Aperçu des nouvelles technologies au service du Citoyen (particulier et entreprise) Guichet unique : Aperçu des nouvelles technologies au service du Citoyen (particulier et entreprise) Développer la communication et le travail collaboratif pour mieux servir le citoyen Thomas Coustenoble

Plus en détail

FAQ : GUIDE DE DÉVELOPPEMENT DE L AUTOMATISATION DE LA COMMUTATION DE DATACENTER

FAQ : GUIDE DE DÉVELOPPEMENT DE L AUTOMATISATION DE LA COMMUTATION DE DATACENTER E-Guide FAQ : GUIDE DE DÉVELOPPEMENT DE L AUTOMATISATION DE LA COMMUTATION DE DATACENTER Search Networking.de FAQ : GUIDE DE DÉVELOPPEMENT DE L AUTOMATISATION DE LA COMMUTATION DE DATACENTER En favorisant

Plus en détail

Web sémantique, données libres et liées, UNT

Web sémantique, données libres et liées, UNT Web sémantique, données libres et liées, UNT Yolaine Bourda September 20, 2012 Web sémantique De nombreux documents sont présents sur le Web. Pourtant il est parfois difficile d avoir des réponses à des

Plus en détail

Gestion de données à large échelle. Anne Doucet LIP6 Université Paris 6

Gestion de données à large échelle. Anne Doucet LIP6 Université Paris 6 Gestion de données à large échelle Anne Doucet LIP6 Université Paris 6 1 Plan Contexte Les réseaux P2P Non structurés Structurés Hybrides Localisation efficace et Interrogation complète et exacte des données.

Plus en détail

Insight Software Live

Insight Software Live Insight Live INSIGHT S SOFTWARE AS A SERVICE SOLUTION www.fr.insight.com 01 30167 29 30 software Sommaire as a Service (SaaS) : une alternative? 3 L Offre de Services Insight Live 4 L Offre en détails

Plus en détail

UltimaX EDM for Microsoft Dynamics AX TM

UltimaX EDM for Microsoft Dynamics AX TM UltimaX EDM for Microsoft Dynamics AX TM Au sein d une organisation, une gestion de l information non structurée se révèle être parfois très compliquée pour l ensemble des collaborateurs. La surcharge

Plus en détail

LIVRE BLANC. Migration de Magento Community Edition MD à Magento Enterprise Edition MD

LIVRE BLANC. Migration de Magento Community Edition MD à Magento Enterprise Edition MD LIVRE BLANC Migration de Magento Community Edition MD à Magento Enterprise Edition MD INTRODUCTION La plateforme de commerce électronique Magento MD offre aux commerçants une solution complète, souple

Plus en détail

B-COMM. ERP 4 HR Access. Solutions d acquisition des temps de travail pour la gestion des temps et des activités d HR Access

B-COMM. ERP 4 HR Access. Solutions d acquisition des temps de travail pour la gestion des temps et des activités d HR Access B-COMM ERP 4 HR Access Solutions d acquisition des temps de travail pour la gestion des temps et des activités d HR Access HR Access et Kaba un partenariat à fort potentiel Depuis plus de 10 ans, nous

Plus en détail

Thème 10 : Développer un concept et une architecture technique de produit

Thème 10 : Développer un concept et une architecture technique de produit Thème 10 : Développer un concept et une architecture technique de produit Serghei Floricel et Eduardo Miranda Si vous réfléchissez encore à un moyen technique pour réaliser un produit qui fonctionne et

Plus en détail

INSTITUT NATIONAL DES LANGUES ET CIVILISATIONS ORIENTALES

INSTITUT NATIONAL DES LANGUES ET CIVILISATIONS ORIENTALES INSTITUT NATIONAL DES LANGUES ET CIVILISATIONS ORIENTALES LICENCE: LANGUES, CULTURES ET SOCIETES DU MONDE SPECIALITE : COMMUNICATION INTERCULTURELLE ET LANGUES DU MONDE (CILM) Design graphique et multimédia

Plus en détail

Le stockage. 1. Architecture de stockage disponible. a. Stockage local ou centralisé. b. Différences entre les architectures

Le stockage. 1. Architecture de stockage disponible. a. Stockage local ou centralisé. b. Différences entre les architectures Le stockage 1. Architecture de stockage disponible a. Stockage local ou centralisé L architecture de stockage à mettre en place est déterminante pour l évolutivité et la performance de la solution. Cet

Plus en détail

Internet et Programmation!

Internet et Programmation! Licence STS Informatique - Semestre 1! BUT de l enseignement:!! Comprendre une grande partie des termes utilisés dans l écriture des pages actuellement véhiculées sur le NET!! Et tendre vers une écriture

Plus en détail

Construire un annuaire d entreprise avec LDAP

Construire un annuaire d entreprise avec LDAP Construire un annuaire d entreprise avec LDAP Marcel Rizcallah Éditions Eyrolles ISBN : 2-212-09154-0 2000 Introduction L économie en réseau ou la Net-économie est au cœur des débats et des stratégies

Plus en détail

La sécurité informatique dans la petite entreprise Etat de l'art et Bonnes Pratiques (2ième édition)

La sécurité informatique dans la petite entreprise Etat de l'art et Bonnes Pratiques (2ième édition) Généralités sur la sécurité informatique 1. Introduction 13 2. Les domaines et normes associés 16 2.1 Les bonnes pratiques ITIL V3 16 2.1.1 Stratégie des services - Service Strategy 17 2.1.2 Conception

Plus en détail

Lycée Louis Vincent. Séance 1. Notions de base pour comprendre les échanges de fichiers, la publication sur le web. Lundi 17 mars 2 014 1

Lycée Louis Vincent. Séance 1. Notions de base pour comprendre les échanges de fichiers, la publication sur le web. Lundi 17 mars 2 014 1 Lycée Louis Vincent Séance 1 Notions de base pour comprendre les échanges de fichiers, la publication sur le web. 1 Contenu de la séance 1 : Le WEB: Comprendre les principes du WEB. Acquérir le vocabulaire

Plus en détail

LE RESEAU INFORMATIQUE

LE RESEAU INFORMATIQUE Sommaire LE RESEAU INFORMATIQUE Introduction Objectifs 1. Pourquoi mettre en place un réseau? 2. Définitions 3. Les modes de réseau 4. Les types de réseaux I- Configuration d un réseau LAN. 1. Outils et

Plus en détail

Vous devez IMPERATIVEMENT installer et utiliser ce navigateur

Vous devez IMPERATIVEMENT installer et utiliser ce navigateur GUIDE d utilisation Logiciels requis Les logiciels requis 3 Vous devez IMPERATIVEMENT installer et utiliser ce navigateur Mozilla Firefox (version minimum 2.0). L utilisation du navigateur Mozilla Firefox

Plus en détail

Le Web Sémantique Une Vue d Ensemble

Le Web Sémantique Une Vue d Ensemble Le Web Sémantique Une Vue d Ensemble Serge Linckels Université du Luxembourg, FSTC, 25 octobre 2004 Un Week-End à Paris Je cherche un hôtel à Paris. Les chambres doivent être équipées d un poste de télévision

Plus en détail

CHAPITRE 1 : CONCEPTS DE BASE

CHAPITRE 1 : CONCEPTS DE BASE CHAPITRE 1 : CONCEPTS DE BASE 1.1 C est quoi l INTERNET? C est le plus grand réseau télématique au monde, créé par les Américains et issu du réseau ARPANET (Advanced Research Projects Agency ). Ce dernier

Plus en détail

Business & High Technology

Business & High Technology UNIVERSITE DE TUNIS INSTITUT SUPERIEUR DE GESTION DE TUNIS Département : Informatique Business & High Technology Chapitre 3 : Le web dans l entreprise Sommaire Introduction... 1 Intranet... 1 Extranet...

Plus en détail

Projet ORI-OAI Outil de Référencement et d Indexation Réseau de portails OAI. Strasbourg, 21 novembre 2007

Projet ORI-OAI Outil de Référencement et d Indexation Réseau de portails OAI. Strasbourg, 21 novembre 2007 Projet ORI-OAI Outil de Référencement et d Indexation Réseau de portails OAI Strasbourg, 21 novembre 2007 Sommaire Introduction Contour fonctionnel Raymond Bourges Université de Rennes 1 Concepts François

Plus en détail

Système d archivage électronique

Système d archivage électronique Les Mémos du CR2PA Système d archivage électronique Comment le choisir? Le bon progiciel d archivage, c'est celui qui répond à la fois à vos besoins et aux exigences légales et/ou réglementaires régissant

Plus en détail

Logiciel d analyse du monde des objets connectés intelligents

Logiciel d analyse du monde des objets connectés intelligents Logiciel d analyse du monde des objets connectés intelligents Le défi : Transformer les données en intelligence décisionnelle Le logiciel SkySpark analyse automatiquement les données issues des équipements

Plus en détail

Services réseau. 6.1 Clients, serveurs et leur interaction. 6.1.1 Relation client-serveur

Services réseau. 6.1 Clients, serveurs et leur interaction. 6.1.1 Relation client-serveur Page 1 sur 35 Services réseau 6.1 Clients, serveurs et leur interaction 6.1.1 Relation client-serveur Tous les jours, nous utilisons les services disponibles sur les réseaux et sur Internet pour communiquer

Plus en détail

Fiches micro-informatique SECURITE LOGIQUE LOGIxx

Fiches micro-informatique SECURITE LOGIQUE LOGIxx Objectif Fiches micro-informatique SECURITE LOGIQUE LOGIxx Présenter des préconisations pour sécuriser le poste de travail informatique et son environnement sous forme de fiches pratiques. Public concerné

Plus en détail

IBM Cognos TM1. Fiche Produit. Aperçu

IBM Cognos TM1. Fiche Produit. Aperçu Fiche Produit IBM Cognos TM1 Aperçu Cycles de planification raccourcis de 75 % et reporting ramené à quelques minutes au lieu de plusieurs jours Solution entièrement prise en charge et gérée par le département

Plus en détail

INITIATION AU SYSTEME D EXPLOITATION WINDOWS 2000

INITIATION AU SYSTEME D EXPLOITATION WINDOWS 2000 INITIATION AU SYSTEME D EXPLOITATION WINDOWS 2000 Introduction : Initiation à la Micro- Informatique 1. Matériel 2. Périphériques a) Le clavier b) La souris c) L écran d) L unité centrale e) L imprimante

Plus en détail

COMMUNICATION ET LA GESTION DE L INFORMATION CE QUE JE DOIS RETENIR

COMMUNICATION ET LA GESTION DE L INFORMATION CE QUE JE DOIS RETENIR 6 - Les en TECHNOLOGIE 6 ème Nom : Prénom : groupe : page 1/5 CONNAISSANCES : Serveurs. Postes de travail. Terminaux mobiles. Périphériques. Logiciels. Acquisition et restitution des données. Stockage

Plus en détail

Microsoft Office system 2007 16 Février 2006

Microsoft Office system 2007 16 Février 2006 Microsoft Office system 2007 16 Février 2006 Attendu d ici la fin de l année 2006, Microsoft Office system 2007 inclut des applications, serveurs et services innovants et perfectionnés. Il a été conçu

Plus en détail

Comment obtenir Internet?

Comment obtenir Internet? Historique A la fin des années 60, le département américain de la Défense crée Internet (baptisé Arpanet à l époque) afin d établir entre tous les centres stratégiques des liens qui resteraient opérationnels,

Plus en détail

Mode d emploi. www.itycom.com/itystudio

Mode d emploi. www.itycom.com/itystudio Mode d emploi www.itycom.com/itystudio Sommaire Glossaire Introduction 6 Qu est ce qu ITyStudio? 6 A qui est-il destiné? 6 Le concept 7 Fonctionnement Global 8 Interface générale 9 Header 9 Création d

Plus en détail

Présentation Internet

Présentation Internet Présentation Internet 09/01/2003 1 Sommaire sières 1. Qu est-ce que l Internet?... 3 2. Accéder à l Internet... 3 2.1. La station... 3 2.2. La connection... 3 2.3. Identification de la station sur Internet...

Plus en détail

Revue scientifique en ligne

Revue scientifique en ligne Revue scientifique en ligne Projet NTIC Cyril Nghiem Semestre de printemps 2014 Travail supervisé par Messieurs Luka Nerima et Asheesh Gulati Tables des matières Contenu Introduction... 2 Diagramme UML

Plus en détail