Soutenance mémoire
LE MODELE DE PROGRAMMATION PAR COMPOSANTS
Le développement orienté composant [HC01] a pour objectif la construction d’applications en intégrant des briques logicielles bien définies et autonomes, appelées composants. La notion classique de développer des applications en écrivant du code a été remplacée par l’assemblage de composants préfabriqués. Plusieurs avantages d’un tel modèle de programmation peuvent être cités :
-Les applications développées ne sont plus des blocs monolithiques mais le regroupement de « pièces » bien définies.
-Le fait que les frontières entre les différentes pièces soient bien spécifiées simplifie l’extension et la maintenance des applications. Grâce à la nature composable de l’application, et en cas de besoin de maintenance, il est plus facile de repérer et de remplacer les pièces concernées. Des mécanismes de surveillance sont souvent nécessaires pour permettre le repérage des composants qui doivent être remplacés.
-Le développement peut se faire d’une manière incrémentale en fonction des capacités de développement et selon les besoins des utilisateurs. Une application partiellement définie peut être exploitée dans l’état sans qu’elle soit obligatoirement complète. Ceci est particulièrement important pour les applications de grande taille.
-La collaboration est plus intuitive et la répartition des compétences est meilleure : des programmeurs bien spécialisés développent les composants de base et un assembleur se charge d’intégrer ces composants pour former l’application. Ce dernier manipule ainsi les composants comme des boîtes noires respectant une spécification précise sans se soucier de leurs détails internes.
-La réutilisation de composants préfabriqués, achetés sur étagère comme les COTS [Gen97, Voa98]. Ces composants sont développés indépendamment et destinés à être utilisés dans la construction de différents systèmes.
Iguana/J
Iguana/J [RC00, RC02] est une plate-forme développée, au début des années 2000, par le Distributed Systems Group au Trinity College de Dublin. Elle a été conçue pour supporter des adaptations dynamiques non anticipées des applications Java. La plate-forme est une extension de la machine virtuelle de Java. L’objectif de l’extension était d’ajouter la réflexion comportementale, pour supporter l’interception et la gestion des opérations, comme la création des objets, les invocations de méthodes, la lecture et l’écriture des attributs. Grâce à la capacité d’interception, de nouveaux comportements peuvent être ajoutés aux applications Java, sans avoir besoin de les modifier et de les recompiler. Initialement, Iguana était proposé comme une architecture réflexive indépendante d’un langage particulier [Gow97]. Elle a été d’abord implémentée pour le langage C++ (Iguana/C++) puis pour le langage Java (Iguana/J).
Rôles de développement
Pour créer une application, dynamiquement adaptable, Iguana/J prévoit trois rôles de développement complémentaires.
-Développeur du niveau de base : il crée les classes, les interfaces et les ressources responsables de fournir les fonctionnalités attendues du système.
-Développeur du méta-niveau : il crée les classes méta-objets, utilisées pour réifier les classes et les interfaces du niveau de base. Ces deux premiers développeurs sont censés être indépendants. Idéalement, aucun des deux n’a besoin de connaître le développement réalisé par l’autre.
-Intégrateur du système : il est responsable de fusionner les éléments fournis par les deux premiers développeurs. Il se charge ainsi de construire le système global. L’intégration consiste à créer les déclarations de sélection, qui permettent de lier les deux niveaux.
Utilisation des inter-procédures
PODUS permet que la nouvelle version d’une procédure, utilise une signature différente de l’ancienne. Pour garder la compatibilité entre les différentes procédures de l’application et la nouvelle version, le concept des inter-procédures a été introduit. Une inter-procédure est une procédure, écrite par le programmeur, et destinée à remplacer l’ancienne version dans le même espace mémoire. La Figure 18 illustre l’interaction entre une procédure de l’application et une nouvelle version d’une procédure. Comme le montre la Figure 18, la procédure Pi tente d’appeler la procédure Pj qui a été adaptée par une nouvelle version Pj’, ayant une signature différente. Une inter-procédure prend alors la place de la procédure Pj dans le même espace mémoire. Son rôle est de recevoir et de rediriger vers Pj’, les appels initialement envoyés vers Pj. L’inter-procédure est responsable, éventuellement, de récupérer le résultat retourné par Pj’, de le transformer en cas de besoin, avant de le transférer à Pi.
Polylith
Polylith [Pur94] est un système développé à l’université de Maryland. Sa première version a vu le jour en 1985. Il définit un langage de programmation, modulaire, basé sur le langage C. Polylith propose des solutions pour porter plus facilement, une application développée pour un environnement, vers un autre environnement. Dans une application distribuée, le développeur doit s’occuper des unités qui encapsulent le code applicatif, mais il doit aussi s’occuper du contexte d’utilisation de ce code. Ceci inclut par exemple la communication entre les unités, le marshalling des données avant de les envoyer sur le réseau, la gestion des erreurs de communication, l’adaptation de l’application en cas de besoin, etc. Les unités de l’application contiennent ainsi, à la fois, du code fonctionnel et du code non-fonctionnel, ce qui complique le développement et réduit les possibilités de réutilisation. L’idée qui est derrière Polylith est de proposer une approche qui permet au développeur de s’occuper uniquement de la logique applicative, le reste est pris en charge automatiquement par le système.
Le bus logiciel
Un bus est un intergiciel (middleware) [Ber96] qui définit les mécanismes d’interaction, et qui encapsule les détails de communication entre les modules. Le changement du mode d’interaction, peut être obtenu en changeant le bus. Aucune modification sur les modules n’est alors nécessaire. Pour construire un bus, principalement deux décisions doivent être prises :
-Comment les processus démarrés par le bus peuvent communiquer.
-Comment les requêtes, exprimées par un module développé dans un langage de programmation particulier, peuvent être traduites et mises en correspondance sur les méthodes abstraites du bus. Polylith supporte plusieurs types de bus, développés dans des travaux indépendants [PSW91]. Un développeur d’applications ne doit pas normalement s’occuper des bus. Les décisions qui concernent l’interaction entre les modules développés et le bus logiciel, et les décisions qui concernent la création des binaires pour un bus particulier, sont prises en charge par un système de packaging fourni par Polylith. En plus de la gestion de la communication entre les modules, le bus est aussi responsable de la reconfiguration dynamique des applications. Plusieurs situations peuvent se présenter en fonction de la localisation des modules. Si les modules doivent s’exécuter dans le même processus, et s’ils sont développés dans le même langage de programmation, le code binaire généré est identique à celui généré par un compilateur normal.
|
Table des matières
CHAPITRE 1 : INTRODUCTION
1 Contexte général
2 Introduction à la problématique de recherche
3 Principes de conception et démarche suivie
4 Organisation du document
CHAPITRE 2 : CONTEXTE SCIENTIFIQUE
1 Introduction
2 Le modèle de programmation par composants
2.1 Notion de composant
2.2 Le modèle JavaBeans
2.3 Le modèle Entreprise JavaBeans
2.4 Le modèle OSGi
2.5 Le modèle COM
2.6 Synthèse
3 Reconfiguration dynamique
3.1 Types de reconfiguration
3.2 Taxonomie
3.3 Propriétés des systèmes de reconfiguration
4 Systèmes réflexifs
4.1 Réification
4.2 Introspection
4.3 Intercession
4.4 Types de réflexion
5 Conclusion
CHAPITRE 3 : ETAT DE L’ART
1 Introduction
2 Solutions de reconfiguration fermées
2.1 Exemple d’adaptabilité dans OSGi
3 Solutions de reconfiguration partiellement ouvertes
3.1 OpenVL
4 Solutions de reconfiguration ouvertes
4.1 Iguana/J
5 Solutions de reconfiguration procédurales
5.1 DYMOS
5.2 PODUS
6 Solutions de reconfiguration modulaires
6.1 Polylith
7 Solutions de reconfiguration orientées objet
7.1 Les classes dynamiques de Java
8 Solutions de reconfiguration orientées composant
8.1 K-Components
8.2 DCUP
9 Solutions de reconfiguration issues du monde industriel
9.1 SNMP
9.2 JMX
10 Solutions de reconfiguration matérielles
10.1 ACARS
10.2 SCP
10.3 Discussion
11 Synthèse et conclusion
11.1 Synthèse des approches étudiées
11.2 Conclusion sur les approches étudiées
11.3 Aspects liés aux systèmes de reconfiguration
CHAPITRE 4 : EXPERIMENTATIONS PRELIMINAIRES
1 Introduction
2 Reconfiguration dynamique dans le modèle JavaBeans
2.1 Support de développement : la BeanBox
2.2 Extension de la BeanBox : la DBeanBox
3 Reconfiguration dynamique dans le modèle OSGi
3.1 OSGiAdaptor : service OSGi dédié à la reconfiguration
3.2 Gestion des communications
4 Adaptabilité dynamique des interfaces
4.1 Problème à l’origine d’OSL
4.2 OSL (OSGiServiceLookup)
5 Synthèses et conclusion
5.1 Synthèse de l’expérimentation sur le modèle JavaBeans
5.2 Synthèse de l’expérimentation sur le modèle OSGi
5.3 Synthèse globale
5.4 Conclusion sur les expérimentations préliminaires
CHAPITRE 5 : DYVA : UN NOYAU GENERIQUE POUR LA RECONFIGURATION DYNAMIQUE
1 Introduction
2 Motivations
3 DYVA : une conception réflexive
4 Architecture interne de DYVA
4.1 Modèle abstrait d’application utilisé par DYVA
4.2 Gestionnaire de reconfiguration
4.3 Capacité d’auto-reconfiguration
5 Vue externe de DYVA
5.1 Interface de notification
5.2 Interface de reconfiguration
5.3 Plugins de projection
6 Problème de transfert d’état
7 Processus de personnalisation et d’utilisation
8 Conclusion
CHAPITRE 6 : DYVA : IMPLEMENTATION
1 Introduction
2 Implémentation de l’architecture
2.1 Modèle abstrait
2.2 Organisation du méta-niveau
3 Outil d’assistance au transfert d’état
4 Interface graphique d’administration
5 Base de composants
5.1 Description explicite
5.2 Description partiellement calculée
5.3 Outil d’édition et de manipulation de la base de composants
6 Conclusion
CHAPITRE 7 : DYVA : PERSONNALISATION
1 Introduction
2 Interface de notification d’OSGi
3 Interface de reconfiguration d’OSGi
4 Plugins de projection
5 Outil d’instrumentation OSGi
6 Application de Portail Web
6.1 Description de l’application
6.2 Lancement de l’application
6.3 Utilisation et reconfiguration dynamique de l’application
7 Conclusion
CHAPITRE 8 : CONCLUSION ET PERSPECTIVES
8 Conclusion
8.1 Problématique de reconfiguration dynamique
8.2 Principales contributions et résultats obtenus
9 Perspectives de la thèse
9.1 Formalisation du problème de transfert d’état
9.2 Cohérence de la reconfiguration
9.3 Auto-reconfiguration
9.4 Approche par raffinement
9.5 Perspectives à court terme
Télécharger le rapport complet
