Espace de travail collaboratif pour un environnement de grille pervasive

Transcription

1 Université de Sciences et Techniques de Franche Comté Département d informatique Rapport de stage Master informatique 2ième année Maître de stage : Dr. Nabil ELMARZOUQI Tuteur universitaire : Prof. Jean-Christophe LAPAYRE Espace de travail collaboratif pour un environnement de grille pervasive Thomas TISSOT Penang, le 28 mai 2010

2

3 Remerciements Je tiens d abord à remercier sincèrement le personnel du Grid Computing Laboratory (GCL) qui a accepté de m accueillir en stage pendant quatre mois et particulièrement Dr. Nabil ELMARZOUQI qui m a suivi, aidé et conseillé dans la réalisation des tâches qui m ont été confiées. Je suis également très reconnaissant envers Dr. MADYA CHAN HUAH Yong, fondateur du Grid Computing Laboratory, qui a bien voulu m accepter au sein de son laboratoire. Je remercie particulièrement M. Jean-Christophe LAPAYRE, qui a supervisé mon stage et m a permis de pouvoir réaliser ce stage à l étranger. Enfin, Je voudrais également remercier les personnes travaillant au laboratoire qui m ont accueilli avec gentillesse et dont j ai eu beaucoup de plaisir à rencontrer et qui m ont aidé à m intégrer au sein du laboratoire. 3

4 Table des matières Remerciements 3 Introduction 7 1 Présentation de l environnement de travail Penang, Malaise Le Grid Computing Laboratory Les projets de recherche Virtual Distributed DataBase Managment System Mobile Desktop Grid Le projet erobory Présentation Organisation du travail Cahier des charges L espace de travail : workspace Le Virtual Group Space Les outils Technologies utilisées Java Agent Developement Environment Java Message Service Javaspaces JavaFX PostgreSQL Mise en œuvre Montée en compétence Les éléments de la plateforme L utilisateur Le VGSManager Le VGS Les outils L interface utilisateur Les tests L intégration Améliorations 32 6 Bilan Bilan technique Bilan humain Table des illustrations 35 4

5 Listing 36 Glossaire 37 Bibliographie 38 Annexes 41 Resumé 42 5

6 Introduction Dans le cadre de la deuxième année de Master informatique à l université des Sciences et Techniques de Franche-Comté, Besançon, chaque étudiant doit effectuer un stage en entreprise d une durée minimum de seize semaines indispensable pour l obtention du diplôme. Ce stage verra son aboutissement lors de la soutenance orale programmée début juin J ai choisi d effectuer mon stage à l étranger afin de vivre une expérience différente. J ai donc réalisé ce stage au sein du Grid Computing Laboratory (GCL) dont les locaux sont situés sur l île de Penang en Malaisie, plus précisément au centre de l Universiti Sains Malaysia (USM). Ce laboratoire travaille principalement sur des solutions se reposant sur les grilles informatiques. Une grille informatique (en anglais, grid) est une infrastructure virtuelle constituée d un ensemble de ressources informatiques potentiellement partagées, distribuées, hétérogènes, délocalisées et autonomes. Une entité est définie comme ressource informatique à partir du moment où elle permet l exécution d une tâche ou de stocker des données numériques. Ainsi un téléphone mobile est aussi bien une ressource informatique qu une imprimante réseau ou encore un ordinateur personnel. L architecture et le concept de grille informatique apparaissent comme étant prometteurs pour plusieurs raisons. Tout d abord sa capacité à faire un usage plus rentable des ressources informatiques. En effet, il est peu courant qu un utilisateur lambda utilise dans sa totalité une station de travail. L idée est alors d utiliser les ressources non utilisées dans le cadre d une grille. Les grilles informatique sont également un moyen de résoudre les problèmes qui ne peuvent pas être résolu sans avoir une puissance de calcul suffisante. En effet ce genre de grilles, appelées grille de calcul, suggère que les ressources de plusieurs ordinateurs peuvent collaborées en vue de la réalisation d un objectif commun. Cette répartition des tâches laisse entrevoir une plus grande disponibilité de la grille informatique contrairement à d autres architecture plus classique. Durant ce stage, j ai été amené à travailler dans un environnement hautement distribué basé sur le principe des grilles informatiques. Il existe plusieurs moyens de programmer dans une grille. Une des solutions consiste à utiliser MPI (Message Passing Interface). Conçu en 1993, MPI est une norme définissant une bibliothèque de fonctions, utilisable avec les langages C et Fortran. Elle permet d exploiter des ordinateurs distants ou multiprocesseur par passage de messages. Il existe bien sûr des alternatives comme Parallel Virtual Machine (PVM). Cette dernière est une bibliothèque de communication (langages C et Fortran) pour machines parallèles et réseau d ordinateurs (locaux ou distants, éventuellement hétérogènes). Cette bibliothèque permet à un réseau d ordinateurs d apparaître comme un seul ordinateur, appelé machine virtuelle. Cette fusion est également possible grâce aux principes multi-agents notamment avec l utilisation de la bibliothèque Jade (Java Agent DEvelopment Framework) écrite entièrement en Java. C est avec cette dernière que j ai travaillé. 6

7 Au cours de ce rapport, je commencerai d abord par vous présenter plus précisément le laboratoire ainsi que quelques uns de ces travaux. Je vous présenterai par la suite le projet sur lequel j ai travaillé en vous en précisant les objectifs. Après quoi, je vous exposerai de la façon dont s est passée la mise en œuvre de ceux-ci. Enfin, ce rapport se terminera par un bilan de mon stage. 7

8 Chapitre 1 Présentation de l environnement de travail Ces seize semaines de stage ce sont déroulés au sein du Grid Computing Laboratry en Malaisie. 1.1 Penang, Malaise La Malaisie, anciennement la Fédération de Malaisie, est un pays d Asie du Sud-Est, constitué de la Malaisie péninsulaire ou Malaisie occidentale (péninsule Malaise) et de la Malaisie orientale (nord de Bornéo). Elle est situé à environ 200 km au nord de l équateur. Sa capitale est Kuala Lumpur et sa superficie est égale à km 2. Le pays compte, en 2010, environ 26.5 millions d habitants. Le nom de Malaisie vient de Malais, qui désigne le groupe ethnique majoritaire (62%) du pays pratiquant l islam d obédience sunnite. Les Malais ne sont pas les uniques citoyens de la fédération. Il y a environ 25% de Malaisiens d origine chinoise et 10% d origine indienne. La communauté chinoise, quant à elle, pratique un mélange de christianisme, de bouddhisme, de taoïsme et de culte des ancêtres. Les Indiens sont, pour la plupart hindous. On trouve aussi des chrétiens et des animistes, principalement au Sarawak et au Sabah. Figure 1.1 Penang dans le monde Penang (en malais Pulau Pinang) est une île de 293km 2 sur la côte Nord-ouest de la Péninsule Malaise. C est également le nom de l un des États de Malaisie dont le chef lieu est Georgetown nommé de la sorte en l honneur au roi Georges III d Angleterre. L état de Penang est la zone la plus peuplé juste après Kuala Lumpur. Penang est également le seul état de Malaisie sans majorité malaise. 8

