[PFE] Mémoire Nam HUYNH · et efficace pour permettre de développer des applications pervasives,...

Plateforme de déploiement de services pour systèmes pervasifs

Ju

ly 1

9,

20

10

OPTIMACS


PROJET FIN D’ETUDE AUTEUR : HONG NAM HUYNH FEVRIER - JUILLET‘10

Département Télécommunications, Services et Usages

Tuteurs : Frédérique Laforest – Yann Gripay


Ju

ly 1

9,

20

10

SOMMAIRE

Sommaire ..................................................................................................................................... 2

I. Introduction............................................................................................................................ 4

I.1. Le LIRIS ......................................................................................................................... 4

I.2. Contexte : Le Projet OPTIMACS.................................................................................... 4

I.3. Objectifs du PFE ............................................................................................................ 5

II. Problématique du Déploiement ............................................................................................. 6

III. Architecture Proposée........................................................................................................... 7

III.1. Préliminaires................................................................................................................... 7

III.1.1. Architecture OPTIMACS existante .......................................................................... 7

III.1.2. Choix techniques et Environnement de Développement ........................................ 8

III.2. Conception de la Solution Proposée ............................................................................ 10

III.2.1. Objectifs ................................................................................................................ 10

III.2.2. Architecture ........................................................................................................... 10

III.2.3. Conception Détaillée ............................................................................................. 12

IV. Développement de la Solution Proposée ............................................................................ 14

IV.1. ConfigProperties........................................................................................................... 14

IV.2. Local Deployer ............................................................................................................. 14

IV.2.1. Classe LocalDeployer & LocalDeployerImpl ......................................................... 15

IV.2.2. Classe activator..................................................................................................... 16

IV.3. GlobalDeployer............................................................................................................. 16

IV.3.1. Classe GlobalDeployer & GlobaldeployerImpl ...................................................... 17

IV.3.2. Class GlobalDeployerGUI ..................................................................................... 18

IV.3.3. Class Activator ...................................................................................................... 18

IV.4. Synthèse ...................................................................................................................... 18

V. Test Réalisés....................................................................................................................... 19

V.1. Local Deployer en Dur en Local ................................................................................... 19

V.2. Local DEployer et ConfigProperties ............................................................................. 19

V.3. Global Deployer en Dur à Distance.............................................................................. 20

V.4. Appel de Service avec l’Interface Graphique ............................................................... 20


Ju

ly 1

9,

20

10

VI. Retour d’Expérience ............................................................................................................ 22

VII. Conclusion........................................................................................................................... 23

ANNEXES……………………………………………………………………………………………………………………………...........……….24

TABLE DE FIGURES

Figure 1 : Architecture existante d’OPTIMACS............................................................................. 7 Figure 2 : Diagramme de cas d’utilisation de la partie Déploiement de DataSource à distance 10 Figure 3 : Diagramme de séquence simplifié ............................................................................. 11 Figure 4 : Nouvelle architecture OPTIMACS .............................................................................. 12 Figure 5 : Diagramme de séquence détaillée du Déploiement ................................................... 13


Ju

ly 1

9,

20

10

I. INTRODUCTION

I.1. LE LIRIS Ce projet fin d’étude(PFE) se déroule au sein du LIRIS (Laboratoire d'InfoRmatique en Image et Systèmes d'information). Ceci regroupe nombreux chercheurs et enseignants-chercheurs lyonnais venant du CNRS, de l’INSA de Lyon, du Lyon 1, Lyon 2 ainsi que de l’Ecole Centrale de Lyon. Mon PFE se fait dans le cadre d’une collaboration entre 2 équipes du LIRIS, BD et DRIM du département DCS.

Le département DCS (Données, Connaissances, Services) a été créé en 2008 et est composé de cinq équipes de recherche. Cette structure se base sur les thématiques de recherche spécifiques de chacune des équipes, au savoir-faire et aux méthodologies complémentaires qui sont utilisées pour explorer différents aspects relatifs à la problématique de gestion de données, de connaissances et de services. Cette diversité d'approche et de compétences constitue la richesse essentielle du département DCS.

L’équipe BD (Bases de Données) centre ses activités sur la gestion des données dans les nouvelles applications incluant les services, les flux et les environnements dynamiques. Les données aujourd’hui peuvent être issues de différentes sources (issues de capteurs, de services) et se retrouvent sur des supports de stockage très différents. Elle emprunte ses méthodes aux domaines des bases de données, de la logique et des contraintes tant au niveau théorique que système. Le stockage des données/services et les langages de requêtes déclaratifs pour les nouvelles applications, les aspects de confidentialité et de sécurité sont au cœur des préoccupations de l'équipe BD.

