La maintenance d‟une application à composants comporte généralement des opérations d‟adaptation de composants. Ces dernières consistent à changer les valeurs des propriétés des composants, à changer l‟architecture de l‟application en redéfinissant les connections entre les composants ou encore à remplacer un composant par un autre qui peut éventuellement fournir et requérir des contrats différents du composant remplacé. Généralement, l‟adaptation requière de déconnecter le composant de l‟application, de transférer son état courant vers un nouveau composant et puis de connecter ce dernier aux autres composants de l‟application.
Aussi, l‟opération d‟adaptation réclame généralement l‟arrêt de l‟application et oblige à reprendre le cycle de vie à partir de la phase d‟assemblage, se qui n‟est pas possible pour les applications qui réalisent des tâches critiques, telles que les applications de télécommunication et les applications bancaires. Pour résoudre ce problème, la notion de l‟adaptation dynamique est apparue, et qui consiste à introduire des modifications dans l‟application au cours de son exécution sans nécessairement arrêter totalement l‟application.
Actuellement, la plupart des modèles de composants qui existent ne sont pas adaptables, ce qui nécessite, donc, d‟arrêter les applications basées sur ces modèle pour les adapter et les mettre à jour. Ce travail nous a permis d‟identifier ce manque et ce problème, particulièrement pour le modèle de composant COM, qui est un modèle non adaptable et non réflexif. Nous avons eu comme principal objectif de rendre celui-ci adaptable en utilisant les langages de script.
Un des points délicats de l‟adaptation dynamique est le transfert de l‟état d‟un composant à un autre quand l‟état est constitué d‟objets difficilement transférables tels qu‟un socket ou bien la pile d‟exécution d‟un thread. De plus, l‟opération d‟adaptation devait répondre à plusieurs contraintes comme la sécurité, la fiabilité, la complétude et la possibilité de retour en arrière dans le cas où l‟adaptation ne peut se terminer avec succès.
Résumé des contributions
La première contribution principale de ce travail est le modèle ScriptCOM qui étend le modèle de composants COM, permettant, ainsi, de faciliter le développement d’applications à base de composants adaptables pendant leurs exécutions par une entité externe (un composant ou une application ou un humain) ou par le composant lui même. Notre idée principale était le fait qu‟il n’était pas nécessaire de redéployer le composant pour le mettre à jour par une entité externe.
Nous sommes arrivés à réaliser une opération d‟adaptation qui répond à plusieurs contraintes, dont la plus importante est la garantie de la cohérence de l‟application qui est reliée avec le passage d‟état entre les composants. Nous avons abouti à ce résultat grâce à l‟utilisation des langages de script pour l‟implémentation des composants car, ils permettent une programmation incrémentale, c.à.d. la possibilité d‟exécuter et de développer simultanément les scripts qui représentent, dans notre contexte, l‟implémentation des composants. La définition de ScriptCOM s‟est basée sur les principes fondamentaux suivants:
Comme ScriptCOM est une extension du modèle de composant COM, il est basé sur les mêmes règles de ce dernier.
En plus des principes de COM, nous avons introduit trois contrôleurs permettant de rendre un composant COM adaptable durant son exécution par une entité externe ou par lui même.
Ces contrôleurs sont :
– Le contrôleur d‟interface CI qui permet l‟ajout, la modification et le retrait des interfaces sur une instance du composant.
– Le contrôleur de script CS qui permet de faire évoluer de manière incrémentale un script programmé dans un langage de script quelconque, à condition que son interpréteur soit disponible dans l‟environnement d‟exécution.
– Le contrôleur de propriétés CP qui permet l‟ajout, la modification, et le retrait des propriétés dans l‟instance du composant.
Dans notre contexte, un composant a un type initial (interfaces), un comportement initial (un script) et une liste initiale de contrôleurs. Le type et le comportement de chaque instance peuvent muter indépendamment par l‟action des contrôleurs sur l‟instance du composant.
Aussi, un composant ScriptCOM représente, dans notre approche, une boîte blanche, parce que la source du composant est entièrement disponible et peut être étudiée, réutilisée, adaptée ou modifiée. La deuxième contribution de ce travail est les mécanismes de maintien de la cohérence des applications sujets à des adaptations dynamiques.
Nous avons intégrer dans notre modèle ScriptCOM un mécanisme de retour en arrière. Ce dernier permet d‟annuler l‟adaptation et faire retourner l‟application à son état initial. Nous avons atteint cet objectif en vérifiant en premier lieu la correction (correctness) de l‟application. S‟il y a certaines erreurs trouvées, le mécanisme va être déclenché.
Notons que la vérification de la correction de l‟application est une partie très importante et essentielle pour atteindre notre objectif. Pour cela, nous avons implémenté aussi un mécanisme de vérification de la correction de l‟application. Ces deux mécanismes réalisés rendent ScriptCOM plus puissant et plus intéressant que la plus part des modèles de composant commerciaux qui existent sur le marché.
Nous avons aussi développé une application de gestion financière d‟un magasin qui fait la vente et la maintenance de matériels informatiques. Cet exemple permet de valider nos propositions et aussi de montrer l’intérêt de ScriptCOM pour accélérer et faciliter le développement des applications adaptables.
En particulier, nous avons montré l’utilité de ScriptCOM quand il s’agit d‟exécuter des adaptations dynamiques et quand il s’agit de faire un retour en arrière pour préserver la cohérence de l‟application. ScriptCOM n’est pas restreint au seul cas des applications de gestion. Au contraire, il peut être appliqué à toute application qui peut offrir différentes qualités de service en fonction des ressources disponibles.
Limites et perspectives
L’expérimentation du modèle ScriptCOM nous a permis d’identifier quelques limites de la solution proposée et a soulevé de nouvelles questions qui peuvent constituer des axes de recherche pour les travaux futurs.
Parmi les travaux possibles à réaliser, nous citons :
– Vérification de l’architecture :
Un problème qui peut être posé dans notre proposition est que les erreurs peuvent être introduites dans l‟architecture lors de l‟usage des opérations des trois contrôleurs proposés. Par exemple, la suppression de la déclaration d‟une méthode dans une interface fournie par un composant, conduit à un blocage de l’exécution fonctionnelle des composants qui invoquent celle-ci. Pour résoudre ce problème, il faux que nous intégrons dans ScritpCOM un mécanisme de vérification de l‟architecture des applications sujettes à des adaptations.
– L’implémentation du ScriptCOM en d’autres langages de script.
L‟implémentation de ScriptCOM est basée sur la technologie Windows Script Component avec JScript comme langage de script. Une autre perspective de ce travail est l‟utilisation d‟autres langages de script, tel que VB (Visuel Basic) pour l‟implémentation de ScriptCOM et de ces composants. Pour le VB, son interpréteur existe déjà dans le host de script Windows, ce qui facilite son utilisation pour le développement des composants ScriptCOM. De plus, l‟implémentation de notre modèle dans d‟autres langages de script augmente son utilisation par les développeurs.
– Généralisation à d’autres modèles de composants.
Notre proposition de l‟utilisation des contrôleurs pour réaliser des adaptations dynamiques est basée sur le modèle de composant COM. Par ailleurs, et pour aller au delà de ce modèle, notre proposition pourrait être généralisée et appliquée à d’autres modèles de composants qui possèdent des capacités similaires d‟adaptation. Le modèle OSGi est ainsi une cible potentielle pour intégrer nos travaux. Cette généralisation nécessiterait un effort de modélisation des concepts de ces différents modèles en terme d’éléments architecturaux et de relations entre ces éléments, comme cela a été fait pour COM.
Retour au menu : UTILISATION DES SCRIPTS POUR LE DEVELOPPEMENT DES COMPOSANTS COM ADAPTABLES