9 1.2 Le Grid Computing Laboratory Les locaux du Grid Computing Lab sont situés au sein de l université de Penang, l USM (Universiti Sains Malaysia). 1.3 Les projets de recherche Le GCL travail sur plusieurs projets simultanément. Certains sont encore à l état de recherche tandis que d autre sont actuellement en phase de développement. Voici quelque uns de ces projets dans cette deuxième phase Virtual Distributed DataBase Managment System L accès, la gestion, l interrogation et la programmation d un système de base de données sont normalement dépendant du type de la base de données, des normes et des conventions définies par l éditeur de base de données. Il en va de même pour le langage qui utilisé pour définir la requête. Actuellement, le Système de Base de Données Relationnel (SGBDR) est l un des système de base de données le plus largement utilisé. Les requêtes sur ce type de bases de données, sont généralement effectuées en utilisant un langage nommé Structured Query Language (SQL). Les SGBDR sont actuellement développé par plusieurs fournisseurs. Parmi ceux-ci ont peut citer Microsoft, Sun Microsystem ou encore Oracle. Cependant, tous ces fournisseurs ont leur propre méthode et conventions sur la façon dont les utilisateurs doivent accéder au système de base de données. Cette convention est définie comme un ensemble de la procédure de programmation appelé API. Ces différences causent, pour un développeur, le nécessité d apprendre beaucoup d API différentes s il souhaite utiliser des SGBD de plusieurs fournisseurs. Le SQL est un langage normalisé. Toutefois, l ensemble de commande standard n est normalement pas suffisant pour un fournisseur de base de données. Par conséquent, ces derniers ajoutent des extensions à ce langage permettant à l utilisateur d utiliser plus efficacement leur SGBD. Toutes ces extensions obligent un administrateur ou un développeur d apprendre et de connaître une multitude de commande SQL non standard. En outre, certains fournisseurs, mettent également à disposition une API personnalisée qui peut-être utilisée si le développeur souhaite un accès encore plus efficace à son SGBDR. De plus, effectuer des requêtes entre deux SGBD, installés sur des machines différentes et créer par deux fournisseurs différents, serait impossible en raison du fait que les fournisseurs utilisent leur propres protocoles pour la communications entre leur SGBD et le client. Aussi, seulement peu de fournisseurs, tels que IBM ou Oracle, permettent d effectuer des requêtes distribuées entre plusieurs hôtes. Le projet Virtual Distributed DataBase Managment System (VDDBMS) vise à fournir une couche de compatibilité entre les différentes implémentations de SGBDR et les utilisateurs finaux. L objectif principal est de permettre des requêtes distribuées entre deux ou plusieurs SGBDR auprès de fournisseurs différents avec le même SQL et l API. 9

10 Figure 1.2 Architecture du projet VDDBMS Mobile Desktop Grid Les capacités d une une organisation ou un d un simple individu à investir dans de puissantes machines de calcul sont toujours limitées à cause de l aspect financier. Grâce au projet Mobile Desktop Grid (MDG), les organisations possédant une grande puissance de calcul peuvent les mettre à disposition d un plus large public. Pour cela, il suffit simplement d enregistré son cluster ou ses machines à partager auprès du MDG server. Le projet MDG apporte donc une solution au problème de puissance de calcul. La solution MDG possède un système centralisé d authentification des utilisateurs, de recrutement de clusters externes ainsi que d allocation de ressources pour une tâche donnée. Elle dispose également d une plateforme de partage de connaissance permettant au chercheurs de se tenir au courant de l avancement de recherche dans des domaines particuliers. 10

11 Chapitre 2 Le projet erobory Le projet erobory est un des nouveaux projet du laboratoire. 2.1 Présentation Le projet erobory débuté récemment est l initiative du Dr. Nabil ELMARZOUQI. Ce projet de recherche fait suite à plusieurs travaux de recherches élaborés et approuvés par le biais d une thèse et de plusieurs publications internationales sur les systèmes distribués, les réseaux ainsi que les grilles informatique entre deux laboratoires de recherche : Laboratoire d Informatique de l Université de Franche-Comté (LIFC) en France et le Grid Computing Laboratory (GCL), en Malaisie. Le but du projet consiste en un réseau de ressources diverses, permettant à des utilisateurs de travailler de manière collaborative dans un monde non pas virtuel mais réel. erobory tire parti de robots, d une infrastructure sous forme de grille, d un environnement de travail collaboratif ainsi que des techniques de télé-présence. Deux types d acteurs sont supportés par la plateforme : les utilisateurs (humains) et les robots. Actuellement ces derniers ont été créer en utilisant des LEGO mindstorm. Les robots ne sont pas autonomes. Ils sont contrôlés, de manières distantes, par les humains. Un des objectifs du projet est de permettre l accès au robot et l utilisation de service à partir de n importe quel support, aussi bien depuis une application de bureau ou pour téléphone mobile, que depuis une page internet. Le but de ce stage est de développer une première version de la plateforme erobory. Ce projet étant conséquent, il est découpé principalement en trois parties auxquels viendront se greffer, par la suite, d autres fonctionnalités (voir fig.2.1). Figure 2.1 Architecture de la plate-forme erobory La partie contrôle à distance a déjà été réalisé par deux étudiants. Cependant, le programme n est pas utilisable dans un environnement de type grille informatique. A cette librairie, il est également demandé d ajouter des fonctionnalités supplémentaires comme le choix d un algorithme spécifique pour le contrôle d un robot. De plus, le programme n a pas été conçu de manière souple. C est à dire qu il 11

12 est impossible de rajouter un nouveaux type de capteurs sans avoir besoin de modifier le code source du programme. Le fonctionnement de la plateforme reposera sur les services proposés par des ressources. Ces ressources peuvent être des robots ou encore des périphériques réseaux tels que scanner ou imprimante. Cependant, la première version de ce projet ne prendra en compte que les robots. Ces ressources offrent de services (relevé de température, capteur de son etc.). Tous ces services seront enregistrés au sein de la plateforme erobory et organisé de sorte à accéder rapidement à un service et à une ressource. Et enfin la partie Espace de travail collaboratif consiste, entre autre, à réunir les deux parties précédentes et d offrir une interface utilisateur multi-plateforme permettant le travail collaboratif. Les deux premières parties ne seront pas abordées dans ce rapport. Ces dernières ont été réalisées, respectivement par, Tony ROUSSEL et Gwenaël CRUSSON. Ce rapport ce concentrera donc sur la dernière partie du projet. 2.2 Organisation du travail Mon travail durant ce stage s est porté sur trois tâches : Étudier les technologies qui seront utilisées tout au long du projet, ainsi que étudier les différentes architecture logicielle existante pour des applications collaboratives. Concevoir la partie traitement de l application collaborative. Concevoir une interface graphique permettant la manipulation d espace virtuel. Le diagramme de gantt de la figure 2.2 présente la répartition de mon travail tout au long du stage : Figure 2.2 Répartition des tâches durant le stage Deux réunions sont organisées chaque semaine avec tous les membres du laboratoire. La première à lieu le mercredi. Elle a pour but d uniformiser les connaissances de chacun sur une technologie donnée. La seconde, plus technique, à pour but de faire part aux membres de l avancement du projet, et du plan de la semaine à venir. 2.3 Cahier des charges L espace de travail : workspace L espace de travail collaboratif (Collaborative Workspace) permet l utilisation collective ou individuelle de connaissances, services, outils ou ressources. Il fournit les moyens nécessaires pour rendre l échange d informations possible au sein du système collaboratif. En utilisant un espace de travail, chaque utilisateurs peut accéder à des ressources, services et charger les outils nécessaires à la réalisation d un objectif commun. L espace de travail collaboratif permet aux différents utilisateurs de travailler ensemble en tant qu équipe virtuelle afin de développer une stratégie permettant l accomplissement d une ou plusieurs tâches en accord avec un objectif commun et ce quelque soit leur logiciel, leur infrastructure réseau, leur situation géographique, grâce à une interface graphique : leur espace de travail. 12

