TER Serveur autonomique de communautés instantanées Cahier des charges version : 1.0. Auteurs AMIMI Raouf BENMATI Nacim BOUHASS Mohamed MAHIOU Mahdi

Transcription

1 1ère année Master Informatique TER Serveur autonomique de communautés instantanées Cahier des charges version : 1.0 Auteurs AMIMI Raouf BENMATI Nacim BOUHASS Mohamed MAHIOU Mahdi Encadrants COLLET Philippe CHANG Hervé MERCIER Annabelle Ce document est le cahier des charges du TER serveur autonomique de communautés instantanées. Le but de ce TER est d équiper le serveur de l application AMUI, précedement développé lors de deux TER de l an dernier, de fonctionnalités autonomiques afin de permettre son autorégulation. Pour se faire nous introduirons des composants logiciels qui permettront au système de se surveiller lui-même et de réagir à des événements afin de se reconfigurer sans l intervention de l homme. Un système de contrats, actuellement en cours de réalisation par l équipe RAINBOW servira à mettre en œuvre les réactions du serveur en cas de violation de l un de ces contrats. Le fait d équiper AMUI[6] de ce caractère réduira fortement son coût de maintenance et d administration. Le 22 mars 2007

2 Table des matières 1 Présentation générale du TER Projet : Serveur autonomique de communautés instantanées Finalités Définitions : Contexte Situation du projet Etudes déjà effectuées Etudes menées sur des sujets voisins Suites prévue Nature des prestations demandées Parties concernées par le déroulement du projet et ses résultats (demandeurs, utilisateurs) Caractère confidentiel du projet Environnement d exploitation du produit Fonctionnalités 7 3 Contraintes non fonctionnelles 7 4 Gestion du projet Priorités Limites et interfaces Hypothèses, dépendances, contraintes Gestion de risque et sécurité Moyens de contrôle Méthodes et outils employés Planning prévisionel A Annexe : définitions 13 I

3 1 PRÉSENTATION GÉNÉRALE DU TER 1 Présentation générale du TER Les architectures des applications sont de plus en plus complexes. La gestion d applications autonomes dans des environnements confinés, est aisée de nos jours, notamment grâce aux normes établies et aux outils de gestions de projets et d environnements de programmation. Le problème se pose lorsque l on veut étendre le spectre d utilisation d un ensemble d applications à des environnements hétérogènes ou même à Internet. Cela conduit à des coûts très importants pour la maintenance, l administration et le déploiement d applications, qui se matérialise par l émergence d un nombre important de sociétés de services. L administration autonome vise à minimiser les interventions humaines, augmenter la réactivité (observation, reconfiguration autonome) et économiser les ressources. Le caractère autonomique des applications vise à supprimer tous ces problèmes, en garantissant aux utilisateurs de ces systèmes une utilisation la plus continue possible 24h/24 et 7j/7 (au moindre coût de maintenance). En effet, le fait d équiper une application du caractère autonomique lui permettrait la reconfiguration automatique en cas de besoin, l auto détection de nouveaux composants ainsi que l ajout/suppression dynamique de ces derniers, mais aussi l auto testabilité de validité et de conformité de l ensemble en un tout cohérent. Le bon déroulement de ces opérations est assuré par des systèmes de transactions et de tests pour tous les changements d états. Amui est une application qui gère des communautés instantanées en pilotant d autres applications à l aide de web services. En utilisant un client spécifique, les utilisateurs se connectent au serveur et sont automatiquement placés dans des groupes d intérêts en fonction des mots-clés qui les caractérisent. Chaque communauté instantanée ainsi formée est configurée pour exécuter différentes applications (messagerie instantanée, diffusion audio ou vidéo, etc.). Chaque application est intégrée côté client et serveur par un web service, ce qui facilite l intégration et le pilotage de nouveaux services dans la plate-forme. L architecture d AMUI est implémentée à base de Fractal[5] et de web services. Le but de notre TER est d équiper le serveur d AMUI de fonctionnalités autonomiques. Ceci afin de répondre aux besoins décrits précedement. D autre part, ce sujet s inscrit dans le cadre d une collaboration entre le laboratoire I3S et France Telecom R&D autour de la plate-forme Fractal de composants logiciels. Le projet Fractal définit un modèle et des API très générales qui englobent les modèles de composants actuels (EJB,.NET, CCM) et ajoute la possibilité de composants hiérarchiques et de reconfiguration à chaud. 1.1 Projet : Serveur autonomique de communautés instantanées Finalités L Objectif de ce projet est d équiper le serveur de l application de communautés instantanées, de fonctionnalités autonomiques en utilisant un système de contrats négociables sur les composants Fractal et les services. 1

