THÈSE - Informatique
131 pages
Français

THÈSE - Informatique

Le téléchargement nécessite un accès à la bibliothèque YouScribe
Tout savoir sur nos offres
131 pages
Français
Le téléchargement nécessite un accès à la bibliothèque YouScribe
Tout savoir sur nos offres

Description

THÈSE
En vue de l’obtention du
DOCTORAT DE L’UNIVERSITÉ DE TOULOUSE
ET DE L’UNIVERSITÉ DE SFAX
Délivré par l’Université Toulouse III - Paul Sabatier
et la Faculté des Sciences Économiques et de Gestion - Sfax
Discipline : Informatique
Présentée et soutenue par
Riadh BEN HALIMA
Le Jeudi 14 Mai 2009
Conception, implantation et expérimentation d’une
architecture en bus pour l’auto-réparation des
applications distribuées à base de services web
JURY
Président
Rapporteurs
M. Ahmed HADJ KACEM Professeur à la FSEG-Sfax, Tunisie
Examinateurs
Directeurs de thèse
M. Khalil DRIRA Chargé de Recherche au LAAS-CNRS
M. Mohamed JMAIEL Professeur à l’ENIS, Sfax, Tunisie
Invité
M. Mohamed Karim GUENNOUN Professeur Assistant à l’EHTP, Casablanca, Marroc
Laboratoire d’Architecture et d’Analyse des Unité de Recherche en développement et contrôle
Systèmes d’applications distribuées
*** ***
LAAS-CNRS ReDCAD i
Résumé
Nos travaux de recherche abordent la problématique de l’auto-réparation dans les applica-
tions orientées services et plus spécifiquement basées sur la technologie des services web.
Nous nous intéressons à un contexte impliquant des applications logicielles construites par
composition de services web distribués et multipropriétaires. Afin de garantir la fiabilité et
la qualité de services de ces applications, nous proposons des techniques d’auto-réparation
des applications à base de service web. Par exemple, si un service web n’arrive pas à sa-
tisfaire la requête d’un utilisateur ...

Sujets

Informations

Publié par
Nombre de lectures 658
Langue Français
Poids de l'ouvrage 2 Mo

Exrait