13 Afin que l espace de travail soit le plus adapté au travail de l utilisateur, ce dernier peut choisir de charger selon trois modes différents. Local (LW) : L utilisateur ne peut que travailler seul. Distant (RW) : L utilisateur peut faire demander de l aide à un autre personne afin d accomplir son travail. Collaboratif (CW) : Plusieurs utilisateurs, en général plus de deux, peuvent se rencontrer pour travailler ensemble pour la réalisation d un objectif commun Le Virtual Group Space Nous introduisons la notion de Virtual Space Group (VGS) comme un élément fondamental de notre espace de travail. Un VGS peut être utilisé par plusieurs utilisateurs comme un point de rencontre virtuel pour les aider à travailler ensemble. Il offre un lieu de rencontre pour partager, explorer, stocker et récupérer des informations se présentant sous plusieurs format. Par conséquent, un espace de travail tolère une multitude de VGS simultanément, eux-mêmes utilisés par zéro ou plusieurs utilisateurs. Un VGS étant une zone de travail permanente, même si aucun utilisateur ne travail dans ce VGS, ce dernier restera actif tant que la personne à l origine de se création n en demande pas sa fermeture de manière explicite. Chaque utilisateurs peuvent travaillé dans de différents VGS en même temps. Tout comme l espace de travail, le VGS peut-être configuré en fonction du travail de l utilisateur. Pour cela trois modes on été défini : Coordination : Permet uniquement le travail personnel. Coopération : Permet le travail personnel ainsi que le travail assisté par une autre personne Collaboration : Permet le travail entre plusieurs membres d un même VGS. Lorsque l utilisateur voudra utiliser l espace de travail collaboratif, il devra au préalable d identifier auprès de la plateforme erobory. Pour cela chaque acteurs bénéficie d un nom d utilisateur et d un mot de passe. Cette identification pour le moins basique sera plus tard renforcée par l authentification via des certificats. Cependant, nous n allons pas abordés ce point dans ce rapport. La correspondance entre le le nom d utilisateur et le mot de passe sera vérifiée à l aide d une base de données. Ce dernière permettra se stocker les préférences de l utilisateurs, les ressources et services auxquels il a accès ou encore les groupes auxquels il appartient. Au moment de l identification, l utilisateur devra choisir quel type de workspace il souhaite utiliser. Ce choix impactera le type de VGS que l utilisateur peut rejoindre et créer. Le tableau 2.1 récapitule tous les modes disponibles en fonction du type de workspace. Workspace Coordination Cooperation Collaboration Utilisateurs Local Oui Non Non 1 Distant Oui Oui Non 1..n Collaboratif Oui Oui Oui 1..n Table 2.1 Correspondance Workspace / VGS Un VGS est créer par un utilisateur, qui deviendra dès lors le maître du VGS. Ce dernier inclus toutes les ressources nécessaires pour la réalisation de l objectif du groupe. Chaque utilisateur peut travailler sur VGS utilisant une instance de l espace de travail et en choisissant l un des trois niveaux de travail collaboratif : coordination, coopération et collaboration. De plus, comme précisé plus haut, un utilisateur peut travailler dans plusieurs VGS à la fois. Ces derniers peuvent avoir des niveaux de collaboration différents. Si besoin est, le maître du VGS peut à tout moment changer le niveau de collaboration. En mode Coordination, un utilisateur peut accéder à tous les objets partagés (documents, vidéos, diagrammes etc.) d un VGS ainsi qu aux objectifx de ce dernier. Chaque utilisateur travaille de leur côté et mettent un commun leur travail. Le mode Cooperation permet quand à lui une relation one-to-one entre deux acteurs. La plupart du temps, ce mode permettra à un expert d aider une personne dont les connaissances sont moins avancés dans un domaine particulier. En enfin, le mode Collaboration plusieurs acteurs du VGS sont fortement impliqué dans un travail. 13

14 2.3.3 Les outils Un VGS n est qu un espace virtuel dans lequel un ou plusieurs utilisateurs peuvent travaillé. Ce n est quand quelque sorte une coquille vide. Le principe est alors de pouvoir greffer au VGS une série d outils permettant le travail aussi bien individuel que collaboratif. Un outil est un programme indépendant ajoutant des fonctionnalité à un VGS. Par défaut, un outil est présent dans tout les VGS, à savoir l outil de partage et de stockage de documents. Plusieurs manières d ajouter un outil dans l espace virtuel ont été considérés. La première méthode est assez naïve. Elle consiste pour l utilisateur à télécharger les outils, sous forme de fichier JAR 1, qu il souhaite utiliser puis lors de la création demander à ce ses outils soit incorporer dans le VGS. Cependant, cette solution comporte plusieurs problèmes. Tout d abord le fait que l utilisateur ait besoin de télécharger, et donc de stocker, l outil. En effet, le but du projet étant de construire une application disponible aussi bien sur des appareils mobiles qu ordinateur. De ce fait, il se peut que la mémoire de l appareil soit limité et donc que le stockage de plusieurs outils soit impossible. La deuxième est assez naturelle. Un utilisateur apporte un outil installé sur son propre terminal et tout les membres du VGS peuvent l utiliser. Cette solution règle en partie le problème ci-dessus puisque tout les membres du VGS pour bénéficier des outils proposer par les autres membres. Cependant, un problème persiste dans cette solution ainsi que dans la précédente. En effet, les outils étant stockés sur le terminal de l utilisateur, si celui-ci vient à changer de station alors il perdra toute sa configuration. La méthode actuelle repose sur un système dit centralisé. Tout les VGS ont accès à ces outils. De ce fait l utilisateur n a plus besoin de télécharger les outils. En fonction du mode dans lequel est lancé l espace de travail ainsi que le niveau de collaboration du VGS, l utilisateur aura accès à plus ou moins de fonctionnalité. Le but de ce projet est donc de réaliser un espace de travail collaboratif dont le fonctionnement est basé sur des espace virtuel (VGS). 1. JAR : Java Archive File 14

15 Chapitre 3 Technologies utilisées 3.1 Java Agent Developement Environment Jade est un logiciel libre distribué par TILab en Open Source avec une licence LGPL. Jade a pour but de simplifier le développement des systèmes multi-agents tout en fournissant un ensemble complet de services et d agents conformes aux spécifications FIPA. Figure 3.1 Logo de jade La plate-forme d agents de Jade inclut tous les composants obligatoires qui contrôlent un Système Multi-Agents (SMA). Ces composants sont : AMS (Agent Management System) qui fournit le service de nommage (pour assurer par exemple que chaque agent possède un identifiant unique dans la plateforme) et qui représente l autorité de la plateforme (par exemple il est possible de créer/arrêter des agents en envoyant des requêtes à l AMS) DF (Directory Facilitator) qui fournit un système de pages jaunes qui permet aux agents de retrouver les agents fournisseurs de services. ACC (Agent Container Controller) qui est l environnement dans lequel les agents peuvent vivre. Toute la communication entre agents est exécutée par messages ACL (Agent Communication Language). Pour chaque agent, JADE crée et contrôle une file d attente des messages entrants. La plate-forme d agents peut être répartie sur plusieurs serveurs. Une seule application Java, et donc une seule machine virtuelle de Java (JVM), est exécutée sur chaque serveur. Chaque JVM est un conteneur d agents qui fournit un environnement complet pour l exécution d agents et permet à plusieurs agents de s exécuter en parallèle sur le même serveur. Cet environnement profite de la technologie multi-thread offerte par Java. En effet chaque agent sera executé dans un thread différent. Tout les comportements (behaviors) qui seront associés à un agent en particulier seront executés dans le même thread à moins de le spécifier explicitement. 15

16 Figure 3.2 Architecture d une plateforme multi-agent De plus, la plateforme Jade met à dispositions des développeurs plusieurs agents intéressants pour le monitoring et le débuggage d un système multi-agents. En voici quelques-uns : Remote Agent Monitoring La plate-forme d agents fournit une interface graphique utilisateur (GUI) pour la gestion à distance des agents RMA (Remote Management Agent), surveillant le statut des agents, permettant par exemple d arrêter et de remettre en marche des agents. Le GUI permet également de créer et de lancer un agent sur un serveur à distance, à condition qu un conteneur est été préalablement démarré. Sniffer Agent L agent Sniffer permet de suivre des messages échangés au sein de la plate-forme. Quand l utilisateur décide de renifler un agent, ou un groupe d agents, chaque message dirigé vers ou venant de cet agent, ou du groupe, est dépisté et montré dans la fenêtre de Sniffer. (fig.3.3) L utilisateur peut alors sauvegarder, charger chaque message pour une analyse postérieure. Figure 3.3 Authentification auprès du VGSManager Introspector agent L agent Introspector permet de surveiller et de commander le cycle de vie d un agent courant ainsi que ses messages échangés (provenant de la file d attente des messages envoyés et reçus). 16