4 1.2 Contexte 1 PRÉSENTATION GÉNÉRALE DU TER Les systèmes autonomes sont capables de se surveiller eux-mêmes et de réagir à des événements afin de se reconfigurer sans l intervention d un administrateur. Ainsi l application de Communautés Instantanées pourra s autoréguler dans les cas décrits explicitement dans le chapitre concernant les fonctionnalités Définitions : Contrat : C est un ensemble de mécanismes de spécifications, de vérifications et de gestion dynamique des propriétés des composants du système. Ces contrats permettent ainsi de décrire les caractéristiques du fonctionnement normal des systèmes en spécifiant certaines propriétés attendues. Fractal : Le projet Fractal définit un modèle et des API générales dédiés à la construction, au déploiement et à l administration. Ils englobent les modèles de composants actuels et ajoutent la possibilité de composants hiérarchiques et de configuration dynamique. Sonde : D une manière génerale, une sonde est un composant responsable de la collecte d informations. Dans notre contexte, une sonde est un composant Fractal, encapsulé dans un système responsable de la collecte d informations sur le système ou sur d autres composants applicatifs. Wildfire : JiveSoftware Wildfire[3] (futur Openfire) est un serveur de messagerie instantanée d entreprise développé sous licence Open Source GPL et sous licence commerciale. Il utilise le seul protocole open source très largement répandu pour faire de la messagerie instantanée, XMPP (également appelé Jabber). Wildfire est facile à installer et à administrer, et offre des garanties de sécurité et de performance. 1.2 Contexte Situation du projet L équipe Rainbow (I3S) développe actuellement un système de contrats «ConFract»[9] pour la plate-forme Fractal. Ce système permet de définir des contraintes et de les négocier dynamiquement sur les composants. Ce projet est un prototype de démonstration de l autonomie résultante du système de contrats négociables et qui pourrait servir à un transfert de technologie Etudes déjà effectuées Un premier travail effectué par une équipe de TER de l année précédente consistait à rendre compatible tout composant Fractal en web service et vice-versa. En parallèle, une application de plate-forme communautaire (AMUI) (voir figure 1) a été développée, par une seconde équipe de TER l année précédente également avec des web services pour permettre de former 2

5 1.2 Contexte 1 PRÉSENTATION GÉNÉRALE DU TER des salons de discussion de façon instantanée à partir de mots-clés, un plugin a été développé afin d adapter la plate-forme logicielle à AMUI. Par la suite, les deux TER ont été fusionnés pour faire en sorte que AMUI soit entièrement fait en composant Fractal et web services Fig. 1 architecture AMUI Des composants englobants (Wrapper) - en Fractal - ont été intégrés à l architecture de AMUI pour permettre de développer l application indépendemment des implémentations des plates-formes logicielles et matérielles Etudes menées sur des sujets voisins Vision d IBM Les systèmes autonomiques sont des systèmes qui peuvent s autogérer. Le professeur Paul HORN[2] (vice-président de IBM recherche) a fait l analogie avec le système nerveux humain (respiration, rythme cardiaque, température) lors de sa définition de ce type de système. Il définit l Autonomic Computing comme étant un nouveau paradigme de programmation. Les caractéristiques des systèmes autonomiques sont : Auto-configuration : 3