THÈSE En vue de l’obtention du DOCTORAT DE L’UNIVERSITÉ DE TOULOUSE ET DE L’UNIVERSITÉ DE SFAX Délivré par l’Université Toulouse III - Paul Sabatier et la Faculté des Sciences Économiques et de Gestion - Sfax Discipline : Informatique Présentée et soutenue par Riadh BEN HALIMA Le Jeudi 14 Mai 2009 Conception, implantation et expérimentation d’une architecture en bus pour l’auto-réparation des applications distribuées à base de services web JURY Président Rapporteurs M. Ahmed HADJ KACEM Professeur à la FSEG-Sfax, Tunisie Examinateurs Directeurs de thèse M. Khalil DRIRA Chargé de Recherche au LAAS-CNRS M. Mohamed JMAIEL Professeur à l’ENIS, Sfax, Tunisie Invité M. Mohamed Karim GUENNOUN Professeur Assistant à l’EHTP, Casablanca, Marroc Laboratoire d’Architecture et d’Analyse des Unité de Recherche en développement et contrôle Systèmes d’applications distribuées *** *** LAAS-CNRS ReDCAD i Résumé Nos travaux de recherche abordent la problématique de l’auto-réparation dans les applica- tions orientées services et plus spécifiquement basées sur la technologie des services web. Nous nous intéressons à un contexte impliquant des applications logicielles construites par composition de services web distribués et multipropriétaires. Afin de garantir la fiabilité et la qualité de services de ces applications, nous proposons des techniques d’auto-réparation des applications à base de service web. Par exemple, si un service web n’arrive pas à sa- tisfaire la requête d’un utilisateur pour une raison quelconque, ceci est considéré comme une panne. Alors il devient nécessaire de remédier à une telle panne en substituant le service défaillant par un ou plusieurs autres services réalisant des fonctions équivalentes. Notre recherche focalise sur la conception d’une architecture qui permet le contrôle et l’analyse des données de la qualité de service (QdS) et la reconfiguration des systèmes en cours d’exécution. Aucune hypothèse sur la logique interne des services n’est néces- saire pour l’applicabilité de notre approche. Celle-ci repose sur des moniteurs capables d’étendre les messages SOAP échangés entre le client et le fournisseur de service et des connecteurs capables de rediriger les requêtes d’un service défaillant vers un autre, sup- posé efficace, implantant la même logique métier. Dans ce cadre, l’objectif principal est de fournir des mécanismes non intrusifs de reconfiguration afin de fournir une qualité de service acceptable tout au long de l’exécution. Nous définissons pour cela une approche formelle et des dispositifs logiciels couvrant toute la boucle de la gestion d’auto-réparation allant du monitoring de la QdS jusqu’aux actions préventives de reconfiguration. Nous re- trouvons, par conséquent, les quatre tâches principales suivantes : Le monitoring : C’est la tâche correspondant à la supervision de l’application. Nous nous focalisons, dans ce cadre, sur l’observation et le stockage des paramètres de QdS. L’analyse : Il correspond à la phase d’exploitation des valeurs obtenues par le monitoring permettant de s’assurer du bon fonctionnement de l’application et de prédire et détecter une éventuelle dégrada- tion de la QdS. Cette détection utilise un algorithme basé sur des fonctions statistiques et des contraintes temporelles et produit, le cas échéant, des alarmes qui vont enclencher le diagnostique. Nous nous intéressons à la surveillance de l’évolution d’une caractéris- tique donnée de QdS plus qu’à ses valeurs absolues. Le diagnostique : Cette tâche est exécutée suite à la détection d’une dégradation de la QdS. L’objectif ici est d’identifier l’origine de cette dégradation et d’éliminer l’effet de sa propagation. La réparation : C’est la tâche correspondant à la reconfiguration de l’application pour rétablir une QdS accep- table pour le système. La mise en pratique des actions de reconfiguration est achevée à travers des connecteurs de liaison dynamique qui seront générés, compilés et déployés automatiquement. Nous avons réalisé deux prototypes implantant ces différentes phases. Chaque phase est traitée par un module implanté sous forme de service web. Le premier prototype considère l’application de la revue coopérative, qui est une coopération de ser- vices web gérant les conférences. Le deuxième prototype représente un cas d’étude pour le commerce électronique. Il s’agit d’une application à base de services web orchestrés. ii Dédicace A tous ceux qui compte pour moi... Riadh BEN HALIMA iii Remerciement C’est avec un grand plaisir que je réserve cette page en signe de gratitude et de profonde reconnaissance à tous ceux qui ont bien voulu apporter l’assistance nécessaire au bon déroulement de ce travail. Je veux d’abord remercier mes encadreurs Monsieur Khalil DRIRA et Monsieur Moha- med JMAIEL qui n’ont pas épargné le moindre effort dans l’encadrement de cette thèse afin de me permettre de défier les entraves rencontrées et de travailler avec volonté et qui ont étaient toujours disponibles pour m’orienter à entreprendre les bonnes décisions. J’es- père être à la hauteur de leur confiance. Qu’ils trouvent dans ce travail le fruit de leurs efforts et l’expression de ma profonde gratitude. Je tiens à exprimer mon profond respect et mes vifs remerciements envers les membres de ce jury : Madame Michelle SIBILLA pour l’honneur qu’elle m’a fait en acceptant de le présider et Madame Laurence DUCHIEN, Monsieur Ahmed HADJ KACEM pour être rapporteurs, Madame Louise TRAVÉ-MASSUYÈS, Monsieur Christophe CHAS- SOT pour être examinateurs de mon travail. Un remerciement ensoleillé à Monsieur Mohamed Karim GUENNOUN, post-doctorant au LAAS-CNRS, pour sa bienveillance, sa fraternité, sa gentillesse et son soutien constant qui m’a donné courage pour l’élaboration de cette thèse. J’apprécie ses grandes qualités morales et son extrême modestie. Qu’il trouve dans ce travail l’expression de mon profond respect et mon infinie reconnaissance. Je remercie aussi tous les membres du laboratoire LAAS, ainsi que les membres du pro- jet européen WS-DIAMOND pour l’ambiance chaleureuse qui règne au sein des deux équipes et pour leur bonne humeur. Mes remerciements à Monsieur René PEGORARO, post-doctorant au LAAS-CNRS, Monsieur Ismail BOUASSIDA, doctorant au LAAS-CNRS, et Monsieur Ahmed JMAL, Technologue à ISET Sfax qui n’ont jamais hésité à m’offrir leur aide, leur coopération et l’élan qu’ils ont su insuffler à mon travail. Il est indispensable de ne pas rater cette occasion pour exprimer ma reconnaissance aux membres de l’unité de recherche REDCAD-Sfax pour leurs efforts qui ont guidé mes pas et enrichi mes connaissances. iv Table des matières 1 Chapitre 1 : État de l’art et Problématique 7 1.1 Service web : historique, concept et technique . . . . . . . . . . . . . . . 7 1.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.1.2 Object, Composant et Service . . . . . . . . . . . . . . . . . . . 8 1.1.3 L’Architecture Orientée Service (AOS) . . . . . . . . . . . . . . 9 1.1.4 Service web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.1.4.1 Transport : SOAP . . . . . . . . . . . . . . . . . . . . 10 1.1.4.2 Découverte : UDDI . . . . . . . . . . . . . . . . . . . 11 1.1.4.3 Description : WSDL . . . . . . . . . . . . . . . . . . . 12 1.1.4.4 Invocation d’un service web . . . . . . . . . . . . . . . 12 1.1.4.5 Apports des services web . . . . . . . . . . . . . . . . 14 1.1.5 Composition des services web . . . . . . . . . . . . . . . . . . . 14 1.2 La Qualité de Service dans les services web . . . . . . . . . . . . . . . . 15 1.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.2.1.1 Modèles de QdS existants . . . . . . . . . . . . . . . . 16 1.2.1.2 QdS spécifiques . . . . . . . . . . . . . . . . . . . . . 17 1.2.1.3 QdS génériques . . . . . . . . . . . . . . . . . . . . . 17 1.2.2 QdS considérées . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.2.2.1 Performance des services web . . . . . . . . . . . . . . 18 1.2.2.2 Monitoring de QdS de point de vue client . . . . . . . . 20 1.2.2.3 Collection des mesures du côté client et fournisseur . . 21 1.2.3 Techniques de mesure des QdS . . . . . . . . . . . . . . . . . . . 21 1.2.3.1 Le Timer inséré dans le code . . . . . . . . . . . . . . 21 1.2.3.2 Utilisation de l’approche orientée aspect . . . . . . . . 21 1.2.3.3 Modification de la bibliothèque du SOAP . . . . . . . . 23 1.2.3.4 Approche du proxy . . . . . . . . . . . . . . . . . . . 23 1.2.3.5 Approche basée sur le monitoring de paquets . . . . . . 23 1.2.3.6 Environnements d’expérimentation . . . . . . . . . . . 24 1.2.3.7 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . 25 1.3 L’auto-réparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 1.3.1 Approches existantes d’auto-réparation . . . . . . . . . . . . . . 27 1.3.1.1 Les approches basées Modèle . . . . . . . . . . . . . . 27 1.3.1.2 Les approches basées Middleware . . . . . . . . . . . 29 1.3.1.3 Les approches basées Plate-forme . . . . . . . . . . . . 33 1.3.2 Approches existantes de Monitoring . . . . . . . . . . . . . . . . 37 vi TABLE DES MATIÈRES 1.3.3 Approches existantes de Substitution . . . . . . . . . . . . . . . 38 1.4 problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 1.4.1 Système d’auto-réparation : Externe vs Interne . . . . . . . . . . 39 1.4.2 Niveau de gestion de la QdS : Instance vs Classe . . . . . . . . . 40 1.4.3 Service cible par le gestion de la QdS : Sans-état vs Avec-état . . 40 1.4.4 Gestion du Monitoring et du diagnostic : Local vs Global . . . . . 41 1.4.5 Gestion de la QdS : Prognostic vs Diagnostic . . . . . . . . . . . 41 1.4.6 Gestion de la QdS : Orchestration vs Chorégraphie . . . . . . . . 42 1.5 conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2 Chapitre 2 : Un Middleware Auto-Réparable guidé par la QdS (MARQ) 43 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.2 Approche Générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.3 Le Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 2.3.1 Algorithmes et modèles sous-jacents . . . . . . . . . . . . . . . . 45 2.3.1.1 Le Monitoring local des communications synchrones . 45 2.3.1.2 Le Monitoring global des communications asynchrones 46 2.3.2 Fonctionnalités et architecture de mise en œuvre . . . . . . . . . 47 2.3.2.1 L’interception niveau SOAP . . . . . . . . . . . . . . 47 2.3.2.2 L’interception niveau HTTP . . . . . . . . . . . . . . . 49 2.4 L’Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 2.4.1 Algorithmes et modèles sous-jacents . . . . . . . . . . . . . . . . 49 2.4.2 Fonctionnalités et architecture de mise en œuvre . . . . . . . . . 53 2.5 Le Diagnostique/Pronostique et la Décision . . . . . . . . . . . . . . . . 53 2.5.1 Algorithmes et modèles sous-jacents . . . . . . . . . . . . . . . . 54 2.5.1.1 Détection de la propagation de dégradation . . . . . . . 54 2.5.1.2 Prévention de dégradation : le modèle Markovien . . . 57 2.5.2 Fonctionnalités et architecture de mise en œuvre . . . . . . . . . 59 2.6 La Reconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 2.6.1 Algorithmes et modèles sous-jacents . . . . . . . . . . . . . . . . 60 2.6.1.1 Les algorithme de substitutions . . . . . . . . . . . . . 60 2.6.1.2 La formalisation de la substitution d’un service . . . . . 63 2.6.1.3 La formalisation de la substitution d’une opération . . . 66 2.6.2 Fonctionnalités et architecture de mise en œuvre . . . . . . . . . 68 2.6.2.1 Reconfiguration par connecteurs de liaison dynamique . 68 2.6.2.2 Reconfiguration par routage adaptatif au niveau HTTP . 70 2.6.2.3 Les niveaux de gestion de la QdS : SOAP vs. HTTP . . 70 2.7 Le protocole d’échange entre les composants de MARQ . . . . . . . . . 71 2.8 Le déploiement des composants de MARQ . . . . . . . . . . . . . . . . 73 2.9 La recherche et la sélection de service de substitution . . . . . . . . . . . 74 2.10 La Conception de MARQ . . . . . . . . . . . . . . . . . . . . . . . . . . 74 2.11 Règle de transformation en architecture auto-réparable en Bus . . . . . . 81 2.12 Intégration de l’auto-réparation niveau classe et niveau instance . . . . . . 83 2.12.1 Intégration Passive . . . . . . . . . . . . . . . . . . . . . . . . . 83 2.12.1.1 La phase transitoire gérée par SH-BPEL (I1) . . . . . . 83 TABLE DES MATIÈRES vii 2.12.1.2 La phase transitoire gérée par MARQ (I2) . . . . . . . . 84 2.12.2 Intégration active (I3) . . . . . . . . . . . . . . . . . . . . . . . . 84 2.12.3 Illustration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 2.13 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 3 Chapitre 3 : Expérimentations et Illustration 89 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 3.2 Le FoodShop : l’exemple de la chaîne de commande automatisé . . . . . 89 3.2.1 Hypothèses d’implantation . . . . . . . . . . . . . . . . . . . . . 91 3.2.2 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 3.2.3 La réparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 3.2.3.1 Le connecteur de reconfiguration niveau HTTP . . . . . 94 3.2.3.2 Le Connecteur de reconfiguration niveau SOAP . . . . 95 3.3 La revue coopérative : l’exemple d’un processus de coordination distribué 97 3.3.1 Description du scénario "Recherche de conférence" . . . . . . . . 98 3.3.2 Hypothèses d’implantation . . . . . . . . . . . . . . . . . . . . . 99 3.3.3 Environnement de développement . . . . . . . . . . . . . . . . . 100 3.3.3.1 Les grilles de calcul . . . . . . . . . . . . . . . . . . . 100 3.3.3.2 La grille’5000 . . . . . . . . . . . . . . . . . . . . . . 101 3.3.3.3 Configuration et préparatifs de l’expérimentation . . . . 101 3.3.3.4 Résultats et analyses . . . . . . . . . . . . . . . . . . . 104 3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Publications 109 viii TABLE DES MATIÈRES
  • Accueil Accueil
  • Univers Univers
  • Ebooks Ebooks
  • Livres audio Livres audio
  • Presse Presse
  • BD BD
  • Documents Documents