17 Figure 3.4 Monitoring de l AMS 3.2 Java Message Service Bien que non-adopté dans la version actuellement développé, la technologie Java Message Service a été considérée plusieurs fois. Nous évoquerons ces raisons dans la partie relative à la mise en œuvre du projet. JMS, acronyme de Java Messaging Service, est une API fournie par Sun pour permettre un dialogue asynchrone entre des applications ou des composants via des fournisseurs de services JMS. Un client peut également recevoir des messages de façon synchrone dans le mode de communication point à point. Ce dernier est l un des deux modes de transmissions existant avec le modèle producteur / consommateurs. Pour le premier modèle, le producteur publie les messages dans une file, appelée queue, et le client lit les messages de la file. Dans ce cas le producteur connaît la destination des messages et poste les messages directement dans la file du client. Dans ce mode de transmission un message est délivré au plus une seule fois. Figure 3.5 Le modèle point-à-point Dans le modèle producteur / consommateurs, des entités s inscrivent pour recevoir des messages, les consommateurs, sur un certain sujet (topic). Celui qui publie les messages et ceux qui les reçoivent ne se connaissent pas. Contrairement au modèle précédent, le messages est délivré autant de fois qu il y a de consommateurs. Figure 3.6 Le modèle producteur / consommateurs 17

18 3.3 Javaspaces En accord avec le cahier des charges, chaque utilisateur à, au sein d un VGS, un espace de stockage privé et à accès à un espace de stockage partagé. La réalisation de ces espaces passent par l utilisation des JavaSpaces. Ce dernier repose sur le principe de tuple space (TS). Tuple space Un TS est une mémoire globale partagée par tous les processus, un élément dans un tuple space est appelé tuple. Ce dernier est une séquence ordonnée de valeurs semblable à un enregistrement dans le langage traditionnel [Gel85]. Listing 3.1 Exemple de tuple - [ Thomas, 24, false ] - tuple avec trois champs : ( name : string, age : integer, married : boolean ). Trois primitives élémentaires ont été définies : Out : insérer un nouveau tuple dans TS. Read : lire un tuple dans TS. In : extraire un tuple dans TS (supprime le tuple). La différence entre les variables partagées et le Tuple space, est que dans ce dernier les tuples ne possèdent pas une adresse mémoire i.e. un tuple est adressé par son contenu, il est désigné en spécifiant la valeur ou le type de chaque champ qu on peut exprimer en fournissant un paramètre réel (une valeur) ou formel (variable) à l une des opérations présentées ci-dessus. Listing 3.2 Exemple de tuple - Read ( Thomas, var age, var married ) - avec age : integer, married : boolean. L opération Read tente de trouver le tuple correspondant dans TS, s il ny a aucun tuple qui correspond, le processus invoquant l opération se bloque en attente d une insertion du tuple demandé. Javaspace JavaSpace est une technologie qui facilite le développement des applications distribuées, elle permet des échanges d objets persistants via des espaces de tuples partagés par lesquels les processus Java distants peuvent collaborer et échanger des données. JavaSpace est inclus dans Jini, sortie par Sun en Jini est basé sur l idée que les appareils électroniques qui nous entourent (imprimantes, portables, GSM, etc.) proposent un ou plusieurs services qu ils publient afin d être utilisés via le réseau. JavaSpace peut être considéré comme un système de mémoire partagée virtuelle sur des architectures distribuées, basé sur la notion d espace de tuples partagés où le tuple est implémenté par une hiérarchie d objets java serialisables (hérite de la classe Entry). Il fournit un petit nombre d opérations sur un espace : write : écrire un objet dans un espace JavaSpace. read : lire un objet dans un espace JavaSpace. take : extraire un objet d un espace JavaSpace. notify : s enregistrer pour être notifier d une insertion ou extraction d un objet correspondant à des critères particuliers. 18

19 Figure 3.7 Exemple JavaSpace 3.4 JavaFX JavaFX est une famille de produits et de technologies de Sun Microsystems, rendue publique à la conférence de développeurs JavaOne en mai Les produits JavaFX ont pour but de créer des applications internet riches (RIA). Cette technologie à l avantage de proposer un langage de script qui, une fois compilé, produit une application exécutable via un appareil mobile, via une applet java, ou encore via une application lourde de type Desktop ou Web start. Le langage de script ayant été fait pour la création d interface graphique, il est donc plus adapté pour des personnes n ayant que peu de connaissances en programmation. Auparavant, créer une interface graphique en utilisant Swing ou même SWT demandait une certaine connaissance de l approche objet. Figure 3.8 Une application multi-plateforme Bien qu utilisant un langage de script, ce dernier une fois compilé n est ni plus ni moins qu un programme java compilé. De ce fait, il est tout à fait possible d utiliser des classes écrites en java pure Pour développer et exécuter une application en JavaFX, il est nécessaire d avoir le kit de développement Java ainsi que l environnement d exécution (Runtime). Ce dernier est dorénavant inclus dans le JRE depuis l update 10 (jre6u10). 19

20 3.5 PostgreSQL PostgreSQL est un système de gestion de base de données relationnelle et objet (SGBDRO). C est un outil libre disponible selon les termes d une licence de type BSD. Ce système est concurrent d autres systèmes de gestion de base de données, qu ils soient libres (comme MySQL et Firebird), ou propriétaires (comme Oracle, Sybase, DB2 et Microsoft SQL Server). Le modèle de base de données est pour le moment assez simple. En effet, la base de données ne sert que, pour le moment, pour l identification des utilisateurs sur la plateforme erobory. Figure 3.9 Le logo de PostgreSQL L accès aux données Afin de gagner en souplesse ainsi que pour respecter le modèle MVC (Modèle-Vue-Contrôleur), l accès aux données se fait via plusieurs classes selon le principe du patron de conception Data Access Object (DAO). L utilisation de DAO propose, d une part, regrouper les accès aux données persistantes dans des classes à part, plutôt que de les disperser et, d autre part, permet de s abstraire de la façon dont les données sont stockées au niveau des objets métier. Ainsi, le changement du mode de stockage ne remet pas en cause le reste de l application. En effet, seules ces classes dites techniques seront à modifier. Pour gagner encore plus de souplesse le patron de conception DAO peut-être couplé avec le patron Fabrique (Factory). Ce dernier permet d encapsuler l instanciation des objets dans une classe. Ceci permet de prévenir des modifications sur la façon de créer les objets concrets car l instanciation de nos DAO sera centralisée dans un seul objet. Voici l architecture adopté pour l accès aux données. Figure 3.10 Accès aux données via DAO et Factory Grâce aux patrons de conception, l ajout d un nouveau composant ou l ajout d un nouveau format de stockage se fait assez simplement. Dans le premier cas, il n est nécessaire que de créer une nouvelle 20

21 classe héritant de DAO<T> et d implémenter et ajouter de nouvelles méthodes de manipulation d objets. Pour l ajout d un nouveau mode de stockage, le processus se fait en plusieurs étapes, la première étant similaire à l ajout d un nouveau composant vu dans le premier cas. Il faut ensuite créer une fabrique qui renverra les objets DAO<T> nouvellement créés. 21