6 1.2 Contexte 1 PRÉSENTATION GÉNÉRALE DU TER Le système est capable de rétablir ou de modifier son état aux moments opportuns conformément au comportement défini par l autorité hiérarchique de niveau supérieur. La dualité temps - taux d erreurs fait que les systèmes complexes sont difficiles à maintenir. Lorsqu un composant sera rajouté à un système, il s adaptera et décrira ces capacités pour que le reste du système puisse au mieux l adapter à ses besoins, tel l intégration d une nouvelle personne dans une société. Autoprotection : Le système cherche à se protéger de la manière la plus efficace possible. Protection du système contre les attaques et les erreurs non gérées par le selfhealing. Anticiper les problèmes en s inspirant des résultats fournis par certaines sondes ou rapports et agir en conséquence pour résoudre le problème. Auto reparation : Détection, traçage et gestion des erreurs dans des systèmes complexes, puis diagnostic et réparation. C est la caractéristique qui nous intéresse le plus pour notre projet. Auto optimisation : Le système cherche à améliorer ses performances. Le système devra donc constamment se redimensionner en modifiant ces paramètres afin d être toujours performant. L implémentation de l une de ces caractéristiques suffit à rendre une application autonomique. IBM définit la complète autonomique, l implémentation de toutes ces caractéristiques, comme étant la complétude en terme d autonomie d une application. JADE Jade[1] est un MIDDLEWARE 1 pour l autogestion en milieu distribué. Il fournit un Framework pour développer des autonomic managers afin de gérer des grappes de serveurs par exemple, ou bien pour l optimisation de performances et la régulation de charge. Les autonomic managers peuvent gérer le comportement d une application selon les informations recueillies sur les composants de haut ou de bas niveau. Ils sont implémentés en utilisant des sensors(collecte d informations), actuators(filtrage et distribution des informations aux abonnés) et reactors (analyse/décision : sont notifiés par le sensors et agissent suivant des stratégies). On s inspirera de cette architecture pour l implémentation des sondes. LeWYS est un canevas générique permettant la supervision d applications. Il possède les caractéristiques suivantes : adaptation à différentes échelles du système. possibilité de développer ses propres collecteurs. 1 Technologie intermédiaire 4

7 1.2 Contexte 1 PRÉSENTATION GÉNÉRALE DU TER Fig. 2 boucle d autonomie fournir des nœuds de filtrage de l information, de composition d événements etc. configuration dynamique des paramètres de l application, sondes, réactions etc. non-intrusivité de la solution (peu chère en ressources). Le modèle de composants utilisé est Fractal. L acheminement des données se fait par des canaux dynamiques DREAM (Intergiciel). LeWYS fournit un certain nombre de sondes et services : sondes Linux : bibliothèque de fonctions qui lit dans le répertoire /proc. sondes Windows : bibliothèque de fonctions qui lit dans la base de registres et dans les composants matériels. Il y a trois niveaux de structuration des données (objet, instance, compteur). sondes applicatives (JMX) : leur but est de collecter des informations applicatives en java. La sonde est structurée en 3 niveaux (instrumentation, serveur de MBeans, niveau protocole). canaux à évènements : permet de construire des intergiciels orientés messages. On utilisera LeWYS pour l implémentation des sondes système seulement car les sondes applicatives sont difficile à réaliser compte tenu du temps qui nous est imparti. CLIF C est un canevas logiciel pour l injection de charge. Il constitue un des éléments du projet ObjectWeb JMOB pour la mesure des performances des intergiciels. CLIF permet de déployer, contrôler et superviser des injecteurs de charge. Il permet également de gérer des sondes pour mesurer l état de ressources systèmes telles que le CPU, la mémoire ou tout autre type de ressource logicielle ou matérielle. Chaque sonde est représentée par un composant Fractal. L implémentation de ce composant repose sur des mécanismes systèmes, externes à Fractal comme par exemple l utilisation de /proc sous Unix. Des composants sont également 5

