Télécharger le fichier original (Mémoire de fin d’études)
Extensibilité de la couche Transport
Au chapitre précédent, nous avons décrit l’architecture proposée pour la couche Trans-port. Les différents composants de l’architecture ont été présentés par leurs principes de fonctionnement et leurs comportements de base. Ces composants assurent l’évolu-tion de la couche Transport par des capacités d’extensibilité et d’adaptabilité. Dans ce chapitre, nous traitons plus en détails de l’extensibilité de l’architecture. Les aspects relevant de l’adaptabilité sont traités dans le chapitre 4.
Le cadre architectural présenté au chapitre 2 permet, en lui-même, d’assurer une cer-taine extensibilité pour l’architecture, notamment en rapport avec les nouvelles fonc-tionnalités de communication, que ce soit pour gérer de nouveaux services / compo-sant de Transport ou de nouvelles technologies réseau. Cependant, la notion d’exten-sibilité est beaucoup plus large, et doit aussi couvrir les composants de gestion et les interactions au sein de l’architecture. En réponse à ces besoins, nous présentons ici les composants, paradigmes et techniques qui garantissent l’extensibilité de notre archi-tecture.
Comme expliqué précédemment, la notion d’extensibilité peut avoir plusieurs signifi-cations. Nous l’entendons ici comme la capacité d’évoluer, par ajout ou modification de nouveaux composants, sans aucun impact sur les autres composants de l’architec-ture, les systèmes ou les applications. C’est cette capacité d’extensibilité qui lui per-mettra d’évoluer dans le temps. En effet, nous estimons que, parmi toutes les limites de la couche Transport qui l’empêche d’évoluer, l’extensibilité est la plus importante. Par ailleurs, nous estimons que le fait de ne pas traiter cette limite qui a fait que les architectures précédentes n’ont pas pu être déployées.
Le chapitre présente en premier les approches et paradigmes de conceptions utilisés dans l’ensemble de l’architecture. Ensuite il décrit les outils qui permettent l’extensibi-lité de l’architecture vis-à-vis des systèmes, l’extensibilité des composants de commu-nication et de gestion, et enfin l’extensibilité vis-à-vis des applications.
Approches de conception
Le premier élément ayant un impact sur le degré d’extensibilité de l’architecture réside dans son approche de conception. Tel que présenté au chapitre 2, nous avons opté pour un modèle orienté services et basé composants, associé à une inconscience sémantique des composants de gestion des éléments qu’ils manipulent.
Outils pour l’extensibilité de la couche Transport
Ce modèle, qui conduit à attribuer un composant logiciel à chaque service de Trans-port, permet de rendre la gestion de l’architecture et la construction des compositions inconsciente de la sémantique des composants. Pour chaque situation, une composi-tion est créée en tenant compte du contexte réseau en cours, du besoin de l’application et de la description de chaque composant. Ainsi aucun lien sémantique n’existe entre la partie de gestion de l’architecture et les composants de communication. Cette approche permet par la suite d’ajouter de nouveaux composants à l’architecture sans avoir à mo-difier quoi que ce soit dans sa partie de gestion, les nouveaux composants étant alors traités de la même façon que les composants déjà existant.
L’approche orientée services permet par ailleurs de séparer les services de Transport, tels qu’ils sont vus par les applications, de la façon dont ils sont réalisés concrètement par la couche Transport. Ceci lève la dépendance classique qui existe entre les applica-tions et les protocoles de Transport. Rappelons en effet qu’actuellement les applications sont écrites pour un protocole particulier, ce qui rend leur utilisation impossible avec d’autres protocoles sans modification du code de ces applications. Dans notre archi-tecture, les applications demandent uniquement des services, et la façon dont ceux-ci sont implantés leur est complètement transparente. L’approche par composant offre une indépendance logicielle entre les composants offrant les différents services. Les modifications portant sur un composant n’affectent ainsi ni les autres composants de communication, ni les composants de gestion. Enfin, l’inconscience sémantique permet aux composants de gestion de pouvoir tenir compte des nouveaux services et compo-sants de communication sans avoir à être modifiés.
Dans la suite de cette section, nous approfondissons l’ensemble de ces paradigmes (section 3.1.1), leur application à notre proposition d’architecture de la couche Trans-port (section 3.1.2), et la façon avec laquelle ils permettent d’assurer son extensibilité (section 3.1.3).
Description des paradigmes
L’approche suivant laquelle l’architecture a été conçue contribue en grande partie à résoudre les problèmes d’extensibilité dont souffre la couche Transport actuelle. Néan-moins, d’autres outils de conception, plus techniques, ont été nécessaires pour assurer cette extensibilité. Nous les étudions dans la suite de ce chapitre.
Approche orientée service (SOA)
Le modèle orienté-service a été proposé dans le but de permettre la portabilité des applications dans des environnements hétérogènes. Il se base sur le principe de la sé-paration entre un service et sa réalisation [58]. Les acteurs externes ayant à interagir avec un système, simple ou complexe, ont uniquement connaissance de la nature du service réalisé ainsi que de l’interface nécessaire pour l’invoquer (paramètres d’appel notamment). L’approche orientée services permet d’avoir un couplage très faible entre les différents composants d’un système, ou entre deux systèmes différents, en limitant autant que possible leurs interactions. Un couplage fort résulte soit d’une interaction importante entre les composants, ou d’une spécificité vis-à-vis d’une approche particu
L’approche orientée services s’apparente au paradigme de la programmation orientée objets qui sépare les interfaces des classes et leur implémentation concrète. Les services s’apparentent donc à des objets mais à plus grande échelle. Il peut s’agir de composants différents d’un même programme, de plusieurs programmes d’un même système, ou même de systèmes distants complètement différents. En outre, la notion d’objet s’ap-plique au niveau du codage (code source) alors que la notion de service s’applique au niveau de programmes finis (compilés).
Un faible couplage entre les différents services permet de pouvoir maintenir plus faci-lement les composants qui les implémentent, dès lors que les modifications qui y sont apportées n’affectent pas les autres services. La facilité de maintenance dont nous par-lons ici concerne la minimisation de l’impact de la maintenance d’un composant sur le reste du système.
La notion de « service », en elle-même, est difficile à déterminer. Aucun consensus n’a pu être établi [60]. Globalement, un service est la fonction de plus haut niveau dont l’uti-lisateur de service a besoin de connaitre la description. Un service doit donc être aussi abstrait que possible pour ne porter comme description que le minimum de détails dont l’utilisateur a besoin pour l’invoquer [58].
Dans leur application courante, les architectures orientées services utilisent un modèle par « inscription », suivant lequel un acteur intermédiaire (typiquement le Service Bro-ker de la figure 3.1) gère le lien entre les fournisseurs et les consommateurs de services [61].
Comme illustré sur la figure, l’utilisateur ou le consommateur de services contacte cet acteur intermédiaire afin de récupérer la liste des services offerts ainsi que les fournis-seurs associés. Dans d’autres modèles, l’acteur intermédiaire peut ne pas se limiter la publication des services, mais gère aussi les requêtes et les réponses entre les utilisa-teurs et les fournisseurs de services.
Table des matières
Résumé
Table des matières
Table des figures
Introduction
1 Etat de l’art et Positionnement
1.1 Evolution des protocoles de Transport
1.1.1 Approche générales et approches spécifiques
1.1.2 Solutions pour les applications et solutions pour les réseaux
1.1.3 Nouveaux protocoles et nouvelles versions
1.1.4 Analyse comparative
1.2 Limites de la couche Transport
1.2.1 Configurabilité
1.2.2 Adaptabilité
1.2.3 Flexibilité
1.2.4 Complexité
1.3 Évolutions architecturales au niveau Transport
1.3.1 Nouvelles architectures
1.3.2 Outils conceptuels pour les architectures configurables
1.3.3 Autonomie
1.4 Le modèle ATN/OSI
1.4.1 Présentation de l’ATN
1.4.2 La pile de protocoles ATN/OSI
1.4.3 La transition vers IP
1.5 Présentation des contributions
1.5.1 Positionnement des contributions
1.5.2 Contributions de la thèse
1.6 Conclusion
2 Architecture pour la couche Transport
2.1 Limites et besoins
2.1.1 Limites des architectures existantes
2.1.2 Besoins pour une couche Transport évolutive
2.2 Une nouvelle architecture pour la couche Transport
2.2.1 Principes généraux et positionnement
2.2.2 Description globale de l’architecture
2.2.3 Structuration par rapport aux besoins
2.3 Description des composants
2.3.1 Composants de gestion de l’architecture
2.3.2 Bases de données
2.3.3 Composants de gestion des connexions
2.4 Cas d’utilisation et description comportementale
2.4.1 Cas d’utilisation
2.4.2 Description comportementale
2.5 Conclusion
3 Extensibilité de la couche Transport
3.1 Approches de conception
3.1.1 Description des paradigmes
3.1.2 Application à la couche Transport
3.2 Extensibilité vis-à-vis des systèmes
3.2.1 Indépendance au noyau
3.2.2 Contraintes de mise à l’échelle
3.3 Extensibilité des composants de communication
3.3.1 Décomposition par services
3.3.2 Composant d’intégration et base locale des composants
3.3.3 Interactions entre composants
3.3.4 Invocation des composants
3.3.5 Autres éléments extensibles
3.4 Extensibilité des composants de gestion
3.4.1 Interface applications
3.4.2 Composant de décision
3.4.3 Cas du gestionnaire des applications legacy
3.5 Extensibilité des applications
3.5.1 Base globale des services
3.5.2 Interface abstraite
3.6 Conclusion
4 Autonomie de la couche Transport
4.1 Besoins et problématique
4.1.1 Besoin en autonomie
4.1.2 Niveaux d’autonomie
4.1.3 Autonomie de la sélection des composants
4.2 Monitoring et changement de contexte
4.2.1 Recueil des données de monitoring
4.2.2 Profils de réseau et changements de contextes
4.2.3 Algorithme de détection de changement de contexte
4.3 Processus de décision
4.3.1 Eléments théoriques
4.3.2 Traitement de la requête de l’application
4.3.3 Sélection des composants
5 Implémentation et Évaluation
5.1 Implémentation et déploiement
5.1.1 Intégration et interaction des composants
5.1.2 Principes d’intégration au noyau
5.1.3 Décision prédéfinie
5.2 Cas d’étude et évaluation
5.2.1 Cas d’étude
5.2.2 Evaluation des performances
5.3 Conclusion
Conclusion et Perspectives
Bibliographie