22 Chapitre 4 Mise en œuvre Cette partie se scinde en trois. Le première étape nécessaire est la montée en compétence sur les technologies utilisées tout au long du projet. La seconde expose tout les éléments de la plate-forme erobory concernant l espace de travail collaboratif. Et enfin la troisième partie concerne tous les tests qui ont été réalisés. 4.1 Montée en compétence La première partie de mon stage était concentrée sur l apprentissage des différentes technologies allant être utilisées pour développer la plate-forme. J ai donc entrepris de poursuivre mon apprentissage en suivant des tutoriels trouvés sur Internet. Ces tutoriels proposaient un apprentissage par l exemple, c est-à-dire qu en plus des explications fournies, elles étaient mis en application sur un exemple suivi tout au long du tutoriel. 4.2 Les éléments de la plateforme Le fonctionnement de l espace de travail collaboratif repose sur principalement trois types agents différents. Ces derniers sont l agent utilisateur, le VGSManager et les VGS. A ces trois, il est possible de rajouter les outils. (voir fig.4.1). A ces agents viennent se greffer deux autres composants que sont une base de données pour l identification de l utilisateur ainsi qu un serveur Javaspace qui va héberger les données des utilisateurs. Figure 4.1 Les différents éléments de la plateforme 22

23 4.2.1 L utilisateur L utilisateur est représenté en tant qu un agent au niveau de la plate-forme. Cela permet une communication plus simple entre les différentes entités de la plate-forme en utilisant les ACLMessage. Il avait été considéré, au début du projet, de représenter un utilisateur par un objet Java (POJO) et de faire communiquer ce dernier avec les autres entités via un service JMS. Ce dernier permet de garder une trace des messages envoyés. En effet les messages sont stockés dans une file jusqu à ce qu il soit traité. L impossibilité de créer des files d attente de manière dynamique, le nombre de message pouvant être échangé entre l utilisateur et les autres entités pouvant être conséquent, il a été décidé d abandonner l utilisation de JMS pour l envoi et réception de message. De plus, JMS se repose sur un systèmes centralisé. Si le fournisseur de service venait à s interrompre c est toute la plate-forme erobory qui en subirait les conséquences. Le système de communication inter-agent se repose également sur un système de queue. Cependant, chaque agent possède sa propre file d attente. De ce fait, la tolérance aux pannes est largement accrue. Un utilisateur n est pas uniquement représenter par un agent. En effet, ce dernier n est utile que pour communiquer avec les autres agents de la plate-forme. Un utilisateur possède également un profil appelé EroboryUser. Ce profil est rempli grâce aux informations contenus dans la base, comme son nom, prénom ou les groupe auxquels il appartient. L utilisateur peut interagir avec le VGSManager (décrit dans la partie suivante), un ou plusieurs VGS ainsi que un ou plusieurs outils. Afin que l utilisateur puisse faire plusieurs choses en même temps, et qu il soit averti en temps réel des modifications apportés à des VGS auxquels il a accès, la réception de message provenant du VG- SManager et des VGS ce fait de manière asynchrone. Par exemple, après avoir soumis une demande d ouverture de VGS au VGSManager, il peut continuer à travailler dans d autre VGS ou configurer son espace de travail. Pour ce faire chaque utilisateur possède un comportement cyclique 1 traitant tout les messages arrivant dans la file d attente de l utilisateur. Ce comportement est executé dans un thread annexe au thread principal. La gestion des erreurs est également très importante. Étant donné qu un utilisateur n a pas forcément immédiatement une réponse à ses actions (demande de connexion à un VGS par exemple), il doit être à tout moment averti d une possible erreur. Pour ce faire, il est seulement nécessaire d envoyer à l agent responsable de l utilisateur un message avec pour entête NOT UNDERSTOOD. Une fois ce message reçu, l interface graphique sera notifié de cette erreur et exécutera l action adéquate Le VGSManager Le Virtual Group Space Manager (VGSManager) est un agent chargé de la gestion des VGS au sein de la plate-forme erobory. Il est également responsable de l identification d un utilisateur sur la plateforme. Cette fonctionnalité est assurée par le Security Manager dont une instance est créer au démarrage du VGSManager. A l heure actuelle l identification n est rendue possible que via l utilisation d un nom d utilisateur et d un mot de passe. Comme dis précédemment, il n est pas à exclure une authentification via certificats. L objet Security Manager permet donc de regrouper toutes les fonctionnalités liés aux accès des utilisateurs. Le VGSManager est donc le seul et unique point d entrée pour un utilisateur. La figure 4.2 décrit ce processus. Suite à ce processus le profil de l utilisateur est chargé, et l utilisateur est inscrit auprès du VG- SManager. L inscription auprès du VGSManager permettra à l utilisateur d être averti en temps réel des modifications apportées à son profil (création de nouveau VGS, fermture etc.). Dans le cas où l identification a échoué l utilisateur en sera informer. L agent VGSManager permet la création d une nouvel espace virtuel ainsi que sa fermeture (décrite par le figure 4.3). Pour ce faire le VGSManager tient à jour un registre de toutes les salles qu il a créé. Cette dernière n est d ailleurs possible que si l utilisateur à l origine de la requête est le créateur du VGS et si aucun utilisateur n est connecté au VGS. Dans le cas contraire, celui-ci recevra une réponse négative quant à son action. 1. comportement cyclique : méthode appelée en continu tant que l agent n est pas tué 23

24 Figure 4.2 Processus d identification auprès du VGSManager Figure 4.3 Processus de création d un nouveau VGS auprès VGSManager Sur le même principe de la création, le VGSManager permet également de modifier la configuration d un VGS. Il est, par exemple, possible de changer le maître d une salle ou encore autoriser des personnes supplémentaires à accéder à un VGS donné. 24

25 4.2.3 Le VGS Tout comme l agent utilisateur un VGS est composé de deux éléments : un agent ainsi qu un profil. Le premier est utilisé pour communiquer avec les autres agents de la plate-forme, cela inclus les utilisateurs, le VGSManager ainsi que les outils. Le profil est quand à lui la carte de visite du VGS (nom, but, mode de collaboration etc.).le VGS tient également à jour plusieurs éléments : Une liste des outils installés dans le VGS. Une liste des utilisateurs autorisés à rejoindre le VGS. Une liste des outils en cours d utilisation pour chaque utilisateur. Utilisé en cas de déconnexion d un utilisateur du VGS. En effet l utilisateur peut ne pas stopper tous les outils un par un. Dans ce cas, il faudra répercuter la déconnexion de l utilisateur sur tous les outils en cours d utilisation. Une liste des utilisateurs connectés au VGS. Une liste des ressources accessibles dans le VGS. Cette fonctionnalité n est pas utilisé. En effet, il est dans l idée de pouvoir associer à un VGS une liste de ressources disponibles pour le travail (robots, imprimantes etc.). Un VGS peut supporte plusieurs opérations dont voici le détails. Événement Javaspace Lorsqu un utilisateur souhaite interagir avec son espace de stockage privé ou public, il lui est nécessaire d envoyer au VGS une requête particulière (fig. 4.4) Figure 4.4 Echange entre un utilisateur et un VGS Une requête de ce genre contient deux informations. La première est le type d opérations à effectuer sur l espace. Il en existe trois sortes : read, write et take. Pour plus d informations sur ces types reportez vous au chapitre 2 de ce rapport. Le deuxième élément de cette requête est une liste de tuples. Cette dernière à une fonction différente en fonction du type de la requête. En effet si la requête est de type write alors la liste de tuple de la requête sera insérer dans l espace partagé. En revanche si la requête est de type take ou read cette liste de tuple sera utilisé en tant que template. Ainsi tout les tuples de l espace correspondants aux templates seront retournés et insérer dans la requête. 25