8 1.3 Environnement d exploitation du produit 1 PRÉSENTATION GÉNÉRALE DU TER disponibles pour décrire les scénarios de tests de charge, la collecte, le stockage et l analyse du résultat des tests Suites prévue Le résultat de notre travail sera utilisé dans le cadre d un contrat de recherche entre le laboratoire I3S et France Telecom R&D notamment pour l étendre en rajoutant plus de fonctionnalités d autorégulation et d autoréparation Nature des prestations demandées Etudier l application AMUI : construire et installer l application, étudier son architecture et les technologies associées. Etude des travaux existant sur l autonomic computing. Concevoir une architecture permettant de mettre en œuvre l Autonomic Computing sur le serveur d AMUI. Développement des composants de gestion de l autonomic computing : en fournissant un certain nombre de sondes système et applicative, et en implémentant un système de contrats. Fournir une documentation technique, un manuel d utilisation, un rapport du travail effectué. Une présentation sera prévue pour expliquer nos travaux Parties concernées par le déroulement du projet et ses résultats (demandeurs, utilisateurs) Le sujet sujet à été proposé par Philippe COLLET et Hervé CHANG. Les personnes concernées par la réalisation du travail sont AMIMI Raouf, BENMATI Nacim, BOUHASS Mohamed, MAHIOU Mahdi. Le résultat de notre travail servira éventuellement à des web masters et des administrateurs pour leur faciliter une gestion plus automatique de l application. Il permettra également à améliorer les services fournis aux clients web par l application AMUI Caractère confidentiel du projet Les sources, la spécification, ainsi que les documents de conceptions ne pourront être exposés car ils seront utilisés dans le cadre d un contrat de recherche entre le laboratoire I3S et France Telecom R&D. Seul le cahier des charges, la documentation, des schémas généraux de l architecture, le rapport final ainsi que le site du projet seront publiques. 1.3 Environnement d exploitation du produit L ensemble des licences exploitées pour la réalisation et la mise en œuvre du projet ne devront pas imposer de mentions particulières ni même s approprier les logiciels bâtis à partir des entités décrites et régies par ces licences. Des licences gratuites de type LGPL devraient, par exemple, être utilisées au lieu des licences GPL. 6

9 3 CONTRAINTES NON FONCTIONNELLES Fig. 3 Environnement d exploitation du produit Le produit fournis pourra être exploité par différents types d équipements : PDA, PC Pocket, PC, Console d accès Web... Certaines bibliothèques ou logiciels seront requises selon la fonction attendue par l utilisateur et le type de média à sa disposition (figure 3). 2 Fonctionnalités On devra équiper le serveur de l application de communautés instantanées AMUI de fonctionnalités autonomiques : auto-réparation et auto-configuration. Il faudra implémenter deux types de sondes : les sondes système et les sondes fonctionnelles. Les sondes système recueilleront des informations sur les composants materiel (CPU, mémoire...) et sur le système d exploitation (bande passante...). On utilisera pour cela LeWYS qui fournit un ensemble de sondes. On devra les envelopper pour les imbriquer au serveur, en utilisant Fractal. Les sondes fonctionnelles recueilleront des informations propres au serveur (nombre de connectés...). Ces sondes transmettront des informations au système de régulation du serveur, qui se chargera de modifier son comportement en fonction d un système de contrats négociables et des valeurs transmises. 3 Contraintes non fonctionnelles Nous n avons pas de contraintes sur le temps de réponse ou l emprunte mémoire. Par contre les contraintes liées aux plates-formes matérielles sont importantes. Linux, Windows, Windows Mobile (Pocket PC, IPAQ) optionel Sun JDK 5 éventuellement Sun JDK 6 7

10 3 CONTRAINTES NON FONCTIONNELLES Tomcat WildFire : (éventuellement la version 3.1.0) Axis v1.4 Julia (éventuellement 2.5) : implémentation Java de Fractal Mysaifu Virtual Machine [4](optionel). XMPP, SOAP, CIWS 8

11 3 CONTRAINTES NON FONCTIONNELLES Annexes techniques : La figure 4 est l architecture préssentie telle que nous la conçevons. Tandis que la figure 5 est une vue détaillée du premier schéma mais reste une vue approximative du server AMUI. Fig. 4 Architecture préssentie Fig. 5 Architecture préssentie du serveur AMUI : niveau Fractal 9