L’équipe DRIM (Distribution et Recherche d'Information Multimédia) travaille sur la modélisation sémantique et l'indexation de données et de documents multimédias, les systèmes d’information pervasifs et ubiquitaires, la recherche sémantique et personnalisée d’information, les réseaux sociaux ambiants, la gestion de la vie privée et le contrôle d’accès dans les systèmes répartis. Ses contributions s’appuient sur 3 idées directrices : les approches proposées sont décentralisées et auto-organisées ; elles sont centrées utilisateurs, adaptées au profil et au contexte d’utilisation ; elles s’appuient intrinsèquement sur la typologie et la sémantique d'utilisation des informations manipulées. Les champs d’application privilégiés de ses travaux concernent l’informatique biomédicale et les SHS (culture, patrimoine, société numérique).

I.2. CONTEXTE : LE PROJET OPTIMACS Ce PFE fait partie du projet OPTIMACS (Service Composition Based Framework For Optimizing Queries), financé par l'Agence Nationale de la Recherche (ANR) concernant les requêtes et la


Ju

ly 1

9,

20

10

composition de services dans les environnements pervasifs (collaboration avec le LIG de Grenoble et le LAMIH de Valenciennes).

En 2010, l’utilisation de systèmes informatiques est très largement répandue. L’information numérique prolifère à travers de nombreux équipements mobiles (ordinateurs portables, téléphones mobiles, PDA, GPS, etc.). Les systèmes pervasifs sont nés de la volonté de permettre à un utilisateur en déplacement d’accéder à ses applications habituelles. Les enjeux actuels sur ce domaine de recherche sont d’assurer les communications grâce à un protocole d’échange de données fiable et de répondre correctement aux requêtes des utilisateurs en leur envoyant un contenu approprié.

Les objectifs du LIRIS dans ce projet OPTIMACS sont de lever le défi dans la recherche de l’exploitation efficace des données provenant de nombreuses sources différentes dans les environnements dynamiques et grand-échelles. Couplage entre services, données et flux en même temps que traiter les requêtes en considérant des environnements dynamiques et la qualité de service est un enjeu important dans la gestion et l’utilisation de base de données.

I.3. OBJECTIFS DU PFE Notre projet a de l’objectif de mettre en place une plateforme d’expérimentation de requêtes à base de services dans les environnements dynamiques. L’essentiel est d’offrir un cadre souple et efficace pour permettre de développer des applications pervasives, qu’on appelle aussi « service » et tester leur déploiement et leur utilisation. Les travaux de nos prédécesseurs ont posé les bases du projet : ils ont établi la structure d’un service et réalisé la couche protocolaire permettant d’y accéder. Nous devons poursuivre en différents tâches tels que :

• Faire évoluer l’architecture d’environnement pervasif pour permettre de déployer un service à distance et de le monitorer,

• Définir les scénarios de test de cet environnement, • Implémenter la nouvelle architecture, • Mettre en place les tests, • Proposer la suite du projet.

Le déploiement à distance d’un logiciel ou d’un service consiste à installer à distance et le mettre à disposition sur un ou plusieurs serveurs. Il s’agit non seulement d’installer les logiciels mais également de pouvoir gérer les packages, décider de les mettre à jour ou pas, de choisir les machines cibles et de choisir les caractéristiques et besoins.


Ju

ly 1

9,

20

10

II. PROBLEMATIQUE DU DEPLOIEMENT

Nous pouvons constater quelques problématiques comme la confidentialité et la sécurité des données et des transferts, la surcharge possible du réseau et du serveur. Il faut donc penser à comprimer les fichiers et utiliser des serveurs de relais.

Trois acteurs, à savoir le producteur du logiciel, le distributeur et l’utilisateur final sont susceptibles de réaliser le déploiement. Celui-ci peut se faire selon les deux modes Push ou Pull.

Une possibilité est d’utiliser un Application Helper(AH)[MERLE 2005] , qui s’exécute localement sur les plateformes clientes. Il est l’interface entre le serveur de déploiement (connexion distante, ex : http,ftp) et le client (connexion locale).

D’après les études de JournalduNet[JDNet 1], voici les leaders du marché de la télédistribution :

Landesk de Intel propose une solution de déploiement des logiciels à distance sur les groupes d’ordinateurs des entreprises. La distribution des paquets d’installation minimise la bande passante utilisée avec des mécanismes de Multicast ou P2P. Landesk permet de centraliser et gérer les données, les configurations et les états des serveurs et des machines.

SMS (System Management Server) de Microsoft donne la possibilité de prendre en main à distance les machines cibles, de télédistribuer des applications. Il permet d’installer des services sur différents appareils. Quand les machines sont en veille, on peut les démarrer le temps de mettre une mise à jour.

ZENworks de Novell supporte le déploiement de logiciels complets sur différentes plateformes (Windows, Unix, Handheld devices) avec une gestion efficace des journaux. Il permet de gérer l'intégralité du cycle de vie des postes de travail, ordinateurs portables, serveurs et périphériques de poche.

Voici quelques solutions académiques :

Software Dock[HALL 1, HALL 2] est un outil universitaire permettant d’installer des logiciels complets et de gérer des applications de type client/serveur. Il introduit la notion de famille de logiciels, représentant un ensemble de configurations ou de versions du logiciel.

Resolvit est un prototype de l’approche proposée par l’Université Polytechnique de Madrid. Il s’agit d’un moteur de déploiement des unités fournissant des services. Il résout les problèmes de dépendances et de conflits entre eux. Il est utilisé pour OSGi, particulièrement pour le déploiement d’architectures orientés service (SOA).

Distributed Ant [GOSCINSKI 2004] est utilisé pour déployer les applications pour des infrastructures de type Grille. Les configurations de déploiement à distance sont communiquées


Ju

ly 1

9,

20

10

au client par les fichiers XML, Ant build file, avantageusement intégrés aux outils de compilation.

III. ARCHITECTURE PROPOSEE

III.1. PRELIMINAIRES

III.1.1. ARCHITECTURE OPTIMACS EXISTANTE L’architecture du projet OPTIMACS est constituée de sources de données hébergées par des Data Sources Container (DSC) et d’un annuaire de services Service Directory (SD). Les sources s'annoncent auprès de l'annuaire de service qui publiera les services qu'elles offrent. Le client se connecte par la suite à l'annuaire, récupère une liste des services disponibles puis va communiquer directement avec la source souhaitée afin d'utiliser le service choisi.

Chaque entité est basée sur OSGi qui permet une gestion souple des modules sous forme de « Bundles OSGi ». Chaque source fait l'objet d'un Bundle. Un Data Sources Container pourra intégrer à la fois des Bundles physiques et logiques.

Figure 1 : Architecture existante d’OPTIMACS

Voici la liste des Bundles et leur fonctionnalité :


Ju

ly 1

9,

20

10

Chaque Bundle peut être construit par un ou plusieurs services d’OSGi. C’est dans la configuration du Bundle que lesquels entre eux sont démarré avec tel configuration. Dans le cadre de ce projet, afin de simplifier des tâches, nous avons décidé que chaque Bundle contient un seul Service d’OSGi.

Il existe également une autre notion de service dans ce projet, un service OPTIMACS. C’est un service d’OSGi qui est construit basé sur un modèle de service déjà construit dans ce projet. Ce modèle met à la disposition des utilisateurs une API qui a été développée de manière à pouvoir être utilisables facilement et qui repose sur l'utilisation du protocole HTTP (RESTful protocol). Il permet de simplifier considérablement des tâches de développement puisque les protocoles de communication entre deux services OPTIMACS sont déjà construits.

III.1.2. CHOIX TECHNIQUES ET ENVIRONNEMENT DE DEVELOPPEMENT OS (Operating System) Le projet a été développé sous Windows 7. Mais le software est indépendant de n’importe quel OS.

IDE (Integrated Development Environment) Eclipse GALILEO version 3.5.2 est utilisé avec les Plug-ins Maven 0.10.0 et Subversive 0.7. Pour les installer sous Eclipse, ces liens sont nécessaires :

http://download.eclipse.org/technology/subversive/0.7/update-site/ http://m2eclipse.sonatype.org/sites/m2e

Langage Le projet est conçu pour travailler dans n’importe quel langage de développement. Au début du PFE, nous devions choisir de travailler soit en Java/OSGi soit en .NET/C#. Sachant que les


Ju

ly 1

9,

20

10

prédécesseurs ont construit les codes en Java, nous avons choisi de continuer de développer l’architecture et l’implémenter en Java.

Intergiciel L’OSGI (Open Services Gateway initiative) est une plateforme de service basée sur le langage Java qui peut être gérée de manière distante. Les différents services sont regroupés sous forme de Bundles qui peuvent être installés, arrêtés, démarrés, mis à jour ou désinstallés de manière distante et à chaud. La gestion du cycle de vie est effectuée à travers une API. L’annuaire (registry) de services permet aux bundles de détecter l’ajout de nouveaux services ou la suppression de services. La plateforme de Services OSGi est donc parfaitement adaptée aux environnements pervasifs.

Protocole de communication Pour invoquer un service, l’utilisateur échange les données via URL et HTTP en basant sur le protocole REST et les WebServices. Ce choix a été fait par les prédécesseurs de ce projet.


Ju

ly 1

9,

20

10

III.2. CONCEPTION DE LA SOLUTION PROPOSEE

III.2.1. OBJECTIFS L’objectif de ce projet est de fournir un outil pour que l’utilisateur, soit l’administrateur OPTIMACS puisse non seulement de réaliser le déploiement à distance, avec ou sans paramètres de configuration un Bundle sur un Container cible mais aussi de récupérer la liste de ses Bundles OPTIMACS, de démarrer avec ou sans configuration d’une de ses Services ou de l’arrêter.

Figure 2 : Diagramme de cas d’utilisation de la partie Déploiement de DataSource à distance

III.2.2. ARCHITECTURE L’architecture proposée est de construire 3 Bundles « Global Deployer », « ConfigProperties » et « Local Deployer ». Le Global Deployer est installé dans le Service Directory tandis que le Local Deployer et le ConfigProperties sont installés dans les DataSources Containers. Les nouvelles entités Local et Global Monitoring font partie du PFE de Vivien CHARLOT qui a commencé en même temps que ce PFE. Nous avons travaillé ensemble dans la partie Conception du projet.

Les fonctionnalités que ces nouveaux modules sont représentées dans le schéma ci-dessous :


Ju

ly 1

9,

20

10

Figure 3 : Diagramme de séquence simplifié

Voici le schéma de la nouvelle architecture OPTIMACS :


Ju

ly 1

9,

20

10

Figure 4 : Nouvelle architecture OPTIMACS

Le Global Deployer, installé au Service Directory, propose à l’utilisateur l’interface pour envoyer les requêtes et regarder les résultats. Les informations sont ensuite communiquées avec les Local Deployer des Containers cibles. Ces Local Deployer se chargent de les traiter, connectent au ConfigProperties de son Container pour y mettre les configurations s’ils existent puis envoyer la commande au Bundle. Pour profiter de cette fonction, les Bundles doivent effectuer une recherche de la service ConfigProperties puis récupérer les configurations s’elles existent au démarrage de son service.

Global Deployer Bundle centralisé au SD fournit l’interface à l’utilisateur pour envoyer

les requêtes de déploiement. Local Deployer Bundle en local qui reçoit les requêtes et les traiter ConfigProperties Bundle qui contient les configurations et permet aux autres Bundles

d’accéder à ses configurations s’elles sont fournis

III.2.3. CONCEPTION DETAILLEE Voici le diagramme UML qui présente l’interaction du client avec le système pour différents phases: le déploiement d’un nouveau Bundle dans un Container cible, la récupération de sa liste de bundles, le démarrage d’un service dans 2 cas avec et sans configuration, et l’arrêt d’un service.

Les colonnes du diagramme sont des services et non des classes. La réalisation de ces services sera vue dans la section suivante.


Ju

ly 1

9,

20

10

Figure 5 : Diagramme de séquence détaillée du Déploiement


Ju

ly 1

9,

20

10

IV. DEVELOPPEMENT DE LA SOLUTION PROPOSEE

IV.1. CONFIGPROPERTIES

Pour gérer les configurations des services, il est indispensable de construire un service OSGi indépendant. Puisque pour démarrer un service, la fonction start d’un bundle OSGi ne possède aucun argument pour qu’on puisse y entrer les configurations, le service ConfigProperties permet donc de les gérer et sauvegarder. Son nom complet est fr.cnrs.liris.ds.configproperties.

Il était possible d’intégrer ce service dans le même Bundle que celui qui contient le service LocalDeployer puisque ConfigProperties doit être démarré avant que LocalDeployer déploie ou démarre un Bundle et invoque les méthodes de ConfigProperties. Pourtant, nous avons décidé que chaque Bundle ne peut contenir qu’un seul Service. Il est donc nécessaire de déclarer le Bundle du ConfigProperties dans le fichier de configuration de démarrage d’OSGi dataspace- SoCQ.config.properties. Ce service doit être démarré en même temps que LocalDeployer. La classe ServiceTracker d’OSGi permet au dernier, à son démarrage, de trouver le service ConfigProperties.

Ce service propose des fonctionnalités suivantes :

• String setConfigProperties(String bundleName,String config) enregistre la configuration donné par config et identifié par le nom du Bundle.

• Properties getConfigProperties(String bundleName) récupére la configuration identifiée par le nom du bundle bundleName, Exception si elle n’est pas trouvé.

• Void delConfigProperties(String bundleName) supprime de la configuration identifiée par le nom du bundle bundleName.

Chaque configuration est sauvegardée dans une classe java Properties (java.util.Properties), qui propose une meilleure gestion des paramètres de configuration de Java qu’un String. Le String config que l’utilisateur fournit doit être conformément à la norme d’un fichier de configuration Java, donc sous la forme « key1=valeur1 key2=valeur2 … ».

La base de données de ConfigProperties est en effet un tableau de 2 colonnes, l’un pour le nom de bundle et l’un pour son Properties.

IV.2. LOCAL DEPLOYER Puisque LocalDeployer doit être accessible par un autre service sur le réseau, GlobalDeployer du Service Directory, pour pouvoir envoyer et recevoir les requêtes, j’ai décidé de construire LocalDeployer en tant qu’un service OPTIMACS afin de bénéficier ses protocoles de communication prédéfinis. Ceci permet d’invoquer une fonctionnalité de ce service à distance, la sortie est formé sous forme un Tuple, un format de donnés prédéfinit dans le projet qui ressemble à un tableau. Pour toutes les fonctionnalités de ce service ainsi que celles du GlobalDeployer, j’ai choisit que le format d’un Tuple est comme suivant : [BundleName, State,


Ju

ly 1

9,

20

10

Version, Location] sauf les getBundleList où le valeur de retour est un tableau dont chaque ligne est un Tuple come précédent.

Ce service consiste en 3 classes :

• Activator implémente la classe BundleActivator, qui est nécessaire pour le démarrage, l’arrêt et l’inscription du service OSGi,

• LocalDeployer définit l’interface du service • LocalDeployerImpl contient l’implémentation des fonctions et méthodes.

L’Activator créé LocalDeployer à son démarrage. LocalDeployer implémente la classe Service pour hériter tous les paramètres d’un service OPTIMACS. Dans son start, elle créé LocalDeployerImpl où se trouve réellement l’implémentation des méthodes du service LocalDeployer.

Dans l’architecture d’OSGi, la gestion des bundles est faite grâce à la classe BundleContext qui peut être compris comme une classe de l’environnement qui est fournit à la classe Activator à son démarrage. Il est donc indispensable de passer BundleContext en argument au LocalDeployer puis au LocalDeployerImpl.

IV.2.1. CLASSE LOCALDEPLOYER & LOCALDEPLOYERIMPL

• Tuple deploy(String bundleURL) throws IOException, BundleException Tuple deploy(String bundleURL, String config) throws IOException, BundleException Permettent de déployer le bundle dont l’URL est bundleURL avec configuration config s’il y en a ou renvoient des Exceptions au cas d’erreur.

Le déploiement peut être fait à partir d’un lien local ou à partir d’un lien URL vers le fichier .jar. Dans le dernier cas, nous avons décidé de laisser Felix de récupérer le fichier jar dans le cache local et non de le récupérer et le sauvegarder dans un endroit choisit manuellement. Felix propose une gestion de cache qui permet d’éteindre et démarrer en gardant le bundle disponible dans le cache même si son source d’origine n’est plus disponible. La configuration est enregistrée dans la base de données du service ConfigProperties s’il existe après que le bundle est installé. Le valeur de retour est un Tuple[4] avec les informations sur le bundle qui vient d’être installé. Ces informations sont nécessaires pour que l’utilisateur puisse vérifier le résultat et démarrer le bundle avec son nom.

• Tuple[] getBundleList() permet de récupérer la liste des Bundles OPTIMACS. La liste de tous les bundles installés dans le Container peut être récupérée grâce à la classe BundleContext. Un filtre sur le résultat est appliqué pour ne pas renvoyer la liste les bundles non OPTIMACS. Seuls ceux qui ont le nom fr.cnrs.liris.ds.service.* sont gardés.

• Tuple start(String bundleName) throws MalformedURLException, BundleException Tuple start(String bundleName, String config) throws IOException, BundleException


Ju

ly 1

9,

20

10

Permettent de démarrer le bundle du nom bundleName avec configuration s’il y en a ou renvoient des Exceptions au cas d’erreur. Une simple recherche dans la registre de listes des Bundles permet de retourner le Bundle souhaite. La configuration, s’il y en a est sauvegardée dans la base de données du service ConfigProperties avant que le bundle est démarré pour qu’il puisse le prenne en compte. La valeur de retour est le même que celle du deploy. Ces informations permettent de vérifier l’état du bundle.

• Tuple stop(String bundleName) throws MalformedURLException, BundleException permet d’arrêter le bundle du nom bundleName ou de renvoyer des Exceptions au cas d’erreur.

• String stateToString(int state) retourne le String correspondant à partir de l’état d’un Bundle en nombre entier.

• Tuple getProperties(Bundle bundle) retourne le Tuple qui contient les informations du bundle donné sous le format [BundleName, State, Version, Location]

• Bundle getBundleFromString(String bundleName) throws MalformedURLException retourne le Bundle correspondant au nom bundleName donné. S’il n’est pas trouvé, une exception MalformedURLException est renvoyée.

• Void getconfigProperties() recherche le service ConfigProperties grâce à la classe ServiceTracker

• Void release() libérer la classe ServiceTracker

IV.2.2. CLASSE ACTIVATOR

Voici les fonctions de ce classe :

• Void start(BundleContext context) throws Exception permet de démarrer et inscrire la service dans le registre,

• Void stop(BundleContext context) throws Exception permet d’arrêter la service.

IV.3. GLOBALDEPLOYER

Ce service est construit en tant que service OPTIMACS de même raison que service LocalDeployer. Il permet à l’utilisateur de faire de différentes requêtes au Container cible.

Le bundle contenant ce service consiste en 4 classes :

• Activator permet de démarrer, arrêter et s’inscrire le service, • GlobalDeployer définit l’interface du service OPTIMACS, ce qui rend ce service

accessible à partir d’un URL, • GlobalDeployerImpl contient l’implémentation des fonctions et méthodes, • GlobalDeployerGUI fournit l’interface graphique (GUI) du service.


Ju

ly 1

9,

20

10

IV.3.1. CLASSE GLOBALDEPLOYER & GLOBALDEPLOYERIMPL C’est au sein de la classe GlobalDeployerImpl où les fonctions et méthodes sont implémentes.

Au niveau des données en entrée, tout d’abord, l’URL du target doit être pointé vers l’endroit où se trouve le service LocalDeployer. Par exemple, si le LocalDeployer cible a de l’adresse http://127.0.0.2/ds/LocalDeployer, l’URL en entrée peut être sous forme :

http://127.0.0.2 http://127.0.0.2/ http://127.0.0.2/ds http://127.0.0.2/ds/ http://127.0.0.2/ds/LocalDeployer

Si l’URL est conformément à ce condition, la connexion avec le LocalDeployer cible est réalisé grâce à la classe ServiceProxy, une classe de CommMgr, qui permet d’envoyer les commandes à la cible tout simplement en appelant la méthode executeMethod(String methodName, Tuple[] input).

Voici les fonctions de ces classes :

• Tuple deploy(String targetURL,String bundleURL) throws IOException, DataspaceFormatException, MethodNotFoundException, ArgumentException Tuple deploy(String targetURL,String bundleURL,String config) throws IOException, DataspaceFormatException, MethodNotFoundException, ArgumentException

Permettent de déployer à distance le bundle dont l’URL est bundleURL sur le DataSource Container dont l’URL est targetURL,avec la configuration config s’il y en a ou renvoient les Exceptions au cas d’erreur.

• Tuple[] getBundleList(String targetURL) throws IOException, DataspaceFormatException, MethodNotFoundException, ArgumentException

Retourne la liste des bundles installés du DataSource Container dont l’URL est targetURL ou renvoie les Exceptions au cas d’erreur.

• Tuple start(String targetURL, String bundleName) throws IOException, DataspaceFormatException, MethodNotFoundException, ArgumentException Tuple start(String targetURL, String bundleName, String config) throws IOException,

DataspaceFormatException, MethodNotFoundException, ArgumentException Permettent de démarrer le bundle du nom bundleName sur le DataSource Container dont

l’URL est targetURL, retournent le résultat sous forme d’un Tuple ou renvoient les Exceptions au cas d’erreur.

• Tuple stop(String targetURL, String bundleName) Permettent d’arrêter le bundle du nom bundleName sur le DataSource Container dont l’URL

est targetURL, retournent le résultat sous forme d’un Tuple ou renvoient les Exceptions au cas d’erreur.


Ju

ly 1

9,

20

10

IV.3.2. CLASS GLOBALDEPLOYERGUI L’interface graphique est réalisé en fournissant tous les fonctionnalités que l’interface de ce service. Nous avons donc 4 boutons : « Deploy », « OPTIMACS Bundle List », « Start Bundle » et « Stop Bundle ».

Une zone de texte est réservée pour afficher les résultats et pas des exceptions et des erreurs, qui sont affichées seulement dans la fenêtre cmd.

IV.3.3. CLASS ACTIVATOR Voici les fonctions de ce classe :

• Void start(BundleContext context) throws Exception permet de démarrer et inscrire la service dans le registre,

• Void stop(BundleContext context) throws Exception permet d’arrêter la service.

IV.4. SYNTHESE La volumétrie du projet est représentée dans ce tableau :

Bundle Classe Nb de méthodes Nb de lignes Activator 2 22 ConfigProperties 5 27

ConfigProperties

ConfigPropertiesImpl 5 52 Activator 2 23 GlobalDeployer 12 262 GlobalDeployerImpl 9 120

GlobalDeployer

GlobalDeployerGUI 4 264 Activator 2 23 LocalDeployer 12 221

LocalDeployer

LocalDeployerImpl 12 103


Ju

ly 1

9,

20

10

V. TEST REALISES

Les tests sont réalisés sur la machine locale 127.0.0.1 (localhost) dans l’ordre suivant :

V.1. LOCAL DEPLOYER EN DUR EN LOCAL Tout d’abord, les fonctionnalités, soit de déployer, démarrer et arrêter un Bundle, doivent être vérifié en local dans le cas simple, soit sans configuration. C’est dans le démarrage du service LocalDeployer, précisément dans la fonction start de son Activator, j’ai mis des lignes de test donc l’appel de la fonction deploy puis start et stop du service de test HelloWorld. Yann a mis en disponible un bundle de test HelloWorld sur le serveur de liris dont l’URL est :

http://liris.cnrs.fr/socq/obr/misc/fr.cnrs.liris.ds.service.helloworld-0.0.1-SNAPSHOT.jar

Les tests que j’ai mis dans l’Activator est :

System.out.println("** Starting Test Deploy ..."); this.localDeployerService.executeMethod("deploy", new Tuple(new Object[]{"http://liris.cnrs.fr/socq/obr/misc/fr.cnrs.liris.ds.service.helloworld-0.0.1-SNAPSHOT.jar"})); System.out.println("** Test Deploy succeed..."); System.out.println("** Starting Test Stop ..."); this.localDeployerService.executeMethod("stop", new Tuple(new Object[]{"fr.cnrs.liris.ds.service.helloworld"})); System.out.println("** Test Stop succeed..."); System.out.println("** Starting Test Start..."); this.localDeployerService.executeMethod("start", new Tuple(new Object[]{"fr.cnrs.liris.ds.service.helloworld"})); System.out.println("** Test Start succeed..."); Pour vérifier le résultat, après chaque test, je regarde le registre des bundles en faisant ps.

V.2. LOCAL DEPLOYER ET CONFIGPROPERTIES Une fois que les codes du service ConfigProperties sont finalisés, j’ai réalisé les mêmes tests en ajoutant la configuration en argument avec le service de test HelloWorldConfig, fournit en Annexe.

Le paramètre de configuration attendu est « loop ». J’ai mis « loop=3 » comme config. Le résultat est que tous les valeurs de retour répètent 2 fois à chaque requête.

Input : http://localhost/ds/service/HelloWorldConfig/Method/hello?firstName=Nam&lastName=HUYNH

Ouput :

hello HUYNH hello HUYNH hello HUYNH hello Nam


Ju

ly 1

9,

20

10

hello Nam hello Nam hello HUYNH Nam hello HUYNH Nam hello HUYNH Nam

V.3. GLOBAL DEPLOYER EN DUR A DISTANCE A ce point, tous les fonctionnalités souhaitées du projet réussi en local. Les appels en dur des fonctions deploy, start et stop sont mises en place pour pouvoir déboguer les erreurs. J’ai passé un temps considérablement sur ce point à cause de la mécompréhension des formats de valeurs de retours des appels à distance des services OPTIMACS. Ceci est malheureusement peu expliqué dans les API.

V.4. APPEL DE SERVICE AVEC L’INTERFACE GRAPHIQUE J’ai testé l’interface graphique manuellement en mettant des valeurs des arguments en dur et en entrant les arguments dans l’interface pour vérifier si le traitement des données par l’interface est fait proprement. Voici le résultat

Si je fais un Deploy sans argument, ca retourne l’Exception:


Ju

ly 1

9,

20

10

Si l’argument est bon, le résultat est comme celle-ci


Ju

ly 1

9,

20

10

VI. RETOUR D’EXPERIENCE

Ce projet de fin d’étude consiste en 3 grandes étapes : la recherche bibliographique, la conception et le développement.

Pendant les 2 premières étapes du projet, j’ai travaillé avec un autre étudiant, Vivien CHARLOT. Nous avons décidé que je travaillais sur la partie Déploiement à distance et que Vivien est chargé de la partie Monitoring du projet.

Parmi les 3 étapes, j’ai un grand regret que la partie Conception du projet a pris un beaucoup de temps avec un résultat pas comme celui attendu. Nous avons du mal à comprendre à avoir une image clair et précis de l’implémentation des modules alors l’implémentation de l’architecture et les tests ne peuvent pas être fini comme prévu, soit en fin Juin.

Au début de la 3ème étape, il était long et difficile de comprendre l’implémentation existant de l’architecture et l’environnement de travail. Il nous arrive des erreurs qui surviennent à cause des logiciels et nous font perdre beaucoup de temps. Nous avons des réunions chaque semaine et il est possible d’envoyer des questions par mail pendant la semaine mais je trouve que ce serait beaucoup plus efficace si nous avons eu d’espace disponible pour travailler proche des bureaux des tuteurs.

A travers ce projet, j’ai acquis des importantes expériences qui me préparent pour la vie professionnelle plus tard :

• Il est indispensable de savoir travailler efficacement en autonome tout en gardant l’esprit d’équipe. Il faut être toujours actif dans le travail de recherches et ne pas oublier de demander d’aide des collègues, des tuteurs pour ne pas perdre trop de temps inutile.

• La gestion de temps est nécessaire pour atteindre les objectifs du projet dans les délais. • L’utilisation de nouveaux outils (OSGi, Eclipse, Maven)


Ju

ly 1

9,

20

10

VII. CONCLUSION

Ma participation dans le projet OPTIMACS a permis de fournir les nouveaux modules pour déployer un Bundle ainsi que le démarrer et l’arrêter à distance avec ou sans configuration. Faute de temps, l’objectif de réaliser le déploiement sur plusieurs DataSource Container cibles n’est pas atteint.

Si le stage était plus long, je trouve la possibilité d’améliorer certains points comme :

• Réaliser le déploiement sur un parc de machine. • Mettre en place l’annuaire des Bundles installés sur le DataSource Container cible qui

permet de vérifier si le nouveau Bundle à déployer existe déjà dans la registre sans être démarré et quel version il est.

• Mettre en place un système de log de déploiement pour enregistrer ses activités ainsi que les configurations utilisées.

• Mettre en place un système d’authentification pour limiter l’accès au service qu’à l’administrateur.

• Proposer une meilleure gestion de cache de Felix pour ne pas perdre le bundle au cas où le bundle origine disparait. Un serveur Apache peut être utilisé pour rendre le bundle local disponible sur le réseau.

• Mettre en place un système de déploiement à froid.


Ju

ly 1

9,

20

10

ANNEXES Code source d’un service HelloWorldConfig qui prend en compte les configurations

Le premier fichier se nomme Activator.java et implémente l’interface BundleActivator nécessaire pour démarrer le service OSGi :

package fr.cnrs.liris.ds.service.helloworldconfig; import java.util.Properties; import org.osgi.framework.BundleActivator; import org.osgi.framework.BundleContext; import org.osgi.framework.ServiceRegistration; import org.osgi.util.tracker.ServiceTracker; import fr.cnrs.liris.ds.configproperties.ConfigProperties; import fr.cnrs.liris.ds.model.service.Service; public class Activator implements BundleActivator { protected HelloWorldConfig helloWorldService; protected ServiceRegistration serviceRegistration; protected ConfigProperties configPropertiesService; protected ServiceTracker configPropertiesTracker; protected Properties configProperties; public void start(BundleContext context) throws Exception { System.err.println("** Starting Hello World bundle..."); this.configPropertiesTracker = new ServiceTracker(context,ConfigProperties.class.getName(),null); this.configPropertiesTracker.open(); this.configPropertiesService = (ConfigProperties) this.configPropertiesTracker.getService(); this.configProperties = this.configPropertiesService.getConfigProperties("fr.cnrs.liris.ds.service. helloworldconfig"); this.helloWorldService = new HelloWorldConfig(this.configProperties); this.serviceRegistration = context.registerService( Service.class.getName(), this.helloWorldService, null ); } public void stop(BundleContext context) throws Exception { System.err.println("** Stopping Hello World bundle..."); this.serviceRegistration.unregister(); this.helloWorldService.release(); this.configPropertiesTracker.close(); } }


Ju

ly 1

9,

20

10

Le deuxième fichier se nomme HelloWorldConfig.java qui implémente l’interface Service afin d’être invoquer facilement en tant qu’un service OPTIMACS.

package fr.cnrs.liris.ds.service.helloworldconfig;

import java.util.List; import java.util.Properties; import java.util.Vector; import fr.cnrs.liris.ds.model.data.Attribute; import fr.cnrs.liris.ds.model.data.Filter; import fr.cnrs.liris.ds.model.data.Schema; import fr.cnrs.liris.ds.model.data.Tuple; import fr.cnrs.liris.ds.model.data.Data.Type; import fr.cnrs.liris.ds.model.service.Command; import fr.cnrs.liris.ds.model.service.Method; import fr.cnrs.liris.ds.model.service.Property; import fr.cnrs.liris.ds.model.service.Relation; import fr.cnrs.liris.ds.model.service.Service; import fr.cnrs.liris.ds.model.service.ServiceDescription; import fr.cnrs.liris.ds.model.service.Stream; import fr.cnrs.liris.ds.model.service.StreamListener; import fr.cnrs.liris.ds.model.service.baseimpl.ServiceDescriptionBaseImpl; import fr.cnrs.liris.ds.model.util.ArgumentException; import fr.cnrs.liris.ds.model.util.CommandNotFoundException; import fr.cnrs.liris.ds.model.util.MethodNotFoundException; import fr.cnrs.liris.ds.model.util.PropertyNotFoundException; import fr.cnrs.liris.ds.model.util.RelationNotFoundException; import fr.cnrs.liris.ds.model.util.StreamNotFoundException; import fr.cnrs.liris.ds.service.helloworldconfig.impl.HelloWorldConfigImpl; public class HelloWorldConfig implements Service { protected ServiceDescriptionBaseImpl description; protected HelloWorldConfigImpl impl; protected Properties config; public HelloWorldConfig(Properties configIn) { this.config = configIn; this.impl = new HelloWorldConfigImpl(this.config); // Service Description List<Method> methods = new Vector<Method>(); { List<Attribute> inputAttributes = new Vector<Attribute>(); List<Attribute> outputAttributes = new Vector<Attribute>(); outputAttributes.add(new Attribute("Message",Type.STRING)); methods.add( new Method( "helloWorld", "Returns the Hello World message...", new Schema(inputAttributes), new Schema(outputAttributes) ) ); } { List<Attribute> inputAttributes = new Vector<Attribute>();


Ju

ly 1

9,

20

10

inputAttributes.add(new Attribute("FirstName",Type.STRING)); inputAttributes.add(new Attribute("LastName",Type.STRING)); List<Attribute> outputAttributes = new Vector<Attribute>(); outputAttributes.add(new Attribute("Name",Type.STRING)); outputAttributes.add(new Attribute("Message",Type.STRING)); methods.add( new Method( "hello", "Builds different Hello messages for the given name", new Schema(inputAttributes), new Schema(outputAttributes) ) ); } this.description = new ServiceDescriptionBaseImpl( "HelloWorld", "Hello World Service", new Vector<Property>(0), new Vector<Command>(0), methods, new Vector<Stream>(0), new Vector<Stream>(0), new Vector<Relation>(0) ); } public void release() { this.impl.release(); } public ServiceDescription getDescription() { return this.description; } public Tuple[] executeMethod(String methodName, Tuple arguments) throws MethodNotFoundException, ArgumentException { if ( methodName.equals("helloWorld") ) { try { String returnValue = this.impl.helloWorld(); return new Tuple[] { new Tuple( new Object[] { returnValue } ) }; } catch(ClassCastException e) { throw new ArgumentException(); } } else if ( methodName.equals("hello") ) { try { String firstName; String lastName; if (config.isEmpty()) { firstName = (String)arguments.getField(0); lastName = (String)arguments.getField(1); } else { firstName = config.getProperty("firstName"); lastName = config.getProperty("lastName"); if (firstName==null||lastName==null) { throw new ArgumentException("Bad Configuration"); } } String returnValue1 = this.impl.hello(firstName);


Ju

ly 1

9,

20

10

String returnValue2 = this.impl.hello(lastName); String fullName = firstName + " " + lastName; String returnValue3 = this.impl.hello(fullName); return new Tuple[] { new Tuple( new Object[] { firstName, returnValue1 } ), new Tuple( new Object[] { lastName, returnValue2 } ), new Tuple( new Object[] { fullName, returnValue3 } ), }; } catch(ClassCastException e) { throw new ArgumentException(); } } throw new MethodNotFoundException(methodName); } // Unused methods => throws NotFoundException public Object[] getPropertyValues(String[] keys) throws PropertyNotFoundException { if (keys.length > 0) { throw new PropertyNotFoundException(keys[0]); } else { return new Object[0]; } } public void subscribeOutputStream(StreamListener streamListener, String streamName, Tuple tuple) throws StreamNotFoundException, ArgumentException { throw new StreamNotFoundException(streamName); } public void unsubscribeOutputStream(StreamListener streamListener) throws StreamNotFoundException { throw new StreamNotFoundException("[StreamListener]"); } public String executeCommand(String commandName, Tuple tuple) throws CommandNotFoundException, ArgumentException { throw new CommandNotFoundException(commandName); } public void feedInputStream(String streamName, Tuple[] tuples) throws StreamNotFoundException { throw new StreamNotFoundException(streamName); } public Tuple[] getRelationTuples(String relationName, Filter filter) throws RelationNotFoundException { throw new RelationNotFoundException(relationName); } public void deleteRelationTuples(String relationName, Filter filter) throws RelationNotFoundException { throw new RelationNotFoundException(relationName); } public void insertRelationTuples(String relationName, Tuple[] tuples) throws RelationNotFoundException { throw new RelationNotFoundException(relationName);


Ju

ly 1

9,

20

10

} }

Le troisième fichier se nomme HelloWorldConfigImpl.java qui contient l’implémentation des méthodes :

package fr.cnrs.liris.ds.service.helloworldconfig.impl; import java.util.Properties; public class HelloWorldConfigImpl { protected Properties config; public HelloWorldConfigImpl(Properties configIn) { this.config = configIn; } public String helloWorld() { if ( this.config == null) return "Hello, World!\n"; else { int loop = this.config.getProperty("loop").toCharArray()[0] - '0'; String returnValue = "Number of loop :" + loop + "\n"; for(int i=0;i<loop;i++){ returnValue = returnValue.concat("Hello, World!\n"); } return returnValue; } } public String hello(String name) { if ( this.config == null) return "Hello, World!\n"; else { int loop = this.config.getProperty("loop").toCharArray()[0] - '0'; String returnValue = "Number of loop :" + loop + "\n"; for(int i=0;i<loop;i++){ returnValue = returnValue.concat("Hello, " + name + "!\n"); } return returnValue; } } public void release() { } }

[PFE] Mémoire Nam HUYNH · et efficace pour permettre de développer des applications pervasives,...

Documents

Transcript of [PFE] Mémoire Nam HUYNH · et efficace pour permettre de développer des applications pervasives,...