26 Connexion et déconnexion d un utilisateur Pour commencer à travailler avec d autre utilisateur ou bien contrôler des robots de manières distante, l utilisateur doit d abord rejoindre un VGS. En admettant qu utilisateur ait au moins un VGS disponible, la figure 4.5 décrit le processus enclenché. Figure 4.5 Connexion puis déconnexion d un utilisateur Une IdentificationRequest est envoyé contenant l identifiant de l utilisateur ainsi que le identifiant du container dans lequel se trouve l agent utilisateur. Nous verrons par la suite pourquoi ce dernier est nécessaire. Le VGS va alors vérifié si l utilisateur peut accéder à ce VGS et si il n est pas déjà connecté. Dans le cas ou une de ces deux conditions n est pas respectée un message d erreur est envoyé à l utilisateur. Dans le cas contraire le VGS répond à l utilisateur via une LoginVGSReply de laquelle se trouve le profil du VGS. Après s être connecté l utilisateur peut se déconnecter. Dans ce cas là, ce dernier envoie simplement un message comportant l entête LOGOUT. Le VGS va commencer par envoyer un ordre d arrêt à tous les outils en cours d utilisation par l utilisateur, puis par la suite le VGS retirera l utilisateur des différentes listes. 26

27 Utilisation d un outil Lorsque l utilisateur souhaite démarrer un outil, il doit en faire la demande auprès du VGS. Cela se traduit par une requête de type UseToolRequest (figure 4.6). Cette dernière contient entre autre le mode dans lequel est démarré l outil ainsi que le nom de l outil a démarrer. Figure 4.6 Processus de démarrage d un outil C est dans ce cas de figure qu intervient l utilisation du nom du container d agent de l utilisateur. En effet pour que l interface graphique de l agent soit démarrée et que l utilisateur puisse l utilisé l outil doit être démarré sur le même conteneur que celui de l utilisateur. Pour cela il est nécessaire d envoyer une requête CreateAgent à l AMS en spécifiant le conteneur de destination Les outils Dans l idée un outil doit être implémenter de la manière suivante : lorsqu un VGS reçoit une requête UseToolRequest d un utilisateur, le VGS doit démarré un agent de configuration. Cet agent va permettre de configurer l outil qui s apprête à être utilisé. Par exemple, dans le cas d un outil de contrôle de robot, l agent de configuration va permettre de choisir le robot qui devra être contrôlé par l utilisateur ou encore l algorithme utilisé. Les agents outils étant créer depuis le VGS, ces derniers possèdent donc un lien implicite vers le VGS. En effet le VGS offre quelques services basiques aidant à la configuration comme la possibilité de récupérer la liste des utilisateurs connectés au VGS ou encore de récupérer le profil du VGS. Un outil est un programme permettant à un utilisateur d effectuer une tâche. De ce fait un outil peut aussi bien être un module de visio-conférence, de messagerie instantanée, de visualisation d image, de contrôle de robot à distance etc. Une API basique a été réalisé permettant la création de tous ses outils. Cette se focalise surtout sur la communication entre agents. Le traitements des messages et la présentation étant laissé à la charge du développeur. Figure 4.7 Différentes méthodes de communciation 27

28 4.2.5 L interface utilisateur L objectif du projet étant, entre autre, de créer une application multi-plateforme pouvant aussi bien fonctionner sur un téléphone portable qu un ordinateur de bureau possédant une grande quantité de mémoire en passant par un utilisation web. JavaFX permet, au travers d un langage de script, de créer des interfaces graphiques qui par la suite pourront être utilisé sur différents type de terminal (voir figure 3.8). De ce fait, il n est pas nécessaire d écrire plusieurs versions d une IHM. Le compilateur JavaFX s en chargera. En effet bien qu une fois compilé, un code source JavaFX produise du code Java classique, il est cependant nécessaire d avoir un runtime particulier. Le modèle MVC Aujourd hui une grande majorité d application sont construites en respectant le modèle MVC. Ce dernier propose de séparer la logique de l application, la couche modèle, et l interface utilisateur, les vues. La partie contrôleur quand à elle est chargé de faire le lien entre les deux parties précédentes en récupérant les actions de l utilisateurs puis les transmettant à la couche modèle (voir figure 4.8). Figure 4.8 Patron de conception Modèle-Vue-Contrôleur JavaFX se prête particulièrement bien à ce type d architecture de part son langage. En effet, la séparation se fait de manière naturelle puisque la couche modèle est écrite en Java pure alors que l interface en JFXScript. Ce dernier étant un remaniement syntaxique du langage java, il est tout à fait possible d utiliser des objets Java classique au sein de l interface graphique. Cependant, une interface graphique créer avec JavaFX ne s intègre pas aussi facilement dans une architecture multi-agent notamment avec le framework Jade. Liaison Modèle-Vue-Contrôleur Il faut préciser que, bien que JavaFX et Java soit intimement lié, ces deux langages n utilisent pas le même compilateur et interpréteur. Dès lors, il faut nécessairement se posé la question des outils à utiliser. > javac maclasse. java > java maclasse Listing 4.1 Compilation et exécution Java Listing 4.2 Compilation et exécution JavaFX > javafxc maclasse. fx > javafx maclasse Le moyen le plus répandu pour démarrer une application JavaFX est de la démarré en utilisant l interpréteur javafx. L interface créera alors le contrôleur qui créera à son tour la partie modèle (ici notre agent utilisateur ). Cependant un problème survient dès l utilisation de Jade. En effet, démarré un agent ne consiste pas en une vulgaire instanciation d un objet. Le processus est à peine plus compliqué : pour 28

29 qu un agent rejoigne une plateforme, ce dernier doit s enregistrer auprès de l AMS. Plusieurs méthodes existe. La plus simple consiste a récupérer l environnement d exécution de Jade puis via celui-ci créer l agent. Cependant cette technique ne permet pas d avoir une référence sur l agent en lui-même. Il devient donc impossible de transmettre les données du contrôleur au modèle. Une application JavaFX/Java peut également être démarré via l interpréteur java classique. Cependant, pour démarrer l interface graphique il est nécessaire de faire une manipulation plutôt compliqué. Brièvement, cette dernière consiste à récupérer le moteur d exécution de JavaFX puis de lui passé en paramètre le script JavaFX à exécuté en enfin spécifier le point d entrée du script. En effet la notion de méthode main est quelque peu différente en JavaFX. Cependant, cette méthode ne fonctionne que sur les JRE récents et ne permet que d appeler des objets JavaFX. La première méthode étant beaucoup plus simple et moins contraignante, elle a donc été retenue. Dès lors plusieurs solutions ont été apportées pour lié l interface graphique/contrôleur avec l agent utilisateur correspondant au modèle : Communication via RMI. Nécessite d avoir un registre RMI de démarré. L existence d un objet partagé entre le contrôleur et le modèle. Communication via files de messages JMS. Une pour l envoi de message et une pour le réception de message. Cependant, on retrouve un problème évoqué par la suite. Si une des files de messages vient à être pleine ou bien que le fournisseur de service s interrompt brutalement, toute l application en sera paralysée donc tous les utilisateurs. De plus comme presque chaque action provoque l envoi d un message à l agent, le nombre de saut pour communiquer avec un VGS peut être conséquent. De ce fait l obtention de réponse est potentiellement plus lente. Il s est avéré qu aucune de ces solutions ne convient. De ce fait l idée d utiliser JavaFX a été abandonné au profit du framework Swing dont l intégration au modèle ne pose pas de problème puisqu écrit entièrement en Java. Pour que le contrôleur puisse avoir une référence de l agent afin d utiliser ces méthodes, ce dernier sera créer par l agent en question. A partir de ce point, il n y a plus de problèmes de communication. 4.3 Les tests Les tests unitaires dans un environnement multi-agents sont assez compliqués. De ce fait ces derniers ont été réalisés manuellement après chaque développement de nouveau module. En plus de ces tests des tests de performances ont été réalisés. Le graphique 4.9 à pour but de tester le temps d envoi de plusieurs fichiers de taille différentes dans l espace de stockage partagé. Ce dernier est lancé sur la même machine que l utilisateur d ou les temps de transfert assez court. Figure 4.9 Performance JavaSpace 29