12 4 GESTION DU PROJET 4 Gestion du projet 4.1 Priorités Priorités de niveau 1 : Travailler avec les versions des outils cités à la section 3. Implémentation des sondes. Elaboration de stratégies d autorégulation. Prototype ad hoc du comportement d autorégulation. Priorités de niveau 2 : Implémentation du même comportement sous forme de contrats négociables. Ajouter d autres sondes au fur et à mesure tout en respectant le système de contrats. Comparaison avec la version ad hoc. 4.2 Limites et interfaces Nous ne travailleront que sur le serveur de l application AMUI. Le fait de rendre le serveur autonomique n aura aucune incidence directe sur le client. On se limitera aux infrastructures de tests qui ont déjà été réalisées pour l application AMUI, en les adaptant ou en les étendant, au besoin, pour l accomplissement de notre tache. 4.3 Hypothèses, dépendances, contraintes On s engage à fournir une application minimale qui fonctionne à toute étape du travail en utilisant le principe d intégration continue. On essayera de faire fonctionner l application sur le maximum de plateformes possibles, de fournir de la documentation et un manuel d utilisation. On essayera de faciliter la maintenance. Notre principale contrainte est la maîtrise de l environnement et des technologies associées compte tenu du temps qui nous est imparti et du nombre important de ces dernières. Il faudra savoir ce que les technologies utilisées, pour mettre en œuvre l autonomie, nous offrent ; à savoir JADE et LeWYS. Il faudra également évaluer le temps de développement d une sonde. 4.4 Gestion de risque et sécurité La maîtrise de l application de communautés instantanées AMUI pourra prendre un temps considérable dû à un grand nombre de technologies annexes à apprendre, en particulier LeWYS, JADE et Fractal. 10

13 4.5 Moyens de contrôle 4 GESTION DU PROJET Etant donné que le nombre de participants est limité et le temps fixé, il faudra se focaliser sur les tâches prioritaires et éventuellement privilégier une certaine tâche au dépend d une autre, c est à dire bien répartir le temps et faire un diagramme de temps et de renfort. 4.5 Moyens de contrôle Faire valider par les encadrants chaque étape de la réalisation. Intégration continue au lieu du développement incrémental : vérifier au fur et à mesure de l avancement du travail. Vérifier que tout fonctionne bien à l aide de la console d administration. Batterie de tests : tests unitaires. Batterie d exemples de test (essayer d atteindre la complétude dans la mesure du possible), ne pas faire que des tests unitaires car insuffisants sur des architectures à composants. Il faudrait également réaliser des tests d ensemble en vérifiant la cohérence avec les diagrammes de collaboration, de séquence et d état. Tests général de l application en expérimentant toutes les combinaisons des fonctionnalités fournies. 4.6 Méthodes et outils employés Pour la conception et documentation (privée/publique) : javadoc, LaTeX, OCL, UML. Le suivi se fera au travers de réunions de pages de suivi et de mails. Pour le développement nous utiliserons : IDE Eclipse Outil de gestion de projet Maven Outil de gestion de versions SVN JUnit pour les tests Outils associés aux technologies Fractal et web services Pour la gestion de projet, nous utiliseront l outil Gantt Project pour dessiner nos planings. 4.7 Planning prévisionel On utilise une approche de l extreme programming pour notre planning. 11

14 4.7 Planning prévisionel 4 GESTION DU PROJET Fig. 6 Planning prévisionel 12