30 Ce graphique met bien en évidence que plus le nombre de fichier est important plus le temps de transfert est conséquent dans le cas de fichier de grande taille. Cependant, il faut noté que lorsqu un fichier est envoyé sur le serveur JavaSpace, ce dernier c est pas stocké sous forme physique. En effet, le fichier n est juste qu un objet en mémoire. De ce fait, si le serveur est interrompu alors toutes les données seront perdues. Il est donc évident que plus le seveur stocke des données plus la mémoire vivre utilisée devient importante. Après l exécution des tests la mémoire vive de la machine sur laquelle est lancé le serveur a atteint plus de 2go. Il faut également noté que les fichiers, afin d être transférés sur le serveur doivent être transformé en bytes. Cette opération allonge quelque peu le traitement. Une fois cette opération réalisé il faut, via l intermédiaire d une requête de type SpaceEvent, l envoyer sur le serveur. C est à ce moment que le framework Jade montre ses limites en termes d envoie de message. En effet, il n est pas rare, suite à l envoi répété de gros fichier, que des erreurs surviennent. En effet lorsque lorsque le contenu d un message ACL est trop important (dans le cas des fichiers en bytes par exemple) ce dernier est tronqué provoquant alors une UnreadableException La graphique 4.10 met en évidence les temps de réponses d un VGS est utilisé par plusieurs utilisateurs en même temps. Figure 4.10 Performance requête VGS Ces VGS ont été réparti à chaque fois sur deux machines différentes possédant la même configuration. Les temps de réponses sont relativement court du fait que chaque agent correspond à un thread. Les VGS étant répartis sur deux machines différentes, par conséquent le nombre de requête traité simultanément est plus important. L action de l utilisateur (démarrage d un outil) ne demandant pas de communication avec les autres utilisateurs du VGS. 4.4 L intégration Dans cette part nous allons brièvement comment c est déroulé l intégration des différents modules développés par Gwenaël CRUSSON (découverte de service) et Tony ROUSSEL (contrôle de robots à distance) Le fichier xpj.properties L intégration à commencé par la création de ce fichier au format XML. C est dans ce fichier que sont définies les différentes conventions de nommage. De plus l application étant hautement distribuée, c est dans ce fichier qu est défini la répartition des différents composants. Listing 4.3 Contenu partiel du fichier xpj.properties < entry key =" VGSManagerName " > VGSManager </ entry > <entry key =" JiniHost "> localhost </ entry > La plupart des composants contenus dans ce fichier doivent être connus dès le lancement de l application ou bien avoir un nom précis. Par exemple, lorsqu un utilisateur rejoint la plateforme erobory, 30

31 ce dernier doit immédiatement localiser, via son nom, le VGSManager sans quoi l identification ne sera pas possible. Le VGSManager quand à lui, pour être trouver, doit s enregistrer avec le nom défini dans le fichier xpj.properties. La découverte de service L utilisateur peut à tout moment rechercher un service. Cette fonctionnalité n est pas vu comme un outil car elle n est pas propre à un groupe d utilisateur ou à un VGS particulier. De ce fait le module développé par Gwenaël CRUSSON a été intégré simplement dans l espace de travail. Un élément du menu de l application lui a été réservé. Dès que ce dernier est cliqué à lors l agent responsable de la découverte de service est démarré et l interface graphique affichée à l utilisateur. Le contrôle à distance Contrairement au module de découverte de service, le système de contrôle de robot à distance n est accessible que sous certaines conditions. De ce fait ce dernier à été développé en tant qu outil et donc accessible qu en étant connecté à un VGS possèdant cet outil. L intégration à également été assez simple. En effet les outils ne doivent posséder qu un seul point d entrée. A partir de là, pour accéder à l outil devient très simple. Il suffit que le VGS puisse supporter cet outil, c est à dire qu il soit dans le bon mode de collaboration ainsi qu installer au sein du VGS. A partir de ce moment l utilisateur n a plus qu à envoyer une requête UseToolRequest avec le nom de l outil qu il désire utiliser. 31

32 Chapitre 5 Améliorations La partie concernant la construction de l interface graphique a été faite tout à la fin de ce projet. De plus les problèmes rencontrés avec l utilisation de JavaFX ont considérablement réduit le temps lié au développement. De ce fait plusieurs fonctionnalités ne sont présente qu au niveau du modèle de données et non au niveau de la vue. Il est possible de citer, par exemple, l explorateur de fichiers d un VGS. En effet, il n est, à l heure actuelle, possible que de chercher des fichiers selon leur visibilité (privé ou partagé). Cependant, le modèle de donnée permet également la recherche selon le type de fichier, le propriétaire du fichier ou encore son nom. La modification de la configuration d un VGS n est pas possible via l interface graphique. Il est à noté aussi que l interface graphique liée à un VGS n est pas créer de manière dynamique. En effet selon les outils installés, la barre de démarrage des outils doit changé. Ainsi, si aucun outil n est chargé dans le VGS, alors la barre de démarrage ne contiendra uniquement que l explorateur d espace ainsi que le module pour déposer un fichier dans l espace d échange. Il faut également remarquer que les spécifications de la technologie Javaspace ne permettent pas de lire plusieurs objet à partir d un seul template. De ce fait, à l heure le processus d exploration est quelque peu lourd comme nous l avons vu dans les tests de performances. La lecture multiple demande donc une réflexion supplémentaire. L API JavaSpaces fournit également un moyen d avertir un utilisateur d un événement survenur dans l espace correspondant à des critères que l utilisateur aura lui-même défini. Ceci est rendu possible via la fonction notify(). Ces événements sont appelés Distributed Events. Cette dernière n est pas actuellement utilisé. Pourtant ses applications sont nombreuses. On pourrait imaginer qu un utilisateur se mette en attente d un fichier d un de ses collègues et qu une fois publier dans l espace, l utilisateur soit averti. 32

33 Chapitre 6 Bilan J ai vraiment porté un intérêt particulier à effectuer ce stage au GCL à Penang en Malaisie. En effet, j ai pu durant ce stage faire la connaissance de personne très sympathique et culture différente, ce qui m a beaucoup intéressé. Bref, ce stage n a fait que confirmer mon désir de continuer dans cette voix. Le contexte de ce stage m a permis d acquérir des compétences technique supplémentaires qui me seront très utiles pour ma prochaine recherche d emploi et dans mon futur métier. La pratique de la langue anglaise que ce fut dans le monde professionnel ou dans la vie de tous les jours m a beaucoup apporté et me donne les moyens de prétendre aux postes les plus intéressants partout dans le monde. 6.1 Bilan technique Le projet erobory m a permis d améliorer mes connaissances en Java notamment grâce à l utilisation de technologies propre à ce langage. Je pense bien sûr à Javaspaces et au framework Jade. Ce dernier est d ailleurs très agréable à utilisé puisque mature, développement démarré en 2001 et suit d ailleurs toujours son court au rythme d une nouvelle version par an, ainsi que très bien documenté. C est documentation passe aussi bien par une Javadoc de qualité que d un tutoriel complet pour découvrir toutes les possibilités offertes par ce framework. Quand à la technologie Javaspace, je ne dresserai pas au bilan aussi positif. Bien que l API soit relativement simple d utilisation, les ressources présentant les aspects avancés de cette technologie, comme les événements distribués, ne sont pas nombreuses. De plus, ce projet m a également permis d améliorer ma pratique de l anglais. Bien qu avoir étudié cette langue depuis maintenant plusieurs années, ça n est que peu comparable à la pratique proprement dite surtout dans le monde du travail. Les débuts furent difficile entre d une part, le manque de capacité de compréhension, qui fut renforcé par l accent de la population locale, puis d autre part les efforts à faire pour parler et se faire comprendre. J ai pu aussi perfectionner ma compréhension en lecture, car j ai été beaucoup amené à lire des documents en anglais pour réaliser mes projets et j ai dû faire des efforts pour bien comprendre le travail que j avais à réaliser. C est pourquoi, je pense avoir aussi maintenant de meilleures connaissances sur l anglais technique en informatique. 33