15 A ANNEXE : DÉFINITIONS A Annexe : définitions AXIS : est l acronyme d Apache extensible Interaction System. Apache AXIS est une nouvelle implémentation de la spécification SOAP développée par la fondation Apache, qui succède à Apache SOAP. AXIS se veut plus performante, plus modulaire, et plus extensible que son prédécesseur. Elle est à la fois un environnement d hébergement de services Web, et un toolkit complet de développement pour la création de services et l accès à des services tiers. CIWS : Communautés Instantanées et Web Services. CLIF : Un canevas logiciel pour l injection de charge, il permet de déployer, contrôler et superviser des injecteurs de charges. Il permet également de gérer des sondes pour mesurer l état des ressources systèmes. ConFract : C est un système de contrats développé pour contractualiser des composants logiciels hiérarchiques. Il fournit plusieurs formes de contrats, qui portent sur différents éléments d architecture : contrats d interface et de composition interne/externe. Il maintient aussi les contrats à jour lorsque des reconfigurations dynamiques sont opérées sur l architecture. JADE : Jade est un MIDDLEWARE pour l autogestion self management en milieu distribué. LeWYS : Un canevas logiciel à composants Fractal pour construire des applications de supervision. SOAP 2 : Définit un protocole permettant des appels de procédures à distance (RPC) s appuyant principalement sur le protocole HTTP et sur XML, mais aussi SMTP et POP. Il permet ainsi de définir des services Web. Les paquets de données circulent sous forme de texte structuré au format XML. XMPP : C est l acronyme extensible Messaging and Presence Protocol 3. C est le nom d un standard de l IETF en développement constant, ouvert et basé sur XML. L implémentation la plus connue est Jabber. Web services : Mécanisme universel pour faire dialoguer deux applications à travers le réseau Internet, les services Web reposant sur des standards. Les services Web proposent un mécanisme de communication standard pour faire dialoguer deux applications basées sur des technologies hétérogènes. La communication repose, le plus souvent, sur l échange de messages XML. L architecture la plus couremment utilisée est orientée services (SOA), reposant sur un mécanisme de type RPC. Les messages sont véhiculés via SOAP ou XML-RPC. La plupart des standards et technologies les plus anciennes ont été conçus pour une architecture reposant sur SOAP. Extrêmement nombreux, les standards des services Web sont organisés en couches qui n évoluent pas à la même vitesse. Seules les fondations - SOAP et WSDL - sont aujourd hui matures et stables. 2 Simple Object Access Protocol 3 Protocole extensible de présence et de messagerie 13

16 A ANNEXE : DÉFINITIONS WSDL 4 : C est le langage de description de web services, permettant aux applications les utilisant d auto configurer les échanges entre eux. Le WSDL est un langage de description de Web Services, au format XML. Il permet de séparer la description des fonctionnalités abstraites offertes par un service, des détails concrets d une description de service, tels que comment et où cette fonctionnalité est proposée. C est donc un langage décrivant les fonctionnalités abstraites d un service ainsi que l architecture décrivant les détails concrets de la description de service. Il définit, de manière abstraite et indépendante du langage, l ensemble des opérations et des messages qui peuvent être transmis vers et depuis un service web. Le WSDL décrit quatre ensembles de données, importantes : 1. information d interface décrivant toutes les fonctions disponibles publiquement; 2. information de type de donnée pour toutes les requêtes de message et requêtes de réponse ; 3. information de liaison sur le protocole de transport utilisé ; 4. information d adresse pour localiser le service spécifié. WSDL est donc conçu pour être la pierre angulaire de l édifice des Web Services, avec un langage commun pour décrire les services et une plateforme pour intégrer automatiquement ces services. 4 Web Services Description Language 14

17 RÉFÉRENCES RÉFÉRENCES Références [1] Chapitre 3 de intergiciel et construction d applications réparties : http ://sardes.inrialpes.fr/ecole/livre/pub/chapters/intro/intro.html. [2] Définition de l autonomic computing, selon ibm : http :// [3] Jive software : http :// [4] Mysaifu virtual machine : http ://www2s.biglobe.ne.jp/ dat/java/project/jvm/index en.html. [5] Site de référence sur la plate-forme fractal : http ://fractal.objectweb.org. [6] Vue d ensemble d amuï : http :// collet/amui/. [7] Second International Conference on Autonomic Computing (ICAC 2005), June 2005, Seattle, WA, USA. IEEE Computer Society, [8] Sara Bouchenak, Fabienne Boyer, Daniel Hagimont, Sacha Krakowiak, Noel De Palma, Vivien Quéma, and Jean-Bernard Stefani. Architecture-based autonomous repair management : Application to j2ee clusters. In ICAC [7], pages [9] Hervé Chang and Philippe Collet. Eléments d architecture pour la négociation de contrats extrafonctionnels. In Oussalah et al. [10], pages [10] Mourad Chabane Oussalah, Flávio Oquendo, Dalila Tamzalit, and Tahar Khammaci, editors. 1er Conférence francophone sur les Architectures Logicielles (CAL 2006), 4-6 September 2006, Nantes, France. Hermes Science,