34 6.2 Bilan humain Lors de mon arrivée au GCL, j avais un peu d appréhension. Je pensais travailler seul sur un projet totalement nouveau. Contrairement au travail en équipe, il n est pas possible de confronter ses idées avec d autres membres et donc de trouver une solution optimale. Cependant, j ai finalement rejoint le même projet que Gwenaël CRUSSON et Tony ROUSSEL. J ai alors mieux appris à trouver comment rassembler les idées que nous avions pour les mettre en commun afin d avoir un produit final en commun. J ai également apprécié les réunions hebdomadaires avec les autres membres du laboratoire. Cela permet d avoir une vision plus général des travaux en cours du laboratoire. En entreprise cela peut-être très bénéfique en cas de migration du personnel vers un autre projet. Les développeurs ont alors une connaissance général du projet leur permettant ainsi d être plus rapidement opérationnel. Enfin, ce stage étant basé à l autre bout du monde pour nous français, j ai aussi beaucoup apprécié de côtoyer durant cette période des personnes de culture très différente avec qui j ai pu sympathiser. Cette expérience m a donné envie de poursuivre dans cette voie et de revenir en Asie. 34

35 Table des figures 1.1 Penang dans le monde Architecture du projet VDDBMS Architecture de la plate-forme erobory Répartition des tâches durant le stage Logo de jade Architecture d une plateforme multi-agent Authentification auprès du VGSManager Monitoring de l AMS Le modèle point-à-point Le modèle producteur / consommateurs Exemple JavaSpace Une application multi-plateforme Le logo de PostgreSQL Accès aux données via DAO et Factory Les différents éléments de la plateforme Processus d identification auprès du VGSManager Processus de création d un nouveau VGS auprès VGSManager Echange entre un utilisateur et un VGS Connexion puis déconnexion d un utilisateur Processus de démarrage d un outil Différentes méthodes de communciation Patron de conception Modèle-Vue-Contrôleur Performance JavaSpace Performance requête VGS Explorateur d espace privé/partagé Fenêtre de création d un VGS Envoi d un fichier dans l espace partagé Aperçu global de l application

36 Listings 3.1 Exemple de tuple Exemple de tuple Compilation et exécution Java Compilation et exécution JavaFX Contenu partiel du fichier xpj.properties Démarrage du VGSManager Démarrage du RCAgentManager Démarrage du RCSessionManager Démarrage du DirFacilitator Faire rejoindre les robots Lancement du workspace

37 Glossaire ANT : Ant (Another Neat Tool) est un projet open source de la fondation Apache écrit en Java qui vise le développement d un logiciel d automatisation des opérations répétitives tout au long du cycle de développement logiciel. Ant est principalement utilisé pour automatiser la construction de projets en langage Java. API : Une interface de programmation (Application Programming Interface) est un ensemble de fonctions, procédures ou classes mises à disposition des programmes informatiques par une bibliothèque logicielle, un système d exploitation ou un service. JRE : environnement d exécution Java (ou en anglais Java Runtime Environment) désigne un ensemble d outils permettant l exécution de programmes Java sur toutes les plates-formes supportées. MVC : Le Modèle-Vue-Contrôleur est une architecture et une méthode de conception qui organise l interface homme-machine (IHM) d une application logicielle. Ce paradigme divise l IHM en un modèle (modèle de données), une vue (présentation, interface utilisateur) et un contrôleur (logique de contrôle, gestion des événements, synchronisation) POJO : Plain Old Java Object. Cet acronyme est principalement utilisé pour faire référence à la simplicité d utilisation d un Objet Java en comparaison avec la lourdeur d utilisation d un composant EJB. Ainsi, un objet POJO n implémente pas d interface spécifique à un framework comme c est le cas par exemple pour un composant EJB. Runtime : Programme ou une bibliothèque qui permet l exécution d un autre programme. SWT : Standart Widget Toolkit est une bibliothèque graphique libre pour Java, initiée par IBM. Cette bibliothèque se compose d une bibliothèque de composants graphiques (texte, label, bouton, panel), des utilitaires nécessaires pour développer une interface graphique en Java, et d une implémentation native spécifique à chaque système d exploitation qui sera utilisée à l exécution du programme. Template : Un template (ou gabarit en français) est, dans la technologie Javaspace, un patron permettant d effectuer des recherches d objet lui correspondant. VGS : Espace de travail virtuel (en anglais Virtual Group Space) est un zone virtuelle dans laquelle se retrouve un ou plusieurs utilisateurs pour effectuer une tâche précise. Worskpace : Espace de travail. 37

38 Bibliographie [dt10] Jade development Team. Site officieldu framework jade, [EGL07] Nabil ELMarzouqi, Eric GARCIA, and Jean-Christophe LAPAYRE. Cscw from coordination to collaboration. In -. 11th International Conference on Computer Supported Cooperative Work in Design, [Gel85] David Gelernter. Generative communication in linda. -, [Hom05] Scott Hommel. Site officiel javafx contenant une multitude de tutoriel sur cette technologie, [Mam05] Qusay H. Mamoud. Tutoriel de prise en main de javaspaces, developer/technicalarticles/tools/javaspaces/. [Sun99] Sun MicroSystems. JavaSpaces Specification, [VN04] Jean Vaucher and Ambroise Ncho. Tutoriel de référence sur le framework jade, http: // 38

39 Annexes Déploiement Cette annexe présente le déploiement de TOUTE la plateforme erobory. Cela comprend donc les différents modules développés (workspace collaboratif, découverte de service et contrôle de robot à distance). Toutes les machines de la plateforme doivent impérativement posséder ant ainsi qu un version récente du JRE. 1. Configurer le fichier xpj.properties notamment toutes les entrées correspondant à la configuration de la plateforme (adresse IP, port etc.) 2. Démarrer le serveur JavaSpace sur la machine spécifier dans le fichier xpj.properties 3. Démarrer la base de données sur la machine dont l adresse a été défini le fichier xpj.properties > ant vgsml > VGSManager démarré Listing 6.1 Démarrage du VGSManager Listing 6.2 Démarrage du RCAgentManager > ant rcam > RCAgentManager démarré Listing 6.3 Démarrage du RCSessionManager > ant rcsm > RCSessionManager démarré > ant mdf > MainDF démarré Listing 6.4 Démarrage du DirFacilitator Listing 6.5 Faire rejoindre les robots > ant ctrl <mode > <id_robot > > Robot < id_ robot > opérationnel Cette dernière commande doit être tapé sur un terminal équipé de bluetooth ayant un robot a portée (dans le cas ou le robot est réel). L identifiant du robot doit être unique. Le mode quant à lui spécifie si l on souhaite avoir un robot réel (real) ou un robot émulé (emu). Listing 6.6 Lancement du workspace > ant userlauncher > Démarrage d un nouvel utlisateur... 39

40 Interface Graphique Ce annexe présente en quelques captures d écrans l application développée. Ces dernières n incluent pas les modules de contrôle à distance de robot et de découverte de service. Figure 6.1 Explorateur d espace privé/partagé Figure 6.2 Fenêtre de création d un VGS Figure 6.3 Envoi d un fichier dans l espace partagé Figure 6.4 Aperçu global de l application Dans le cadre bleu, la liste des VGS accessible par cette utilisateur ainsi que deux boutons permettant de rejoindre le VGS sélectionné ou de le fermer. Si entre temps, un autre utilisateur créer (ou ferme) un VGS accessible à l utilisateur actuel, la liste sera automatiquement à jour. Le profil de l utilisateur sera donc modifié. Une fois sélectionner, le profil du VGS apparaît dans le cadre rouge. Le cadre vert correspond à la zone dans lequel seront affichés tout les VGS ouvert. Sur la capture d écran 6.4, on 40