THÈSE. Présentée à. en habilitation conjointe avec l Université de Rennes 1. En vue de l obtention du grade de. DOCTEUR de l ENST Bretagne.

Transcription

1 N o d ordre: 2008telb0060 THÈSE Présentée à l ÉCOLE NATIONALE SUPÉRIEURE DES TÉLÉCOMMUNICATIONS DE BRETAGNE en habilitation conjointe avec l Université de Rennes 1 En vue de l obtention du grade de DOCTEUR de l ENST Bretagne Mention Informatique par Meriem Belguidoum Titre de la thèse : Conception d une infrastructure pour un déploiement sûr et flexible des composants logiciels À soutenir le 27 février 2008 devant la commission d examen Françoise André Professeur à l Université de Rennes1 Président Laurence Duchien Professeur à l Université de Lille Rapporteurs Ralf Treinen Professeur à l Université Paris Diderot Antoine Beugnard Professeur à l ENST Bretagne Examinateurs Mickael Salaun Chercheur à FT R&D Fabien Dagnat Maître de conférences (Encadrant) Guy Bernard Professeur à l INT (Directeur de thèse)

2

3 à mes parents, à mon époux, à ma famille, à mon petit ange.

4

5 Remerciements Je tiens d abord à remercier tous les membres du jury qui ont accepté de juger mon travail. Un très grand merci à mes rapporteurs, Laurence Duchien et Ralf Treinen pour le temps qu ils ont consacré pour rapporter cette thèse avec tant d attention et de pertinence. Je remercie mon directeur de thèse Guy Bernard qui m a toujours encouragé, mon encadrant Fabien Dagnat qui m a offert une bonne ambiance de travail et qui m a appris beaucoup de choses durant ces trois années. Un grand merci pour Antoine Beugnard pour ses encouragements et ses conseils. Enfin, un merci pour Mickael Salaun pour son attention et sa présence. Je tiens à remercier tous les membres du département informatique particulièrement Anne-Marie, Odile, Armelle, Paul pour leur qualités humaines remarquables et et leurs encouragements. Mes derniers remerciements qui ne sont pas les moindres sont pour les personnes les plus chères dans ma vie, mes parents qui ont tout sacrifié pour moi et qui m ont toujours soutenu dans tout ce que j entreprenais. Ce travail est le fruit de leurs patiences et sacrifices. Je ne pourrais pas oublié mon époux qui a subi tous les désagréments durant ces deux années et m a énormément motivé.

6

7 Résumé Le déploiement de logiciels est une tâche complexe car elle nécessite la réalisation de nombreuses actions ayant de fortes contraintes de dépendance. Il recouvre toutes les activités qui composent le cycle de vie du logiciel depuis son développement jusqu à son utilisation. Dans le cadre de ce travail, nous nous intéressons aux activités d installation, de désinstallation et de mise à jour. En parallèle, les applications deviennent de plus en plus complexes, ce qui provoque une explosion de leur taille. Pour faciliter leur gestion et leur réutilisation, elles sont représentées par des collections de composants qui sont partagés entre plusieurs applications. Ainsi, une opération de déploiement concernant une application aura un effet sur toutes les applications qui l utilisent. Une telle opération, nécessite la connaissance préalable de l architecture sur laquelle repose les applications avec toutes leurs dépendances. Les approches de gestion du déploiement actuelles sont souvent ad-hoc et se basent sur l intervention d experts pour résoudre les problèmes et mener à bien le déploiement. De plus, il n existe pas de moyens efficaces pour garantir le bon déroulement du déploiement. Il est donc crutial de changer ces approches en des approches plus structurées, plus flexibles et plus sûres afin de maîtriser et de vérifier le déploiement. Pour cela, nous proposons un méta-modèle générique pour le déploiement automatique des composants ainsi qu un système formel pour vérifier et garantir le bon déroulement du déploiement. Le méta-modèle permet d abstraire tous les concepts nécessaires au déploiement ainsi, il peut être réutilisable dans plusieurs contextes. Le système formel est une formalisation mathématique du modèle générique. Il permet de démontrer et de prouver la réussite (le bon déroulement) et la sûreté (maintien de la cohérence du système) des opérations de déploiement. Enfin, nous proposons un système formel intégrant les propriétés non fonctionnelles (version, niveau de sécurité, performance, etc.) dans la gestion du déploiement. L intérêt est de pouvoir prendre en compte plusieurs instances d un même composant ou d un même service selon la plate-forme visée afin de personnaliser le déploiement. Mots clés : composants logiciels, déploiement sûr, gestion des dépendances, métamodélisation, preuve formelle.

8

9 Abstract Software deployment is a complex task because it requires numerous dependent actions to be carried out. It covers all the activities of the software life cycle from its development to its use. In this work, we are interested in the installation, deinstallation and update activities. At the same time, applications are becoming more complex, causing an explosion in their size. To facilitate their management and reuse, they are represented as collections of components that are shared between several applications. Thus, deploying an application will affect all the applications that use it. Such an operation requires prior knowledge of the architecture of the applications with all their dependencies. The current approaches for managing deployment are often ad hoc and necessitate the intervention of experts to solve problems and carry out the deployment. Moreover, there is no way to guarantee the correctness of the deployment operation. Therefore, it is necessary to change to more structured, flexible and reliable approaches to be able to verify the deployment. Hence, we propose a generic meta-model for automatic component deployment and a formal system to check and ensure correct deployment. The meta-model represents the main deployment concepts so it can be re-used in several contexts. The formal system represents the mathematical description of the generic model. It allows the success and safety (maintaining consistency of the system) of the deployment operations to be demonstrated and proved. Finally, we propose a formal system which integrates the non-functional properties (version, level of security, performance, etc.) in managing the deployment. The interest of these properties is that they can take into account multiple instances of the same component or the same service in order to personalize deployment, depending on the target system. Key words : software component, reliable deployment, dependency management, meta-modeling, formal proof

10

11 Table des matières Table des matières 1 I Déploiement : contexte, modèles et outils 19 1 Les composants et les services Les concepts principaux des composants logiciels Représentation d un composant Cycle de vie Langage de description d architecture Quelques modèles de composants CCM Microsoft.NET Fractal Les modèles orientés services Les concepts principaux des services OSGi Le service binder FROGi SCA Synthèse Synthèse Conclusion Le déploiement : principaux concepts Qu est-ce que le déploiement? Les acteurs de déploiement Les entités déployées Le cycle de vie du déploiement Quelques problématiques de déploiement Le déploiement dirigé par les modèles La spécification D&C ORYA CADeComp

12 2 Table des matières Synthèse Conclusion Réalisation et description du déploiement Quelques outils de réalisation du déploiement Les gestionnaires de paquets Nix Installshield Quelques langages de description des entités du déploiement Les langages de description de composants Les langages de description des paquets Descripteur dans EDOS UML Quelques standards de description Synthèse Comment décrire nos modèles de déploiement? Les ressources Les mécanismes Les politiques Les propriétés Conclusion Préambule sur les contributions Introduction Description des entités du déploiement Modélisation du déploiement Le modèle générique Le méta-modèle du déploiement Synthèse Réalisation du déploiement II Vérification formelle du déploiement Description formelle des entités de déploiement Introduction Les dépendances des composants logiciels Un exemple de composant et d assemblage Description des dépendances Construction d un assemblage de composant Description du système cible Conclusion

13 Table des matières 3 6 L installation et la désinstallation de composants Introduction Description de l installation Installabilité Installation Exemple d installation Description de la désinstallation Désinstallabilité Désinstallation Trois exemples de désinstallation Conclusion Mise à jour des composants Description de la mise à jour Définition de la substituabilité Substituabilité des composants Formalisation de la substituabilité Interprétation dans notre système Algorithme de substitution Deux exemples de mise à jour Mise à jour par un composant fournissant moins Mise à jour par un composant fournissant plus Quelques travaux connexes Synthèse Conclusion Extension du système par les propriétés Description des propriétés Description des dépendances Description du contexte Description de l installation L installabilité L installation Deux exemples d installation Description de la désinstallation La désinstallabilité La désinstallation Description de la mise à jour Algorithme de substitution Exemple Conclusion

14 4 Table des figures III Mise en œuvre et validation Mise en œuvre de l architecture de déploiement Présentation de l architecture de déploiement Mise en œuvre de l architecture de déploiement Mise en œuvre du moteur de déploiement Architecture du moteur de déploiement Quelques exemples d illustration Intégration du moteur de raisonnement dans OSGi Architecture de déploiement répartie Langage de déploiement La gestion du déploiement Interface graphique Conclusion Comparaison avec les paquets et les composants Comparaison avec les paquets Description des paquets Gestion des paquets Comparaison de la description des paquets Discussion Comparaison avec les composants Forme usuelle des composants Les composants orientés services Synthèse Preuve formelle Introduction La propriété de réussite La réussite de l installation La réussite de la désinstallation La propriété de sûreté La sûreté d installation La sûreté de désinstallation Conclusion Conclusion et perspectives 219 Bibliographie 231

15 Table des figures 1 Organisation du manuscrit Méta-modèle des principaux éléments d un composant [Ous05] La composition de composant Architecture générale de.net Architecture générale des modèles à services Architecture multi-couche d une plate-forme OSGi [Ope03a] Structure d un bundle Cycle de vie d un bundle OSGi Le composant SCA Le modèle d assemblage SCA La granularité des entités déployées Cycle de vie du déploiement Le modèle de données de composant [OMG06] Le modèle de données de cible [OMG06] Le méta-modèle de déploiement [Mer04] Le méta-modèle de groupe [Mer04] Le méta-modèle de machine Le méta-modèle de l unité du déploiement [Mer04] Architecture de CADeComp [Aye05] Modèle de paquet de composant [Aye05] Le domaine de déploiement Le constructeur (a) et la composition (b) de GNU Hello avec d autres composants [Dol06] Expression Nix pour GNU Hello [Dol06] Assemblage Fractal de l exemple HelloWorld Un exemple d un fichier SPEC rpm Exemple d un fichier control DEB Un exemple de configuration décrite en UML Exemple de description RDF Le méta-modèle d un composant Notre représentation graphique

16 6 Table des figures 4.3 Les relations de dépendances Les quatre modèles du déploiement Les trois niveaux de modélisation Les principales phases de déploiement Principe (a) d installation (b) de désinstallation et (c) de mise à jour L analyse des dépendances L espace multidimensionnel des dépendances [KBK00] Un exemple de serveur mail Les intra-dépendances du composant POSTFIX Exemple d un composant de mise à jour Une partie du graphe de dépendance d un système contenant le composant de la figure Une partie du graphe de dépendance du serveur mail de la figure Principe d installation Les règles d installabilité et d évaluation des prédicats Les règles de calcul du graphe de dépendance Les règles d installation Principe de désinstallation Le graphe de dépendance du composant de mise à jour MAJ Désinstallation du composant MAJ Désinstallation du composant SÉCURITÉ Un exemple d authentification SVN via APACHE Avant et après la désinstallation du composant Perl-LDAP La compatibilité verticale et horizontale Comparaison entre les services fournis et requis de C old et C new Les phases de substituabilité Exemple d un serveur mail avec le composant ORGANIZER Le graphe de dépendance du serveur mail de la figure Substitution de THUNDERBIRD par SYLPHEED Le composant SEAMONKEY Substitution de THUNDERBIRD par SEAMONKEY Extension de la grammaire des dépendances Extension des règles d installabilité Extension des règles de calcul du graphe Extension des règles d installation Les phases de substituabilité avec vérification des propriétés Exemple d un lecteur multimédia Monde réel vs monde formel Diagramme de séquence du déploiement Architecture du déploiement en Fractal

17 Table des figures Architecture du prototype du moteur de raisonnement en OCaml La preuve de l installation de POSTFIX La preuve de la désinstallation de POSTFIX la preuve de la substitution de THUNDERBIRD par ICEDOVE Architecture de déploiement réparti La négociation et le déploiement Interface graphique du prototype du déploiement réparti La description debian du paquet POSTFIX Description graphique du composant POSTFIX Encapsulation des paquets Exemple d un éditeur de texte Description des intra-dépendances de POSTFIX

18 8 Table des figures

19 Liste des tableaux 1.1 Étude comparative des modèles de composants et de services Comparaison des différents modèles étudiés Les langages de description des entités et des systèmes de déploiement Les différentes possibilités de substituabilité Les condition de substituabilité Résumé des conditions de substituabilité Résumé sur les travaux connexes Comparaison de la description Debian avec la notre Comparaison entre les paquets les composants et notre description

20 10 Liste des tableaux

21 Introduction Contexte de travail Le déploiement de logiciels est une tâche complexe car elle nécessite la réalisation de nombreuses actions ayant de fortes contraintes de dépendance. Il recouvre toutes les activités qui composent le cycle de vie du logiciel depuis son développement jusqu à son utilisation. En effet, il ne s agit pas uniquement d installer ces logiciels, mais de les gérer jusqu à leur désinstallation en passant par toutes les activités intermédiaires. Les principales activités sont : l installation, la désinstallation et la mise à jour. L installation consiste à ajouter une entité dans un système, la désinstallation consiste à la supprimer et la mise à jour consiste à la remplacer par une autre. Cependant, pour réaliser toutes ces activités, il faut d abord s assurer de leur faisabilité (elles ne conduisent pas le système à un état de conflit) avant leur réalisation. Nous constatons que la gestion de ces activités est encore plus complexe devant l utilisation massive des différents logiciels. Une automatisation des activités de déploiement de logiciels est à priori nécessaire. D autre part, les logiciels deviennent de plus en plus complexes, ce qui provoque une explosion de leur taille (on arrive souvent à plusieurs millions de lignes de code). Pour rendre possible leur gestion, ils doivent être découpés en «bouts de logiciel» appelés par la suite composants. Ce découpage est fait suivant des critères divers et variés issus du domaine du génie logiciel, comme par exemple la réutilisation. Ainsi, un logiciel consiste en une très large collection de composants. Par ailleurs, les terminaux possèdent des ressources limitées et les applications utilisent souvent les mêmes composants, il est nécessaire de partager les composants communs entre applications pour optimiser l utilisation des ressources. En conséquence, si un composant est partagé entre plusieurs applications, une opération de déploiement touchant ce composant aura un effet sur toutes les applications qui l utilisent. Pour cela, il est nécessaire de maîtriser toutes les opérations de déploiement, il faut donc connaître l architecture de toutes ces applications. Cette architecture décrit toutes les dépendances qui existent entre les différentes applications et les différents composants qui la constitue. La description explicite de ces dépendances permet de bien gérer les opérations de déploiement et de contrôler leurs effets sur l ensemble des applications. Il est donc nécessaire d avoir des mécanismes appropriés pour pourvoir vérifier le bon déroulement du déploiement, de contrôler sont effet sur le système et de maîtriser sa complexité. Les approches de gestion du déploiement actuelles ne sont pas à la mesure de la 11

22 12 Introduction complexité de la tâche de déploiement. Elles sont souvent ad hoc et nécessitent l intervention d experts pour résoudre les problèmes liés au déploiement. Ces approches utilisent aussi des langages de scripts pour réaliser le déploiement. Ces langages ne permettent pas de construire des descriptions suffisamment génériques car ils sont souvent destinés à des tâches précises et/ou un site particulier. Il faut donc définir des solutions particulières pour chaque tâche et pour chaque site. Ainsi, ces solutions sont donc peu réutilisables De plus, un script rend la vérification a priori du bon déroulement du déploiement impossible, puisque sa description est pauvre et ne permet pas le contrôle des opérations de déploiement. En effet, il ne permet pas d exprimer des contraintes sur le déploiement comme par exemple, vérifier que l effet du déploiement n invalide pas les invariants du système cible (sûreté du déploiement) [PDC01]. Une autre constatation est le problème de la gestion uniforme du déploiement sans tenir compte de l hétérogénéité des applications et des sites. Cette gestion est caractérisée par le manque de flexibilité dans le sens où le traitement est toujours figé et ne s adapte pas aux différents besoins. Ainsi, la réalisation du déploiement est la même malgré la diversité des besoins des utilisateurs, des infrastructures, etc. (pas de gestion flexible). Nous visons donc un déploiement flexible qui se base sur des concepts plus génériques et pouvant être spécialisés. Les travaux de recherche nécessaires pour aboutir à un déploiement réussi, sûr et flexible sont encore nombreux. Le principal travail consiste à passer d une approche pragmatique proposant des solutions ad hoc spécifiques à certains cas, à une véritable approche structurée, adaptable et sûre afin de maîtriser et de vérifier le déploiement. Il est donc possible d envisager de conférer à ces systèmes une vérification formelle du déploiement avec une adaptation des applications au système cible. Nous pouvons ainsi résumer ces différentes problématiques de déploiement logiciel comme suit : 1. Comment faciliter l écriture des programmes de déploiement? 2. Comment garantir que ces programmes de déploiement respectent des propriétés attendues? Pour le premier point, il est primordial d une part, de comprendre et de modéliser le domaine du déploiement et d autre part, de décrire formellement les entités impliquées par le déploiement ainsi que les programmes de déploiement. Le deuxième point consiste à vérifier ces contraintes et de garantir le respect des propriétés attendues par les règles de déploiement. Il est donc nécessaire d avoir une approche structurée et systématique pour permettre un déploiement flexible qui s adapte au système cible, et une approche formelle pour garantir le bon fonctionnement du système cible. Concernant le besoin de la description abstraite, nous pouvons citer les exemples de programmation objet, la méta programmation, les aspects, etc. permettant la construction des programmes de meilleure qualité, plus réutilisables en dehors de leur contexte initial et souvent plus flexibles. Ainsi, le concepteur ou le programmeur pourrait exprimer plus clairement (avec un langage plus abstrait) ses besoins. De la même façon, nous pensons que dans le domaine de déploiement, il y a un besoin de concept de structuration et de description de haut niveau pour garantir la sûreté du déploiement.

23 Introduction 13 Problématiques et objectifs Les techniques de déploiement actuelles manquent d un modèle de déploiement de haut niveau décrivant les différentes entités de déploiement (englobant des concepts pouvant influer sur le déploiement), d un moyen pour garantir le bon déroulement des opérations de déploiement (réussite du déploiement) et de contrôler leurs effets sur le système (sûreté du déploiement). Le manque d un modèle de déploiement générique est dû essentiellement à l absence d un consensus sur la définition des différents concepts, modèles et architectures du système de déploiement. Les modèles de déploiement construits devraient être abstraits afin de garantir un déploiement flexible et une gestion de déploiement indépendante des contraintes du site cible. Afin de maîtriser le déploiement dans un système, il faut d une part, déterminer ses principaux modèles qui représentent ses concepts les plus pertinents et les décrire de façon abstraite, et d autre part, définir un ensemble de règles vérifiant le déploiement et garantissant sa réussite et sa sûreté. Pour ce faire, il est important d avoir une approche déclarative pour décrire les entités qui sont déployées. La description du site cible doit représenter toutes ses caractéristiques matérielles et logicielles existantes. En effet, il est important d avoir un langage de description régulier qui permet d exprimer tous les besoins des applications ainsi que leurs effets d une manière explicite. Une description non précise des besoins, des effets ainsi que les contraintes exigées par le système cible peut mener à des dépendances non satisfaites et empêcher, en conséquence, l exécution de l application. Pour résoudre ce problème, il est nécessaire d avoir un langage de description précis et clair ayant une sémantique bien fondée. Pour garantir la réussite et la sûreté du déploiement, il est nécessaire de fournir une preuve pour vérifier la possibilité du déploiement et pour vérifier son effet sur le système. Dans la mesure du possible, le déploiement doit assurer les propriétés exigées par le système cible et/ou l application (la qualité de service, etc.). En effet, il doit être adapté aux besoins de l application et aux exigences du site selon les propriétés de l un et/ou de l autre. Par exemple, un système ou une application peut exiger un certain niveau de sécurité pour effectuer le déploiement. Cette contrainte sera vérifiée avant le déploiement de l application, si elle n est pas vérifiée le déploiement ne sera pas possible. Démarche suivie Dans le cadre de cette thèse, nous visons deux objectifs principaux qui sont : garantir le bon fonctionnement du système cible, et pouvoir adapter le déploiement en fonction des exigences et des propriétés visées par les politiques du système cible. Pour ce faire, nous procédons par les étapes suivantes : 1. L étude et la compréhension du déploiement et des modèles existants pour proposer un modèle générique de déploiement ;

24 14 Introduction 2. La description explicite des entités nécessaires au déploiement à savoir les dépendances de l application en question et la description du contexte du site cible ; 3. La proposition de règles formelles permettant de prouver le déroulement correcte des différentes phases de déploiement et 4. La proposition d une extension des descriptions proposées par des propriétés pour spécialiser les entités de déploiement Le travail présenté dans cette thèse constitue une brique de base d un système de déploiement pouvant garantir une gestion correcte, sûre et adaptable au contexte. Il s agit donc d une proposition d une infrastructure de déploiement de composants logiciels qui prend en compte deux aspects. Le premier aspect, est celui de la structuration et de la modélisation du déploiement afin de gagner en flexibilité. Le second aspect, est la formalisation du déploiement dans le but d assurer le bon fonctionnement du site cible en prouvant que le déploiement s est bien déroulé et il garantit bien les deux propriétés de réussite et de sûreté. La propriété de réussite permet d assurer qu une fois les exigences et les règles de déploiement vérifiées, l application est correctement déployée (fonctionne dans le cas de l installation et de la mise à jour, et ne fonctionne plus dans le cas de la désinstallation). La propriété de sûreté garantit l évolution du système, afin de fournir l assurance qu après chaque opération de déploiement le système sera dans un état dans lequel les entités déjà existantes sont toujours utilisables et les entités rajoutées sont également utilisables (cas de l installation et la mise à jour par exemple). Cette définition repose sur l hypothèse que la description des exigences ainsi que les effets des composants sont complètes. Selon l approche classique [Szy98], un composant requiert des services et en fournit. La relation qui existe entre un service fourni par un composant et ses services requis est l intra-dépendance. Une spécification précise de cette dépendance permet au système de gestion du déploiement de s assurer que (1) les exigences du composant sont satisfaites et (2) ses effets (ses services fournis) ne détériorent 1 pas le système cible. Un démonstrateur de déploiement basé sur les descriptions logiques du système cible et de l entité déployée permet, de garantir le bon déroulement des opérations de déploiement. Par exemple, le mécanisme de gestion du déploiement des systèmes actuels doit être capable de s assurer que l entité est déployable et n aura aucune mauvaise répercussion (conflits par exemple) sur le site. Enfin, nous avons fourni une preuve de la réussite et de la sûreté des opérations d installation et de désinstallation qui sont réalisées par l infrastructure de déploiement que nous avons proposés. Contributions Cette thèse vise à fournir, d une part une modélisation abstraite du déploiement avec les principaux concepts du déploiement pour permettre un déploiement flexible, et d autre part, un cadre formel pour le déploiement afin d assurer la réussite du déploiement et la sûreté du site cible. Nous proposons donc une infrastructure de déploiement 1 Dans le sens de «une application qui fonctionnait ne peut plus être utilisée».

25 Introduction 15 qui se base sur des modèles abstraits et sur un système formel pour la vérification et la preuve des opérations déploiement du déploiement. Nous avons également défini les propriétés de réussite et de sûreté des opérations d installation et de désinstallation et nous les avons prouvées. Les contributions de cette thèse sont donc les suivantes : La définition d un modèle de déploiement générique qui englobe les principaux concepts qui nous intéressent dans le déploiement. Chaque concept représente un rôle bien particulier. Nous défendons un découpage en quatre concepts : les ressources utilisées, les mécanismes de déploiement, les politiques et les propriétés du système cible et des entités. Ainsi, le modèle des ressources contient les entités qui sont manipulées durant le déploiement. Le modèle des mécanismes contient les opérations qui agissent sur les ressources. Le modèle des politiques contient les descriptions de la façon dont sont réalisés les choix. Enfin, le modèle des propriétés décrit les caractéristiques des ressources ainsi que les buts à atteindre par le système cible (par exemple, la réussite et la sûreté). Un site peut ainsi définir la structuration de ses ressources (machines, etc.), ses propres propriétés (par exemple la cohérence et la sécurité) et ses politiques de déploiement (par exemple l optimisation des ressources). Toujours dans le cadre de la modélisation, une architecture de déploiement est également proposée avec une séparation du monde réel du déploiement et du monde formel. Le monde formel représente une abstraction du monde réel. L abstraction du déploiement représente le cœur de notre contribution et se caractérise par trois niveaux de formalisation distincts : la description, le raisonnement et la preuve du déploiement. Notre notion de flexibilité au niveau du déploiement repose sur la possibilité de réutiliser les modèles abstraits proposés en les spécialisant suivant les contraintes et les besoins du déploiement. La proposition d une description des intra-dépendances des composants par un langage approprié basées sur un sous ensemble de la logique des prédicats et d une description du contexte du système cible. Ces dépendances peuvent être obligatoires, optionnelles ou négatives (pour exprimer des conflits). L intérêt du choix de la logique du premier ordre est la possibilité d avoir une description formelle munie d une sémantique sûre et pouvant être démontrée par des règles d inférence. La proposition d un démonstrateur de déploiement muni d un ensemble de règles de déploiement pour la vérification et la preuve de la réalisation des opérations d installation, de désinstallation et de mise à jour. Ainsi, la résolution des contraintes de déploiement utilise ces règles de déploiement comme système de déduction pour les formules des dépendances. En résumé, cette thèse propose un modèle de déploiement sûr et flexible, basé sur l analyse des dépendances des composants et la preuve des règles de déploiement. La sûreté veut dire d une part que toutes les dépendances sont satisfaites et d autre part que le système ne sera jamais dans une situation de conflit. La flexibilité veut dire la capacité du système de paramétrer et d adapter le déploiement selon des propriétés et/ou des politiques exigées par le site, et le composant.

26 16 Introduction Organisation du document Ce document est divisé en trois parties principales (voir la figure 1). La Partie I présente un état de l art sur les entités de déploiement que nous manipulons (les composants et les services), sur les concepts du déploiement et sur la réalisation et la description du déploiement dans quelques outils existants. Elle représente un cadre conceptuel de travail avec une synthèse sur les contributions par rapport à l état de l art présenté, elle comporte les chapitres suivants : le chapitre 1 décrit un état de l art sur le composants et les services qui représentent les entités de déploiement choisies dans notre travail (le Qui?), ainsi quelques points qui motivent nos choix pour décrire notre modèle de composant qui sera décrit dans le chapitre 4. le chapitre 2 présente un état de l art sur le déploiement, ses principaux concepts et les approches de déploiement basées sur les modèles (le Quoi?). Il décrit les modèles de déploiement que nous avons retenus pour modéliser notre déploiement. Il vise à déterminer les concepts les plus communs pour décrire des modèles abstraits appropriés afin d avoir un déploiement flexible. Nos modèles de déploiement sont décrits dans le chapitre 4. le chapitre 3 propose un état de l art sur quelques outils avec la description de leurs réalisation des opérations du déploiement ainsi que leurs descriptions des entités de déploiement (Comment?). Nous avons comparés entre ces différentes descriptions par rapport au niveau d expressivité des dépendances. Nous retenons les trois principales opérations de déploiement qui sont l installation, la désinstallation et la mise à jour. le chapitre 4 regroupe les contributions proposées en guise de synthèse des chapitres précédents, c est-à-dire notre modèle de composant, le méta-modèle du déploiement, et enfin l architecture globale de la réalisation du déploiement. La Partie II concerne une description formelle de l infrastructure de déploiement, elle comporte les quatre chapitres suivants : le chapitre 5 correspond à la description formelle des dépendances des entités de déploiement, c est-à-dire les composants, les services (abordés dans le chapitre 1) et le système cible. le chapitre 6 décrit les règles utilisées pour la vérification du bon déroulement de l installation et la désinstallation des composants. le chapitre 7 définit la phase de mise à jour avec les différentes règles utilisées pour la vérification de son bon déroulement. le chapitre 8 propose une extension du moteur de raisonnement qui se base sur l intégration de la description des propriétés au niveau des dépendances et du système cible. La Partie III présente la description de la mise en œuvre de l infrastructure du déploiement, la comparaison de notre description avec les paquets et les composants et la preuve de la réussite et la sûreté de l installation et de désinstallation. Elle comporte les trois chapitres suivants :

27 Introduction 17 PARTIE I : ETAT DE L ART Déploiement : contexte, modèles et outils Chapitre 1 : (Qui?) Les composants et les services PARTIE II : CONTRIBUTION Vérification formelle du déploiement Chapitre 5 : (Qui?) Description des entités de déploiement Chapitre 2 : (Quoi?) Le déploiement : principaux concepts Chapitre 6 : (Quoi et Comment?) L installation et la désinstallation Chapitre 3 : (Comment?) Réalisation et description Chapitre 7 : (Quoi et Comment?) La mise à jour des composants Chapitre 4 : Préambule sur les contributions Chapitre 8 : Extension du système par les propriétés PARTIE III : MISE EN OEUVRE ET VALIDATION Chapitre 9 : Mise en oeuvre de l architecture de déploiement Chapitre 10 : Comparaison avec les paquets et les composants Chapitre 11 : Preuve formelle Conclusions et perspectives Fig. 1 Organisation du manuscrit

28 18 Introduction le chapitre 9 décrit notre architecture de déploiement et sa mise en œuvre en Fractal, la mise en œuvre en OCaml du moteur de raisonnement qui est la partie la plus importante de notre architecture. Enfin, ce moteur de raisonnement est utilisé au niveau d un gestionnaire de déploiement réparti au-dessus d OSGi pour vérifier le déploiement des bundles puisque OSGi ne permet pas de le faire. le chapitre 10 compare notre description des dépendances avec celle utilisée dans les gestionnaires de paquets, les composants et les composants orientés services. le chapitre 11 propose une preuve des propriétés de réussite et de sûreté au niveau de l installation et de désinstallation. Enfin, le document se termine par une conclusion qui présente une synthèse de nos contributions, des limites et des perspectives de notre proposition.

29 Première partie Déploiement : contexte, modèles et outils 19

30

31 Chapitre 1 Les composants et les services La première partie de l état de l art présente les concepts de base des composants logiciels et des modèles orientés services. Notre objectif est de définir les approches de composants et de services et de présenter quelques modèles autour desquels se bâtit notre réflexion sur le modèle de composants et de service choisi. Nous décrivons quelques modèles de composants CCM,.NET, Fractal ainsi que la plate-forme orientée services OSGi, le Service Binder, FROGi et SCA. Enfin, nous présentons une synthèse sur la vision des composants et des services adoptée dans le cadre de cette thèse et la façon dont nous allons les utiliser dans le déploiement. 1.1 Les concepts principaux des composants logiciels La notion de composant vise à permettre un développement modulaire et une maintenance plus aisée des applications. Les composants (comme les objets) favorisent la réutilisation et la programmation à grande échelle. Ils cherchent à maîtriser le couplage entre les entités et à mettre en avant la notion d architecture. Pour cela, ils s appuient sur les notions de composition et d assemblage. Il existe de nombreuses définitions de composant dans la littérature, la plus utilisée est celle que donne Szyperski dans [Szy98] : Définition : A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties. Dans cette définition, un composant est considéré comme une boite noire représentant une entité indivisible encapsulée par ses interfaces. Elle implique donc l existence des notions de composition, d interface, de dépendance et de cycle de vie (définies par la suite) indépendamment des contraintes sur le type d interaction avec d autres composants ou le monde extérieur. 21

32 22 Les composants et les services 0..* Implémentation Propriété 1..* composé 0..* Composant 0..* Contrainte 1..* Interface Interface privée() Interface publique() Servide 1..* utilise 1..* possède PointDeConnexion (Port) ModeDeConnexion 1 1 Synchrone Asynchrone Continu Fig. 1.1 Méta-modèle des principaux éléments d un composant [Ous05] Représentation d un composant Parmi les nombreux modèles de composant existants, nous avons choisi de présenter celui décrit dans [Ous05] pour illustrer juste les principaux concepts qui nous intéressent dans les composants. La figure 1.1 représente un méta-modèle décrivant la notion de composant et de ses principaux éléments. Un composant est généralement représenté par les éléments suivants [Ous05] : son type qui représente la définition abstraite du composant caractérisé par ses interfaces avec leurs modes de connexion et ses propriétés configurables ou non. son implantation qui contient la mise en œuvre des aspects fonctionnels (code métier) et non fonctionnels (gestion des connexions, persistance, transactions, etc.) de son type. ses instances qui s exécutent dans le système, chaque instance est définie par une référence unique, à savoir un type de composant et une implantation particulière de ce type Interface Les interfaces de composants définissent les services requis et fournis par un type de composant. L interface décrit entièrement ce que fait le composant et ce qu il a besoin de connaître. De ce fait une interface définit des contrats qui doivent être respectés pour la réalisation d un composant. Pour un objet, l interface correspond à la liste des

33 Les concepts principaux des composants logiciels 23 signatures de ses méthodes 1. Cette notion de contrat est assez pauvre puisqu il est principalement syntaxique et ne concerne que ce que fournit l objet. Dans les modèles de composant, les contrats peuvent prendre différentes formes souvent beaucoup plus riches [BJPW99]. La forme la plus commune de contrats est la spécification des services fournis et requis par un composant. Un autre type de contrat consiste en la définition de pré et post-conditions sur l exécution des méthodes. D autres contrats plus complexes permettent la spécification de protocoles d interactions spécifiant les séquences de services qu un composant accepte. Une interface est composée de deux éléments (cf. figure 1.1) : les points de connexion sont les points d interaction (des besoins ou des services) entre le composant et son environnement. Ils sont appelés aussi port. Le port qui exprime le besoin du composant en termes de service est un port requis. Le port qui fournit un service aux autres composants est un port fourni. Un port qui fournit un service et qui en requiert en même temps, est un port mixte. les services décrivent le comportement fonctionnel du composant en exprimant la sémantique des fonctionnalités fournies (ce que fait le composant) et requises par le composant (ses besoins pour fonctionner). D après [Ous05], un port peut avoir plusieurs modes de connexions possibles : synchrone, asynchrone et continu Composition La composition est le mécanisme qui permet de lier un composant avec d autres composants en satisfaisant les services requis d un composant grâce aux services offerts d un ou de plusieurs autres composants. Elle permet de construire des applications complexes à partir de composants plus simples comme dans le méta-modèle de la figure 1.1. Un composant peut être le résultat d une composition récursive d autres composants. La figure 1.2 illustre un exemple de composition de deux composants, cette composition est réalisée dans le Corba Component Model (CCM) [CCM02]. Les composants de droite fournissent des interfaces au composant de gauche qui en avait besoin Propriété Les propriétés d un composant peuvent concerner aussi bien sa structure, son comportement ou ses fonctionnalités. Elles peuvent être paramétrées et configurées selon le contexte d exécution. Il existe également des propriétés non fonctionnelles qui ne font pas partie des services applicatifs et sont plutôt fournies par l architecture à travers le serveur et les conteneurs (sécurité, réseau, traçage, etc.) Contraintes Les contraintes représentées dans le méta-modèle de la figure 1.1 page de gauche représentent les besoins des composants et les conditions de leur bon fonctionnement. 1 son nom, le nom et le type des différents paramètres et le type du résultat

34 24 Les composants et les services Fig. 1.2 La composition de composant Ces exigences portent sur l environnement de déploiement et sur l utilisateur. Elles peuvent également être un type spécial de propriétés mais elles ont une syntaxe spéciale vue leur rôle dans la conception d architecture à base de composant Cycle de vie Le cycle de vie d un composant définit les différentes étapes nécessaires pour construire et exécuter une application à base de composants. Il existe plusieurs cycles de vie possibles selon le modèle de composant et le composant que l on observe [Far03, LW05]. Les phases du cycle de vie le plus usuel d un composant sont les suivantes : 1. Création : durant cette phase, les services offerts et requis, les pré et postconditions, etc. sont définis en respectant les contraintes spécifiées dans les interfaces. L emballage du composant (s il contient d autres composants par exemple) a lieu également pendant cette phase. 2. Assemblage : consiste à assembler tous les composants d une application. Il reflète l architecture d une application. Les composants de l application sont reliés les uns aux autres suivant l architecture d assemblage. Un assemblage doit être empaqueté pour qu il puisse être diffusable et utilisable par des tiers. L assemblage peut être réalisé pendant l exécution comme dans le modèle de composant Fractal [BCS03]. 3. Déploiement : le déploiement d un composant consiste à extraire le composant de son paquet, à l installer dans son site d utilisation et à valider les contraintes qui existent sur son déploiement. Le composant est défini comme une entité logicielle conçue et construite indépendamment d une application spécifique. Elle est intégrée plus tard dans une ou plusieurs applications. Cette entité se présente souvent sous la forme d un fichier archive, contenant principalement le code du

35 Quelques modèles de composants 25 composant 2, et un descripteur de déploiement indiquant comment effectuer ce déploiement [Car03]. Ce descripteur du composant contenu dans le paquet est utilisé pour instancier le composant. Souvent ces descripteurs de déploiement sont écrits en XML extended Markup Language [Bra04]. Ils contiennent toutes les caractéristiques nécessaires au déploiement du composant (catégorie de composant, interfaces, services requis, etc.). 4. Exécution : représente l étape d utilisation du composant par le client, après son installation Langage de description d architecture Les modèles de composant introduisent la notion d architecture. Cette architecture est décrite explicitement dans un langage spécialisé (appelé Architecture Description Language (ADL), voir [MT00, SD02]). Cette description est utilisée pour permettre un déploiement plus simple et parfois automatique des applications à base de composants. Dans ce cadre et dans celui des modèles de composants, les entités déployées exportent des interfaces permettant leur contrôle depuis l extérieur. Cela permet de gérer certains aspects de leur cycle de vie depuis un composant externe. Même si certains ([MMHR04, BJC05]) permettent l utilisation de cette architecture durant l exécution de l application, de nombreux travaux restent à mener pour que cette architecture devienne la base d un véritable outil de gestion du déploiement. Quelques exemples d ADL seront décrits dans le chapitre 3 page Quelques modèles de composants Dans cette section, nous présentons brièvement quelques modèles de composants les plus connus : CCM,.NET et Fractal. Vue l objectif de cette thèse nous nous concentrons sur leurs spécifications, la description de leurs architectures ainsi le principe de leur déploiement CCM Le modèle CCM (Corba Component Model) de l OMG (Object Management Group) [CCM02] vise à améliorer la réutilisation des composants logiciels. Il favorise la description plutôt que la programmation (seuls les aspects fonctionnels doivent être programmés, les autres aspects doivent être décrits et/ou générés). La description des spécifications, des composants et du déploiement est présentée ci-dessous Les spécifications Dans la spécification CCM, il existe quatre modèles de spécification ainsi qu un méta-modèle pour les composants CCM, ils sont définis comme suit : 2 En général, ce code est une forme pré-compilée binaire.

36 26 Les composants et les services le modèle abstrait permet de décrire la spécification du composant en IDL (Interface Definition Language) [OMG02] ; le modèle de programmation permet de définir la coopération entre le composant et la plate-forme d exécution ; il définit les relations entre l implantation du composant et les spécifications du modèle abstrait. le modèle de déploiement définit un processus d installation de composants sur différents sites ; le modèle d exécution définit l environnement d exécution des composants (avec les services associés, comme la transaction ou la persistance) Les composants La norme CCM définit un modèle abstrait de composant (cf. figure 1.2 page 24), qui impose une représentation précise des relations entre le composant et son environnement (notamment les services que fournit ou requiert le composant). Deux modes d interaction entrante sont fournis : Les facettes sont des ports fournis à invocation synchrone, qui représentent les différentes interfaces fonctionnelles. Les puits d évènement sont des ports fournis permettant les notifications asynchrones. Ce sont les points d entrée dans lesquels des évènements peuvent être déposés. De plus, un composant peut définir ses interfaces requises, qui définissent comment le composant utilise des services d autres composants : Les réceptacles sont des ports requis à invocation synchrone. Ce sont les points d entrée qui décrivent la capacité d un composant à pouvoir exploiter des références d objets fournies par une entité tierce (ils représentent les dépendances vers d autres composants). Les sources d évènement sont des ports requis pour les notifications asynchrones, elles émettent des évènements vers plusieurs consommateurs ou vers un canal d évènement. L interface est décrite en IDL et comporte plusieurs types de ports que l on peut interconnecter entre eux. Chaque port fourni du composant correspond à l implantation d une interface, et a sa propre référence (référence de facette/de puits). Trois interfaces (facettes) sont implantées par tous les composants, et permettent d accéder aux différents ports proposés par le composant : Components::Navigation permet d accéder aux facettes ; Components::Receptacles permet de (dé)connecter les composants pendant leur exécution ; Components::Events permet d accéder aux sources et puits d événements (avec notamment des opérations de (dés)abonnement à une source d événements). Quatre catégories d instance de composants existent : Service, Session, Processus et Entité (selon que l on considère le mode d accès, et l existence d une clé primaire liée à la notion de persistance 3 ). Les deux premières catégories sont non persistantes donc 3 Représente l identité du composant persistant.

37 Quelques modèles de composants 27 n ont pas de clés primaires, de plus la première catégorie est avec état et la seconde est sans état. La persistance de la catégorie processus est transparente pour le client, ce qui n est pas le cas avec la catégorie entité. Le type du composant est décrit dans le descripteur de déploiement correspondant, qui va être abordé par la suite dans le déploiement Le déploiement CCM spécifie explicitement un scénario de déploiement pour les composants. Ainsi, les composants sont empaquetés dans des paquets auto-descriptifs pouvant être assemblés entre eux. Ils forment ainsi un assemblage, qui correspond à l unité de déploiement de CCM. Pour réaliser le déploiement d applications, il est nécessaire de définir la liste des composants constituant l application, leur localisation et leurs connexions. Pour chaque composant, il est nécessaire de spécifier ses éléments (interfaces, implantations), de décrire les dépendances qui représentent ses contraintes systèmes (OS, ORB (Object Request Broker) et sa configuration initiale. Toutes ces informations permettent d installer et d exécuter l application. Pour décrire ces informations, CCM spécifie des descripteurs décrivant les paquets, les composants et les assemblages. Ces différents descripteurs sont basés sur un langage dérivé de XML qui s appelle OSD (Open Software Descriptor) [HPT97] que nous allons aborder par la suite dans le chapitre 3 page 70. Dans ce modèle, le déploiement est réalisé par un ORB qui représente le support d exécution des applications, il fournit les différents services d interaction. Il existe également des outils de déploiement qui utilisent les services de l ORB pour réaliser le transfert, l installation, l assemblage, l instanciation et la configuration des applications sur les machines des clients. Les différents éléments utilisés pour le déploiement d un composant CCM sont regroupés dans deux fichiers ZIP correspondant à deux paquets différents : le paquet de composant qui donne les informations associées au déploiement d un composant et le paquet d assemblage qui contient l ensemble des paquets de composants, un descripteur de propriétés et un descripteur d assemblage CAD (Component Assembly Descriptor) qui donne les caractéristiques de l assemblage (fabriques, instances de composant et connections à créer), il représente donc un descripteur d architecture (ADL) Microsoft.NET L architecture.net proposée dans [Pla02] par Microsoft, représente un regroupement d applications Microsoft qui vise les deux points suivants : une évolution du modèle de composant COM+ ; fournir une plate-forme de développement Windows, qui soit ouverte à tout type de langage Les spécifications Deux spécifications de l organisation de standardisation internationale ECMA (European Computer Manufacturers Association) existent pour l architecture de Microsoft :

38 28 Les composants et les services Fig. 1.3 Architecture générale de.net le langage C# et l infrastructure CLI (Common Language Infrastructure). La figure 1.3 représente l architecture générale de.net, il s agit d un ensemble de services communs, utilisables depuis plusieurs langages. Ces services s exécutent sous la forme d un code intermédiaire indépendant de l architecture sous-jacente. Ces services s exécutent dans un CLR (Common Language Runtime) assurant les fonctions de gestion des ressources et de surveillance du bon fonctionnement des applications. Enfin, pour garantir l interopérabilité entre les langages, le langage de spécification CLS (Common Language Specification) est utilisé pour définir les propriétés qu un langage doit vérifier pour interopérer avec la plate-forme.net Les composants Les composants.net sont appelés Objets Distants. Ils peuvent être programmés dans n importe quel langage et peuvent avoir plusieurs interfaces. Un mécanisme d introspection permet de naviguer parmi les services proposés par le composant Le déploiement Le framework.net est proposé en partie pour résoudre les problèmes de version et de déploiement. Ces problèmes apparaissent lorsqu on installe une nouvelle application et qu elle comporte des composants déjà présents sur la machine, dans une autre version. Ce problème est dû essentiellement aux librairies dynamiques (DLLs). Pour résoudre ce genre de problèmes, l architecture.net utilise le fichier de déploiement qui est une librairie Windows (fichier.dll), avec éventuellement un exécutable (.EXE) 4 et également un nouveau concept appelé assemblage. Il est constituée de : Nom du composant, sa version ; La spécification des interfaces du composant ; DLL. 4 La compilation d un composant.net fournit soit le fichier DLL, soit l exécutable et un fichier

39 Quelques modèles de composants 29 Les ressources (textes, images, sons, etc.) ; Les composants ou assemblages requis ; Les permissions de sécurité ; Les méta-données qui donnent des informations sur les types et/ou classes fournies par l assemblage. Elles sont utilisées pour créer les accès vers les composants (objets proxy). Ces méta-données peuvent être utilisées à la compilation du composant client, ou à partir d une description WSDL (Web Services Description Language) [CCMW01] qui décrit le composant et ses méthodes. Les informations sur le composant telles que la liste des fichiers, les dépendances et d autres informations utilisées pour exécuter le code sont mises dans un manifeste. Il suffit juste de copier les applications dans leur répertoire. Pour concevoir des applications.net, on doit respecter les contraintes suivantes : Les assemblages doivent être assez descriptifs, pour simplifier les activités d installation et de désinstallation. Les assemblages doivent respecter une politique de numérotation des versions. L infrastructure doit permettre à plusieurs versions d un composant de s exécuter sur la même machine Fractal Fractal est un modèle de composants hiérarchique, modulaire et extensible pouvant être utilisé pour la conception, l implantation, le déploiement et la reconfiguration des applications [BCS03]. Les caractéristiques principales du modèle Fractal sont la récursivité, l introspection et le partage Les spécifications La spécification d un composant en Fractal est basée sur la séparation des préoccupations, et la définition de la composition hiérarchique des instances d un composant. La spécification contient trois modèles : Le modèle abstrait divise un composant en deux parties, une partie contrôleur qui implante des interfaces de contrôle dont un certain nombre sont prédéfinies dans la spécification du modèle de composant, et une partie contenu qui contient du code fonctionnel sur lequel le contrôleur agit. Le modèle concret définit deux types d interfaces : les interfaces clients (service requis) et les interfaces serveurs (service fourni). Ces interfaces peuvent porter sur le métier (la finalité de l application) ou le contrôle. Une interface peut être obligatoire ou facultative et interne ou externe. Le modèle de programmation décrit la structure d implantation des composants. L implantation d un composant peut être programmée en utilisant les API, par une approche déclarative en utilisant FractalADL [Bru04], ou être visuelle à travers l outil FractalGUI. FractalADL sera présenté dans le chapitre 3 page 75.

40 30 Les composants et les services Les composants Fractal possède une vue externe composée de plusieurs interfaces fournies ou requises, obligatoires ou optionnelles, simples ou multiples. Un des aspects importants du modèle Fractal est qu il n impose pas un nombre fixe d interfaces de contrôle, celles-ci sont découvertes durant l exécution. Elles peuvent être programmées ou obtenues par des outils de déploiement ou de supervision. Comme mentionné dans les spécifications, un composant Fractal est divisé en deux parties : 1. Le contenu qui gère les aspects fonctionnels. Il peut être un ensemble d autres composants (les composants Fractal peuvent être partagés, i.e. dans plusieurs composants en même temps). 2. Le contrôleur gère les aspects non fonctionnels (introspection, configuration, sécurité, transaction, etc.). L introspection et la configuration permettent le déploiement et la reconfiguration dynamique des composants Le déploiement Il existe deux types de dépendance en Fractal : dépendance à travers l encapsulation de composants et dépendance à travers les interfaces de composants. Un paquet Fractal représente une archive java qui contient les classes, ressources et méta-données d un ou plusieurs composants. Les méta-informations doivent contenir : Le fichier ADL : décrivant les composants et leurs dépendances Fractal. D autres méta-informations peuvent contenir des legacy dependencies (librairies natives, OS...). Le nom de l auteur et la description du composant. Plusieurs composants Fractal peuvent être assemblés en un composant récursivement, il est possible d agréger plusieurs paquet Fractal en un seul paquet. Les dépendances entre composants Fractal sont décrites par le binding (liaison entre ces derniers) et doivent être utilisées au moment du déploiement seulement. Les dépendances entre paquets ne sont pas toujours liées aux dépendances entre composants Fractal (ex : si le paquet contient plus d un composant ou si un paquet contient un composant legacy ou des composants non Fractal). 1.3 Les modèles orientés services Cette section présente brièvement l approche orientée services en décrivant ses principaux concepts. Pour illustrer ce modèle la plate-forme de service OSGi [Ope03a] est décrite. Il existe également des approches qui combinent, le concept de service introduit dans les modèles de composants avec approche orientée services. Ces dernières offrent des mécanismes permettant aux applications de s adapter, pour supporter la disponibilité dynamique des composants. Nous présentons le service binder [Cer04], FROGi [DCD06] et SCA [BBBD05].

41 Les modèles orientés services Les concepts principaux des services L approche orientée services connaît un succès grandissant surtout depuis l apparition des web services. Un service peut être défini comme une fonctionnalité réutilisable qui est décrite de façon contractuelle dans un descripteur de service qui inclut les informations syntaxiques (interfaces de service) et peut aussi contenir le comportement du service [Cer04]. Le concept principal des modèles orientés services est l interaction entre des demandeurs, fournisseurs et registres de services pendant l exécution pour réaliser la liaison entre les demandeurs et les fournisseurs. La figure 1.4 montre l interaction entre ces trois acteurs. Registre de service 1. Publie la description d un service 4. Obtient une référence et une description 2. Demande un service Fournisseur de service 3.Liaison vers le service Demandeur de service Fig. 1.4 Architecture générale des modèles à services Un fournisseur enregistre son service auprès du registre de services en y associant un contrat qualifié. Le client demande la liste des services et la récupère à partir du registre de services après avoir été lié à un fournisseur de service. Nous pouvons déduire de ces trois concepts un certains nombre de caractéristiques utiles pour leur réalisation dans une plate-forme de services. Ces caractéristiques sont les suivantes : la description des services. la publication qui contient les opérations fournies par le registre et destinées aux fournisseurs de services pour réaliser la publication et le retrait de services. la découverte qui couvre les opérations fournies aux demandeurs de services pour réaliser la découverte de la liaison vers un fournisseur avec l ensemble des mécanismes autorisés pour le filtrage au niveau du registre de services OSGi OSGi (Open Services Gateway Initiative) [Ope03a] est une spécification ouverte pour la définition d une plate-forme de déploiement, de gestion et d exécution de services administrée à distance. Initialement conçue pour des dispositifs électroniques de type domotique, son champs d application est maintenant plus large. Elle est particulièrement adaptée aux applications dynamiques qui évoluent pendant leur exécution. Cette plate-forme trouve désormais son application dans des domaines d application tels que le développement des logiciels (les plugin eclipse), la téléphonie mobile ou l in-

42 32 Les composants et les services formatique embarquée. Nous pouvons également citer le serveur d application JOnAS [Obj06b] qui se base sur l architecture à services dynamiques d OSGi pour ses avantages en termes de re-configuration dynamique de serveurs, gestion du cycle de vie, etc Les spécifications Le cœur des spécifications d OSGi concerne la description de sa plate-forme. Cette plate-forme offre aux applications un environnement basé sur les bundles qui sont des composants (cf. la figure 1.6). L architecture d OSGi composée de plusieurs couches (cf. la figure 1.5) : Fig. 1.5 Architecture multi-couche d une plate-forme OSGi [Ope03a] L environnement d exécution est la plate-forme d exécution d applications basée sur Java. Chaque application qui est attachée à un fournisseur de services peut éventuellement collaborer avec les applications des autres fournisseurs hébergées sur la plate-forme. La plate-forme est généralement représentée comme une surcouche au Java Runtime Environnement5 introduisant l aspect dynamique dans les relations entre les applications déployées. Les modules se basent sur Java en ajoutant les classes privées pour les modules et en contrôlant le lien entre les différents modules. Cette couche est complètement intégrée avec l architecture de sécurité de Java. La gestion du cycle de vie a pour objectif de s occuper des opérations de l installation, du démarrage, de l arrêt, de la mise à jour et de la désinstallation des bundles. Le registre de services fournit un modèle coopératif pour partager les objets entre les bundles. Un certain nombre d événement est prise en compte pour rechercher des objets offrant un contrat de service donné et pour la gestion des services entrants et sortants du registre.

43 Les modèles orientés services Les composants La plate-forme d exécution OSGi définit les unités de livraison et d activation de services à déployer. Elle utilise comme unité de déploiement une archive Java appelée bundle. Cette archive contient une description (manifest) et un ensemble de classes, des bibliothèques de code natifs (dépendant du processeur et du système d exploitation) ou d autres ressources associées (cf. figure 1.6). Le fichier usuel de manifeste du JAR est étendu par l ajout d informations propres à OSGi. Ces entrées décrivent, entre autres, la classe servant de point d entrée pour l activation des services (Bundle-Activator), des informations factuelles (auteur, nom, nom symbolique, licence, url vers le dépôt de l archive, etc.), les dépendances de paquets sont représentées par les paquets importés (Import-Package) et les paquets exportés (Export-Package). Les services sont représentés par les services importés (Import-Service) et les services exportés (Export-Service). L atome de partage de code (des classes) dans OSGi est le paquet et chaque paquet possède une version. OSGi suppose à priori une compatibilité 5 ascendante vis à vis des versions antérieures. Fig. 1.6 Structure d un bundle Le déploiement Un bundle peut être installé, démarré, arrêté, désinstallé, activé et résolu (cf. la figure 1.7). La première étape est l installation : elle consiste à télécharger le fichier archive du bundle et de le stocker localement (dans le bundle cache). Le bundle change alors d état et devient INSTALLED. Ensuite, le système commence la résolution des dépendances. Le bundle passe à l état RESOLVED si pour chaque paquet qu il importe, il existe un bundle installé et résolu sur la plate-forme qui l exporte. Une fois, dans cet état, le bundle est prêt pour exporter les paquets listés dans l entrée Export-Package 5 La spécification 4 introduit la notion d intervalle de versions pour limiter la compatibilité ascendante.

44 34 Les composants et les services uninstall install INSTALLED resolve RESOLVED uninstall refresh update UNINSTALLED update refresh start Transition explicite Transition automatique STARTING ACTIVE stop STOPPING Fig. 1.7 Cycle de vie d un bundle OSGi du manifeste. Quand un paquet identique est exporté par plusieurs bundles, un seul de ces bundles devient l exportateur effectif et les autres se comportent comme des importateurs. La désignation de l exportateur effectif se fait par rapport au plus haut numéro de version de paquet puis au plus petit identifiant d installation de bundles. L activation d un bundle devient alors possible. L activation consiste pour la plateforme à instancier un objet de la classe donnée par l entrée Bundle-Activator du manifeste. Cette classe doit réaliser l interface BundleActivator qui définie les opérations de gestion du cycle de vie des bundles. La méthode start(bundlecontext) est alors invoquée avec en paramètre un objet qui représente le contexte d exécution. La méthode start(bundlecontext) peut rechercher des services, les utiliser et en enregistrer. Il se trouve alors dans l état ACTIVE. L état STARTING est l état temporaire dans lequel est le bundle tant que l exécution de la méthode start(bundlecontext) n est pas terminée. L arrêt d un bundle déclenche la méthode stop(bundlecontext) qui doit désenregistrer les services fournis et relâcher les services utilisés. Le bundle repasse alors à l état résolu. La mise à jour d un bundle provoque l arrêt, la réinstallation, la résolution puis la réactivation automatiquement. Enfin, la désinstallation du bundle provoque la suppression de l archive JAR du cache local. Les liaisons entre bundles sont réalisées dès que les services requis sont disponibles. Les dépendances de paquets sont gérées par OSGi de manière automatique. Ces dépendances permettent de partager du code entre bundles en exportant les interfaces de services.

45 Les modèles orientés services Discussion OSGi gère les dépendances qui concernent les bibliothèques natives, et la liste des paquets qui pourront être importés en cours d exécution. Cependant, il présente un ensemble de limitations en termes de gestion de dépendances car, il n existe pas d ADL pour décrire l architecture du système à déployer et ne permet pas d observer le système d exécution. D autre part, l utilisation des contextes entre bundle cache des dépendances et ne permet pas l exposition de l architecture d une manière explicite. De plus, il n y a pas de moyen de représenter des relations d encapsulation entre composants il est donc difficile de représenter l architecture du système Le service binder Le service binder [Cer04] est un modèle de composant orienté service : les composants sont faiblement couplés et leurs cycle de vie sont indépendants les uns des autres. Le Service binder est un mécanisme qui facilite la création de bundles et qui gère les dépendances de services de façon automatique. Les dépendances sont décrites avec une cardinalité et une politique (statique ou dynamique). Il est implanté comme un bundle OSGi. Il utilise un fichier en format XML dans lequel les dépendances sont décrites. Le Service Binder manipule des instances de composants. Une instance est un composant créé à partir d une classe issue d un bundle. Les méta-informations pour une instance contiennent : les interfaces de service fournies, ses propriétés et celles de ses services et les dépendances envers d autres services. Les instances sont soit valides dans le cas où leurs dépendances sont satisfaites, soit invalides dans le cas contraire. Les dépendances sont caractérisées par leur Cardinalité et leur multiplicité. La cardinalité permet d exprimer le caractère optionnel ou obligatoire de la création d une connexion avec un fournisseur de l interface de service requise. La multiplicité concerne la connexion c est-à-dire simple ou multiple si une ou plusieurs connexions sont crées. Il y a donc quatre combinaisons : 1..1 : la dépendance est simple et requise. 1..n : la dépendance est multiple et requise : la dépendance est simple et optionnelle. 0..n : la dépendance est multiple et optionnelle. Ce modèle reste néanmoins limité à la gestion automatique des liaisons et du cycle de vie des composants. Le Service Component Runtime (SCR) est une extension du modèle Service Binder. Il est introduit dans la spécification 4 d OSGi, propose un modèle de composants orienté services qui capture la dynamique des services. Le développement est grandement simplifié par la description du composant au moyen d un descripteur déclaratif dans une grammaire XML. Le composant SCR est décrit par le service (facette) qu il fournit et par les services (réceptacles) qu il utilise. Un service est un contrat fournissant une ou plusieurs interfaces java (contrat syntaxique selon [BJPW99]) qualifiées par des propriétés qui servent au courtage des services (contrat qualité de service selon [BJPW99]). SCR permet de limiter l usage des ressources de la machine hôte lorsque

46 36 Les composants et les services de nombreux services sont déployés sans être utilisés en retardant l instanciation de l objet de service jusqu à la demande de liaison effective par un bundle usager. SCR reste cependant un modèle de composants simple et non-hiérarchique qui ne prend pas en charge les aspects non fonctionnels comme la persistance, la sécurité, etc. Le développeur OSGi doit encore gérer ceux-ci de manière ad-hoc et non transparente FROGi Il existe néanmoins plusieurs travaux apparentés. Par exemple, FROGi [DCD06] qui vise à introduire le modèle à composant Fractal à l intérieur de la plate-forme OSGi. Son intérêt est donc double, d une part il offre aux développeurs de services OSGi un modèle de composant extensible qui facilite le développement des bundles. D autre part, bénéficie de l infrastructure de déploiement d OSGi qui facilite la réalisation du conditionnement du déploiement de composants Fractal. FROGi propose donc de développer les applications selon le canevas Fractal et de conditionner celles-ci dans un ou plusieurs bundles SCA SCA (Service Component Architecture) [BBBD05] est un modèle d architecture à composants spécifié par des industriels tels que IBM, Oracle, BEA, etc. Pour concevoir des applications et des systèmes utilisant une architecture orientée services (SOA). SCA est un ensemble de spécifications visant à simplifier la création et la composition de services (indépendamment de leur implantation) dans le cadre d architectures orientées service (SOA). SCA permet d organiser l architecture globale des applications et d abstraire les dépendances entre les modèles liés aux intergiciels et la logique métier. Il vise à réduire ou à éliminer la complexité des APIs d intergiciels et permettre aux développeurs de se concentrer plutôt sur la logique métier. La complexité des APIs ne se retrouve alors plus dans l application mais elle est gérée par l architecture. SCA propose donc un modèle de programmation pour la construction d applications à base de composants suivant le paradigme SOA. Ce modèle se base notamment sur l idée qu un service de niveau n se construit par assemblage / agrégation / orchestration de services de niveau n-1 ou n. Le modèle de composant SCA est présenté dans la figure 1.8, il est constitué de services, propriétés, références et implantation. SCA fournit deux niveaux de modèle : un modèle d implantation pour construire des composants qui fournissent et consomment des services et un modèle d assemblage pour construire une application métier en liant entre eux un ensemble de composants. Ainsi, SCA insiste sur une séparation forte entre l implantation des services et leur assemblage. A noter que SCA accepte un grand nombre de langages de programmation tels que Java, PHP, etc. Chacun est doté de son propre système de spécification.

47 Les modèles orientés services 37 Fig. 1.8 Le composant SCA Le modèle d implantation L élément de base de SCA est le composant qui constitue l unité élémentaire de construction. Un composant est une instance configurée d implantation où une implantation est un code source fournissant des fonctionnalités. Ces fonctionnalités sont exposées en tant que services en vue de leur utilisation par d autres composants. Les services sont décrits au travers d interfaces qui constituent le contrat de service. Ces contrats sont implantés par le composant. Les paramètres des services sont des structures de données pour lesquelles SCA recommande fortement l utilisation de la spécification SDO (Service Data Objects) dont il est également l instigateur. L implantation peut s appuyer sur des services fournis par d autres composants dont elle dépend. Ces dépendances sont appelés références. Elles sont associées à des services qui peuvent être soit exposés par d autres composants SCA soit exposés par des systèmes tiers (Web services, etc.). L implantation peut être paramétrable au travers de propriétés qui influencent sur le comportement d une fonctionnalité. C est le composant qui configure l implantation en fournissant des valeurs à ses propriétés et en liant les références aux services fournis par d autres composants. Le système de références associé à celui des interfaces permet de réaliser un couplage lâche (ou faible) entre les composants Le modèle d assemblage SCA Le deuxième modèle définit par SCA est le modèle d assemblage. Il est représenté dans la figure 1.9, il est composé de : composants, interfaces, liens, services, références, et propriétés. Les interfaces définissent une ou plusieurs fonctions métier. Ces dernières sont fournies par les services et utilisées par les composants par l intermédiaire des références. La spécification SCA accepte actuellement deux catégories d interface : les interfaces

48 38 Les composants et les services Fig. 1.9 Le modèle d assemblage SCA Java et de type WSDL (Web Services Description Language) [CCMW01]. Les liens sont employés par les services et les références. Ces dernières recourent aux liens (bindings) afin de décrire le mécanisme d accès utilisé pour appeler le service auquel elles sont rattachées. Les services SCA servent à déclarer les services extérieurs accessibles. Les services sont définis par l interface qu ils mettent en œuvre. Les fils (wires), quant à eux, connectent les références de services aux services, à la manière d un bus. Le composite SCA est l unité de base de composition à l intérieur d un système SCA. Il s agit d un assemblage de composants, services, références et fils qui les relient. Le composite inclut également des propriétés. Celles-ci servent à configurer une implantation à l aide de jeux de données extérieurs. Ces instances configurées d implantations SCA fournissent et consomment les services. La spécification SCA autorise plusieurs technologies d implantation telle que Java. Les références définissent les liens qui peuvent exister entre les différents services extérieurs. Un composé n est donc rien d autre qu un composant de plus haut niveau que ceux qui le composent (il fournit des services, dépend de références et a des propriétés). Un composé peut donc à son tour être référencé par d autres composants et utilisé au sein d autres composés. Du côté de l open source, on notera le projet Tuscany [Tus07] de la fondation Apache qui vise à fournir un environnement d exécution SCA. Pour ce qui est des outils de conception / développement, on retiendra le projet Eclipse STP (SOA Tools Platform) [STP07, LM07] qui se base sur les modèles SCA.

49 Synthèse Synthèse Dans cette section, nous avons présenté l approche de composant orientée services en présentant quelques exemples. Plus particulièrement les travaux : Service binder, FROGi et SCA. Le principe est d introduire dans un modèle de composant les concepts de l approche orientée service ainsi que les mécanismes permettant de séparer la logique d adaptation du code applicatif. Dans ce cadre les applications sont auto-assemblées et auto-adaptatives parce que chaque instance de composant est gérée de façon indépendante à partir d informations disséminées dans chaque composant. Cependant, l architecture des applications n est pas explicite. 1.4 Synthèse L étude des modèles de composants et services présentée dans ce chapitre nous permet de déterminer les points forts et les points faibles de chaque modèle. Le tableau 1.1 synthétise les évaluations des modèles de composants et de services étudiés en fonction d un ensemble de critères qui nous intéresse plus particulièrement. Ces critères sont : les notions de service (unité qu un composant peut fournir et exiger), la hiérarchie qui caractérise l assemblage hiérarchique des différents composants (un composant peut être créé par assemblage d autres composants) et enfin la description des dépendances qui sont de deux types : les interdépendances et les intra-dépendances. L interdépendance est une dépendance entre des composants différents (service requis d un composant avec service fourni d un autre composant). L intra-dépendance est une dépendance au niveau d un même composant (la relation qui existe entre les services requis d un composant et ses services fournis). Au niveau du critère de service, nous nous sommes concentrés sur la notion de service requis (client) et service fourni (serveur), cette notion existe dans tous les modèles exposés. Par rapport au deuxième critère qui concerne le niveau d hiérarchie dans l assemblage de composant, nous avons constaté que la notion de composant composite qui encapsule les sous composants dans le composant père n est possible que dans les modèles Fractal et SCA. Enfin, en termes de description de dépendance, l interdépendance entre les différents composant est décrite au niveaux de tous les modèles présentés. Cependant, aucun des modèles exposés ne permet de l exprimer la relation d intra-dépendance entre chaque service fourni d un composant et ses exigences. Nous avons décrit notre modèle de composant dans le chapitre 4. Il contient des services requis et fournis et des relations d interdépendances et d intra-dependances. 1.5 Conclusion Dans ce chapitre, nous avons décrit quelques modèles de composants et de services en présentant leurs concepts principaux. Chaque modèle à ces propres qualités et inconvénients, nous avons tenté d utiliser une approche mixte qui combine entre les composants et les services. Nous adoptons une approche de composants orientée services pas forcément identique à celle utilisé dans FROGi ou SCA mais qui se base sur le

50 40 Les composants et les services Caractéristiques Plate-formes Service Composition Dépendance CCM requis (Réceptacle et puits composant (IDL) et d événement) et fourni (facette assemblage (descrip- et source d événement) teur).net requis (source d événement) composant (manifest) interdépendance et fourni (méthode) et assemblage (assemblysembly) Fractal requis (client)/fourni (serveur), composant, assem- interdépendance métier/contrôle, blage (ADL) et (ADL) obligatoire/optionnel, composant composite simple/multiple OSGi requis/fourni, bundle et pas assemblage simple/multiple, statique/dynamique FROGi requis/fourni, composant, assemblage simple/multiple, statique/dynamique (manifest) et composant composite SCA requis (référence)/fourni composant, assem- interdépendance (service) blage et composite (langage de programmation, WSDL) interdépendance (descripteur) (as- interdépendance (manifest) interdépendance (manifest) Tab. 1.1 Étude comparative des modèles de composants et de services même principe. Nous considérant un service comme une unité logiciel qu un composant peut fournir et peut exiger. Nous métons en avant une principale relation entre les services requis et les services fournis. Cette relation est la relation de dépendance. Nous distinguons deux niveaux : le premier concerne l interdépendance entre deux composants. Le deuxième niveau concerne la description au sein d un même composant (l intra-dépendance). L interdépendance représente la relation entre le service requis d un composant et le service fourni d un autre composant. L intra-dépendance décrit la relation précise entre chaque service fourni par un composant et ses exigences. Cette relation est très intéressante pour décrire les composants et maîtriser leurs fonctionnalités. En effet, nous pouvons déterminer en fonction des exigences vérifiées quels sont les services fournis. De cette façon, le composant s adapte à l environnement dans lequel il est installé en fonction de ses exigences fournies. La description du méta-modèle du composant est présentée dans la section 4.2 page 90. Une description plus formelle des intra-dependances est présentée dans le chapitre 5 page 103. À présent une fois que nous avons étudié dans ce chapitre nos entités de déploiement (les composants et les services) et déterminé la principale relation permettant de les décrire plus précisément, nous aborderons dans le chapitre suivant la description des principaux concepts de déploiement.

51 Chapitre 2 Le déploiement : principaux concepts Sommaire 1.1 Les concepts principaux des composants logiciels Représentation d un composant Cycle de vie Langage de description d architecture Quelques modèles de composants CCM Microsoft.NET Fractal Les modèles orientés services Les concepts principaux des services OSGi Le service binder FROGi SCA Synthèse Synthèse Conclusion Après avoir décrit dans le chapitre précédent nos entités de déploiement qui sont les composants et les services, nous allons présenter dans ce chapitre quelques concepts principaux du domaine du déploiement. L objectif de ce chapitre, est d étudier les modèles de déploiement à définir dans le cadre de cette thèse afin de répondre aux problèmes de l automatisation et de la flexibilité du déploiement. Pour répondre à ces problèmes, nous avons besoin de définir et de construire des modèles abstraits qui permettent d avoir d un coté un aspect paramétrable et extensible et d un autre coté un raisonnement indépendant des contraintes de réalisation. Pour cela, nous étudions un ensemble d outils de déploiement existants utilisant une approche 41

52 42 Le déploiement : principaux concepts dirigée par les modèles pour l automatisation du déploiement. Nous donnons ensuite une synthèse sur ces différents modèles avec les principaux concepts que nous avons retenus pour modéliser le déploiement. Les détails de notre modèle de déploiement sont présentés dans le chapitre Qu est-ce que le déploiement? Le mot déploiement (ou le verbe déployer) correspond à l expression de mise en œuvre. Ainsi, lorsqu il porte sur une entité logicielle que l on souhaite utiliser, il couvre toutes les activités nécessaires : l installation, la configuration la mise à jour, etc. Ce sens est alors étendu à toutes les opérations de gestion de l entité logicielle. Ainsi, le déploiement d un logiciel ne consiste pas seulement à l installer mais aussi à le gérer durant tout son cycle de vie (postérieur à sa création), depuis son empaquetage 1 jusqu à son installation, sa désinstallation du site utilisateur en passant par son transport et sa gestion [CFH + 98]. Ces activités sont donc la dernière phase du cycle de vie d une entité logicielle. Le cycle de vie global d une entité logicielle est donc : analyse, conception, réalisation, test et enfin, déploiement. Cette étape est cruciale car (1) elle est nécessaire pour que l entité logicielle soit utilisable et (2) elle doit se dérouler dans de bonnes conditions pour ne pas perturber le site du client (où elle est déployée) Les acteurs de déploiement Le déploiement d une entité est le fait d au moins trois acteurs qui collaborent pour cette tâche : Le producteur qui produit l entité à déployer et la met à disposition des clients (l ensemble : entreprise et utilisateurs). L entreprise qui est responsable de l élaboration de la politique de déploiement sur chaque site pour l utilisateur ainsi que de la gestion de ce déploiement. L utilisateur qui représente le site où s effectue l installation avec ces spécificités. Ces acteurs, ont souvent des attentes différentes : Le producteur veut réduire ses coûts de production, pour cela, il souhaite souvent fixer un certain nombre de contraintes précises sur l environnement dans lequel sera déployée sa production. Il doit aussi souvent gérer un passé (des versions précédentes) et ne peut donc pas modifier certaines parties de ses productions. L entreprise souhaite diminuer ses coûts d utilisation de l entité, c est-à-dire, les coûts d acquisition mais également les coûts de d installation et ensuite d administration. Pour cela, elle souhaite optimiser l adéquation d un poste de travail à ces utilisations (ces rôles). Elle peut ainsi diminuer (en l optimisant) le nombre d entités logicielles à déployer et donc leur coût. Pour cela, elle va adapter l entité le plus possible à ses besoins, ce qui est contradictoire avec les objectifs du producteur puisque cela rend le développement plus complexe. 1 Le terme empaquetage est utilisé pour traduire le terme anglais packaging.

53 Qu est-ce que le déploiement? 43 Les clients souhaitent disposer des logiciels adaptés à leurs besoins. Parfois, ces objectifs sont en contradiction avec des objectifs plus globaux de l entreprise Les entités déployées Historiquement, l utilisation du terme déploiement est liée surtout à l installation de (nouveaux) logiciels. L évolution récente de l informatique a conduit à une diminution importante de la taille de ces logiciels. Maintenant, on déploie des services, des paquets ou même des composants (cf. figure 2.1). La différence entre ces différentes tailles de bout de logiciel en termes de déploiement est actuellement très importante et le nombre de solutions de déploiement est important. gros grain Applications, Progiciels 1 * Logiciels 1 * Paquets 1 * Composants, Librairies, Frameworks 1 * petit grain Classes, Interfaces, Services Fig. 2.1 La granularité des entités déployées Le cycle de vie du déploiement Comme cela a été introduit dans la section précédente, le déploiement ne consiste pas seulement à installer comme cela est souvent compris par les personnes extérieures au domaine. Le déploiement représente toutes les activités qui rendent une entité (un

54 44 Le déploiement : principaux concepts Empaquetage Fin de support Installer Desinstaller Mettre à jour Adapter Activer Desactiver Fig. 2.2 Cycle de vie du déploiement logiciel, un composant logiciel, etc.) directement utilisable par un utilisateur. Le processus de déploiement fait référence à toutes les activités et leurs interactions lors du cycle de vie d une application (cf. [CFH + 98]). Ces activités concernent l empaquetage, l installation, la désinstallation, l adaptation et la mise à jour, l activation et la désactivation d une entité. L enchainement de ces activités est représenté dans la figure 2.2, les activités étant décrites ci-dessous Empaquetage Cette activité suit le développement du logiciel chez le producteur et précède l installation du logiciel chez le client. Elle est parfois appelée configuration, nous n avons pas conservé ici ce terme pour le réserver aux opérations réalisées sur le site client pour préparer l entité à être utilisée. Le but de cette étape est de mettre à la disposition des clients du producteur l entité souhaitée. Pour cela, il faut spécifier les fonctionnalités attendues par le client ainsi que ces contraintes (par exemple, le client utilise telle architecture, tel OS, etc.). Puis, il faut regrouper dans une forme emballée, un paquet, les différents composants qui forment la version de l entité correspondante aux besoins spécifiés. Ce paquet doit également contenir la liste des dépendances logicielles et matérielles, des informations liées au déploiement (identifiant du paquet, date de création,...) et sa description. Un paquet peut également être utilisé pour une mise à jour.

55 Qu est-ce que le déploiement? Installation Cette phase du cycle de vie consiste à installer sur une machine une entité emballée. Deux activités doivent être exécutées avant l installation : Le transfert du producteur vers le client, il existe deux mode de transfert : mode push (le producteur est à l initiative du transfert) et mode pull (le client demande l installation d un paquet). La configuration qui consiste à fixer les derniers choix en fonction des données (et des politiques) locales au site de déploiement. Par exemple, le choix du répertoire d installation ou une configuration personnalisée où l on peut sélectionner les fonctionnalités proposées par l entité. La vérification des exigences de l application car elle peut avoir des dépendances avec d autres applications c est-à-dire, elle ne peut pas être utilisée sans ces applications. Il faut donc résoudre ces dépendances en installant les applications concernées. Avant l utilisation de l application installée, il faut passer par l étape d activation Activation Dans cette phase sont regroupées toutes les opérations nécessaires pour que l entité puisse être utilisée. Sans l activation de ses composants, l entité ne peut pas fonctionner correctement. Par exemple, l application de gestion d impression sous Linux cups nécessite le démarrage d un serveur apache (car son administration se fait à travers le web) Désactivation Cette étape consiste à désactiver l ensemble des unités de l application pour pouvoir effectuer des modifications sur celui-ci. Elle est effectuée avant une activité d adaptation / mise à jour et de désinstallation. Cette activité est utilisée que pour des modifications statiques parce que dans les modifications dynamiques, il n est pas possible d arrêter complètement l application Mise à jour Cette activité consiste à installer une autre version d une application déjà installée, en général pour corriger des erreurs ou pour ajouter de nouvelles fonctionnalités. Il existe deux types de mise à jour, la mise à jour statique et la mise à jour dynamique. La mise à jour statique nécessite la désactivation de l application sur le site client pour effectuer les modifications appropriées. Ces modifications peuvent être mineures, par exemple, l ajout d une librairie, ou majeures pouvant amener jusqu à la désinstallation de l ancienne application et l installation de la nouvelle. La mise à jour peut être effectuée de façon dynamique dans le cas où l arrêt de l application n est pas souhaitable, par exemple, dans le cas des applications critiques, en temps réel, embarquées, etc.

56 46 Le déploiement : principaux concepts Adaptation Cette activité permet de modifier la configuration d une application déjà installée et fournir une configuration plus adaptée. À l inverse de l activité de mise à jour, l adaptation permet de garder la même version de l application. Elle est guidée par l utilisateur et faite localement sur la machine sans faire appel à d autres paquets du producteur contrairement à la mise à jour. Cette activité est produite lors du changement des caractéristiques matérielles et/ou logicielles du site utilisateur ou lors des extensions au niveau du site producteur Désinstallation Cette activité consiste à supprimer l entité du site de déploiement sans perturber les autres entités logicielles du site. Pour cela, il faut tenir compte des composants partagés et des dépendances des entités à supprimer. En effet, il ne faut pas retirer une entité qui est utilisée par d autres, pour que celles-ci puissent continuer à fonctionner correctement. Il faut également vérifier si les dépendances de l application doivent aussi être désinstallées au même titre que l entité. L évolution des logiciels vers un découpage de plus en plus important (pour faciliter le partage, l adaptation, etc.) la rend encore plus complexe. De plus, cette phase demande la collaboration d acteurs distants qui peuvent avoir des objectifs divergents. Toute cette complexité à amener à un grand nombre de systèmes de déploiement, nous résumons quelques uns avec leurs modèles de déploiement dans la section suivante Quelques problématiques de déploiement Plusieurs problèmes peuvent intervenir au niveau du déploiement, nous pouvons citer quelques uns qui nous intéressent le plus : Description et résolution des dépendances : les applications sont souvent liées les unes aux autres en termes de dépendances. Ces dépendances doivent être décrites explicitement pour pouvoir gérer les étapes de déploiement et détecter les situations de conflit. À chaque phase de déploiement (installation, désinstallation, etc.), les dépendances et les conflits entre les composants doivent être prises en compte pour mener a bien le déploiement et garantir le bon fonctionnement des entités existantes. Par exemple, dans le cas de l installation d une nouvelle application contenant une DLL déjà installée dans une version différente, il faudra choisir entre, garder l ancienne (au risque de rendre incohérente la nouvelle application), la remplacer par la nouvelle (avec ce que cela implique pour les autres applications utilisant ce composant) ou être capable d installer et de gérer les deux versions. De la même façon, dans le cas de la désinstallation, il faut traiter le cas des applications dépendantes c est-à-dire faire le choix entre désinstaller les applications ou les laisser. La gestion du cycle de vie : la complexité du déploiement est due à l interaction des différentes activités du cycle de vie du déploiement, car ces activités sont dépendantes entre elles. Le traitement du déploiement consiste à couvrir toutes

57 Le déploiement dirigé par les modèles 47 ces activités, à gérer les relations qui peuvent exister entre elles (les dépendances), à coordonner leur réalisation, sans pénaliser une activité par rapport à une autre et surtout garantir le bon déroulement de ces activités. La gestion de configuration : le déploiement implique la résolution (ou de traitement) des problèmes liés à la gestion de configuration comme la résolution des dépendances, la gestion des versions, la compatibilité ascendante/descendante, la gestion des changements matériels et logiciels et la mise à jour des configurations 2, etc. L adaptation à l environnement et aux plates-formes hétérogènes : les applications déployées doivent s adapter à l environnement et donc aux configurations logicielles et matérielles des machines sur lesquelles elles seront installées. Par exemple, prenons le cas d une application existante sous 2 versions : l une avec une interface graphique et l autre avec une interface textuelle. Une stratégie de déploiement peut consister à déployer la version graphique sur les machines disposant d une carte graphique assez puissante et sur les autres la version textuelle. Il faut également que le déploiement prenne en compte l hétérogénéité des plates-formes. Un déploiement automatique considère par exemple que l application peut être exécutée sur Windows et Linux, la solution peut être spécifique à chaque plate-forme, ou générique. 2.2 Le déploiement dirigé par les modèles Dans cette section, nous allons aborder quelques modèles existants définis pour le déploiement. Nous en présentons trois, celui proposé par l OMG [OMG06], celui proposé dans ORYA [Les03, Mer05], enfin celui de CADeComp [Aye05] La spécification D&C La spécification D&C est un modèle proposé par l OMG [OMG06] pour le déploiement et la configuration d applications distribuées à base de composants Les domaines de spécification La spécification OMG utilise trois domaines différents : les applications à base de composants, l environnement cible et le procédé de déploiement. Les applications à base de composants Les applications doivent être décrites explicitement pour permettre leur déploiement sur une cible. Dans cette spécification les composants logiciels peuvent avoir deux types d implantation : implantation monolithique (code compilé) ou une implantation d assemblage (assemblage d autres composants fournissant une définition récursive). 2 Pour avoir une information cohérente à tout moment.

58 48 Le déploiement : principaux concepts L environnement cible L environnement cible est appelé domaine. Les domaines sont composés de nœuds, d interconnexion et de passerelles. Les nœuds possèdent une capacité de calcul et représentent la cible pour l exécution des implantations de composants. Les interconnexions fournissent une connexion partagée entre les nœuds (par exemple, un câble Ethernet). Les passerelles représentent les routeurs et les ponts (switches). Les nœuds, les interconnexions et les ponts sont définis par des caractéristiques, des ressources et des capacités. Par exemple, pour un nœud, le type du système d exploitation et la capacité mémoire peuvent être décrits ; une interconnexion peut décrire comme ressource sa bande passante. Un aspect important de l environnement cible est que le logiciel qui supporte l exécution des composants sur un nœud particulier (environnement d exécution) doit pouvoir être implanté indépendamment du service de déploiement. Le procédé de déploiement Le procédé de déploiement décrit les différentes phases de déploiement. Le procédé débute après le développement, l empaquetage et la publication du logiciel, et après son acquisition par son propriétaire qui l a déployé (déployeur). Le procédé de déploiement prend généralement en compte les étapes suivantes : Pendant l étape de vérification des pré-conditions du procédé de déploiement, l application est empaquetée par le producteur et son paquet est rendu par la suite disponible au déployeur ; L installation représente l acte de mettre le paquet dans un dépôt (repository) avec un certain nombre de politiques comme l authentification sous le contrôle du déployeur. Cependant, l endroit où se trouve le dépôt n est pas forcement celui où l application doit réellement s exécuter ; La configuration permet de configurer l application pour son exécution une fois qu elle est dans le dépôt. La planification définit où et comment l application s exécutera dans l environnement cible. Elle tient compte des besoins du composant qui va être déployé, des ressources de l environnement cible dans lequel le composant va être exécuté et la décision du choix de l implantation. Le résultat de cette phase est un plan de déploiement spécifique à l environnement cible. La préparation définit les tâches nécessaires pour préparer le site cible pour l exécution de l application. Par exemple, le transfert des fichiers binaires aux ordinateurs appropriés dans l environnement cible. Le lancement rend l application exécutable. Les applications à base de composants sont lancées en instanciant les composants suivant le plan de déploiement sur les nœuds de l environnement cible Le Modèle indépendant de plate-forme La spécification D&C définit un modèle indépendant de toutes plates-formes (PIM ), exprimé en UML. Le PIM de base représente les capacités fonctionnelles métiers et le

59 Le déploiement dirigé par les modèles 49 comportement du système. Ce modèle est modifié uniquement dans le cas de changement des connaissances ou besoins métiers. Le modèle PIM est transformé suivant l environnement cible en un modèle spécifique à une plate-forme (PSM ). Il est divisé en trois grandes parties : le modèle de données de composant et le modèle de gestion de composant, le modèle de données de la cible de déploiement et le modèle de gestion de la cible, le modèle de données d exécution et le modèle de gestion d exécution, Le modèle de composant Un composant possède des interfaces et est connecté avec d autres composants à travers des ports. Un paquet de composant contient plusieurs implantations du même composant. Il est donc possible, de distribuer dans un même paquet les implantations avec des propriétés différentes. Ces paquets sont installés dans un dépôt. Pour exprimer comment les ressources vont être utilisées, un ensemble de descriptions (description d implantation, d assemblage, etc.) et un ensemble d exigences sont associés aux composants et aux paquets. Fig. 2.3 Le modèle de données de composant [OMG06] Le modèle cible de déploiement Le modèle cible représente le lieu où sont déployées les applications. Il décrit et gère les informations relatives au domaine du lieu du déploiement. Un domaine représente l ensemble des nœuds interconnectés et communiquant par des passerelles. Les passerelles représentent la description d un chemin de communication direct entre les nœuds. Les interconnexions décrivent une connexion directe partagée entre les nœuds.

60 50 Le déploiement : principaux concepts Fig. 2.4 Le modèle de données de cible [OMG06] Un nœud, une interconnexion ou une passerelle peut avoir des caractéristiques (capacité de calcul, etc.) qui sont appelées ressources dans l environnement cible. Le modèle d exécution Les informations relatives au déploiement sont représentées dans le plan de déploiement. Ce dernier permet d effectuer les différentes tâches pour le déploiement. Il contient l information sur les artefacts, les façons de créer les instances de composants à partir des artefacts, où les instancier, etc Discussion La spécification D&C proposée par l OMG est une référence dans le domaine de déploiement et configuration. Elle est basée sur l ingénierie dirigée par les modèles (MDE). Elle définit un modèle indépendant de la plate-forme (PIM) qui est ensuite utilisé pour spécifier un modèle spécifique (PSM) pour le modèle de composant CCM. La spécification des contraintes de déploiement se base uniquement sur la description des besoins des applications en termes de ressources et de propriétés. Il serait intéressant d intégrer dans cette spécification la description des politiques (stratégies) de déploiement pour personnaliser le déploiement, par exemple de pouvoir choisir l implantation du composant la plus optimale ou avoir une préférence pour une certaine implantation. Il faut préciser un autre point fort de cette spécification qui est la possibilité de créer plusieurs plans de déploiement et d en choisir un pendant l exécution du déploiement. Ainsi, le déploiement peut être adapté en fonction à l environnement cible.

61 Le déploiement dirigé par les modèles ORYA ORYA [Les03] est un environnement ouvert basé sur l utilisation d outils de déploiement existant, développé au laboratoire LSR de Grenoble. Il permet d automatiser et de coordonner les différentes activités du cycle de vie du déploiement. Il permet d offrir un procédé de déploiement adaptable capable de couvrir tout le cycle de vie du déploiement. Son adaptation est réalisée par l utilisation de modèles paramétrables pour décrire les applications, les sites, les entreprises et les procédés. C est un outil qui permet de prendre en compte la structure de l entreprise et ses stratégies de déploiement Les modèles d ORYA L approche adoptée par ORYA est également une approche dirigée par les modèles, les concepts de déploiement sont donc décrits par un méta-modèle. Le méta-modèle d ORYA contient les descriptions de l environnement de l entreprise, les machines cibles et les applications à déployer. Ce méta-modèle vise à représenter les concepts communs de déploiement et s abstraire de toute notion spécifique. Enfin, un plan de déploiement est créé pour réaliser toutes les étapes de déploiement de plusieurs applications sur plusieurs machines. Fig. 2.5 Le méta-modèle de déploiement [Mer04] Le méta-modèle est divisé en trois parties liées aux concepts d entreprise, de site cible et de produit (cf. figure 2.5).

62 52 Le déploiement : principaux concepts Fig. 2.6 Le méta-modèle de groupe [Mer04] Le modèle de l entreprise La figure 2.6 représente le méta-modèle des concepts liés à l entreprise. Le modèle de l entreprise décrit la structure hiérarchique de l entreprise, il est considéré comme un groupe d entités composé de sous groupes et/ou de machines. Une machine peut appartenir à plusieurs groupes et un groupe peut être un sous groupe de plusieurs groupes. Cependant, il n existe pas de relation cyclique entre les groupes. Pour déployer des unités de déploiement, des stratégies sont appliquées sur les machines qui composent un groupe. Les stratégies décrivent le plan de déploiement. Plusieurs types de stratégies peuvent être appliqués à un groupe ou à une seule machine selon les besoins de l entreprise. Le modèle de stratégie peut être étendu pour rajouter de nouveaux types de stratégies. Le modèle du site cible Ce modèle décrit les machines nécessaires au déploiement avec leur caractéristiques matérielles ou logicielles. Les caractéristiques matérielles sont décrites par des propriétés comme la taille mémoire, l espace disque, le processeur, etc. Les caractéristiques logicielles décrivent l ensemble des unités déployées sur la machine. Les propriétés permettent de décrire quelques caractéristiques logicielles comme le système d exploitation par exemple. La figure 2.7 décrit le méta-modèle de la machine. Les propriétés permettent de décrire la machine et l unité de déploiement. Ces descriptions permettent de vérifier si les contraintes imposées par une unité de déploiement sont satisfaites dans le site client. Le modèle du produit Le produit à déployer représente l unité de déploiement. Le modèle de cette dernière décrit les unités avec leurs contraintes de déploiement. La figure 2.8 représente le méta-

63 Le déploiement dirigé par les modèles 53 Fig. 2.7 Le méta-modèle de machine Fig. 2.8 Le méta-modèle de l unité du déploiement [Mer04] modèle de l entité de déploiement. Une unité est caractérisée par son nom, sa version, ses dépendances et un ensemble de propriétés et de contraintes. L ensemble de propriétés permet de décrire une unité, par exemple, pour indiquer que l implantation est réalisée en Java. La valeur de la propriété Implantation est Java (<Implantation, java>). Un ensemble de contraintes d une unité représente l ensemble des caractéristiques que doit avoir une machine cible pour pouvoir l accueillir. Une unité de déploiement peut dépendre d une autre unité pour fonctionner. Pour chaque dépendance, des stratégies (ou politiques) de déploiement différentes peuvent être appliquées. L unité de déploiement possède également des dépendances. Les différents types de dépendances traitées sont : les dépendances obligatoires, les dépendances de conflit, les dépendances de remplacement (pour les unités qui ont la même fonctionnalité), les dépendances facultatives. Les dépendances d une unité sont conservées dans la structure d application. Les différents types de dépendances sont définis comme des attributs de l unité représentant une liste de liens vers d autres unités.

64 54 Le déploiement : principaux concepts Le plan de déploiement Le plan de déploiement représente l ensemble des actions à réaliser pour effectuer une activité de déploiement. L unité de déploiement est déployée selon un plan de déploiement qui peut être spécialisé en fonction des différentes activités du cycle de vie. Le modèle du plan de déploiement global est décrit pour refléter le résultat de l application des contraintes et des stratégies de déploiement, pour ordonner les déploiements unitaires (associés à chaque unité de déploiement) et enfin pour indiquer les choix possibles d unités à déployer. Un plan de déploiement global concerne le déploiement de n unités sur p machines. Les différents plans de déploiement unitaires, concernant un couple <unité de déploiement, machine cible>, sont les briques de base pour construire le plan de déploiement global Mise en œuvre La réalisation du déploiement dans ORYA utilise la technologie des procédés et celle des fédérations. La technologie des procédés permet de structurer et d automatiser les différentes étapes du déploiement et de gérer les erreurs. La technologie des fédérations permet de concevoir des applications à partir de méta-modèles et de lier les concepts des différents domaines utilisés dans le déploiement. Nous n allons pas présenter les détails des deux technologies puisque cette partie ne concerne pas le cadre de cette thèse Discussion ORYA est novateur dans son approche puisqu il essaie de construire une approche plus globale du déploiement. Il se base sur des modèles précis ce qui permet de les rendre modifiables. Sa modélisation est suffisamment abstraite et générique pour lui permettre de déployer la plupart des applications existantes. Le déploiement dans ORYA est réalisé par les procédés et les fédérations. Les procédés permettent de structurer et d automatiser les différentes étapes du déploiement. Les fédérations permettent de lier les concepts des différents domaines utilisés dans le déploiement. ORYA intègre les modèles d entreprise, de site cible et d application. À partir de ces modèles un plan de déploiement peut être généré pour réaliser les étapes de déploiement. D autres concepts importants sont associés à ces différents modèles : les propriétés qui décrivent les unités de déploiement et les machines cibles, les dépendances entre les unités de déploiement, les contraintes associées aux unités de déploiement et les stratégies qui sont associées aux entités de l entreprise (groupe et machine) et permettent de construire le plan de déploiement. Nous nous sommes inspirés des concepts définis dans ORYA pour déterminer les concepts primordiaux du déploiement. Par contre, son expressivité au niveau des contraintes est limitée à des attributs (système, langage de réalisation, mémoire minimale, etc.). Pour réaliser des déploiements utilisant des contraintes plus complexes, il faut construire des procédés spécifiques qui effectueront la résolution de ces dépendances. Or, ce langage de procédé est de plus

65 Le déploiement dirigé par les modèles 55 haut niveau qu un langage de script mais reste un langage de programmation, ce qui rend difficile toute vérification CADeComp CADeComp (Context-Aware Deployment of Components) [Aye05] est un intergiciel sensible au contexte. Il est basé sur un ensemble de règles et d algorithmes définis indépendamment de la plate-forme d exécution. La définition des règles d adaptation du déploiement est réalisée pendant les différentes étapes de production de l application, c est-à-dire pendant la spécification des composants de l application et l assemblage de ces composants Architecture et modèle de données Fig. 2.9 Architecture de CADeComp [Aye05] L architecture détaillée est présentée dans la figure 2.9. Le fournisseur du service de déploiement repose sur un ensemble de nœuds appelés serveurs d exécution. Ils sont des environnements d exécution pour les instances de composants. Le référentiel de paquets contient les paquets de composants à déployer. Le paquet de composant contient les différentes implantations d un composant ainsi que son descripteur de propriétés. Le référentiel de méta-données contient les descripteurs nécessaires au déploiement. Le

66 56 Le déploiement : principaux concepts composant Adaptateur de déploiement analyse les contextes pertinents notifiés par le filtre. Il détermine le plan de déploiement final de l application à déployer. Cet adaptateur utilise le descripteur de déploiement sensible au contexte pour choisir les instances de composants de l application, les connexions entre eux, la version d implantation, l emplacement et la configuration de chaque composant. Ainsi, il produit le plan de déploiement final de l application. Les paramètres de déploiement qui peuvent varier en fonction du contexte sont identifiés : L architecture de l application qui représente le nombre d instances et de connexions de composants constituant l application. L emplacement des instances de composants selon plusieurs paramètres de contexte tels que la disponibilité de leurs ressources et la localisation de l utilisateur. Par exemple, si les ressources du terminal de l utilisateur sont insuffisantes pour installer toutes les instances de composants, une partie de ces instances sera installée sur le terminal de l utilisateur et le reste sera distribué sur des machines distantes. Le choix des implantations des composants dépend de la plate-forme logicielle et matérielle sur laquelle va être déployée l instance de composant ainsi que le profil utilisateur comme dans le cas du choix de la langue de l utilisateur dans un composant GUI. Les valeurs des propriétés fonctionnelles et non fonctionnelles d un composant dépendant du contexte et de la préférence de l utilisateur. Les dépendances du composant peuvent changer lorsque le contexte de l utilisation du composant change. Un modèle de données indépendant de la plate-forme est proposé pour la description des informations nécessaires à la variation des paramètres déjà cités. Modèle de description du contexte Ce modèle décrit les informations du contexte de l utilisateur, le domaine de déploiement ainsi que les informations sur le contexte pertinent pour le déploiement d une application. Le contexte de l utilisateur représente les préférences de l utilisateur, les propriétés de son terminal, son identité ou son activité. Chaque contexte est défini par un nom et un identifiant qui lui permet d être référencé lors son utilisation. Le domaine du déploiement représente le réseau d interconnexion des ressources offertes par les différents nœuds existants. Il est important dans la détermination des nœuds sur lesquels vont être placés les composants. Le contexte pertinent détermine l ensemble des valeurs pertinentes du contexte qui influencent sur le déploiement de l application. Un contexte pertinent est décrit par un opérateur de comparaison (>, <, =,, ) et une valeur de contexte.

67 Le déploiement dirigé par les modèles 57 Fig Modèle de paquet de composant [Aye05] Modèle de description de paquets de composants Ce modèle se base sur le modèle de description de paquet de la spécification D&C [OMG06] (cf. page 47). Il est étendu pour le déploiement sensible au contexte qui permet de prendre en compte les variations du contexte (cf. figure 2.10). Le modèle de paquet présenté dans la figure 2.10 décrit des informations descriptives générales (GeneralDescription), des informations structurelles (ComponentInterfaceDescription), la description des différentes implantations du composant (ComponentImplementation- Description), des informations sur les dépendances du composant (CADependency) et la description des valeurs de propriétés de configuration (CAProperties-Description). Pour prendre en considération le contexte auquel le déploiement est sensible, ce modèle décrit en plus la variation des propriétés de configuration du composant en fonction du contexte (CAPropertiesDescription), la variation des dépendances du composant en fonction du contexte (CADependency) et les contraintes de placement de chaque implantation (PlacementConstraint). Les éléments qui sont représentées en gras dans la figure 2.10 contiennent les informations de contexte. Un composant peut être simple ou composite. L implantation d un composant simple représente du code compilé (le cas d une implantation monolithique : MonolithicComponent). L implantation d un composant composite représente un assemblage de composants ( le cas d implantation d assemblages récursifs : ComponentAssemblyDescription). Un composant composite représente un ensemble d instances de composants connectées entre elles. Une connexion (AssemblyConnectionDescription) relie plusieurs ports de composants afin de circuler un message vers ces différents ports.

68 58 Le déploiement : principaux concepts Plan de déploiement sensible au contexte Le plan de déploiement est représenté par des méta-informations qui permettent de planifier le déploiement d une application selon un contexte. Il spécifie la variabilité de l architecture de l application, de l emplacement de ses instances de composants et de leurs propriétés. Règles d adaptation du déploiement au contexte Les règles d adaptation permettent de déterminer les valeurs des paramètres de déploiement. Les règles associées à ces différents paramètres ont la forme suivante : condition deployementparameter = value La condition est exprimée par une contrainte sur le contexte : (condition = ContextConstraint). Les règles d adaptation sont appliquées au niveau composant et au niveau application. Les règles d adaptation au niveau composant sont de trois types : Les règles de choix d implantation et de placement : P lacementconstraints ComponentImpl = impl i, i = 1..n Les règles de variation des propriétés fonctionnelles et non fonctionnelles : ContextConstraint P ropertyv alue = value i, i = 1..n ou ContextConstraint P ropertyv alue = ContextM apping(context) Les règles de variations de dépendances : ContextConstraints ComponentDependency = dependency i, i = 1..n. Les règles d adaptation au niveau de l application sont aussi de trois types : des règles d adaptation de l architecture des applications à déployer en fonction du contexte, des règles d adaptation de l emplacement des instances de composant et les règles de variation des propriétés Discussion CADeComp est un framework pour l adaptation du déploiement des applications à base de composants sensibles au contexte. Il se base sur la spécification D&C en l étendant pour la prise en compte du contexte lors du déploiement (la sensibilité au contexte). Il utilise des (méta-)informations pour décrire l application, le contexte et les règles qui spécifient la variation des paramètres de déploiement en fonction de ce contexte. Le point fort de ces règles est qu elles manipulent différentes instances de composants et d applications en fonction des variations des propriétés d implantations et de placement. La cohérence entre ces différentes règles est également étudiée. Cependant, les règles utilisées pour l adaptation des applications sont destinées à des clients mobiles car les composants sont installés et désinstallés respectivement à chaque nouvelle demande et arrêt de service (il n y a donc pas de mise à jour). Par ailleurs, au niveau du déploiement il n existe pas de raisonnement automatique car les règles d adaptation utilisées sont spécifiques à l application. Nous pouvons imaginer des règles plus générique pour la manipulation des ressources du système afin

69 Le déploiement dirigé par les modèles 59 Plates-formes Caractéristiques D&C ORYA CADeComp site cible application plan de déploiement politique + propriété + Tab. 2.1 Comparaison des différents modèles étudiés d assurer son bon fonctionnement, par exemple pour interdire le déploiement dans le cas où le réseau est déjà surchargé Synthèse Après l étude des modèles proposés par D&C, ORYA et CADeComp, nous pouvons déduire les principaux concepts de déploiement décrits par ces modèles. Nous retrouvons d abord les modèles qui décrivent les informations nécessaires au déploiement à savoir l entité de déploiement (le modèle de produit) et le site de déploiement (le modèle de site). Ensuite, nous retrouvons les modèles qui décrivent comment déployer un produit ou une application. Il s agit donc de plan ou de procédé de déploiement. Nous retrouvons également une description des activités des différents acteurs de déploiement. L application est mise à disposition par le producteur avec sa description. Ensuite, le plan de déploiement est établi par l entreprise pour déterminer quelle entité déployer et sur quel site. Enfin, l application est déployée et exécutée sur le site cible. ORYA fournit un modèle de stratégie qui permet de personnaliser le déploiement et de prendre en compte les contraintes imposées par l entreprise. Le tableau 2.1 présente une comparaison entre les différents modèles de déploiement proposés par D&C, ORYA et CADeComp. La comparaison est faite selon la modélisation des concepts présentés ci-dessus (l application, le site cible, le plan de déploiement, les politiques et les propriétés). Ces concepts nous semblent être les plus pertinents au niveau du déploiement. Nous constatons que le modèle ORYA est celui qui est le plus complet en regroupant les concepts de site cible, application, plan de déploiement stratégie et propriété. Nous retenons dans notre approche ces concepts vue leur importance au niveau du déploiement. Nous retenons dans notre approche le modèle de produit et le modèle de site et nous les regroupons sous un seul concept qui est le modèle de ressources. Ce dernier sera présenté en détail par la suite. Un autre concept intéressant dans notre approche est celui des propriétés des entités de déploiement. Ce concept existe également dans ORYA au niveau du modèle produit et du modèle site. Nous visons un modèle plus générique dans le sens où nous utilisons le site cible et l application comme étant des spécialisations du concept de ressource qui va être décrit par la suite. Ce concept peut cependant être spécialisé par d autres entités, par exemple l utilisateur. La généricité du modèle construit, permet d avoir un déploiement

70 60 Le déploiement : principaux concepts Propriétés Politiques Cohérence Sécurisée Déploiement Ressources Mécanismes Machine Postfix Installation Fig Le domaine de déploiement adaptable au modèle spécifique en spécialisant ces ressources, ces mécanismes (plan de déploiement), ces stratégies et ces propriétés. L idée principale derrière ce modèle est de pouvoir réifier les quatre concepts (ressource, mécanisme, politique et propriété) pour pouvoir construire un système de déploiement flexible qui permet de réutiliser ce modèle et de le spécialiser suivant les applications à déployer et des environnements cibles. Par exemple, rajouter d autres types de ressource au niveau du méta-modèle, définir des propriétés ou des politiques plus spécifiques pour un système particulier. 2.3 Conclusion Dans ce chapitre, nous avons présenté les concepts principaux du déploiement et quelques modèles de déploiement existants destinés pour l automatisation du déploiement. Pour cela, nous avons besoin de définir et de construire des modèles abstraits. L intérêt de ces modèles est double, ils permettent d avoir d un coté un aspect paramétrable et extensible ; donc plus de flexibilité au niveau du système et de l autre coté, un raisonnement indépendant des contraintes de réalisation donc plus générique. Nous pensons qu un outil de déploiement doit donc être : ouvert pour que tous les producteurs puissent l utiliser, générique pour que l entreprise puisse se contenter d utiliser un seul outil et flexible pour que l entreprise puisse utiliser ses propres ressources, politiques et que les contraintes des utilisateurs puissent également être prises en compte. Pour ce faire, nous avons étudié les concepts les plus utilisés dans ces modèles de déploiement. Nous avons retenu : le modèle de l application qui décrit qui va être déployé, le modèle de site cible qui décrit ou le déploiement aura lieu, le plan de déploiement décrit comment le déploiement sera réalisé et quels sont les mécanismes mis en œuvre, le modèle des politiques de déploiement qui décrit le choix de la façon dans laquelle le déploiement sera réalisé, enfin le modèle des propriétés qui décrit les caractéristiques fonctionnelles et non fonctionnelles des entités déployées. Les modèles retenus sont présentés dans la figure À partir du concept de site cible, et celui d application déjà définis dans ces modèles nous avons proposé un concept unificateur : les ressources. L intérêt de ce regroupement est d avoir un modèle plus

71 Conclusion 61 abstrait et plus générique pour avoir un niveau d abstraction qui permet de faire des instanciations différentes et selon le besoin. Nous avons décrit le plan de déploiement qui définit comment réaliser le déploiement à travers le concept de mécanisme qui n est pas abordé en détails dans cette thèse. Nous nous sommes inspirés du concept des stratégies d ORYA pour définir un concept de politique. Enfin, nous utilisons le modèle de propriétés qui étend celui d ORYA en intégrant des propriétés non fonctionnelles. Les détails de notre modèle de déploiement seront abordés dans le chapitre 4.

72 62 Le déploiement : principaux concepts

73 Chapitre 3 Réalisation et description du déploiement Sommaire 2.1 Qu est-ce que le déploiement? Les acteurs de déploiement Les entités déployées Le cycle de vie du déploiement Quelques problématiques de déploiement Le déploiement dirigé par les modèles La spécification D&C ORYA CADeComp Synthèse Conclusion La première partie de l état de l art concerne l étude de la problématique de l automatisation et la flexibilité dans le déploiement. La deuxième partie se concentre sur l étude de la de la réussite et la sûreté du système de déploiement. Pour avoir des systèmes de déploiement sûrs, nous avons besoin d étudier comment les systèmes existants décrivent et réalisent le déploiement. Ce chapitre décrit quelques outils de déploiement en mettant en avant leurs architectures de déploiement, leurs descriptions des entités ainsi que leurs mécanismes de réalisation et de gestion du déploiement. La première partie décrit les mécanismes du déploiement les plus communs dans ces outils. La deuxième partie survole quelques langages et standards de description pour le déploiement. L objectif de ce chapitre, est de donner une vision de ce qui existe en terme de réalisation et de description du déploiement pour déduire et proposer une architecture du déploiement qui permet de vérifier et de garantir la sûreté du système. 63

74 64 Réalisation et description du déploiement 3.1 Quelques outils de réalisation du déploiement Dans cette section nous allons survoler quelques outils de réalisation du déploiement logiciels. En premier, nous présentons quelques gestionnaires de paquets dans les systèmes GNU/Linux comme rpm [ET96] et Debian [Deb05]. Enfin, Nix [DdV04] qui est un outil de déploiement et installshield [Ins05]. Nous avons séparé la réalisation du déploiement de sa description dans ces outils. Leurs descriptions sont présentées dans la section 3.2 page Les gestionnaires de paquets Les gestionnaires de paquets sont des outils qui permettent d automatiser le processus d installation, de désinstallation et de mise à jour de logiciels. Ce terme est surtout utilisé dans les systèmes d exploitation libres. Parmi ces systèmes, nous retrouvons GNU/Linux qui est developpé autour du noyau Linux et FreeBSD [Fre07], NetBSD [Net07] et OpenBSD [Ope07] qui sont developpés autour du noyau libre BSD au sein d un laboratoire de recherche de l université de Berkeley. Nous allons aborder brièvement les gestionnaires les plus populaires de GNU/Linux. Au début, dans les systèmes GNU/Linux, l utilisateur compilait lui même chaque programme qu il voulait utiliser. Pour cela, il a été nécessaire que le système s occupe de la gestion des paquets installés sur la machine. Ainsi, ce fut la première fois qu un «système de paquets» était inclus dans GNU/Linux «dpkg» et par la suite «rpm» de Red Hat. Les gestionnaires de paquets sont des utilitaires de systèmes d exploitation qui permettent d assister l administrateur dans la gestion des applications. Ils sont basés sur le concept de paquet et de dépôt (repository) de site qui stocke l information sur l état de chaque paquet installé. Un paquet est une archive (fichier compressé) contenant tous les fichiers d une application et des scripts de contrôle exécutés lors de l installation ou de la désinstallation de l application. Ce fichier contient aussi toutes les dépendances vers d autres paquets. Ces gestionnaires sont très répandus dans le monde Linux. On peut citer, par exemple, RPM [ET96] de la distribution Fedora Core ou APT de la distribution Debian [Deb05] RPM Il existe au moins trois distributions importantes de Linux utilisant le format RPM (RedHat Package Manager) [ET96] : Fedora Core, Mandriva et SuSE. Ces distributions peuvent partager les outils de gestion de paquets même si ces derniers sont souvent plus ou moins incompatibles entre les différentes distributions. RPM est, comme son nom l indique (en anglais), un outil de gestion de paquets pour Linux. Il permet d installer des paquets, les désinstaller et les mettre à jour. Il existe des outils comme apt-get sur RedHat qui permettent de faciliter la gestion des paquets par la résolution automatique des dépendances au niveau de l installation, la désinstallation et la mise à jour.

75 Quelques outils de réalisation du déploiement 65 L installation de paquet RPM Les étapes nécessaires pour la réalisation de l installation des paquets sont résumées comme suit : vérification des dépendances à partir du fichier SPEC de description du paquet. RPM vérifie que tous les paquets requis sont présents dans le système ; vérification des conflits : il s assure que les contraintes conflictuelles décrites dans le fichier de description de paquet sont vérifiées, s il existe un paquet qui ne satisfait pas ces contraintes l installation n est pas possible ; exécution du script %pre ; traitement des fichiers de configuration qui sont installés par le paquet (comme spécifié dans le fichier SPEC, cf. figure 3.4 page 78) car il est possible que ces fichiers puissent écraser les fichiers existants. Pour contourner ce problème, RPM fait des copies de sauvegarde de ces fichiers avant l installation des nouveaux fichiers ; exécution du script %post ; mise à jour de la base de données. La désinstallation de paquet RPM RPM effectue la désinstallation des paquets en réalisant les étapes suivantes : vérification des dépendances à partir de la base de données pour s assurer qu il n existe aucun paquet qui dépend du paquet qui va être supprimé ; exécution du script %preun sauvegarde d une copie des fichiers de configuration avant leur suppression ; vérification et suppression de fichiers : pour chaque fichier du paquet à supprimer vérifier s il n appartient pas à d autres fichiers pour le supprimer sinon le garder ; exécution du script %postun ; mise à jour de la base de données. La mise à jour de paquet RPM La mise à jour d un paquet rpm est réalisée par son installation d abord, et par la suite la suppression des paquets mis à jour en manipulant correctement les différents fichiers de configuration qui sont présents dans les paquets. Il faut souligner la différence entre l installation et la mise à jour. La mise à jour écrase l ancien paquet par le nouveau et l installation conserve (si possible) l ancienne version de l application et installe la nouvelle en parallèle Debian Dans les systèmes GNU/Linux, le besoin d une solution rapide, pratique et efficace pour installer et gérer automatiquement les dépendances entre paquets est devenu important. Après le gestionnaire basique «dpkg» Debian a donné naissance à APT,

76 66 Réalisation et description du déploiement Advanced Packaging Tool [Sil04], qui depuis a été porté par Conectiva pour l utiliser avec les rpm et a été adopté par quelques autres distributions. APT est un système complémentaire qui gère les dépendances entre les différents paquets et permet ainsi de les mettre à jour par simple téléchargement. Il fonctionne à partir d une liste de sources (emplacements des paquets disponibles) présente dans le fichier /etc/apt/sources.list. APT devra ensuite rapatrier la liste des paquets disponibles pour chacune de ces sources, ainsi que leurs en-têtes. Le système de paquets utilise sa propre base de données pour garder une trace des paquets qui sont installés, de ceux qui ne sont pas installés et de ceux qui peuvent être installés. Le programme apt-get gère ces paquets en utilisant cette base de données pour retrouver l emplacement des paquets à installer et les paquets supplémentaires nécessaires pour qu un paquet sélectionné fonctionne correctement. L installation de paquet Debian APT permet d installer des paquets dans le système avec la commande apt-get install. Il se sert du fichier /etc/apt/sources.list qui spécifie les archives (serveurs, CD, etc.), le contenu de ces archives va être récupéré par la commande apt-get install et mémorisé dans des fichiers dans le répertoire /var/lib/apt/lists. Ces fichiers vont par la suite être utilisés pour localiser les paquets demandés. Il peut choisir d installer une version particulière d un paquet en faisant suivre son nom par un signe égal et par la version. On peut aussi choisir une distribution particulière en faisant suivre le nom du paquet par une barre oblique et par le nom de la distribution ou de l archive (stable, testing, unstable). La désinstallation de paquet Debian APT permet supprimer des paquets dans le système avec la commande apt-get remove, apt supprimera les paquets dépendant du paquet en cours de désinstallation après confirmation de l utilisateur. L option purge demande une désinstallation complète, les fichiers de configuration sont alors également supprimés. La mise à jour de paquet Debian La mise à jour est réalisée par la commande apt-get upgrade précédée de la commande apt-get update. La commande update permet de resynchroniser un fichier répertoriant les paquets disponibles et sa source. Ces fichiers sont récupérés aux endroits spécifiés dans /etc/apt/sources.list. La commande upgrade assure une mise à jour la moins intrusive possible en cherchant les mises à jour des paquets installés sans ajouter ou supprimer de paquets. La commande apt-get dist-upgrade effectue la fonction upgrade en y ajoutant une gestion intelligente des changements de dépendances dans les nouvelles versions des paquets. apt-get possède un système «intelligent» de résolution des conflits et il essaie, quand c est nécessaire, de mettre à niveau les paquets les plus importants au dépend des paquets les moins importants.

77 Quelques outils de réalisation du déploiement Synthèse Ces gestionnaires permettent de créer, d installer, de mettre à jour, et de désinstaller des paquets. Ils permettent également d interroger le dépôt pour connaître l état du système. Ils sont assez proches avec de petite variation sur l extensibilité des descriptions, sur les possibilités de vérification et sur la convivialité. Ils possèdent une limitation importante qui est d interdire les versions multiples d un même paquet dans un même dépôt. La stratégie de déploiement est difficilement configurable car l administrateur devra donc gérer à la main cette stratégie. Par contre, ils sont assez complets dans leur couverture du cycle de vie des paquets Nix Nix [DdV04] est un outil de déploiement purement fonctionnel (i.e. pas de mise à jour destructive et les anciennes versions sont toujours accessibles). C est un système de gestion de paquets qui permet d assurer que les spécifications des dépendances sont complètes, que l installation des paquets est concurrente et sûre. NixOS [DVH07] est une distribution du système d exploitation Linux qui est basée sur Nix. Les expressions Nix permettent de décrire comment construire des paquets à partir du code source. Généralement, le déploiement d un composant est réalisé suivant les étapes suivantes : l écriture de l expression Nix du composant (cf. la figure 3.2 page 74) qui permet de décrire toutes les dépendances, les sources, etc. pour la construction du composant. l écriture du constructeur (le script shell) qui permet la construction du composant. La figure 3.1(a) représente le constructeur de GNU Linux. la construction de la composition. Pour réaliser une construction concrète d un composant, les dépendances doivent être vérifiées. Pour composer le composant avec ses dépendances, une autre expression Nix doit être écrite pour faire l appel à des fonctions avec les arguments appropriés (cf. figure 3.1(b)) L installation L installation se base sur la description Nix du composant. Une description Nix détaillée d un composant Hello est présentée dans la figure 3.2 page 74. Cette description est évaluée et toutes les dépendances sont construites La désinstallation Un composant peut être supprimé de l environnement utilisateur grâce à la commande nix-env -e. Cependant, cette commande ne supprime pas le composant du répertoire store de Nix (/nix/store est un répertoire dans le système de fichier qui contient les composants). La raison est que le composant pourrait être encore utilisé dans un autre environnement par un autre utilisateur, ou il représente une dépendance

78 68 Réalisation et description du déploiement source $stdenv/setup PATH=$perl/bin:$PATH tar xvfz $src cd hello-*./configure --prefix=$out make make install (a)... rec { hello = (import../applications/misc/hello) { inherit fetchurl stdenv perl; }; perl = (import../developement/interpreters/perl) { inherit fetchurl stdenv; }; fetchurl = (import../build-support/fetchurl) { inherit stdenv;... }; stdenv =...; } Fig. 3.1 Le constructeur (a) et la composition (b) de GNU Hello avec d autres composants [Dol06] (b) d un autre composant. Plus précisément, si le composant est supprimé, il ne serait plus possible de faire des retours arrière. Pour gagner de l espace disque, il est nécessaire d exécuter périodiquement le mécanisme de garbage-collection qui consiste à supprimer les composants inutilisés par n importe quelle génération de n importe quel environnement utilisateur. Un composant ne peut être supprimé que s il n est pas utilisé par n importe quel autre composant ou utilisateur. Cette commande supprime toutes les anciennes générations du profil utilisateur excepté le courant : nix-env remove-generations old La mise à jour Au niveau de la mise à jour, la nouvelle version du composant sera stockée dans un répertoire différent de l ancienne. La gestion de la mise à jour dans Nix est semblable à celle utilisée dans RPM. En revanche, dans le cas où les besoins de la nouvelle version ne sont pas satisfaits, Nix permet reprendre l ancienne version. Dans un modèle purement fonctionnel, les mises à jour ne sont pas destructives. Les composants ne changent jamais après avoir été construits Discussion Grâce à l aspect purement fonctionnel de Nix, il est possible d avoir des versions multiples ou des variantes d un composant installé en même temps. En revanche, dans les systèmes tels que différentes versions de RPM, l installation d une version enlèvera l autre. C est particulièrement important dans le cas d utilisation d applications qui ont des conditions contradictoires sur différentes versions d un composant (version > 1 et version = 1). Ainsi, les utilisateurs peuvent avoir différentes «vues» (profils)

79 Quelques outils de réalisation du déploiement 69 sur l ensemble des applications installées dans un système. Par exemple, un utilisateur peut avoir la version 1.0 d un certain paquet, alors qu un autre emploie la version 1.1. De même, il est possible de faire des retours arrières après une installation, une mise à jour, ou une désinstallation. C est parce que les actions de mise à niveau ou de désinstallation n enlèvent pas réellement des composants du système. En conséquence, la consommation en terme d espace disque est nettement plus importante Installshield InstallShield [Ins05] est l outil industriel le plus utilisé pour le déploiement des applications Windows. Il utilise le service Windows Installer [Mic05]. Ce service permet d installer, de configurer et de gérer les applications comportant l extension MSI. Dans Windows Installer nous retrouvons les notions de paquet (fichier.msi) et de Code de produit (identifiant unique du produit) pour que le service d installation puisse identifier le produit et savoir s il est déjà installé. Le processus de déploiement de Windows Installer est composé de trois activités : La création : spécifie le fichier MSI de l application en créant le paquet. Ce fichier contient des informations sur le paquet (par exemple : date de création, nom du vendeur, etc.), des instructions d installations et les références vers les ressources de l application. Cette activité permet donc de spécifier les fichiers de l application et de résoudre les dépendances de l application en se basant sur ce fichier. La distribution : est caractérisée par le transfert du paquet, via le Web, un intranet, ou en utilisant un CD d installation. Une fois le paquet transféré, il est lu et exécuté par le service Windows Installer. La maintenance : met à jour et assure la cohérence de l application installée. Le service Windows Installer offre les fonctionnalités suivantes : Des moyens automatiques pour réparer les fichiers corrompus d une application, permet d installer et de désinstaller correctement les applications (par exemple la prise en charge de la gestion des registres et des raccourcis), Un service de reprise (roll back) pour retourner à l état initial en cas de problème lors de l installation. InstallShield permet de générer deux principaux types d installateurs : Basic MSI (Microsoft Setup Installer) et InstallScript. Les installateurs produits par Basic MSI sont des paquets pour Windows Installer (MSI), et ceux produits par InstallScript sont des exécutable (appelés souvent setup.exe). Exemple Le programme exécutable qui interprète les paquets et installe les produits est Msiexec.exe. Quelques lignes de commandes et options standards de ce programme sont présentées ci-dessous : /uninstall <package.msi ProductCode> : désinstalle le produit ;

80 70 Réalisation et description du déploiement /uninstall /package <package.msi ProductCode> /uninstall <update1.msp patchguid1<[ ;Update2.msp PatchGUID2] : désinstalle et met a jour le patch (une section de code ajouté au produit pour le modifier) ; /package <package.msi ProductCode> : installe ou configure le produit ; /update <Update1.msp>[ ;Update2.msp] : met à jour le produit. 3.2 Quelques langages de description des entités du déploiement Dans la section précédente, nous avons constaté que pour la réalisation d une opération de déploiement, nous devons décrire les entités concernées (les paquets, les applications, etc.). Dans cette section, nous présentons quelques langages de description de ces entités. En premier, nous présentons quelques langages de description dédiés aux composants tels que : OSD [HPT97], COACH [HRR + 03], DSD, le langage de description des composants Nix, quelques ADLs et les langages de description des paquets. Par la suite, nous abordons UML et quelques standards de description qui sont utilisés pour la modélisation et la description des entités de déploiement. Une comparaison de ces langages est présentée en terme de description des dépendances de l application (ses exigences, ses conflits ses effets et ses intra-dépendances) ainsi qu en terme de description de la plate-forme cible de déploiement. Enfin, nous résumons les principaux langages qui permettent de décrire les quatre concepts de déploiement définis dans le chapitre Les langages de description de composants Dans cette partie, nous présentons quelques langages de description tels que OSD Open Software Description [HPT97] et les descripteurs utilisés dans le projet COACH IST [HRR + 03] dans CCM. Par la suite, nous décrivons le langage de description des composants Nix et quelques langages de description d architecture OSD Le langage OSD (Open Software Description) [HPT97] créé par Marimba et Microsoft et soumis au W3C offre un vocabulaire XML [Bra04] pour décrire les logiciels, leurs versions, leur structure et leurs relations avec d autres logiciels. Il permet de définir une famille de logiciels, c est-à-dire un ensemble de configurations d un même logiciel. Une famille est décrite par : Son identité : nom, description et localisation de l accord de licence, Ses différentes configurations, Ses dépendances vis-à-vis d autres logiciels ou composants. Une configuration est décrite par : La localisation de ses composants, Des contraintes logicielles : version de l OS requis, machine virtuelle, etc.

81 Quelques langages de description des entités du déploiement 71 Des contraintes physiques : espace disque et taille mémoire minimum, processeur, etc. Des informations : langage de réalisation, type d implantation, etc. Les dépendances de la configuration. Exemple Nous illustrons par un exemple comment les dépendances sont traitées en OSD. Chaque fichier OSD décrit un niveau de dépendance en permettant de référencer d autres fichiers OSD contenant d autres niveaux de dépendances. Par la suite un graphe de dépendance est construit. L exemple ci-dessous représente un «bout» de description d un logiciel de type solitaire présenté dans [HPT97]. Dans cet exemple, la configuration pour la plate-forme Java a une dépendance vis-à-vis d un autre composant : le paquet de cartes. <SOFTPKG NAME="com.foobar. VERSION="1,0,0,0"> <TITLE>Solitaire</TITLE>... <IMPLEMENTATION> <IMPLTYPE VALUE="Java" /> <CODEBASE HREF =" /> <! - La configuration Java a besoin de l objet paquet de cartes --> <DEPENDENCY> <CODEBASE HREF =" /> </DEPENDENCY> </IMPLEMENTATION> </SOFTPKG> Ses dépendances sont décrites sous forme de graphe orienté pour distinguer quel paquet logiciel dépend des autres. Chaque paquet est représenté par un nœud et chaque nœud peut avoir aucun ou plusieurs arcs incidents. Le label du nœud est le nom de la distribution. Cette description permet de déterminer les exigences des composants pour fonctionner. Pour découvrir entièrement le graphe de dépendances le client doit posséder tous les fichiers OSD qui en dépendent. Par exemple, dans l exemple cidessus, cards.osd est un autre fichier qui spécifie des dépendances supplémentaires de deuxième niveau. Le client peut employer le graphe résultant pour déterminer quelles sont les réalisations pertinentes qui doivent être téléchargées pour finaliser l installation du paquet COACH Le projet COACH [HRR + 03] vise à fournir un outil complet pour le développement des applications orientées composants. Le modèle de composant CCM est choisi dans ce projet pour spécifier le format des paquets pour l implantation des composants. Un composant CCM peut avoir plusieurs implantations, par exemple, pour différentes plate-formes, systèmes d exploitation ou des besoins en matière de qualité de service QoS.

82 72 Réalisation et description du déploiement Pour être déployable, un composant CCM doit être empaqueté dans une archive Zip. Ces archives contiennent un ensemble de descripteurs XML décrivant les implantations du composant (DLL ou JAR). COACH permet de décrire la topologie et les propriétés de l environnement de déploiement en définissant deux niveaux de descriptions. Le premier niveau concerne la description des propriétés du réseau qui est la description physique du réseau en terme de nœuds et liens de communication entre les nœuds. Le deuxième niveau concerne la description des capacités et propriétés des nœuds en terme de composants matériels (processeur, mémoire, etc.) et logiciels (OS, ORB, etc.). Exemple Le schéma décrit ci-dessous est un exemple de DTD d un descripteur de capacité et propriétés des nœuds. <!ELEMENT node ( (description)?, (authority)?, (os), (networkadress)*, (processor)*, (memory)?, (storage)*, (installedhardware)?, (installedsoftware)?,(properties)?, ) > <!ATTLIST node id ID #REQUIRED > DSD DSD (Deployable Software Description) est une description utilisée au niveau du déploiement [HHW99a] par l outil Software Dock [HHW99b, HHW98, HHW99a]. Cet outil permet d installer et de gérer des applications de type client/serveur. Ce langage de description décrit les composants et les dépendances logicielles et matérielles (ressources) nécessaires au composant au niveau application. Le format des descripteurs DSD offre un vocabulaire XML pour décrire les logiciels et leurs relations avec d autres logiciels. Ces descripteurs sont de type événement condition action (ECA) permettant de décrire plus précisément les différentes entités d un déploiement. DSD permet de décrire une famille de logiciels à travers un seul schéma. Les fichiers DSD modélisent aussi bien les différents sites de déploiement que les applications : Le serveur est spécifié par sa localisation et les différentes applications qu il peut déployer. Pour chacune de ses applications, la localisation du fichier DSD correspondant et le nom de sa famille sont donnés. Le client est décrit par sa localisation, son matériel (architecture, mémoire, etc.) et ses logiciels (OS et les applications déjà présentes sur le site). Une application est décrite en termes d attributs et de contraintes :

83 Quelques langages de description des entités du déploiement 73 Attributs internes qui décrivent ses constituants, ses caractéristiques, nom, version ; externes qui décrivent le site cible du déploiement, telles que l OS ou l architecture. Contraintes représentent les exigences matérielles ou logicielles requises pour une exécution normale du logiciel. Deux types de contraintes sont distingués : les assertions qui interrompent le déploiement si elles ne sont pas vérifiées et les dépendances qui provoquent le lancement d une action correctrice si elles ne sont pas vérifiées. Exemple Ci-dessous un exemple d assertion et de dépendances : <Assertions> <Guard></Guard> <Assertion> <Guard></Guard> <Condition> (($OS$=="Win95") ($OS$=="WinNT") ($OS$=="Solaris") ($OS$=="Linux")) </Condition> <Description> Only supported on Win95, WinNT, Solaris, and Linux. </Description> </Assertion> </Assertions> <Dependencies> <Guard></Guard> <Dependency> <Guard>($Implementation$ == "Java")</Guard> <Condition> (!installed("cards")) </Condition> <Description> Java version depends on deck of cards component. </Description> <Resolution>Install</Resolution> <Constraints></Constraints> <!-- Software Dock specific attributes --> <ReleaseDock> <Family>Cards</Family> </Dependency> </Dependencies> Artefacts : ce sont les fichiers qui composent l application. La localisation de chacun d entre eux est spécifiée avant et après le déploiement. Les artefacts sont regroupés dans des collections. Chaque collection est contrôlée par une

84 74 Réalisation et description du déploiement garde. Cette dernière a pour rôle de déterminer si la collection est incluse dans la configuration ou pas. Il existe également en DSD des règles de composition qui décrivent des relations entre plusieurs attributs d une famille. Une règle est composée de trois parties : un prédicat, un opérateur de relation et un ensemble d attributs concernés par la règle. Il existe quatre opérateurs en DSD : EXCLUDES, si le prédicat est vérifié alors la liste des attributs n est pas permise, INCLUDES, si le prédicat est vérifié alors la liste des attributs est permise, ONEOF, si le prédicat est vérifié alors l un des attributs seulement est permis et pas les autres, ANYOF, le prédicat est vérifié un ou plusieurs attributs sont permis La description des composants Nix Les composants Nix [Dol06] sont construits à partir des expressions Nix. Les expressions de Nix [Dol05] décrivent les composants et les compositions de ces derniers. En d autres termes, les expressions de Nix décrivent également comment établir toutes les dépendances. Nous illustrons le langage d expression Nix par un simple exemple présenté dans [Dol06]. L exemple concerne GNU Hello qui est un programme qui affiche «hello world», la figure 3.2 présente l expression Nix pour GNU Hello. {stdenv, fetchurl, perl}: stdenv.mkderivation { name = hello ; builder =./builder.sh; src = fetchurl { url = md5 = 70c9ccf9fac07f762c24f2df d ; }; inherit perl; } Fig. 3.2 Expression Nix pour GNU Hello [Dol06] Les arguments de fonction stdenv, fetchurl et openssl représentent les dépendances de Hello. stdenv est utilisée dans la plupart des paquets Nix, il fournit ce qui est exigé dans les environnements UNIX basique (gcc, cp, tar, grep, etc.). fetchurl est une fonction qui télécharge les fichiers. perl est l interpréteur Perl. La fonction mkderivation est une fonction fournie par stdenv qui construit un composant à partir d un ensemble d attributs. L ensemble d attributs représente une liste de couples (clé/valeur) où chaque valeur est une expression Nix arbitraire. L attribut builder spécifie le script qui construit le composant. Le constructeur par défaut réalise la séquence de commande standard pour la construction de composants Unix :

85 Quelques langages de description des entités du déploiement 75 configure ; make ; make install. Le constructeur doit connaître les sources du composant. L attribut src fait appel à la fonction fetchurl qui télécharge le fichier à partir de l attribut url et vérifie sa clé MD5. Enfin, la valeur de l argument de la fonction perl est utilisée par le constructeur. Discussion Le langage d expression de Nix permet de décrire facilement la variabilité dans les composants (par exemple, les dépendances et les caractéristiques optionnelles). Nix traite également les dépendances entre les codes, les configurations et les données. En revanche, les opérations de déploiement sont exprimées sous forme fonctionnelle avec un langage de description Nix assez complexe. Cette complexité rend d une part la mise en œuvre de Nix complexe, et d autre part le raisonnement sur les propriétés de la configuration plus difficile. De plus, ce langage n est pas typé et se réduit à l utilisation de scripts Les langages de description d architecture Depuis plusieurs années, des techniques centrées sur la description de l architecture des systèmes sont développées [Gro00]. Celles ci ont été élaborées afin d améliorer la compréhension et la conception des systèmes complexes, de favoriser leur évolution et leur réutilisation, de procéder à diverses analyses, de faciliter la construction et le déploiement, ou encore d assister la gestion de configuration. Ces techniques se sont concrétisées par des langages spécifiques, les ADLs (Architecture Description Language), et l outillage associé. Les ADLs sont donc un support pour la description de la structure de l application. Ils permettent de spécifier les composants de façon abstraite sans rentrer dans les détails d implantation. Ils offrent également des moyens pour la description de la composition par la description des dépendances entre composant et des règles de communication à respecter. Plusieurs ADLs existent mais avec des formalismes, des concepts et des usages différents. Parmi les problèmes des ADLs nous pouvons citer leur incompatibilité, multiplicité et l absence de standardisation. Ce qui conduit à la spécification de certains ADL s par les métalangages d XML (DTD et XML schema). Parmi les langages qui ont répondu à ces problèmes nous pouvons citer xadl [DdHT01] et FractalADL [Bru04] qui va être décrit par la suite. FractalADL Le modèle de composants Fractal utilise le langage de description d architecture FractalADL[Bru04] permettant de spécifier une architecture de composants hiérarchiques. Ce langage est utilisé également pour le déploiement, la vérification, l analyse, etc. Il est constitué de deux parties : un langage basé sur XML et une usine qui permet de traiter les définitions faites dans ce langage. L usine est constituée d un ensemble de composants Fractal qui peuvent être assemblés pour traiter les différents modules de

86 76 Réalisation et description du déploiement Fractal ADL. Le langage ADL de Fractal est extensible car sa DTD peut être étendue pour prendre en compte des propriétés extra-fonctionnelles. En effet, contrairement aux autres ADL qui fixent l ensemble des propriétés (implantations, liaisons, attributs, etc.) qui doivent être décrites pour chaque composant, l ADL Fractal n impose rien. L élément de base est appelé definition définit l élément XML qui est utilisé pour démarrer la description de tout composant. Il possède un attribut obligatoire qui s appelle name qui spécifie le nom du composant décrit. Différents types de modules peuvent être définis. Un exemple typique de module est le module containment qui s applique au module de base en permettant d exprimer des relations de contenance entre composants. Ce module définit un élément XML component qui peut être ajouté en sous-élément d un élément definition ou de lui-même pour spécifier les sous-composants d un composant. Notons que l élément component a un attribut obligatoire name qui permet de spécifier le nom du sous-composant. Fractal ADL définit actuellement trois autres modules qui s appliquent soit au module de base, soit au module containment pour spécifier l architecture de l application : le module interface permet de décrire les interfaces d un composant ; le module implementation permet de décrire l implantation des composants primitifs (i.e. une classe Java) ; le module controller permet la description de la partie contrôle des composants. Exemple Un exemple de définition correspondant à la description de l assemblage Fractal de l exemple de HelloWorld est présenté dans la figure 3.3. Cet exemple est décrit ci-dessous : <definition name="helloworld"> <interface name="r" role="server" signature="main"/> <component name="client"> <interface name="r" role="server" signature="main"/> <interface name="s" role="client" signature="service"/> <content class="clientimpl"/> </component> <component name="server"> <interface name="s" role="server" signature="service"/> <content class="serverimpl"/> </component> <binding client="this.r" server="client.r"/> <binding client="client.s" server="server.s"/> </definition> Autres types d ADLs Dans [BJC05] un méta framework est proposé. Il permet la spécification et la création de framework basé sur les composants pour faciliter la gestion de la reconfiguration

87 Quelques langages de description des entités du déploiement 77 Main Client Service Serveur Fig. 3.3 Assemblage Fractal de l exemple HelloWorld des systèmes pendant l exécution. Ce méta framework représente l intégration d un langage de description d architecture (une extension de ACME/Armani) sous Open- COM [CBG + 04] qui est utilisé pour l implantation d une version réflexive de OpenORB [Ope03b]. Armani [Mon98] est une extension d ACME [GMW00], il est basé sur la logique des prédicats du premier ordre (FOPL) utilisée pour exprimer les contraintes d architecture. Les extensions d ACME représentent : la construction conditionnelle au niveau des contraintes, la suppression des éléments existants, l expression des dépendances d exécution entre les éléments de l architecture et la possibilité de manipuler des instances pendant l exécution. Un nouveau type d ADL (π-adl) [Oqu04] a été conçu dans le projet européen d ArchWare pour les spécifications d architectures dynamiques et mobiles basées sur la réflexion et la réification. C est un langage de haut niveau basé sur le π-calcul qui permet de décrire la structure et le comportement. Il fournit d une part une description formelle expressive et d autre part une notation graphique UML dans un framework dirigé par les modèles (MDA) [Gro03a]. La principale originalité de ce langage d architecture est la spécification de comportement des entités du système, ce qui permet à la connexion de vérifier plus précisément si deux composants sont compatibles et ne se limite pas à un contrat de type interface Discussion Nous pouvons constater la grande diversité des ADLs au niveau de leurs caractéristiques et de leurs interprétations de la sémantique d assemblage. Ces différents langages permettent de décrire l architecture d un système en termes d interfaces et d assemblage. Néanmoins, ils ne sont pas assez précis car ils ne fournissent pas d informations sur les dépendances existantes entre les interfaces requises et fournies d un même composant par exemple. Contrairement a notre approche, le composant est souvent considéré dans les ADLs comme étant une boite noire Les langages de description des paquets Nous présentons ci-dessous brièvement les descripteurs des paquets RPM et Debian.

88 78 Réalisation et description du déploiement Name: nom_du_spec Version: Release: 1%{?dist}... BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{ id_u} -n) BuildRequires: Requires: Conflicts : %description %prep %setup -q %build %configure make %{?_smp_mflags} %install rm -rf $RPM_BUILD_ROOT make install DESTDIR=$RPM_BUILD_ROOT %clean rm -rf $RPM_BUILD_ROOT %files %defattr(-,root,root,-) %doc %changelog Fig. 3.4 Un exemple d un fichier SPEC rpm Description d un paquet RPM Un paquet RPM possède un fichier SPEC qui contient les informations et directives pour la gestion du paquet (installation, etc.). Un exemple de SPEC est présenté dans la figure 3.4. Un paquet RPM possède deux sortes de dépendances : les dépendances pour la compilation et celles pour l utilisation. Les dépendances de compilation sont définies par le mot clés BuildRequires. Les dépendances d installation sont décrites par Requires. Les paquets qui ne doivent pas être installés pour que le paquet puisse fonctionner sont décrits par conflicts La section %build compile le logiciel. La section %install installe le logiciel. La section %files permet d installer les fichiers du paquet. La partie Changelog indique les modifications apportées au fichier par rapport à la version précédente. Paquet virtuel Il est également possible de déclarer les dépendances sur les paquets virtuels. Un paquet virtuel est un nom spécifié à l aide du marqueur provides. Les paquets virtuels permettent de décrire qu une fonctionnalité est fournie par plusieurs paquets. Par exemple, si le paquet ocaml fournit le paquet virtuel ocaml alors n importe quelle dépendance sur ocaml peut être satisfaite par le paquet ocaml.

89 Quelques langages de description des entités du déploiement 79 Package: Ocaml Version: Section: devel Priority: optional Depends: ocaml-base (= ), ocaml-base , ocaml-nox , ocaml-base-nox(>= ) Suggests: xlibs-dev, tcl8.4-dev, tk8.4-dev Provides: ocaml Installed-Size: 7052 Maintainer: Debian Ocaml Maintainer Description: ML language implementation with a class-based object system Objective Caml is an implementation of the ML language... Fig. 3.5 Exemple d un fichier control DEB RPM traite les dépendances entre les paquets dans les cas d installation de suppression et de mise à jour Description d un paquet Debian Nous présentons comment un paquet dans Debian est décrit. La figure 3.5 illustre un exemple d un fichier contrôle d un paquet Debian. Les champs du fichier control (excepté ceux relatives aux dépendances) d un paquet binaire sont les suivantes : Package qui est le nom du paquet. Source identifie le nom du source du paquet à partir duquel le paquet est créé.version est le numéro de version du paquet. Section pour classifier les paquets (il existe trois sections : main, contrib et non-free). Priority indique la priorité du paquet, elle peut être required dans ce cas le système ne fonctionnera pas sans ce paquet, important (le minimum exigé par n importe quel système Unix), standard (installé par défaut), optional (installé souvent mais pas nécessairement, par exemple le système X Window) et extra (tous les autres cas). Architecture peut être spécifique (i386, sparc, etc.) ou indépendante du paquet (all). Essential si ce champ est positionné a yes, le paquet ne devrait pas être supprimé. Installed-Size est la taille du paquet après son installation. Maintainer est le responsable du paquet. Concernant les dépendances le système de paquet Debian a un ensemble de dépendances de paquets que nous résumons comme suit : Depends : si le paquet A dépend du paquet B, le paquet B doit être installé pour exécuter A (dépendance d exécution). Recommends : si le paquet A recommande le paquet B, le paquet B n est pas nécessaire mais il est requis pour le bon fonctionnement de A. Suggests : si le paquet A suggère le paquet B, le paquet A peut fonctionner proprement sans le paquet. Conflicts : si le paquet A est en conflit avec le paquet B, le paquet A ne peut pas

90 80 Réalisation et description du déploiement être exécuté si B est installé dans le système. Les conflits sont souvent présents quand les mêmes fichiers contenus dans A et B possèdent des versions plus récentes dans B. Il est donc impossible pour deux paquets en conflit d être installé dans un système en même temps. Replaces : si le paquet A est en conflit avec le paquet B et si le paquet A remplace le paquet B alors le paquet B va être supprimé et le paquet A va être installé et les fichiers installés par B sont supprimés et remplacés par ceux de A. provides permet de décrire les paquets virtuels fournis Synthèse Nous remarquons que la description des exigences des paquets est assez riche par rapport aux langages vus précédemment. Cependant, au niveau des exigences, il n existe aucun moyen pour préciser qu un composant fonctionnera avec soit le paquet A ou le paquet B mais pas les deux en même temps. De plus, la description permet d exprimer des dépendances optionnelles mais pas des fonctionnalités optionnelles, par exemple, qu un paquet fournit en plus des paquets virtuels obligatoires d autres paquets optionnels. En effet, nous pouvons imaginer que le paquet peut fournir des paquets optionnels (conditionnels) dans le cas où leurs exigences sont disponibles et dans le cas contraire, ils ne seront pas fournis mais le paquet principal est toujours installable. Il faut également noter que le langage manque d une description déclarative du contenu du paquet et s appuie sur les scripts Descripteur dans EDOS EDOS (Environment for the development and Distribution of Open Source software) [EDO, R. 05] vise à gérer la complexité dans le domaine du développement Open Source. Il s intéresse à la gestion des dépendances des paquets logiciels en se basant sur un langage de prédicat étendu [R. 06]. Ce langage permet d exprimer des disjonctions de dépendances et des conflits entre les composants. En effet, il est possible d exprimer qu un paquet a besoin du paquet A ou du paquet B. De plus, les paquets peuvent spécifier les conflits en interdisant la coexistence des paquets en question. Il décrit formellement les dépendances au sein d un dépôt en représentant des conjonctions, des disjonctions et des conflits entre paquets dans un graphe. Le framework propose une spécification formelle pour la gestion du déploiement des paquets et pour la résolution du problème d installabilité [R. 06]. Il fournit également d une part, une preuve sur la complexité du problème d installabilité (NP-complet) et d autre part, une implantation du problème comme étant un SAT et un CP (Constraint Problem). Un ensemble d outils est développé dans le cadre de ce projet pour la gestion des dépendances, la vérification des archives Debian, des extension pour le gestionnaire de paquets APT, etc. [R. 06, DM07]. Le langage de prédicat considère la relation de conflit comme étant une relation binaire. En conséquence, il n existe aucun moyen de spécifier par exemple, qu un composant ne peut pas être déployé en présence de deux paquets distincts A et B en même

91 Quelques langages de description des entités du déploiement 81 <<RootComponent>> PC 1 <<ComponentType>> Motherboard <<ComponentType>> Motherboard <<ComponentType>> Motherboard-2 1 <<ComponentType>> CPU 1 1 <<ComponentType>> Serveur-OS build : date 1 <<ComponentType>> Software-Package <<ComponentType>> Application built : date <<ComponentType>> CPU-586 <<ComponentType>> CPU <<Port>> AT-Bus-Slo <<requires>> 3 <<Port>> PCI-Slot <<requires>> <<ComponentType>> Server-OS-1 <<ComponentType>> Server-OS <<ComponentType>> Dev-Environment <<hcompatible>> Fig. 3.6 Un exemple de configuration décrite en UML temps. Pour l instant, la spécification permet d interdire un à la fois et pas les deux paquets en même temps. Enfin, en ce qui concerne la gestion des paquets, EDOS ne donne aucune information sur la façon dont les paquets interagissent avec le noyau et le système de fichiers existants UML Nous avons vu dans le chapitre 2 quelques travaux de déploiement dirigés par les modèles : la spécification D&C proposée par l OMG, ORYA et CADeComp. Ces travaux utilisent UML pour modéliser le déploiement. UML (Unified Modeling Language, [Gro03b]) est un langage de modélisation qui est largement utilisé dans l industrie. Il fournit plusieurs diagrammes pour la modélisation des systèmes, par exemple les diagrammes d activité, les diagrammes de séquence et les diagrammes d état qui permettent de modéliser le comportement. Comme les outils offerts par UML sont assez connus pour leur simplicité, son utilisation est plus facile. Dans [FFJZ02], UML est utilisé pour la modélisation de la configuration de systèmes. En effet, un autre exemple d utilisation d UML se trouve dans [FFJ99]. Par exemple, la figure 3.6 illustre une partie d un modèle de configuration de PC qui représente la description de la carte mère et le paquet logiciel. Ces descriptions sont ensuite utilisées pour la génération de descriptions formelles pour les applications industrielles [FFJ00]. Les descriptions formelles permettent de réduire le temps et les efforts de développement parce qu elles sont directement exécutables. Cependant, les diagrammes UML ne permettent pas d exprimer des contraintes sur

92 82 Réalisation et description du déploiement les entités. Pour cela, la norme UML intègre le langage formel OCL (Object Constraint Language). Ce langage logique permet de spécifier des contraintes et des invariants sur les opérations, les méthodes et les classes d un modèle UML. L avantage d exprimer un ensemble de contraintes OCL au niveau méta-modèle réside dans le fait que ces contraintes peuvent porter sur n importe quel type de diagramme UML. Il permet également de spécifier des requêtes sur des entités décrites dans le modèle. Pour enrichir la description de contrat d un système, il est possible d aller plus loin qu OCL et utiliser des langages permettant, par exemple, d exprimer des propriétés temporelles (par exemple, LOTOS [ISO89]). En revanche, ce type d approche reste totalement ad-hoc, chaque utilisation d un nouveau formalisme exigeant une intégration manuelle avec UML. De plus, UML contient des points de variation sémantique qui permettent à des outils d avoir des interprétations différentes d un même modèle UML. Comme un de nos objectif est de concevoir un système de déploiement sûr qui exige une sémantique de description claire et une interprétation unique, nous utilisons donc UML juste pour la modélisation globale du déploiement et pas pour la description précise des entités Quelques standards de description Il existe plusieurs standards pour décrire des entités logicielles et matérielles. Parmi eux peuvent être mentionnés les standards proposés par le Desktop Management Task Force (DMTF) plus particulièrement Common Information Model (CIM) et les standards proposés par W3C plus particulièrement RDF Ressource Description Framework et CC/PP (Composite Capabilities/Preference Profiles) CIM CIM (Common Information Model) [Com99] est un standard proposé par DMTF (Distributed Management Task Force) [DMT] qui représente un ensemble de définitions pour la gestion des réseaux, des applications et des services dans les entreprises. Ces définitions permettent aux industriels de s échanger ces informations sur leurs systèmes à travers le réseau. Les spécifications CIM décrivent un méta-modèle objet basé sur le langage UML. Ce modèle inclue les expressions des éléments communs qui doivent être présents pour la gestion des applications (par exemple : classes, propriétés, méthodes, indications, associations). La spécification définit une syntaxe pour les langages CIM basée sur le langage IDL [OMG02] appelé MOF (Management Object Format) et des mécanismes de nommage RDF RDF (Resource Description Framework) [RDF03] recommandé par W3C (World Wide Web Consortium) est un framework pour la description de ressources sur le web. Il utilise la syntaxe XML pour décrire des ressources Web sous forme du triplet : ressources, propriétés et valeurs. Les ressources sont identifiées par une URI (Uniform

93 Quelques langages de description des entités du déploiement 83 Fig. 3.7 Exemple de description RDF Resource Identifiers) et ne sont pas obligatoirement accessibles via le Web. Les propriétés représentent des caractéristiques, des attributs ou de relations utilisées pour décrire des ressources particulières. Les valeurs peuvent être d un type primitif (par exemple, chaînes de caractères) ou une autre ressource. La modélisation RDF ne permet pas de définir des vocabulaires pour décrire la sémantique de description de ressources. Cependant, RDFS [W3C00] permet d étendre le vocabulaire RDF en définissant le schéma correspondant au contexte d utilisation. Il se base sur le concept de triplet et permet de définir des classes, des sous classes, des propriétés et des sous propriétés. Exemple La description RDF ci-dessous représente la description des propriétés : créateur, titre et date d une ressource. La description graphique correspondante est présentée dans la figure 3.7. <?xml version="1.0"?> <rdf:rdf xmlns:rdf=" xmlns:dc=" <rdf:description about=" <dc:creator>john Punin</dc:creator> <dc:title>programming XML in Java</dc:title> <dc:date> </dc:date> </rdf:description> </rdf:rdf> CC/PP CC/PP (Composite Capabilities/Preference Profiles) [W3C04a] est un standard proposé par le W3C [W3C04a] pour la description des capacités du terminal et des préférences de l utilisateur. Il est basé sur RDF, il permet de fournir une description à deux niveaux : composant et attribut. Un composant représente une ressource (par exemple

94 84 Réalisation et description du déploiement un logiciel), et un attribut représente une propriété du composant comme la version du logiciel. Un profil CC/PP contient un ou plusieurs composants, qui contiennent à leurs tours un ou plusieurs attributs. Chaque composant est représenté par une ressource de type ccpp :Component Synthèse Cette section présente une synthèse sur les langages de description les plus utilisés pour la description de nos modèles que nous avons proposés dans le chapitre 2. Ces quatre domaines de modélisation ont besoin d un (ou plusieurs) langage(s) qui permette(nt) de réaliser le modèle de déploiement. Nous nous sommes concentrés plus particulièrement sur la description des ressources. Le tableau 3.1 représente une synthèse sur les langages présentés dans cette section en terme de description des ressources à savoir les applications à déployer ou la plateforme cible. La description de l application est divisée en quatre principales parties : la description de ses exigences, ses conflits, ses effets sur le système cible et ses intradépendances. Ces intra-dépendances représentent les relations qui existent entre chaque service fourni (l effet) avec l ensemble de ses exigences et ses conflits. Nous constatons que les langages OSD et les descripteurs des paquets Debian, rpm ainsi que les descripteurs de composants Nix ne permettent pas de décrire la plateforme cible mais uniquement l application, contrairement aux langages RDF, CC/PP, DSD et COACH. Au niveau de la description de l application, les conflits ne sont pas décrits dans la plupart des langages à l exception des descripteurs de paquets. De plus, les intradépendances des composants ne sont pas décrites dans la plupart des formalismes et langages présentés. Cependant, dans un descripteur de paquet nous retrouvons la description des dépendances obligatoires souvent par rapport à un seul paquet virtuel fourni et pas de description des dépendances optionnelles relatives aux paquets supplémentaire. En revanche, la description des exigences et des services fournis est globale dans la plupart des autres descriptions car il n existe aucun moyen de savoir pour chaque service fourni ses exigences précises. En effet, les exigences concernent souvent tout le composant avec tout ce qu il peut potentiellement fournir. Avec le besoin de description détaillée aussi bien au niveau de l application et du système cible, nous utilisons un langage de description approprié. Ce langage doit décrire les différentes dépendances de l application. La description des dépendances doit être riche dans le sens où nous pouvons décrire des exigences pour chaque service potentiellement fourni. Ce langage devrait décrire des exigences plus complexes, par exemple, sous forme de conjonction, de disjonction, de conflits, obligatoires ou optionnelles. Au niveau des services fournis, il devrait également décrire un choix entre plusieurs services et des services optionnels. Nous décrivons dans le chapitre 5 page 103 ce langage de dépendance ainsi que notre description de la plate-forme cible.

95 Comment décrire nos modèles de déploiement? 85 Langages Application Exigences Conflits Effets Intra-dépendances Plate-forme OSD + + DSD COACH + ADL rpm deb Nix + + RDF + CC/PP + Tab. 3.1 Les langages de description des entités et des systèmes de déploiement 3.3 Comment décrire nos modèles de déploiement? Dans cette section nous décrivons brièvement les langages les plus utilisés pour décrire les modèles de déploiement retenus dans le chapitre 2. Ces modèles sont décrits plus en détail dans le chapitre suivant Les ressources Le domaine où cette question est la plus simple est celui des ressources. En effet, un certain consensus scientifique semble se faire sur les langages de description de ressources. Ce qu il faut noter est qu au niveau des ressources, nous avons besoin de décrire (1) le composant ou l application en question avec ses exigences et ses effets (2) la description du système cible et son architecture. Pour cela, il faut étudier au niveau de chaque langage présenté quel est celui qui permet de décrire l application en question ou le site cible ou les deux en même temps. La description du composant concerne ses dépendances qui représentent ses contraintes et ses effets sur le système cible (pré et post conditions). Pour chaque effet potentiel du composant sur le système, nous devons décrire l ensemble des contraintes le concernant, ce que nous avons appelé intra-dépendance. Cette description est plus riche que celle utilisée dans certains langages présentés car elle décrit explicitement la relation entre chaque élément fourni et ses exigences. En effet, dans la plupart des descriptions actuelles nous avons une description globale de toutes les exigences ainsi que leurs effets. Comme nous avons vue dans le chapitre 2, le langage de modélisation UML est souvent utilisé pour décrire les entités de déploiement (application et site cible). L intérêt majeur d UML est sa diffusion, il est largement utilisé dans l industrie et donc bien connu. De plus, une représentation UML peut être transformée en une représentation en logique pour raisonner (cf. [FFJ00]). RDF, est un standard sur lequel sont basés beaucoup d autres standards de des-

96 86 Réalisation et description du déploiement cription des méta-données notamment CC/PP, OWL [W3C04b], etc. Il permet un traitement automatique de l information. C est un langage probablement moins utilisé actuellement mais qui est fortement relié à des travaux sur le raisonnement à partir de connaissances. Il permet de décrire les ressources du site cible. Les ADLs permettent de décrire l architecture du composant mais souvent d une façon statique. De plus, les exigences au niveau des composants sont d une part globales et pas propres à chaque service fourni, et d autre part, moins riche que celles exprimées par les descripteurs des paquets logiciels. Les langages de description des paquets permettent de décrire les exigences des paquets. L assemblage est dirigé par les exigences, il suffit d avoir l exigence disponible pour installer le paquet. L architecture des paquets est donc plus dynamique que celle des composants. Nous décrivons dans le chapitre 10 page 195 une comparaison de notre approche de description avec celle utilisée dans les composants et les paquets Les mécanismes Les mécanismes peuvent être décrits suivant de nombreuses approches. Nous pouvons citer : les réseaux de Pétri [Mur89], des approches flot de données (workflow), des calculs de processus : CSP [Hoa78], CCS [Mil82], Pi-calcul [Mil99], etc. Des langages de spécification et les scripts exécutables (un shell d exécution comme dans les systèmes Linux, un script perl, etc.). Si l on veut être capable de raisonner sur les mécanismes, il faut que le formalisme de leur description le permette ce qui exclu les langages de script souvent utilisés pour l installation et la configuration. La difficulté est similaire au problème de la réalisation de programme, toutes les approches semblent pertinentes et sont adaptées pour certains domaines. À notre connaissance, aucun travaux n a vraiment étudié l adaptation des approches de la programmation (fonctionnelle, déclarative, impérative, etc.) dans le domaine du déploiement. Et les langages utilisés (par exemple, pour ORYA) sont des résultats hybrides de tous ces modèles. Une autre approche possible serait de séparer l exécution du mécanisme de sa description. Cela rendrait le système plus souple puisque le langage de réalisation serait libre. La seule exigence serait de fournir une description abstraite du mécanisme, par exemple, la liste des ressources manipulées, le type de manipulation accès, modification, destruction, les propriétés du mécanisme, etc. La difficulté majeure d une telle approche serait la difficulté de construire la description de manière sûre. L expérience montre que les programmeurs ne maîtrisent souvent pas toutes les actions de leurs programmes. Dans le cadre de notre travail nous nous concentrons sur le raisonnement formel du déploiement qui déclenche un ensemble de mécanismes sûrs. Les mécanismes abordés dans notre travail représentent l ensemble des règles formelles de déploiement Les politiques Dans le domaine des politiques, l approche dominante est celle du modèle ECA (Événement Condition Action). Cette approche décrit les politiques comme des réponses par des actions sous certaines conditions sur des événements particuliers. Par exemple,

97 Conclusion 87 si une alerte «manque espace disque» survient et que la machine n est pas trop chargée, supprimer les applications non indispensables. La limite de cette forme de langage de spécification est la problématique de la construction de politiques complexes. En effet, comment se combinent de telles règles? Comment s assurer qu une règle n est pas en contradiction avec une autre? Comment faire pour que le système finisse par converger et ne boucle pas sur certaines règles? Les travaux dans le domaine de la gestion par politique sont actuellement très actifs. L IETF propose une classification des politiques fonctionnelles ainsi que le modèle PCIM (Policy Core Information Model) [MEJW01] qui permet de modéliser les politiques à déployer pour une gestion de réseau. Ce modèle est basé sur le modèle CIM (Common Information Model) cité dans la section Dans le carde de notre travail, nous n avons pas décrit formellement les politiques dans notre système de déploiement Les propriétés Le domaine des propriétés est assez ouvert et des divers projets de recherche sur le domaine sont en cours. Les outils actuels considèrent que ces propriétés sont fixes et sont des caractéristiques du système de déploiement. Or, nous pensons que dans la description de politiques ou de celle de mécanismes, nous aurons besoin d expliciter les propriétés que nous souhaitons pour notre système. Dans les travaux sur les propriétés de performance et de sécurité plusieurs travaux utilisent les formalismes des calculs de processus (CSP [Hoa78], CCS [Mil82], Pi-calcul [Mil99], Ambiant, etc.). Nous retrouvons le projet COMQUAD [GPA + 04] qui s intéresse à la spécification des propriétés non fonctionnelles des composants. Il se base sur le langage CQML (Component Quality Modeling Language) [RZ03] pour la description des propriétés de qualité de service requises et offertes par des composants. Cependant, ce langage est basé sur les relations de qualité de service entre les différents composants et ne permet pas de spécifier les besoins en terme de ressources. Nous avons choisie une description simple des propriétés qui représentent les caractéristiques fonctionnelles ou non-fonctionnelles d une ressources. Une propriété est représentée par une variable, un opérateur et une valeur. La variable est un string, la valeur peut être un nombre, un string et un booléen, l opérateur de comparaison sert pour comparer les variables avec les valeurs. Les détails sur la description des propriétés sont présentés dans le chapitre 8 page Conclusion Dans ce chapitre nous nous sommes concentrés sur les opérations de déploiement effectuées dans quelques outils ainsi que les langages de description des entités de déploiement. Chaque outil possède ses propres entités, systèmes et mécanismes de déploiement. Dans le contexte de notre travail l unité de déploiement est le composant et ses services. La notion de composant s applique dans de nombreuses approches. Par exemple, les composants CCM, EJB, Fractal, etc., Les paquets Linux (rpm, deb, etc.) ou encore sur les conteneurs d applications (bundles OSGi abordé dans le chapitre 1).

98 88 Réalisation et description du déploiement Si chaque plate-forme définit sa propre structure de paquet ou de composant et de déploiement, on y retrouve particulièrement les concepts suivants : Descripteur de composant qui contient ses dépendances et permet de contrôler si le composant est déployable ou non ; Descripteur de déploiement qui décrit l archive, le format peut être une description de l archive, un script comme dans les systèmes Linux, un fichier XML (CCM) ou encore un fichier manifest java (OSGi). Pour gérer tous ces concepts chaque système possède sa propre architecture pour réaliser le déploiement. Dans notre architecture, nous nous sommes focalisés sur ces trois concepts plus particulièrement le moteur de déploiement qui est une sorte de descripteur de déploiement. Ce dernier utilise des descriptions de la plate-forme et du composant à déployer pour effectuer le déploiement. Les détails sur notre architecture sont présentés dans le chapitre 4. Nous devons décrire les entités de déploiement qui sont l application ou le composant et le site cible. La description du composant doit être suffisamment précise pour exprimer la relation entre chaque service fourni et ses exigences. Cette description spécifie les intra-dépendances (abordées dans le chapitre suivant). Cette relation représente des contrats paramétriques [RPS03] car les services fournis sont liés aux services requis qui en dépendent. En effet, les services fournis varient en fonction de la disponibilité des exigences. La description du composant représente donc l ensemble de ses intradépendances (contraintes du composant et ses effets sur le système cible). La description du système cible représente l ensemble des entités matérielles et logicielles de l environnement avec tous les composants qui constituent l architecture du système. Elle représente l interconnexion entre tous les composants du système. Une telle architecture aussi explicite n est pas facile à gérer vue sa taille. Pour cela, afin de gérer les opérations de déploiement, nous faisons une approximation de ces dépendances entre composants (interdépendances). Il conviendrait de décrire les entités de déploiement avec un langage approprié. Pour le choix de ce langage de description, une approche simple utilisant la logique du premier ordre qui est munie d une sémantique sûre semble suffisante pour décrire les différentes entités de déploiement avec leurs dépendances plus formellement. Les détails sur ces langages seront abordés dans le chapitre 5 page 103. Notre architecture du déploiement et décrite en détail avec nos modèles de déploiement retenus dans le chapitre suivant.

99 Chapitre 4 Préambule sur les contributions Sommaire 3.1 Quelques outils de réalisation du déploiement Les gestionnaires de paquets Nix Installshield Quelques langages de description des entités du déploiement Les langages de description de composants Les langages de description des paquets Descripteur dans EDOS UML Quelques standards de description Synthèse Comment décrire nos modèles de déploiement? Les ressources Les mécanismes Les politiques Les propriétés Conclusion Dans les chapitres précédents, nous avons abordé l état de l art sur les entités qui nous intéressent (les composants et les services), les principaux concepts de déploiement et la façon dont ils sont réalisés. L objectif de cet état de l art est de construire une base d étude pour proposer un modèle de déploiement flexible et sûr afin de répondre à quelques problématiques de déploiement. Pour répondre au besoin de la flexibilité, il faut construire des modèles abstraits qui définissent de manière générique ces principaux concepts étudiés. Pour répondre au besoin de la sûreté, il faut proposer une architecture de déploiement qui permet de vérifier les opérations du déploiement et d assurer le bon fonctionnement du système cible. Ce chapitre décrit notre modèle de composant, notre méta-modèle de déploiement ainsi que notre architecture de déploiement. Les détails sur la vérification des opérations du déploiement seront abordés dans les chapitres suivants. 89

100 90 Préambule sur les contributions 4.1 Introduction La principale constatation issue de l état de l art est qu il existe de nombreux outils qui ont des approches souvent très différentes du problème de déploiement. En effet, pour résoudre de façon pragmatique le problème du déploiement, ils se sont souvent spécialisés soit sur certaines phases du déploiement, soit sur des systèmes d exploitation, soit sur un procédé de déploiement fixe sans fournir un moyen pour garantir le bon fonctionnement du système cible. Les limites de ces outils sont donc rapidement atteintes. Pour pouvoir parler d un déploiement flexible et sûr, c est-à-dire, déployer selon les besoins et les exigence et diminuer fortement l intervention humaine, il faut aller plus loin et concevoir une infrastructure de déploiement suivant : un modèle de déploiement et une architecture qui soient les plus génériques possible, et un système formel pour la vérification et la preuve du bon déroulement du déploiement. 4.2 Description des entités du déploiement Après l étude des modèles de composants et de services, nous avons opté pour une approche mixte, c est-à-dire une approche qui considère les deux entités : les composants et les services. Les composants requièrent et fournissent des services, le service représente donc l unité logiciel qu un composant peut fournir ou exiger. Le descripteur d un composant est un descripteur des dépendances qui existent entre ses services fournis et ses services requis. La réalisation et la vérification de l installation et de la mise à jour des composants sont basés principalement sur ce descripteur de dépendances. Au niveau du déploiement, le plus important est la représentation des dépendances (relation entre les interfaces requises et fournies). Pour cela, nous avons choisi de représenter le composant par ses dépendances, ses services requis, ses services fournis et ses propriétés. La figure 4.1 représente le méta-modèle de composant que nous proposons. Un composant peut être composé de plusieurs composants (composant composite). La description usuelle d une dépendance de façon générale est représentée par relation d InterDépendanceComposant qui décrit la liaison entre deux composants différents. Le lien entre un services requis par un composant et un service fourni par un autre composant représente la relation d InterDépendanceService (le service requis et le service fourni doivent être compatibles). Cette relation est définie par l assembleur de l application, elle est un raffinement de la relation InterDépendanceComposant qui a la même signification mais décrite en termes de composants. Enfin, la relation IntraDépendance est la partie la plus originale de notre contribution, elle permet d exprimer le lien entre chaque service fourni par un composant et l ensemble de ses exigences. L intradépendance est définie par le concepteur ou le développeur de l application. Étant donné que ces intra-dépendances sont explicites dans notre modèle, le composant n est donc plus considéré comme une boite noire. Pour représenter graphiquement un composant et ses services requis et fournis, nous proposons la représentation graphique de la figure 4.2. Les services fournis sont représentés par des ronds noirs. Les exigences peuvent être logicielles et correspondre à des services (demi-cercle) ou portées sur l environnement.

101 Description des entités du déploiement 91 Les dépendances entre composants (description usuelle) Propriété 1..* 0..* 1 1 Composant * 1 InterDépendanceComposant 0..* * Service Les dépendances au sein d un même composant, entre chaque service fourni d un composant et ses exigences (développeur) Les dépendances entre service requis d un composant et service fourni d un autre composant (assembbleur) IntraDépendance 0..* 1..* Requis Fourni 1 0..* InterDépendanceService (C.Fourni,C.Requis) 0..* * C1.Fourni=C2.Requis Fig. 4.1 Le méta-modèle d un composant Ces dernières seront alors de la forme une variable comparée à une valeur et sont représentées par des crochets. Ainsi, par exemple, le système d exploitation Linux peut être exigé (OS=Linux) ou l espace disque requis peut être de 100 Mo (Free disk space 100 Mo). Nous reviendrons en détail sur la description formelle des composants dans le chapitre 5 page 103. La figure 4.3 illustre les différentes relations de dépendances qui peuvent exister au sein d un assemblage de composants : l intra-dépendance au niveau d un seul composant, elle est représentée par des traits continus à l intérieur des composants, et l interdépendance entre les différents composants, elle est représentée en pointillé. Selon le diagramme de la figure 4.1, il existe trois niveaux de dépendances. Nous pouvons les illustrer en utilisant le schéma de composition de la figure 4.3. Le premier niveau concerne l InterDépendanceComposant qui décrit les dépendances usuelles entre composants (le composant B dépend du composant A). Le deuxième niveau concerne InterDépendanceService, c est-à-dire la relation d interdépendance en termes de services entre un composant et un autre (le service rb2 requis par le composant B dépend du service pa1 fourni par le composant A). Enfin, le troisième niveau concerne l intra-

102 92 Préambule sur les contributions Fig. 4.2 Notre représentation graphique rb1 pb1 ra1 ra2 pa1 pa2 rb2 B pb2 rc1 rc2 rc3 pc1 pc2 ra3 A C Fig. 4.3 Les relations de dépendances dépendance qui représente la relation entre des services requis et fournis au sein du même composant (le service pa1 est fourni par le composant A si le service ra1 et le service ra2 requis par ce dernier sont disponibles). 4.3 Modélisation du déploiement Pour l automatisation du déploiement, nous avons besoin de définir et de construire des modèles abstraits. L intérêt de ces modèles est double, ils permettent d avoir d un coté un aspect paramétrable et extensible donc plus de flexibilité au niveau du système et de l autre coté un raisonnement indépendant des contraintes de réalisation donc plus générique Le modèle générique Après l étude des différents concepts de déploiement dans le chapitre 2, nous défendons un découpage en quatre modèles présentés dans de la figure 4.4 : les ressources, les mécanismes, les politiques et les propriétés. Dans ce découpage, les concepts sont classés suivant leur rôle durant le déploiement. Ainsi, les ressources sont manipulées durant le déploiement (n importe quelle entité intervenant au niveau du déploiement). Par exemple, lors de l installation d un serveur de mail sur une machine, le serveur de mail (POSTFIX) et la machine sont des ressources. Les mécanismes décrivent la façon dont sont réalisées les opérations agissant sur les ressources (installer, copier, supprimer, rajouter, etc.). Les politiques décrivent les choix des mécanismes à appliquer en

103 Modélisation du déploiement 93 fonction de l état des ressources. Par exemple, une politique de sécurité peut interdire l installation des programmes qui sont susceptibles à diminuer le niveau de sécurité du système cible (par exemple, l interdiction de l installation d un composant ftp). Enfin, les propriétés permettent de décrire les caractéristiques des ressources : l entité (E.version=1.0.2) ou le système cible (RAM=64Mo) ou un autre niveau de propriétés qui exprime les buts à atteindre par le système (sûreté, succès). Les politiques portent souvent sur des propriétés du système cible ou de l entité. Ces modèles sont récursifs, c est-à-dire qu une entité manipulée (ressource, mécanisme, politique ou propriété) est également composée de sous-entités. Par exemple, une ressource de type machine contient des ressources de type logiciel qui contiennent des ressources de type composant qui sont composés de ressources de type service. Ainsi, chaque modèle fournira une description hiérarchique et structurée. Propriétés Politiques Cohérence Sécurisée Déploiement Ressources Mécanismes Machine Postfix Installation Fig. 4.4 Les quatre modèles du déploiement La figure 4.5 illustre les trois niveaux d abstraction relatifs au déploiement : le premier niveau concerne les principaux modèles de déploiement proposés, il est générique (le méta-méta modèle), le deuxième niveau concerne le méta-modèle qui est défini par par le système, enfin, le troisième niveau est de l ordre d instanciation réelle des modèles de déploiement proposés. Chaque niveau hérite de niveau d au-dessus. Ainsi, le passage de haut en bas permet d avoir des modèles de déploiement plus spécialisés et le passage de bas en haut permet de généraliser et d abstraire les modèles de déploiement. L intérêt de cette séparation est de pouvoir définir une infinité de choix et de personnaliser ces modèles pour mettre en œuvre des solutions spécifiques à partir des concepts génériques (méta-méta modèle). Par exemple, les ressources représentent le concept générique, le contexte et le composant représentent une spécialisation des ressources, ils représentent nos choix par défaut en terme de ressources, enfin, au niveau du modèle, le système Linux est une instance du contexte et POSTFIX est une instance de composant. L assemblage des composants représenté dans le modèle de la figure 4.5 illustre les relations décrites dans le méta-modèle au dessus : l interdépendances entre les différents composants et l intra-dépendances au niveau d un même composant. Nous pouvons imaginer en rajouter de nouveaux types de ressources au niveau du méta-modèle comme l utilisateur par exemple.

104 94 Préambule sur les contributions Méta-méta modèle 1..* 1 <<metaclass>> Propriété 0..* 0..* 0..* 0..* <<metaclass>> Politique 0..* 1..* * <<metaclass>> Ressource * 1..* 1..* <<metaclass>> Mécanisme 1..* 1 Méta modèle 1..* * 1 <<Ressource>> Composant 1 1..* * 1 <<Propriété>> InterDépendanceComposant <<Ressource>> Contexte 1 Instance de <<Propriété>> Propriété 0..*1 <<Ressource>> Service <<Propriété>> IntraDépendance 0..* Requis 1 1 Fourni 1 0..* <<Propriété>> InterDépendanceService 0..* Instance de (C.Fourni,C.Requis) C1.Fourni = C2.Requis <<Mécanisme>> Règles de déploiement 1 <<Composant>> POSTFIX IntraDep1 Composant 1 InterDep(1-2) Composant 2 IntraDep3 1 <<Contexte>> LINUX Modèle IntraDep2 Composant 3 InterDep(3-2) Fig. 4.5 Les trois niveaux de modélisation

105 Modélisation du déploiement Les ressources Une ressource peut représenter n importe quelle entité intervenant au niveau du déploiement. Dans notre cas, nous nous sommes intéressés à deux entités : le site de déploiement et l entité qui est déployée. Dans le premier cas, elle est représentée par une description du contexte de déploiement regroupant l ensemble des entités qui le composent. Dans le second cas, elle est représentée par une description des dépendances du composant. Une ressource possède des mécanismes de déploiement, par exemple, le site de déploiement possède ses propres mécanismes d installation, de désinstallation et de mise à jour. Une ressource possède également des politiques de déploiement et des propriétés Les mécanismes Les mécanismes représentent une suite d actions à effectuer au niveau du site de déploiement. Ils peuvent représenter aussi bien des actions élémentaires (par exemple : transférer, copier, etc.) que des actions plus complexes comme les différentes opérations d un déploiement par exemple : l installation, la configuration, la désinstallation, etc. Au niveau du site de déploiement un mécanisme peut être par exemple : enregistrer l application déployée dans une base de données de l entreprise, rendre une application ou une machine accessible à des utilisateurs du système ayant un certain profil, etc. Au niveau de l entité à déployer, les mécanismes peuvent être représentés par l exécution d un Makefile associé à cette entité, ou la saisie de la clé d installation, etc Les politiques Les politiques permettent de guider le choix des mécanismes, elles dirigent le déploiement suivant des objectifs définis par les ressources (site cible ou application). Elles peuvent être soit au niveau du site, soit au niveau de l entité que l on veut déployer. Ces politiques peuvent être basiques (par exemple : maintenir une certaine propriété ou une certaine valeur d une variable du système) ou de haut niveau c est-à-dire des politiques dirigées par d autres politiques (par exemple : appliquer des politiques de QoS seulement après celles relatives à l optimisation des ressources du système). Une politique peut également interdire l installation d un composant qui consomme beaucoup en termes de ressources ou qui a une propriété interdite par le système cible. Certaines propriétés du système cible peuvent être réalisées par un certain nombre de politiques (maintenir le niveau de sécurité) Les propriétés Les propriétés déterminent les caractéristiques des ressources. Par exemple, la propriété niveau de sécurité peut être décrite au niveau du site de déploiement ou de l entité qui va être déployée. Elle peut avoir plusieurs valeurs relatives à plusieurs niveaux du plus haut niveau de sécurité au plus faible.

106 96 Préambule sur les contributions Ces quatre concepts (ressource, mécanisme, politique et propriété) sont réifiés pour permettre la construction d un système de déploiement flexible. Par exemple, rajouter d autres types de ressource au niveau du méta-modèle, définir des propriétés ou des politiques plus spécifiques pour un système particulier Le méta-modèle du déploiement Le méta-modèle de la figure 4.5 est une représentation UML des différents concepts introduits précédemment. Nous avons divisé ce modèle en deux parties. La première partie est liée aux composants et au contexte du site cible qui sont des spécialisations des ressources (décrites au dessus au niveau du méta-méta-modèle). Le composant est décrit avec ses différentes relations de dépendances dans la section 4.2 page 90. La deuxième partie du méta-modèle, représente le moteur de raisonnement qui est le cœur de notre travail et qui représente une spécialisation des mécanismes. Cette partie est réalisée par un ensemble de règles de déploiement qui utilisent la description des ressources (le composant et le site cible) pour vérifier et réaliser le déploiement. Ces règles peuvent également utiliser les propriétés et les politiques des ressources pour effectuer le déploiement. Les deux principales catégories de ressources sont le contexte du site cible et le composant. Elles sont décrites ci dessous Le contexte de déploiement Le contexte cible du déploiement représente toutes les entités qui constituent les différentes ressources. Elle est une abstraction de la structure arborescente des différents éléments constituant le site cible. Par exemple, un réseau est constitué de plusieurs machines qui ont chacune un OS et plusieurs applications qui sont à leur tour composées de plusieurs composants, etc Le composant Le modèle de composant est déjà décrit dans la section 4.2 page 90. Nous nous concentrons sur la description des dépendances du composant en particulier la relation de l intra-dépendance. Elle représente la relation entre ses fonctionnalités offertes et ses exigences. Les intra-dépendances dépendent du type des exigences qui peuvent être obligatoires, optionnelles ou conflictuelles. Par exemple, si nous prenons le serveur de messagerie POSTFIX, nous pouvons déterminer ses différents types de dépendances : Les dépendances obligatoires comme l OS, la mémoire, les librairies, etc. Les dépendances optionnelles qui ne sont pas nécessaires pour le fonctionnement. Par exemple les services relatives à l anti virus et l anti spam pour augmenter le niveau de sécurité des mails. Les dépendances négatives représentant des relations conflictuelles. Par exemple, les serveurs mail POSTFIX et SENDMAIL de Linux ne peuvent pas coexister sur la même machine en même temps.

107 Réalisation du déploiement 97 Un exemple plus détaillé sur les dépendances du serveur mail POSTFIX sera présenté au chapitre 5 page Les règles de déploiement Les règles de déploiement représentent une spécialisation des mécanismes, elle permettent d effectuer le déploiement en vérifiant les contraintes de l entité qui va être déployée (dépendances) dans l environnement du déploiement (description du contexte). Elles peuvent également utiliser des politiques pour vérifier certaines contraintes sur des propriétés du système cible et/ou de l entité. La réalisation effective de cet effet est interprétée par un certain nombre de mécanismes de bas niveau qui vont êtres déclenchés par la suite au niveau du système cible. Ce type de mécanismes concret n est pas abordé dans notre travail. Si l on considère une gestion du déploiement par politique, nous pouvons choisir la politique la plus appropriée pour le système. Ainsi, dans le cas où il y a des choix à faire (une application avec des dépendances à choix multiples), nous pouvons choisir suivant la politique du système cible, d installer l implantation appropriée de l application. Par exemple, si la politique du système cible est d optimiser les ressources (choisir les entités qui prennent le moins d espace ou choisir le format compressé), et si on avait le choix entre plusieurs application par exemple, l application qui consomme moins de ressource sera installée Synthèse Nous avons présenté dans cette section notre modèle de déploiement basé sur un méta-modèle. Ce dernier décrit les concepts les plus pertinents au niveau du déploiement dans le cadre de notre travail. L idée derrière ce méta-modèle, et de pouvoir le réutiliser indépendamment des entités impliquées dans le déploiement. Ainsi, réifier les quatre concepts de ce méta-modèle (ressource, mécanisme, politique et propriété) pour construire un système de déploiement flexible qui permet de modifier un certain nombre de choix. Par exemple, rajouter d autres types de ressource au niveau du méta-modèle, définir des propriétés ou des politiques plus spécifiques pour un système particulier, etc. 4.4 Réalisation du déploiement L état de l art a permis de déterminer un ensemble de mécanismes suffisants pour décrire les actions de déploiement : l installation, la désinstallation et la mise à jour. Quelques soit le mécanisme effectué, nous retrouvons la description de l environnement cible dans lequel les mécanismes seront réalisés et la description des entités en question (paquet, composant, etc.). Nous avons constaté dans le chapitre 3 que pour la mise en œuvre du déploiement, chaque système propose sa propre architecture de déploiement en présentant les différentes entités permettant de mettre en œuvre les mécanismes de déploiement.

108 98 Préambule sur les contributions La figure 4.6 représente les principales opérations de déploiement que nous étudions. Les entités de déploiement que nous manipulons sont des composants logiciels et les services (décrits dans le chapitre 1 page 21). Dans un système cible, nous pouvons ajouter, supprimer ou mettre à jour des composants. Entité Ajout Retrait Mise à jour Entité Système Entité Fig. 4.6 Les principales phases de déploiement Pour la réalisation du déploiement, nous utilisons des règles de déploiement pour vérifier et prouver ces opérations de déploiement. Pour chaque opération de déploiement, il existe un ensemble de règles. Ces règles sont divisées en deux catégories : celles qui vérifient la possibilité du déploiement (i.e. est il possible de déployer une certaine entité dans un contexte particulier?), et celles qui calculent l effet du déploiement sur le système cible (contexte) une fois l opération de déploiement est possible. Une fois que les dépendances sont vérifiées par ces règles, le déploiement est alors possible et l effet du déploiement est calculé. Le moteur de raisonnement avec ses différentes règles de vérification et de réalisation de l installation et de désinstallation est décrit dans le chapitre 6 page 119, la mise à jour est décrite dans le chapitre 7 page 137. L installation, la désinstallation et la mise à jour d un composant dans un système correspondent respectivement à son ajout, sa suppression et son remplacement dans le système. Le succès de ces opérations exige les contraintes suivantes : 1. Le système fournit les ressources exigées et les services requis par le composant à installer 2. Le composant à installer et ses services fournis ne sont pas en conflit avec les composants et les services déjà installés. 3. Les services fournis par le composant à désinstaller ne sont pas utilisés par d autres composants dans le système. 4. Les services fournis par le composant à mettre à jour et utilisés par d autres composants doivent être fournis également par le nouveau composant. Pour répondre à ces questions, nous avons besoin de décrire les ressources du déploiement : (1) les dépendances du composant en question (ses contraintes et son effet

109 Réalisation du déploiement 99 sur le système cible) (2) le système cible et son architecture. Ces descriptions sont abordées dans le chapitre 5 page 103 de façon plus formelle et détaillée. Les architectures abstraites de notre système d installation, de désinstallation et de mise à jour sont illustrées dans la figure 4.7. Nous avons séparé la réalisation concrète du déploiement de sa description abstraite et sa vérification formelle. Au niveau de la partie qui est au dessous nous retrouvons le système cible dans lequel l entité de déploiement sera déployée réellement. La partie supérieure représente l abstraction de la partie inférieure, c est-à-dire, une description abstraite du système cible que nous avons appelé contexte, une description abstraite de l entité. Le moteur de raisonnement vérifie la faisabilité du déploiement en utilisant ces descriptions et un ensemble de règles de vérification appropriées pour chaque opération de déploiement. La figure 4.7(a) illustre l installation pour laquelle il faut (1) déterminer si l on peut installer l entité en vérifiant sa description abstraite et son effet dans le contexte et (2) calculer l impact de son installation sur le contexte en ajoutant l effet de l installation de l entité dans le contexte (cf. section 6.2 page 120). La figure 4.7(b) décrit le raisonnement de la désinstallation qui se base sur la description du contexte pour (1) déterminer si l on peut désinstaller l entité du contexte et (2) calculer l impact de sa désinstallation sur le contexte (cf. section 6.3 page 129). Enfin, la mise à jour d une entité par une autre telle que présentée dans la figure 4.7(c) consiste à (1) déterminer si l on peut remplacer «entité» par «entité» (2) calculer l impact de la substitution sur le contexte (cf. section 7.1 page 137).

110 100 Préambule sur les contributions Description abstraite de l entité avec effet Raisonnement Ajout effet Description abstraite du contexte Entité Installation Système Entité à désinstaller (a) Raisonnement Retrait effet Description abstraite du contexte Désinstallation Entité Système (b) Description abstraite de l entité avec effet Description Raisonnement abstraite du contexte Ajout/Retrait effet Entité Mise à jour Entité Système (c) Fig. 4.7 Principe (a) d installation (b) de désinstallation et (c) de mise à jour

111 Deuxième partie Vérification formelle du déploiement 101

112

113 Chapitre 5 Description formelle des entités de déploiement Sommaire 4.1 Introduction Description des entités du déploiement Modélisation du déploiement Le modèle générique Le méta-modèle du déploiement Synthèse Réalisation du déploiement Nous avons présenté dans le chapitre précédent notre méta-modèle qui représente les principaux concepts de déploiement que nous avons retenus dans le chapitre 2. Dans ce chapitre, nous présentons la description formelle de deux entités du modèle des ressources. Ces entités sont le composant et le système cible. Notre modèle de composant est présenté dans le chapitre précédent avec ses différentes dépendances de façon globale. Nous détaillons ici la description formelle des intra-dépendances des composants et leur assemblage ainsi que la description du contexte du système cible. L intérêt de ces descriptions formelles est double, d une part, elles permettent d avoir un niveau d expressivité des dépendances plus élevé entre les différentes entités, et d autre part, elles sont utilisées pour vérifier le déploiement et garantir un certain niveau de sûreté dans le système. Cette vérification est réalisée par un ensemble de règles proposées par la suite dans le chapitre 6 et le chapitre Introduction L étude des dépendances des différentes applications est primordiale dans le déploiement. Une dépendance d une application représente la relation entre les fonctionnalités qu elle peut offrir et ses exigences. Elle décrit des contraintes sur l environnement cible 103

114 104 Description formelle des entités de déploiement Exigences Utilisateur Language Mode graphique Doc en ligne.. Contexte Application SE RAM Priorité Processeur CPU... Contexte OK Analyse des dépendances KO Existant Environnement Logiciels SE,... Matériels CPU, RAM,.. Contexte Réseaux bande passante, protocoles,..... Fig. 5.1 L analyse des dépendances dans lequel l application sera déployée. Dans le schéma de la figure 5.1, l analyse des dépendances représente la résolution de l ensemble des contraintes de déploiement liées à l application qui va être déployée par rapport à l existant (les contraintes liées à l environnement) et aux exigences de l utilisateur. Les dépendances peuvent être vues comme un contrat représentant un ensemble de pré et post-conditions. Une classification des contrats est présentée dans [BJPW99]. La démarche que nous avons adoptée est de déterminer les différents types de dépendances liées au déploiement de composants. Par la suite, il faut pouvoir les décrire dans un langage formel pour pouvoir les vérifier dans le contexte de l environnement afin de garantir le bon déroulement du déploiement. Dans [KBK00], une classification des dépendances est proposée (cf. figure 5.2). Les différents types de dépendances sont représentés dans un espace multidimensionnel. Dans le cadre de nos travaux, nous étudions le traitement d une partie de ces dépendances : Selon l axe space/locality/domaine, nous nous intéressons aux intra-dépendances. Selon l axe dependency strength, toutes les dépendances (obligatoires et optionnelles). Selon l axe component type, les dépendances logicielles et matérielles. Selon l axe component activity, nous étudions les composants passifs (aspect statique). Selon l axe dependency formalization, nous visons une formalisation des dépendances en utilisant un sous ensemble de la logique des prédicats. Selon l axe dependency criticality, qui traite l aspect temporel des dépendances et cycle de vie de dépendance, nous étudions pour l instant les dépendances statiques dont la structure ne change pas.

115 Les dépendances des composants logiciels 105 space/locality/domain optional mandatory dependency strength inter domain intra domain inter system intra system intra package none component type hardware logical entity software low corequisite exrequisite passive dependency criticality prerequisite high active component activity dependency formalisation Fig. 5.2 L espace multidimensionnel des dépendances [KBK00] 5.2 Les dépendances des composants logiciels Les dépendances permettent de disposer d une bonne description des exigences et des effets des applications. Une telle description va permettre au système de déterminer les cas de conflits et d incompatibilité, de vérifier les conditions de déploiement et de prévoir les traitements appropriés pour des cas complexes par exemple Un exemple de composant et d assemblage Avant de donner les définitions de nos descriptions, nous présentons un exemple pour en donner l intuition de notre description des dépendances. Cet exemple est un serveur mail dans un système Linux, il est présenté dans la figure 5.3. Le serveur mail que nous présentons est constitué des composants suivants : POSTFIX, PROCMAIL, FETCHMAIL et THUNDERBIRD. Ces composants sont décrits ci-dessous : POSTFIX est un serveur SMTP pour le relais de mails. Il joue le rôle d un Mail Transport Agent (MTA). FETCHMAIL permet de récupérer du mail par un protocole de transport de courrier électronique (Pop ou IMAP), d un hôte distant vers une machine locale (les messages sont redirigés vers la messagerie locale). PROCMAIL gère les mails reçus, il permet par exemple de filtrer les mails, de faire des redirections en fonction de l émetteur, du sujet, de la taille du mail, etc. Il traite la messagerie locale. THUNDERBIRD est un gestionnaire de courrier électronique qui permet de lire et composer des mails.

116 106 Description formelle des entités de déploiement FETCHMAIL THUNDERBIRD FDS 852 FDS 1508 lib2 popclient lib4 MDA MUA MTA spell-dict corrector POSTFIX PROCMAIL FDS 1380 popclient SM MTA lib3 MDA lib1 FDS 248 amavis AntiVirus spam AntiSpam MTA MDA MUA AntiVirus AntiSpam corrector Fig. 5.3 Un exemple de serveur mail La description graphique de ces composants est présentée dans le chapitre 1. Les composants sont donc représentés par des rectangles avec des interfaces requises qui expriment les exigences des composants et des interfaces fournies (les ronds noirs). Ces exigences peuvent être de type logiciel, par exemple, elles correspondent à des services (demi-cercle) ou à des propriétés de l environnement cible. Ces dernières sont alors de la forme d une variable comparée à une valeur et sont représentées par des crochets. Par exemple, il est possible d exiger une certaine valeur d espace disque libre : Free Disk Space 1380 Ko. Cet exemple sert de fil rouge par la suite pour illustrer les opérations de déploiement qui nous interessent Description des dépendances Dans cette partie, nous présentons la définition précise de la relation entre les services fournis et les services requis par le même composant (intra-dépendance) ou deux composants différents (interdépendance). L exemple du serveur mail de la figure 5.3 illustre ces dépendances au niveau d un même composant et au niveau de plusieurs composants 1. Il existe trois formes principales de dépendances : une dépendance obligatoire (représentée à l intérieur d un composant par une ligne continue) représente un besoin nécessaire d un composant pour qu il puisse être installable et utilisable. Par exemple, un serveur mail a besoin d un système d exploitation particulier, d un espace disque libre suffisant, de certaines librairies, 1 Les dépendances sont simplifiées par rapport aux dépendances réelles.

117 Les dépendances des composants logiciels 107 (FDS 1380) POSTFIX lib MTA SM amavis av Fig. 5.4 Les intra-dépendances du composant POSTFIX etc. une dépendance optionnelle (représentée par un trait discontinu) spécifie qu un composant peut fournir un service optionnel. Le composant peut donc être installé même si le service optionnel n est pas fourni (dans le cas où ses exigences ne sont pas disponibles). Par exemple, POSTFIX peut fournir un anti-virus si le composant AMAVIS est disponible. Dans le cas contraire, POSTFIX peut toujours être installé et fournit le service de transport de mail MTA sans un anti-virus av. une dépendance négative (exprimée par une négation) exprime les conflits entre composants et services. Par exemple, POSTFIX ne peut être installé si un autre MTA est déjà installé (tel que SENDMAIL par exemple). Une intra-dépendance représente la relation entre ce qui est requis et ce qui est fourni au niveau d un même composant. Les besoins du composant représentent ses pré-conditions et les services qu il fournit représentent ses post-conditions. Par exemple, la figure 5.4 représente les intra-dépendances du composant POSTFIX, pour chacun de ses services fournis (post-conditions), il exige un certain nombre de pré-conditions. Pour fournir le service MTA, POSTFIX exige un minimum d espace de disque libre (FDS 1380), une librairie (lib) et interdit le composant SM (sendmail). Le service anti-virus av est fourni de manière optionnelle selon la disponibilité du service amavis. Le langage de description des intra-dépendances se base sur la logique des prédicats. Les pré-conditions sont décrites par des prédicats et la dépendance représente la description des pré-conditions et leurs post-conditions. Le langage de dépendance est défini par la grammaire ci-dessous, s représente le nom du service et c le nom du composant : D ::= P s D D D # D? D P ::= true P P Q Q ::= Q Q [v O val] s c c.s s O ::=> < = Les dépendances peuvent être simples (P s) ou composées (D D, D # D,? D). Les détails sur la grammaire des dépendances sont présentés ci-dessous :

118 108 Description formelle des entités de déploiement P s est la dépendance la plus simple, elle est représentée par une suite de pré-conditions décrites par le prédicat P et une post-condition qui représente la fourniture du service s ; D D est la conjonction de dépendances D 1 et D 2 ; D # D est la disjonction de dépendances D 1 et D 2 ;? D est la dépendance D rendue optionnelle. Au niveau des prédicats, le langage est un sous ensemble de la logique des prédicats sans l ensemble des fonctions. Le prédicat true désigne une dépendance toujours vérifiée et le service en partie droite de l implication est toujours fourni. Le prédicat doit être défini en forme normale conjonctive (composée de conjonction de disjonction) pour faciliter l écriture de certaines règles. Le couple [v O val] représente l ensemble des valeurs val données pour une certaine variable v, en sachant que O représente un opérateur de comparaison (>,, <,, =,ou ). Les prédicats s et c permettent de préciser que le service s respectivement, le composant c, sont interdits. Enfin, le prédicat s exige la disponibilité du service s de n importe quel composant, par contre c.s exige le service s fourni par le composant c. Par exemple, les principales dépendances du composant POSTFIX représentées graphiquement dans la figure 5.4 sont : l espace disque disponible (F DS 1380), les librairies (lib), l absence de SENDMAIL ( SM), le service amavis pour fournir l antivirus av est optionnel. L expression des dépendances de POSTFIX selon la figure 5.4 est : ([F DS 1380] ( SM) lib MT A)? (amavis av) Remarque 5.1 Il faut noter qu un composant peut interdire un service qu il fournit et avoir une dépendance sous la forme.. s.. s. Cette contrainte peut être utilisée par un composant qui fournit le service s et qui interdit l installation d un autre composant fournissant le même service. Cette dépendance n est pas contradictoire car le prédicat s applique sur le contexte actuel ( pré-condition) et le service est ajouté au nouveau contexte ( post-condition) Construction d un assemblage de composant De même que la notion de composant, la notion d architecture est importante car elle permet d organiser et d assembler les composants lors de la construction d une application. Cette architecture est généralement décrite en utilisant un ADL (Architecture Description Language) qui définit l ensemble des artefacts (composant, connecteur, liaison, port, interface, etc.) et une syntaxe concrète qui permettent aux développeurs de décrire la structure des applications. Un assemblage produit un nouveau composant à partir d un ensemble de composants. Dans le cadre de cette thèse, nous n allons pas définir un assemblage en connectant précisément une exigence d un composant au service fourni d un autre composant, mais seulement en spécifiant l ensemble des composants de l assemblage. Un outil calcule alors l ensemble des services que peut fournir l assemblage et ses exigences (sa dépendance interne). Pour cela, il va déterminer toutes les connections possibles entre

119 Les dépendances des composants logiciels 109 sous-composants. Par exemple, si on assemble un composant C 1 de dépendance s 1 s 2 et un composant C 2 de dépendance s 2 s 3, le service s 2 de C 1 sera utilisé pour satisfaire l exigence s 2 de C 2. L assemblage a donc la dépendance interne s 1 {s 2, s 3 }. Cette opération d assemblage s applique à un ensemble de composants avec leurs dépendances. Elle est notée par (cf. la définition 5.4 page 111). Ensuite, l assembleur peut décider de cacher (abstraire) des services que l assemblage fournit potentiellement mais qu il ne souhaite pas afficher à l extérieur. Il utilise pour cela l opérateur Abs(D, E) qui construit une dépendance en cachant les services de E dans la dépendance D (cf. définition 5.5 page 111) Calcul de la dépendance Le processus de calcul de la dépendance décrit intuitivement ci-dessus est complexe à mettre en œuvre du fait des disjonctions et des dépendances optionnelles puisqu il va falloir explorer tous les cas possibles. Dans un premier temps, nous calculons l ensemble des services susceptibles d être fournis (par l assemblage) avec leurs exigences et leur source (le composant qui les fournit) à partir des descriptions des dépendances de tous les sous-composants. Pour cela, nous allons manipuler des couples (P, E) qui expriment l exigence P qui est nécessaire pour fournir les services de l ensemble E. Chaque exigence est un prédicat étiqueté par le composant qui a cette exigence et chaque service de E conserve également le composant par lequel il est fourni. Comme présenté plus haut, les services de E peuvent satisfaire les exigences de P, on peut donc simplifier P. Nous respecterons cependant la contrainte qu un composant ne peut pas satisfaire ses propres exigences. C est pour assurer le respect de cette contrainte que nous mémorisons les composants. Par contre, nous autorisons les cycles, un composant A peut utiliser un composant B qui utilise A. Un couple (P, E) représente une situation possible si la condition P est satisfaite. Dans ce cas, tous les services de E sont alors disponibles simultanément. Ainsi, le calcul de l assemblage est fait en produisant l ensemble des couples (P, E) possibles. Cet ensemble qui représente les situations possibles est noté comme une somme (+) de couples. La dépendance interne résultante correspond alors à la retraduction sous forme de disjonction de cette somme des cas possibles. C est ce calcul que nous décrivons ci-dessous. Pour le calcul des (P, E), nous utilisons les opérateurs suivants : { (P1, E 1 ) (P 2, E 2 ) = (P 1 P 2, E 1 E 2 ) ((P 1, E 1 ) + (P 2, E 2 )) (P 3, E 3 ) = (P 1, E 1 ) (P 3, E 3 ) + (P 2, E 2 ) (P 3, E 3 ) Ce calcul est réalisé par la fonction Calc RF qui prend un ensemble de composants avec leurs dépendances en paramètre. Définition 5.1 (Calc RF ) La fonction Calc RF calcule l ensemble des services fournis potentiellement et leurs exigences à partir de la description des dépendances d un ensemble de composants. Elle est définie comme suit :

120 110 Description formelle des entités de déploiement Calc RF ({C 1 : D 1,..., C n : D n }) = i 1..n Calc RF (C i : D i ) Calc RF (C : P s) = (P C, {C.s}) Calc RF (C : D 1 D 2 ) = Calc RF (C : D 1 ) Calc RF (C : D 2 ) Calc RF (C : D 1 #D 2 ) = Calc RF (C : D 1 ) + Calc RF (C : D 2 ) Calc RF (C :?D) = Calc RF (C : D) + (true, {}) Il faut noter que l ordre de la somme de la disjonction des cas possibles des services fournis avec leurs exigences est important, donc les sommes ne peuvent pas être réordonnées. En fait, le résultat correspond à une mise sous forme normale disjonctive de la dépendance de l assemblage. Par exemple, soit un composant A de dépendance s 1 s 2 #?(s 3 s 4 ) et un composant B de dépendance s 2 s 5 s 3 s 6. Le calcul des services potentiellement fournis SP F de l assemblage des deux composants est présenté ci-dessous. La notation s A 1 désigne le service s 1 exigé par le composant A. SP F = Calc RF ({A : (s 1 s 2 #?(s 3 s 4 )), B : (s 2 s 5 s 3 s 6 )}) = Calc RF (A : s 1 s 2 #?(s 3 s 4 )) Calc RF (B : s 2 s 5 s 3 s 6 ) = (Calc RF (A : s 1 s 2 ) + Calc RF (A :?(s 3 s 4 ))) (Calc RF (B : s 2 s 5 ) Calc RF (B : s 3 s 6 )) = (s A 1, A.s 2) + (Calc RF (A : (s 3 s 4 )) + (true, {})) ((s B 2, B.s 5) (s B 3, B.s 6)) = ({(s A 1, A.s 2)} + {(s A 3, A.s 4)} + (true, {})) (s B 2 sb 3, {B.s 5, B.s 6 }) = (s A 1 sb 2 sb 3, {A.s 2, B.s 5, B.s 6 }) + (s A 3 sb 2 sb 3, {A.s 4, B.s 5, B.s 6 })+ (s B 2 sb 3, {B.s 5, B.s 6 }) Le terme obtenu décrit les trois états possibles de la composition avec à chaque fois la condition nécessaire. Ainsi, si s 1, s 2 et s 3 sont fournis l assemblage peut fournir les services s 2, s 5 et s 6. Sinon, si seulement s 2 et s 3 sont disponibles, les services s 4, s 5 et s 6 sont fournis. Le dernier terme de la somme est inutile puisque la condition est la même qu une condition précédente et le cas est déjà évalué. La règle de simplification de ce cas est la suivante : (P 1, E 1 ) + (P 2, E 2 ) = (P 1, E 1 ) si P 2 P 1 (F1) Nous avons : (s B 2 sb 3 sa 3 sb 2 sb 3 ), en appliquant (F1) on obtient : SP F = (s A 1 s B 2 s B 3, {A.s 2, B.s 5, B.s 6 }) + (s A 3 s B 2 s B 3, {A.s 4, B.s 5, B.s 6 }) D autre part, on voit clairement que le terme doit être simplifié puisque des services exigés par l un sont fournis par l autre. Par exemple, dans le premier sous-terme, le service s 2 fourni par A permet de satisfaire l exigence s 2 de B. La fonction de simplification est décrite ci-dessous : Définition 5.2 (simpl) La fonction de simplification simpl permet de simplifier le terme des prédicats dans le cas où le service exigé par un composant est fourni par un autre. Dans ce cas, l exigence s c est remplacée par true dans la partie du prédicat P,

121 Les dépendances des composants logiciels 111 on note cette opération : (s c true)p. Il faut noter qu un service exigé est fourni par le même composant n est pas simplifié. La fonction simpl est définie comme suit : simpl(true, E) = { true (true, E) si simpl(s c c c, c, E) =.s E { (s c, E) sinon ((s simpl(p, E) = c true)p, E) si c c, c.s E (P, E) sinon Ce processus nous amène à la dépendance suivante : SP F = (s A 1 s B 3, {A.s 2, B.s 5, B.s 6 }) + (s A 3 s B 2 s B 3, {A.s 4, B.s 5, B.s 6 }) Enfin, on peut reconstruire la dépendance de l assemblage par la fonction AssDep décrite dans la définition 5.3. Définition 5.3 (AssDep) La fonction AssDep permet de calculer la dépendance de l assemblage à partir des couples (P, E). Elle est calculée comme suit : { AssDep(P, E) = {P s}, c.s E AssDep((P 1, E 1 ) (P n, E n )) = #{AssDep(P 1, E 1 ),..., AssDep(P n, E n )} Définition 5.4 (D A D B ) L opérateur représente l opérateur d assemblage, il permet d appliquer la fonction AssDep sur la somme des couples (P, E) calculée par Calc RF après les avoir simplifiés avec la fonction simpl. Il est décrit comme suit : A : D A B : D B = AssDep(simpl(Calc RF (A : D A, B : D B ))) La dépendance de l assemblage est donc : A : D A B : D B = AssDep((s A 1 sb 3, {A.s 2, B.s 5, B.s 6 }) + (s A 3 sb 2 sb 3, {A.s 4, B.s 5, B.s 6 })) = (s 1 s 2 s 3 s 5 s 3 s 6 )#(s 3 s 4 (s 2 s 3 ) s 5 (s 2 s 3 ) s 6 ) Choix d abstraction L assembleur peut choisir de cacher des services fournis (ils ne seront alors pas disponibles à l extérieur, en revanche disponibles à l intérieur). Leurs exigences seront prises en compte si les services sont obligatoires et seront ignorées si leurs services fournis sont optionnels. Pour cela, nous définissons l opérateur Abs qui permet de cacher des services fournis par l assemblage. Définition 5.5 (Abs) L opération Abs(ξ s, D) permet d abstraire une liste de services ξ s dans une dépendance D. Elle retourne la dépendance résultante de l abstraction. La méthode de calcul de cette fonction est énumérée comme suit : 1. Calculer la fonction Calc RF (D) = +(P i, E i )

122 112 Description formelle des entités de déploiement 2. Dans chaque E i retirer tous les services de ξ s 3. Simplifier le terme obtenu avec la règle (P i, E i ) + (P i, E i ) = (P i P i, E i ) Abs(ξ s, D) = +{(P i, E i)} avec E i = E i \ ξ s et (P i, E i) + (P i, E i) = (P i P i, E i) Par exemple, soit un composant A de dépendance s 1 s 2?(s 3 s 4 ) et un composant B de dépendance s 2 s 5 #s 3 s 6. Le calcul des services potentiellement fournis SP F est le suivant : SP F = Calc RF ({A : (s 1 s 2?(s 3 s 4 )), B : (s 2 s 5 #s 3 s 6 )}) = Calc RF (A : s 1 s 2?(s 3 s 4 )) Calc RF (B : s 2 s 5 #s 3 s 6 ) = (Calc RF (A : s 1 s 2 ) Calc RF (A :?(s 3 s 4 ))) (Calc RF (B : s 2 s 5 ) + Calc RF (B : s 3 s 6 )) = (s A 1, A.s 2) (Calc RF (A : (s 3 s 4 )) + (true, {})) ((s B 2, B.s 5) + (s B 3, B.s 6)) = ({(s A 1 sa 3, {A.s 2, A.s 4 })} + {(s A 1, A.s 2)}) ((s B 2, B.s 5) + (s B 3, B.s 6)) = (s A 1 sa 3 sb 2, {A.s 2, A.s 4, B.s 5 }) + (s A 1 sb 2, {A.s 2, B.s 5 })+ (s A 1 sa 3 sb 3, {A.s 2, A.s 4, B.s 6 }) + (s A 1 sb 3, {A.s 2, B.s 6 }) En appliquant la fonction simpl, le terme se simplifie en retirant le service s 2 fourni par A de la première exigence : (s A 1 sa 3, {A.s 2, A.s 4, B.s 5 }) + (s A 1, {A.s 2, B.s 5 })+ (s A 1 sa 3 sb 3, {A.s 2, A.s 4, B.s 6 }) + (s A 1 sb 3, {A.s 2, B.s 6 }) Nous avons s A 1 sa 3 sb 3 sa 1 et sa 1 sb 3 sa 1, en appliquant (F1) on obtient : Ce qui correspond à la dépendance : (s A 1 s A 3, {A.s 2, A.s 4, B.s 5 }) + (s A 1, {A.s 2, B.s 5 }) A : D A B : D B = (s 1 s 3 s 2 true s 5 s 1 s 3 s 4 )#(s 1 s 2 true s 5 ) Et alors, si l on abstrait s 4, il suffit de reprendre la forme de somme et d y retirer s 4 de tous les fournis. Ce qui conduit à : Ce qui correspond à la dépendance : (s A 1 sa 3, {A.s 2, B.s 5 }) + (s A 1, {A.s 2, B.s 5 }) (s 1 s 3 s 2 true s 5 )#(s 1 s 2 true s 5 ) Le cas des dépendances optionnelles Nous présentons un autre exemple de dépendance optionnelle. Soit un composant A de dépendance : s 1 s 2?(s 3 s 4 ) et un composant B de dépendance s 4 s 5. Dans cet exemple, nous allons montrer la disparition de l exigence sur le service optionnel.

123 Les dépendances des composants logiciels 113 Le calcul des services potentiellement fournis SP F est : SP F = Calc RF ({A : (s 1 s 2?(s 3 s 4 )), B : (s 4 s 5 )}) = Calc RF (A : s 1 s 2?(s 3 s 4 )) Calc RF (B : s 4 s 5 ) = (Calc RF (A : s 1 s 2 ) Calc RF (A :?(s 3 s 4 ))) (Calc RF (B : s 4 s 5 )) = (s A 1, A.s 2) (Calc RF (A : (s 3 s 4 )) + (true, {})) ((s B 4, B.s 5)) = ({(s A 1 sa 3, {A.s 2, A.s 4 })} + {(s A 1, A.s 2)}) ((s B 4, B.s 5)) = (s A 1 sa 3 sb 4, {A.s 2, A.s 4, B.s 5 }) + (s A 1 sb 4, {A.s 2, B.s 5 }) En simplifiant par le retrait du service s 4 fourni par A des exigences du premier terme, on obtient : (s A 1 s A 3, {A.s 2, A.s 4, B.s 5 }) + (s A 1 s B 4, {A.s 2, B.s 5 }) Ce qui correspond à la dépendance : A : D A B : D B = (s 1 s 3 s 2 s 1 s 3 s 4 true s 5 )#(s 1 s 2 s 4 s 5 ) Si l on abstrait le service optionnel s 4, il suffit de reprendre la forme de somme et d y retirer s 4 de tous les fournis. Ce qui conduit à : (s A 1 sa 3, {A.s 2, B.s 5 }) + (s A 1 sb 4, {A.s 2, B.s 5 }) En appliquant la règle la règle (P i, E i )+(P i, E i ) = (P i P i, E i ) sur ce terme, on obtient : La dépendance correspondante est : ((s A 1 sa 3 ) (sa 1 sb 4 ), {A.s 2, B.s 5 }) A : D A B : D B = (s 1 (s 3 s 4 ) s 2 ) (s 1 (s 3 s 4 ) s 5 ) Le cas des dépendances cycliques Dans le cas d un cycle, les exigences vont disparaître également. Soit un composant A de dépendance : s 1 s 2 et le composant B de dépendance : (s 2 s 1 s 3 s 4 ). Le calcul des services potentiellement fournis SP F est : SP F = Calc RF ({A : (s 1 s 2 ), B : (s 2 s 1 (s 3 s 4 )}) = Calc RF (A : s 1 s 2 ) Calc RF (B : s 2 s 1 ) Calc RF (s 3 s 4 ) = (s A 1, A.s 2) ((s B 2, B.s 1) (s B 3, B.s 4)) = ({(s A 1 sb 2 sb 3, {A.s 2, B.s 1, B.s 4 })}) En simplifiant le terme par le retrait des services s 1 et s 2, on obtient : (s B 3, {A.s 2, B.s 1, B.s 4 }). La dépendance correspondante est : A : D A B : D B = (s 3 s 1 s 3 s 2 s 3 s 4 ) Si l on abstrait les services s 1 et s 2, on obtient : (s B 3, {B.s 4}). La dépendance est donc : s 3 s 4.

124 114 Description formelle des entités de déploiement 5.3 Description du système cible Les ressources et l architecture du système cible sont représentées par le contexte. Ce dernier pourrait être représenté par l union des dépendances de tous ses composants. Mais, le calcul et la manipulation de cette union sont plutôt difficiles à gérer. Nous choisissons donc d utiliser une approximation de cette union. Pour assurer un déploiement sûr, cette approximation doit être sûre et contenir les services disponibles du système cible, les composants qui les fournissent, ainsi que l ensemble des exigences et des conflits du système. Nous avons également besoin des valeurs des variables d environnement. Le Contexte est composé de (1) l ensemble des valeurs des variables d environnement noté E (2) l ensemble C des quadruplets (c, P s, F s, F c ) mémorisant, pour chaque composant installé c, l ensemble de ses services fournis P s, celui de ses services interdits F s et celui de ses composants interdits F c et (3) un graphe de dépendance G stockant l ensemble des dépendances existantes dans le système. Un nœud du graphe G est un service disponible avec son fournisseur (c.s). Un arc est une paire de nœuds n 1 n 2 où n 2 dépend de n 1. Chaque arc est étiqueté par le type de dépendance entre les deux nœuds qui soit obligatoire M (Mandatory) soit optionnel O (Optional). Le graphe de dépendance représente donc la configuration actuelle du système cible et son architecture en termes de composants et services. Il est construit pendant l installation et utilisé pendant la désinstallation. Il est également mis à jour par chaque opération du déploiement. Remarque 5.2 Le graphe de dépendance est un graphe acyclique, c est-à-dire la relation n 1 n 2 implique que n 1 était disponible avant n 2 donc le graphe ne contient pas de cycle. Dans la pratique cette hypothèse peut être une limitation car deux composants peuvent être mutuellement dépendants. Nous pensons que ces cycles doivent être résolus par l opération de composition de la section précédente qui va construire des composants composites et donc cacher cette circularité au système. pluginihm hachage sha256 sha256 ihm web SECURITE transfert maj tcp-ip dns INTERNET web web MAJ Fig. 5.5 Exemple d un composant de mise à jour

125 Description du système cible 115 C 3.hachage SÉCURITÉ.sha256 C 2.dns INTERNET.web C 1.tcp-ip MAJ.maj C 4.transfert C 5.pluginihm MAJ.ihm Fig. 5.6 Une partie du graphe de dépendance d un système contenant le composant de la figure 5.5 La figure 5.5 présente un exemple d un composant de mise à jour (MAJ) qui utilise la fonction de transfert, le service web fourni par le composant INTERNET, et la fonction optionnelle de hachage cryptographique (sha256) fournie par le composant SECURITE pour fournir le service de mise à jour. Il fournit également le service ihm qui est optionnel et qui utilise le service pluginihm. La figure 5.6 représente une partie du graphe de dépendance d un système contenant le composant de mise à jour présenté dans la figure 5.5. La figure 5.7 représente une partie du graphe de dépendance d un système qui contient le serveur mail présenté dans la figure 5.3. Le composant POSTFIX fournit un service obligatoire MTA qui requiert la librairie lib fournie par le composant C 1 (C 1.lib) et un service optionnel anti-virus av qui requiert le service amavis fourni par le composant AMAVIS (AMAVIS.amavis). La dépendance obligatoire est représentée donc par un arc continu ( ) qui désigne l arc M (entre C 1.lib et POSTFIX.MTA) et la dépendance optionnelle par un arc discontinu qui désigne l arc O (entre AMAVIS.amavis et POSTFIX.av). Pour simplifier la présentation de nos règles de déploiement, nous définissons des fonctions qui calculent l ensemble des services disponibles AS, celui des composants disponibles AC, celui des services interdits FS et enfin celui des composants interdits FC. Elles sont définies comme suit : AS(Ctx) = {P s (, P s,, ) Ctx.C} AC (Ctx) = {c (c,,, ) Ctx.C} FS(Ctx) = {F s (,, F s, ) Ctx.C} FC (Ctx) = {F c (,,, F c ) Ctx.C} avec Ctx.C représente la quadruplet (c, P s, F s, F c ) qui décrit le composant c avec l ensemble de ses services fournis P s, l ensemble de ses services interdits F s et l ensemble de

126 116 Description formelle des entités de déploiement POSTFIX PROCMAIL AMAVIS.amavis POSTFIX.av SANITIZER.sanitizer PROCMAIL.av SPAM.spamassassin PROCMAIL.spamassassin C1.lib POSTFIX.MTA FETCHMAIL.popclient THUNDERBIRD.MUA THUNDERBIRD.Corrector PROCMAIL.MDA C2.lib FETCHMAIL C3.lib C4.lib SPELL.spelldictionnary THUNDERBIRD Optionnel (O) Obligatoire (M) Fig. 5.7 Une partie du graphe de dépendance du serveur mail de la figure 5.3 ses composants interdits F c. Supposons qu initialement ces ensembles sont les suivants : AS(Ctx) = {C 1.lib, } AC (Ctx) = {c (c,,, ) Ctx.C} FS(Ctx) = {F s (,, F s, ) Ctx.C} FC (Ctx) = {F c (,,, F c ) Ctx.C} Ces ensembles sont calculés à chaque fois qu ils sont utilisés au niveau des règles de vérification de l installabilité de l installation et de la construction du graphe de dépendance (cf. chapitre 6). Ces ensembles contiennent donc toujours les informations effectives sur les composants et les services actuellement disponibles et/ou interdits dans le contexte. Par exemple, dans le cas de l installation de POSTFIX, les ensembles AS, AC, FS, FC seront mis à jours. Les services fournis par POSTFIX (MTA et av) feront partis de l ensemble des services disponibles dans Ctx new. Le composant POSTFIX fera parti de l ensemble des composants disponibles dans Ctx new. Le composant SENDMAIL interdit par le composant POSTFIX sera également interdit dans Ctx new. Les ensembles AS, AC, FS, FC seront mis à jour comme suit : 5.4 Conclusion AS(Ctx new ) = AS(Ctx old ) {MTA, av} AC (Ctx new ) = AC (Ctx old ) {POSTFIX} FS(Ctx new ) = FS(Ctx old ) FC (Ctx new ) = FC (Ctx old ) {SENDMAIL} Dans ce chapitre, nous avons présenté la description formelle des entités de déploiement à savoir, le composant, l assemblage de plusieurs composants et le système cible. La description des composants concerne leurs dépendances vis-à-vis de l environnement

127 Conclusion 117 dans lequel ils vont être déployés. Ces dépendances sont décrites suivant un langage de prédicat sous la forme «si pré-conditions alors post-conditions». Les pré-conditions présentent les conditions et les contraintes matérielles et logiciels et les post-conditions sont les services pouvant être fournis si leurs pré-conditions sont vérifiées. L originalité dans notre description des entités est la description de l intra-dépendance qui est la relation entre chaque service fourni avec ses exigences au niveau d un même composant. En effet, en plus de la description des interdépendances entre les différents composants, nous nous sommes concentrés sur la description précise des besoins de chaque service fourni par un composant. L intérêt est de pouvoir maîtriser l effet d un composant par rapport à ses besoins disponibles en déterminant plus précisément au niveau d un même composant tous les besoins de chaque service fourni avec leurs niveau de nécessité (obligatoire ou optionnel). Le langage qui permet d exprimer cette relation est assez riche puisqu il permet de décrire des dépendances obligatoires, optionnelles, conflictuelles et des choix entre les services requis et les services fournis d un même composant. Les langages existants décrivent d une façon générale les besoins des composants ainsi que leurs services fournis sans exprimer la relation exacte entre chaque service fourni et ses propres besoins. Le point fort de ce langage est qu il est basé sur la logique des prédicats et sera utilisé dans la suite pour la démonstration de la faisabilité du déploiement dans un certain contexte. L assemblage de composant est également décrit par ce langage suivant une forme plus simplifiée permettant de considérer que les services pertinents pour l assemblage. Le système cible (le contexte) est décrit suivant une abstraction qui regroupe les propriétés matérielles et logicielles de l environnement, l ensemble des composants du système avec l ensemble de leurs services fournis et interdits et leurs composants interdits. Enfin, le graphe de dépendance décrit la configuration actuelle du système avec les dépendances existantes entre les différents services et composants. Ce chapitre présente le premier niveau de description formelle qui concerne les entités de déploiement à savoir les dépendances de composants et le contexte cible. Il constitue une base de description sur laquelle s appuient tous les chapitres de la partie II. Le chapitre suivant traite les règles d installation et de désinstallation des composants.

128 118 Description formelle des entités de déploiement

129 Chapitre 6 L installation et la désinstallation de composants Sommaire 5.1 Introduction Les dépendances des composants logiciels Un exemple de composant et d assemblage Description des dépendances Construction d un assemblage de composant Description du système cible Conclusion Après avoir présenté les descriptions formelles des dépendances des composants ainsi que le site cible, nous devons vérifier avec des règles appropriées pour chaque opération de déploiement la cohérence et la validité de ces descriptions. Dans ce chapitre, nous présentons la formalisation des opérations d installation et de désinstallation. L objectif de ce chapitre est d illustrer comment la faisabilité de ces opérations ainsi que leurs réalisations sont vérifiées et démontrées formellement. Cette vérification se base sur une suite de règles de dérivation permettant d assurer le bon déroulement des opérations d installation et de désinstallation. 6.1 Introduction Pour déduire la possibilité d un déploiement (installation, désinstallation, etc.), nous nous sommes basés sur le calcul logique. Un calcul en logique est un ensemble de règles permettant en un nombre fini d étapes, selon des règles explicites et selon des procédés mécanisables de déterminer si une proposition complexe (c est-à-dire formée d au moins deux propositions atomiques) est vraie ou fausse. D une façon générale, les règles exposées dans nos travaux sont celles de la déduction naturelle pour le calcul des propositions. Elles permettent d enchaîner logiquement les phrases, c est-à-dire d introduire de nouvelles phrases comme conséquences logiques 119

130 120 L installation et la désinstallation de composants de ce qui a été dit auparavant. À chacun des opérateurs logiques fondamentaux sont associées deux règles de déduction. L une des règles est une règle d introduction : elle explique comment prouver une proposition possédant l opérateur. L autre règle est une règle d élimination : elle explique comment utiliser une proposition possédant l opérateur pour poursuivre le raisonnement. L introduction et l élimination sont nécessaires pour pouvoir démontrer des formules. La recherche d une déduction logique consiste à analyser les prémisses, c est-à-dire à les démontrer, et à réassembler les morceaux pour faire des formules que l on peut enchaîner logiquement jusqu à la conclusion. Les déductions correctes sont toutes celles qui respectent rigoureusement les règles fondamentales. Toutes les expressions doivent être des axiomes, ou des hypothèses provisoires, ou des conséquences des phrases qui les précèdent en vertu d un ensemble de règles fondamentales. Ce type de règles est appelé règle d inférence, elle est formulée de cette manière : (1) un certain nombre de prémisses (partie supérieure de la règle) ; (2) un symbole de dérivation signifiant «infère», «démontre» ou «conclut» ; (3) une conclusion la partie inférieure de la règle. Par exemple dans la règle suivante : Règle-Inférence: S P 1... S P n S C Le principe est de vérifier les prémisses, dans ce cas P 1 jusqu à P n. Si ces prémisses sont vérifiées alors la règle est déclenchée et la conclusion C est réalisée. 6.2 Description de l installation L installation d un composant dans un système correspond à l ajout d un composant dans un environnement. Pour cela, nous procédons en deux étapes suivant le diagramme de la figure 6.1 : Vérification de l installabilité du composant, en répondant à la question est ce que le composant peut être installé dans le système? Pour répondre à cette question, il faut appliquer un ensemble de règles qui vérifient les exigences du composant par rapport à l environnement. De plus, ces règles permettent de vérifier en amont l impact de l installation de ce composant sur le système et ainsi de s assurer qu il ne perturbera pas le système (par exemple, il ne sera pas en conflit avec les autres composants). La deuxième étape consiste à calculer l effet de l installation du composant sur le système en mettant à jour l ensemble des services et des composants disponibles, l ensemble des services et des composants interdits, ainsi que le graphe de dépendance (cf. description du système cible section 5.3 page 114) Installabilité Avant d autoriser l installation d un composant, il faut s assurer que (1) le composant n est pas interdit par le système cible, (2) les services qu il requiert sont disponibles

131 Description de l installation 121 Dépendance du composant Contexte non Installabilité oui Effet Installation Fin Fig. 6.1 Principe d installation dans le contexte et (3) il ne fournit pas des services interdits par le système cible. Plus formellement, nous décrivons l étape d installabilité d un composant comme suit : Définition 6.1 (Installabilité) Un composant c avec une dépendance D est installable dans un contexte Ctx ssi le composant n est pas interdit et la dépendance D est vérifiée par les règles de vérification de l installabilité. Ces règles sont présentées dans la figure 6.2 : CComp: Ctx C D Ctx c : D c / FC (Ctx) Le principe est de vérifier la prémisse, par exemple, dans ce cas la dépendance D est vérifiée dans le contexte (Ctx C D) et le composant c n appartient pas à l ensemble des composants interdits (c / FC (Ctx)). Si la prémisse est vérifiée alors la règle est déclenchée et la conclusion est réalisée. Plusieurs règles de cette forme seront dans une base de règles. Le moteur d inférence va mener des raisonnements, des inférences, sur cette base de règles. Les règles de vérification de l installabilité de la figure 6.2 permettent de garantir que toutes les dépendances obligatoires du composant sont vérifiées. Pour une dépendance simple exprimée comme suit : P s, cela veut dire que le prédicat P doit être vrai et le service s n est pas interdit par le contexte du système cible (CTriv). L évaluation du prédicat P dans le contexte Ctx est présentée dans la première partie de la figure (les règles Ctx P P ). Ces règles correspondent à l évaluation de la grammaire des prédicats déjà présentée dans le chapitre 5 page 107. La règle PTrue représente l évaluation du prédicat true qui est toujours vrai. La règle PAnd démontre la conjonction de deux prédicats par l introduction de la démonstration de chaque prédicat. Les règles POrL et POrR démontrent la disjonction de deux prédicats par la démonstration d un seul parmi eux. La règle PVar démontre le prédicat [v O V ], c est-à-dire, la variable v de l environnement du contexte Ctx vérifie bien la contrainte par rapport à la valeur V. La règle PNotS démontre la négation du

132 122 L installation et la désinstallation de composants Évaluation des prédicats : PTrue: Ctx P true PAnd: Ctx P P 1 Ctx P P 2 Ctx P P 1 P 2 POrL: Ctx P Q 1 Ctx P Q 1 Q 2 POrR: Ctx P Q 2 Ctx P Q 1 Q 2 PVar: Ctx.E(v) O V Ctx P [v O V ] PNotS: s / AS(Ctx) Ctx P s PNotC: c / AC (Ctx) Ctx P c PServ: s AS(Ctx) Ctx P s PComp: (c, P s,, ) Ctx.C Ctx P c.s s P s Règles d installabilité : CTriv: Ctx P P s / FS(Ctx) Ctx C P s CAnd: Ctx C D 1 Ctx C D 2 Ctx C D 1 D 2 COpt: Ctx C? D COrL: Ctx C D 1 Ctx C D 1 # D 2 COrR: Ctx C D 2 Ctx C D 1 # D 2 Fig. 6.2 Les règles d installabilité et d évaluation des prédicats service s par sa non disponibilité dans l ensemble des services disponibles du Contexte. La règle PNotC démontre la négation du composant c par sa non disponibilité dans l ensemble des composants disponibles dans le contexte. La règle PServ démontre le service s par sa disponibilité dans l ensemble des services disponibles du contexte. Enfin, la règle PComp démontre le service s du composant c (c.s) par la disponibilité du service dans l ensemble des services fournis par le composant. Dans cette phase de vérification, les dépendances optionnelles sont ignorées (COpt) car la non disponibilité de telles dépendances n empêche pas l installation du composant. La conjonction des dépendances est résolue si les deux dépendances sont valides (CAnd). Par exemple, considérons l exemple de la dépendance suivante : ((C1.S 1 S 2 ) (S 3 [F DS 10]) S 4 ), les conditions d installabilité sont : la disponibilité des services S 1 fourni par le composant C 1 et S 3 dans le contexte (ils appartiennent à l ensemble des services disponibles AS(Ctx)), la disponibilité de l espace disque requis (supérieur ou égale à 10 Mo) et que les services S 2 et S 4 ne sont pas interdits dans le contexte (n appartiennent pas à l ensemble des services interdits FS(Ctx)). La disjonction des dépendances ( ) est valide si l une des deux dépendances est valide (COrL et COrR). Cette disjonction représente un niveau de description assez intéressant, car elle implique un choix entre deux services ou deux implantations différentes. Le choix du service est fait selon les exigences du système ou les préférences de l utilisateur. Par exemple, un composant peut fournir une interface graphique avec

133 Description de l installation 123 une qualité supérieure si la capacité de la carte graphique est supérieure, ou un affichage textuel si la qualité de la carte graphique est médiocre. Nous pouvons donc envisager deux implantations différentes du composant et exécuter celle qui est la plus intéressante pour le système ou l utilisateur au moment opportun Calcul des services interdits La fonction CalcF permet de déterminer les services et les composants qui sont interdits en collectant les négations introduites dans les prédicats de la dépendance. Le cas le plus délicat est celui de la disjonction. En effet, plusieurs sous termes de la disjonction peuvent interdire des services ou des composants. Par exemple, dans l expression de dépendance a b s, a ou b peuvent être interdits. Pour garder la trace de ces possibilités, le système peut prendre en considération seulement la négation appropriée et réellement utilisée. Si par exemple, a est disponible (resp. b) nous pouvons conserver b (resp. a) et si aucun d entre eux n est disponible nous conservons la disjonction. Ce système est complexe et coûteux, nous avons donc opté pour un système plus simple mais plus contraignant. Pour cela, nous avons choisi dans le cas de disjonction de services interdits d interdire tous les services précédés par une négation. L ensemble des services interdits dans le cas de la disjonction est donc le même que celui de la conjonction (cf. définition 6.2). Définition 6.2 (CalcF) La fonction CalcF calcule l ensemble des services interdits et l ensemble des composants interdits à partir des prédicats des dépendances, elle est définie comme suit : CalcF (true) =, CalcF (P 1 P 2 ) = Fs 1 Fs 2, Fc 1 Fc 2 où CalcF (P i ) = Fs, i Fc i CalcF (Q 1 Q 2 ) = Fs 1 Fs 2, Fc 1 Fc 2 où CalcF (Q i ) = Fs, i Fc i CalcF (s) = CalcF { (c.s) = CalcF ([v O V ]) =, {s}, si s / AS(Ctx) CalcF ( s) = {, sinon, {c} si c / AC(Ctx) CalcF ( c) =, sinon Prenons l exemple du composant POSTFIX présenté dans le chapitre précédent, sa dépendance est décrite comme suit : D = ([F DS 1380] ( C sendmail ) S lib S MT A )?(S amavis S AV ), le calcul des services et des composants interdits se fait comme suit : CalcF (P ) = CalcF ([F DS 1380] C sendmail S lib ) = (, ) (, {C sendmail }) (, ) =, {C sendmail } L ensemble des services interdits par le composant POSTFIX pour la fourniture du service S MT A est vide et un seul composant est interdit C sendmail.

134 124 L installation et la désinstallation de composants GTrue: Ctx, c, s G true GAnd: Ctx, c, s G P 1 G 1 Ctx, c, s G P 2 G 2 Ctx, c, s G P 1 P 2 G 1 G 2 GOrL: Ctx, c, s G Q 1 G 1 Ctx P Q 1 GOrR: Ctx P Q 1 Ctx, c, s G Q 1 Q 2 G 1 Ctx, c, s G Q 1 Q 2 G 2 GVar: Ctx, c, s G [v O V ] GNotS: Ctx, c, s G s GNotC: Ctx, c, s G c GServC: (c, P s,, ) Ctx.C s P s Ctx, c, s G c.s {c.s M c.s} GServ: Ctx, c, s G s {c.s s AS(Ctx) M c.s (c, P s,, ) Ctx.C s P s } Fig. 6.3 Les règles de calcul du graphe de dépendance Installation Une fois que l installabilité du composant est prouvée, l effet de l installation de ce dernier dans le système cible doit être calculé. Cet effet concerne les nouveaux services disponibles, les nouveaux services interdits, les nouveaux composants interdits ainsi que les nouvelles dépendances (représentées par un graphe de dépendance). Nous allons présenter dans un premier temps avant de décrire les règles d installation, les fonctions qui permettent de calculer l effet de l installation Calcul du graphe de dépendance Le graphe de dépendance est construit pendant la phase d installation, il représente l ensemble de toutes les dépendances des composants qui sont vérifiées dans le système (architecture du système). Définition 6.3 (Calcule du Graphe) Le graphe de dépendance G représente la relation entre les services requis et les services fournis du même composant ou des composants différents. Il représente donc les interdépendances et les intra-dépendances. Les règles utilisées pour la construction du graphe de dépendance sont présentées dans la figure 6.3. Le principe des règles qui calculent le graphe de dépendance est de s assurer que l ensemble des exigences de chaque service fourni est disponible dans le contexte (cf. les prémisses des règles GServC et GServ de la figure 6.3). Une fois que ces services (c.s ) sont disponibles dans le contexte les nœuds qui y correspondent sont liés avec celui correspondant au service fourni c.s (cf. les conclusions des règles GServC et GServ).

135 Description de l installation 125 L extrémité initiale de chaque arc représente donc un nœud requis par le nœud de son extrémité finale (par exemple, pour l arc (a,b) : b dépend de a). La règle GServ permet de lier chaque fournisseur potentiel du nœud s (que le composant c requiert pour fournir s) avec le nœud c.s par un arc M. La règle GServC permet de lier le nœud c.s correspondant au service s fourni par le composant c avec le nœud c.s par l arc M. Les règles GTrue, GVar, GNotS, GNotC ne génèrent aucun nœud ni arc. La règle GAnd calcule le graphe résultant d une conjonction de deux prédicats en faisant l union des graphes correspondant à ces prédicats. La règle GOrL calcule le graphe résultant d une disjonction de deux prédicats dans le cas où le premier prédicat est vérifié. La règle GOrR calcule le graphe résultant d une disjonction de deux prédicats dans le cas où le premier prédicat n est pas vérifié et le second l est. Il faut noter que les ars optionnels (O) du graphe G ne sont pas produits par ces règles mais plutôt par les règles d installation présentées par la suite (cf. règle IOpt 2 figure 6.4) Calcul de l effet de l installation L installation est définie comme suit : Définition 6.4 (Installation) L installation d un composant c de dépendance D dans un contexte Ctx a un effet sur : l ensemble des services fournis P s, l ensemble des services interdits F s, l ensemble des composants interdits F c et le graphe de dépendance G. Ces effets sont calculées par les règles présentées dans la figure 6.4. IComp: Ctx, c I D P s, F s, F c, G c Ctx I c : D P s, F s, F c, G c Au niveau de la prémisse de la règle IComp nous vérifions la dépendance D dans Ctx avec l hypothèse que c est installable, nous calculons par la suite l ensemble des services fournis P s, l ensemble des services interdits F s, l ensemble des composants interdits F c, le graphe de dépendance relatif à cette dépendance G c. Ce calcule sera propagé au niveau de la conclusion et le composant c sera avec l effet calculé. Le nouveau contexte sera égal à l ancien contexte avec en plus le composant c installé (avec son quadruplet) et le graphe résultant de sa dépendance vérifiée. Le nouveau graphe de dépendance résultant est : G c = {n 1 n2 n 1 AS(Ctx) n 2 c.p s }. Une fois D P s, F s, F c, G c est vérifiée dans le contexte (Ctx I c : D P s, F s, F c, G c ), le nouveau contexte est calculé comme suit : Installation(Ctx, c : D) = Ctx.E, Ctx.C (c, P s, F s, F c ), Ctx.G G c La dépendance peut être non dérivable ou invalide c est-à-dire soit le prédicat n est pas vérifié, soit le service fourni par la dépendance est interdit dans le contexte. Cette dépendance est notée par. La dépendance P s n est pas vérifiée si le prédicat P est faux (INot 1 ) ou le service s est interdit (INot 2 ). Dans le cas contraire, le service s est disponible, les

136 126 L installation et la désinstallation de composants ITriv: Ctx P Ctx, c, s G P G s / FS(Ctx) CalcF (P ) = F s, F c Ctx, c I (P s) {s}, F s, F c, G INot 1 : Ctx P P Ctx, c I (P s) INot 2 : s FS(Ctx) Ctx, c I (P s) IOpt 1 : Ctx, c I D Ctx, c I? D,,, IOpt 2 : Ctx, c I D P s, F s, F c, G Ctx, c I? D P s, F s, F c, {s O s s s G} IAnd 1 : Ctx, c I D 1 Ctx, c I D 1 D 2 IAnd 2 : Ctx, c I D 2 Ctx, c I D 1 D 2 IAnd 3 : Ctx, c I D 1 P 1 s, F 1 s, F 1 c, G 1 Ctx, c I D 2 P 2 s, F 2 s, F 2 c, G 2 Ctx, c I D 1 D 2 P 1 s P 2 s, F 1 s F 2 s, F 1 c F 2 c, G 1 G 2 IOrL: Ctx, c I D 1 P s, F s, F c, G Ctx, c I D 1 # D 2 P s, F c, F s, G IOrR: Ctx, c I D 1 Ctx, c I D 2 P s, F s, F c, G Ctx, c I D 1 # D 2 P s, F s, F c, G IOr3: Ctx, c I D 1 Ctx, c I D 2 Ctx, c I D 1 # D 2 Fig. 6.4 Les règles d installation

137 Description de l installation 127 services et les composants interdits sont calculés par la fonction CalcF et le graphe par les règles présentées dans la figure 6.3 (ITriv). Pendant l étape d installation l effet de la dépendance optionnelle? D est le même que celui de D mais tous les services de D deviennent des services optionnels. Dans le cas où D n est pas vérifiée rien n est fourni (IOpt 1 ). Dans le cas contraire, les services optionnels sont fournis et toutes les dépendances du graphe sont modifiées pour avoir une étiquette O. L ensemble des services et composants interdits ainsi que l ensemble des services fournis sont ceux qui sont calculés au niveau de la dépendance D. Dans le cas de la conjonction de dépendance D 1 D 2, D 1 et D 2 doivent être vérifiées, l effet représente l union des effets de D 1 et D 2 (IAnd 3 ). Dans les autres cas, la dépendance n est pas vérifiée et l effet n est pas calculé (IAnd 1 and IAnd 2 ). Enfin, l effet de la disjonction D 1 # D 2 représente soit l effet de D 1 (IOrL) si D 1 est vérifiée, soit l effet de D 2 (IOrR) si D 2 est vérifiée et si D 1 et D 2 ne sont pas vérifiées. La sémantique de la disjonction est similaire a celle du if D 1 then...else if D 2 then... (D 2 n est évaluée que si D 1 n est pas vérifiée). La règle IOr3 concerne le cas où les deux dépendances D 1 et D 2 ne sont pas vérifiées. Remarque 6.1 Il faut noter que le moteur de raisonnement formel ne prend pas en compte la mise à jour des variables d environnement (espace disque, mémoire, etc.). Le moteur de déploiement réel met à jour le contexte physique avec les nouvelles valeurs. Par la suite, le moteur de raisonnement formel les reçoit à travers des capteurs Exemple d installation À titre d illustration, nous allons présenter les dérivations qui permettent la vérification de l installabilité de POSTFIX (C P X ) et celles qui permettent son installation. Initialement nous supposons que le contexte est le suivant : La preuve de l installabilité E = {F DS = , OS = LINUX, RAM = 128}; C = {(C 1, {S lib },, ), (C A, S amavis,, )}; G = Les services qui sont obligatoirement requis par POSTFIX sont : une librairie (S lib ) avec la condition de l absence du composant SENDMAIL (C SM ), le service amavis (S amavis ) qui fournit l antivirus S AV est optionnel. La dépendance de POSTFIX est donc (D 1 D 2 ) avec : { D1 = [F DS 1380] C SM S lib S MT A D 2 =?(S amavis S AV ) Il faut donc prouver la conjonction des dépendances D 1 et D 2 (Ctx D 1 D 2 ). La dépendance D 2 représente une dépendance optionnelle donc elle est toujours vérifiée pendant cette étape. La preuve de l installabilité de POSTFIX est donc liée à la

138 128 L installation et la désinstallation de composants dépendance D 1. La démonstration est illustrée ci-dessous en respectant les règles de vérification de l installabilité de la figure 6.2 page 122. CAnd CComp A Ctx C [F DS 1380] C SM S lib S MT A Ctx C?(S amavis S AV ) Ctx C D 1 D 2 C P X / Ctx C P X : D 1 D 2 A = Ctx P F DS 1380 C SM / {C 1, C A } Ctx P C SM S lib {S lib, S amavis } Ctx P S lib Ctx P [F DS 1380] C SM S lib Ctx C [F DS 1380] C SM S lib S MT A Dans notre contexte, le composant POSTFIX est donc installable. S MT A / La preuve de l installation L étape d installation suit l étape de vérification de l installabilité, elle consiste à calculer l effet de l ajout du composant POSTFIX (C P X ) dans le contexte. Cet effet consiste à mettre à jour l ensemble des services disponibles, l ensemble des services interdits, l ensemble des composants interdits et le graphe de dépendance. La dérivation d installation de D 1 est notée A, le prédicat de cette dépendance est représenté par P. Le résultat de l installation de D 1 est caractérisé par l ajout du composant C P X avec le service S MT A dans l ensemble de ses services fournis, l ajout du composant C SM dans l ensemble de ses composants interdits et la construction du graphe de dépendance G 1. La dépendance optionnelle D 2 va être vérifiée dans cette étape pour fournir les services qui peuvent être disponibles. La dérivation de D 2 est représentée par l arbre de dérivation B. L effet de la dépendance optionnelle consiste à ajouter le service S AV dans l ensemble Ps 2 du composant C P X et construire le graphe G 2 résultant. La preuve de l installation est réalisée par les règles de dérivation de la figure 6.4 page 126 : A B IAnd3 IComp Ctx, C P X I D 1 Ps 1, Fs 1, Fc 1, G 1 Ctx, C P X I D 2 Ps 2, Fs 2, Fc 2, G 2 Ctx, C P X I D 1 D 2 Ps 1 Ps 2, Fs 1 Fs 2, Fc 1 Fc 2, G 1 G 2 Ctx C C P X : D 1 D 2 Ps 1 Ps 2, Fs 1 Fs 2, Fc 1 Fc 2, G 1 G 2 8 >< >: Ps 1, Fs 1, Fc 1, G 1 = {S MT A},, {C SM }, {C 1.lib M C P X.S MT A} Ps 2, Fs 2, Fc 2, G 2 = {S AV },,, {A.S O amavis C P X.S AV } P 1 s P 2 s, F 1 s F 2 s, F 1 c F 2 c, G 1 G 2 = {S MT A, S AV },, {C SM }, {C 1.S lib M C P X.S MT A, A.S O amavis C P X.S AV }

139 Description de la désinstallation 129 A =ITriv S lib {S lib, S amavis } Ctx, C PX, S MT A G S lib {C 1.S lib CPX.S MT A } Ctx, C PX, S MT A G C SM Ctx, C PX, S MT A G [F DS 1380] M Ctx, C PX, S MT A G P {C 1.S lib CPX.S MT A } S MT A / CalcF (P ) =, {C SM } Ctx, C PX I (P S MT A ) {S MT A },, {C SM }, {C 1.S lib M M CPX.S MT A } B=IOpt2 S amavis {S lib, S amavis } M Ctx, C PX, S AV G S amavis {C A.S amavis CPX.S AV } S AV / CalcF (S amavis ) =, Ctx, C PX I (S amavis S AV ) {S AV },,, {C A.S amavis Ctx, C PX I?(S amavis S AV ) {S AV },,, {C A.S amavis M CPX.S AV } O CPX.S AV } Après installation du composant C P X, le contexte est mis à jour et devient : E = {F DS = , OS = LINUX, RAM = 128}; C = {(C 1, S lib,, ), (C A, {S amavis },, ), (C PX, {S MT A, S AV },, {C SM })}, O M G = {A.S amavis CPX.S AV, C 1.S lib CPX.S MT A } 6.3 Description de la désinstallation La désinstallation d un composant est également réalisée en deux étapes (cf. figure 6.5) : La première étape vérifie la faisabilité de la désinstallation en se basant sur le graphe de dépendance. Cette vérification consiste à s assurer que les services fournis par le composant en question ne sont pas utilisés par d autres composants. La deuxième étape consiste à calculer l effet de la désinstallation sur le contexte, i.e. désinstallation effective du composant et de tous ses services fournis au niveau du contexte ainsi que l ensemble de tous les services qui en dépendaient de façon optionnelle (directement ou indirectement) et qui ne possèdent pas d autres exigences dans le graphe (ne représentent pas des extrémités finales des arcs du graphe). Les nœuds et les arcs correspondants dans le graphe seront supprimés Désinstallabilité D un point de vue formel, au niveau de la première étape, on utilise une règle de désinstallabilité qui s assure qu aucun service déjà utilisé par d autres composants ne sera supprimé. La règle se base sur le graphe de dépendance du contexte. Un composant

140 130 L installation et la désinstallation de composants Nom du composant Contexte Graphe de dépendance Fin non Désinstallabilité Mise à jour oui Désinstallation Fig. 6.5 Principe de désinstallation peut être désinstallé si aucun de ses services fournis n est utilisé par d autres composants de façon obligatoire. Pour cela, pour chaque service fourni, il faut s assurer qu il ne possède aucune dépendance obligatoire avec d autres services. Ainsi, un service peut être désinstallé s il n est pas utilisé (i.e. il est une feuille du graphe de dépendance) ou il est utilisé de façon optionnelle (tous les chemins partant de ce service aux feuilles du graphe sont des arcs optionnels cf. la définition 6.6) et ne possède aucune exigence dans le graphe. Des exemples illustratifs sont présentés par la suite. Définition 6.5 (Dépendance obligatoire (MD)) L ensemble des dépendances obligatoires (MD) d un service s fourni par un composant c dans un graphe de dépendance G est l ensemble des services qui en dépendent directement ou indirectement de façon obligatoire. Il est défini comme suit : MD(G, c.s) = {{c.s } MD(G, c.s ) c.s M c.s G} Définition 6.6 (Désinstallabilité) Un composant c peut être désinstallé du contexte Ctx ssi tous ses services fournis ne sont pas utilisés obligatoirement par d autres composants, i.e. ces services ne sont pas des dépendances obligatoires pour d autres composants : Check-DI: (c, P s,, ) Ctx.C {MD(Ctx.G, c.s) s Ps } = Ctx D c Désinstallation Une désinstallation a un effet sur les composants (leurs services fournis, leurs services interdits, et leurs composants interdits) et sur le graphe de dépendance. L ensemble des nœuds qui doivent être supprimés du graphe de dépendance contient tous les services

141 Description de la désinstallation 131 fournis par c et tous les services optionnels qui en dépendent directement ou indirectement et qui ne représentent pas une extrémité finale des arcs du graphe. Une fois que la désinstallation est réalisée, Ctx est mis à jour en supprimant c (et ses services fournis, services interdits et composants interdits) de C et en supprimant du graphe G tous les nœuds concernés par les services supprimés. Si l on suppose que l ensemble de ces nœuds est noté N, le graphe résultant de la désinstallation est calculé en supprimant ces nœuds avec leurs arcs associés dans la graphe. Il est calculé comme suit : x x G \ N = {n 1 n2 n 1 n2 G n 1 / N n 2 / N} Définition 6.7 (Dépendances optionnelles (OD)) Un ensemble de dépendances optionnelles (OD) d un service s fourni par un composant c dans un graphe de dépendance G est l ensemble des services qui en dépendent directement ou indirectement de façon optionnelle. Il est défini comme suit : OD(G, c.s) = {{c.s } OD(G, c.s ) c.s O c.s G} Définition 6.8 (Désinstallation) la désinstallation d un composant c a les effets suivants : 1. suppression du composant c avec ses services fournis P s, ses services interdits F s, ses composants interdits F c ; 2. mise à jour des ensembles AC (suppression du composant c), FS (suppression de l ensemble F s ) et FC (suppression de l ensemble F c ) ; 3. suppression des nœuds calculés par la règle Effet-DI du graphe ; 4. mise à jour de l ensemble AS par la suppression des services calculée par la règle Effet-DI. (c, P s,, ) Ctx.C Ctx E c {{c.s} c, s c, s OD(Ctx.G, c.s) n, n x c.s Ctx.G} s P s Effet-DI: La règle Effet-DI calcule l ensemble des nœuds à désinstaller du graphe G. Ces nœuds sont soit fournis par le composant à désinstaller soit dépendent de façon optionnelle des services fournis par ce composant (directement ou indirectement selon la définition OD) et ne sont pas des extrémités finales des arcs du graphe (ne possèdent aucune autre exigence à part le service fourni par le composant à désinstaller). Le nouveau contexte est donc calculé comme suit : Désinstallation(Ctx, c) = Ctx.E, Ctx.C, \(c,,, ), Ctx.G \ N avec N est l ensemble des nœuds calculés par la règle Effet-DI (Ctx E c N) Les ensembles AS, AC,FS,FC sont mis à jour comme suit : AS(Ctx) = AS(Ctx) \ {N} AC (Ctx) = AC (Ctx) \ c FS(Ctx) = FS(Ctx) \ c.f s FC (Ctx) = FC (Ctx) \ c.f c

142 132 L installation et la désinstallation de composants Trois exemples de désinstallation Nous présentons quelques scénarios de désinstallation pour illustrer les règles de désinstallabilité et de désinstallation (les règles Check-DI, Effet-DI). Désinstallation d un composant utilisé obligatoirement Pour illustrer quelques cas de désinstallation, rappelons l exemple de la figure 5.5 page 114 ainsi que son graphe de dépendance présenté dans la figure 6.6. C 3.hachage SÉCURITÉ.sha256 C 2.dns INTERNET.web C 1.tcp-ip MAJ.maj C 4.transfert C 5.pluginihm MAJ.ihm Fig. 6.6 Le graphe de dépendance du composant de mise à jour MAJ Dans le cas de la désinstallation du composant INTERNET, le service web fourni par ce composant n est pas une feuille, il est utilisé obligatoirement par les composants SÉCURITÉ et MAJ (cf. figure 6.6). L ensemble des dépendances obligatoires de ce service n est pas vide : MD(Ctx.G, INTERNET.web) = {{SÉCURITÉ.sha256,MAJ.maj}} donc la règle Check-DI n est pas vérifiée et le composant INTERNET ne peut pas être désinstallé. Désinstallation d un composant non utilisé Supposons que nous souhaitions désinstaller le composant MAJ (cf. figure 6.6). Tous les services qu il fournit sont des feuilles dans le graphe et ne sont utilisés par aucun composant. En appliquant la règle Check-DI, l ensemble des dépendances obligatoires (MD) de chaque service fourni par le composant MAJ (maj et ihm) est vide. La règle Check-DI est donc triviale et la désinstallation est possible. La règle de désinstallation (Effet-DI) calcule l ensemble des nœuds à désinstaller du graphe, c est-à-dire, elle calcule les services fournis par le composant ainsi que les services qui en dépendent de façon optionnelle directement ou indirectement et qui ne sont pas des extrémités finales des arcs du graphe. Les services fournis par le composant MAJ sont maj et ihm, l ensemble des services qui en dépendent de façon optionnelle (OD) est vide. Les nœuds et les arcs correspondants seront supprimés (MAJ.maj, MAJ.ihm,C4.transfet M MAJ,maj, INTERNET.web M MAJ,maj,C.pluginihm O MAJ.ihm, SÉCURITÉ.sha256 O MAJ.maj). Le graphe résultant est présenté dans la figure 6.7.

143 Description de la désinstallation 133 C 3.hachage SÉCURITÉ.sha256 C 2.dns INTERNET.web C 1.tcp-ip Fig. 6.7 Désinstallation du composant MAJ C 2.dns INTERNET.web C 1.tcp-ip MAJ.maj C 4.transfert C 5.pluginihm MAJ.ihm Fig. 6.8 Désinstallation du composant SÉCURITÉ Désinstallation d un composant utilisé de façon optionnelle Dans le cas de la désinstallation d un composant utilisé de façon optionnelle, nous dévons vérifier que l ensemble des services qui utilisent directement ou indirectement ses services fournis de façon optionnelle n a pas d autres exigences. Nous supposons que nous allons désinstaller le composant SÉCURITÉ avec ses services fournis (cf. la figure 6.6). Le service SÉCURITÉ.sha256 fourni par le composant SÉCURITÉ et est utilisé de façon optionnelle par le composant MAJ. L ensemble des dépendances obligatoires (MD) du service fourni par le composant SÉCURITÉ est vide. Ce dernier est donc désinstallable. Les nœuds à désinstaller du graphe sont calculés par la règle Effet-DI. L ensemble des dépendances optionnelles OD du service fourni par le composant SÉCURITÉ et qui n est pas une extrémité finale des arcs du graphe (pas d autres exigences) est vide. En effet, le service MAJ.maj qui fait parti de l ensemble des dépendances optionnelles du service SÉCURITÉ.sha256 possède deux exigences INTERNET.web et C4.transfet, il représente l extrémité finale de deux arcs. Le composant MAJ ne peut donc pas être désinstallé. L ensemble des services à désinstaller est seulement le service SÉCURITÉ.sha256 fourni par le composant SÉCURITÉ. Nous allons présenter un exemple de désinstallation d un composant ayant des dépendances optionnelles. Pour cela, nous supposons que nous avons un gestionnaire de version SVN qui utilise une authentification LDAP à travers APACHE et PERL. Le composant PERL-LDAP permet d authentifier l utilisateur, en se basant sur les attributs d un

144 134 L installation et la désinstallation de composants LDAP LDAP PERL PERl-LDAP APACHE SVN Perl Perl-LDAP WebAuthLDAP SVNAuthLDAP Fig. 6.9 Un exemple d authentification SVN via APACHE composant LDAP. Pour désinstaller le composant PERL-LDAP avec son service perl-ldap, selon la définition 6.6 de la désinstallabilité, nous devons déterminer MD. Au niveau du graphe de la figure 6.10 les chemins à partir du nœud S LDAP Perl possèdent que des arcs optionnels. En effet, ce service est utilisé de manière optionnelle par APACHE et ensuite SVN. Ainsi, MD est vide et PERL-LDAP peut être désinstallé. Selon la définition 6.8, pour désinstaller perl-ldap, nous devons désinstaller tous ses services fournis ainsi que les nœuds qui en dépendent de façon optionnelle (directement ou indirectement) et ne possèdent pas d autres exigences. Ses dépendances optionnelles récursives (définies par OD) sont webauthldap et svnauthldap, ces services ne possèdent aucune autre exigence, il sont donc désinstallés récursivement et les composants APACHE et SVN resteront installés mais ils ne fourniront plus ces services. Le résultat de cette désinstallation est présenté dans le graphe de droite de la figure G LDAP.ldap DEINSTALL G LDAP.ldap PERL LDAP.perl ldap APACHE webauthldap SVN.svnAuthLdap G PERL.perl G PERL.perl Fig Avant et après la désinstallation du composant Perl-LDAP

145 Conclusion Conclusion Nous avons présenté la formalisation des phases d installation et de désinstallation. Cette formalisation se base sur l application d un ensemble de règles pour démontrer la faisabilité de chaque phase. Le processus de démonstration passe par deux étapes, la première consiste à vérifier la faisabilité de l opération de déploiement et la seconde consiste à calculer l effet de cette opération en mettant à jour le système cible et démontrer qu il ne le contraint pas.

146 136 L installation et la désinstallation de composants

147 Chapitre 7 Mise à jour des composants Sommaire 6.1 Introduction Description de l installation Installabilité Installation Exemple d installation Description de la désinstallation Désinstallabilité Désinstallation Trois exemples de désinstallation Conclusion La mise à jour des composants est une phase de déploiement très importante à gérer. Elle ne consiste pas seulement de désinstaller l ancien composant et d installer le nouveau. En effet, cette phase est fortement liée au problème de substituabilité qui est une propriété essentielle utilisée en particulier pour l adaptation d une application. Ce chapitre décrit le problème de la substituabilité qui consiste à vérifier la possibilité de remplacer un composant par un autre. Des exemples sur différents cas de figures de substitution sont présentés pour illustrer notre approche de vérification. Enfin, une comparaison de notre approche avec quelques travaux sur la vérification de la substituabilité est présentée. 7.1 Description de la mise à jour La mise à jour consiste à vérifier la compatibilité entre l ancien et le nouveau composant. Deux formes de compatibilité entre composants peuvent être définies : la compatibilité horizontale et la compatibilité verticale (appelée par la suite substituabilité). La compatibilité verticale permet d exprimer les conditions permettant de remplacer un composant par un autre (C old par C new dans la figure 7.1). La compatibilité horizontale 137

148 138 Mise à jour des composants C old est compatible avec C client? C old C client P 1 S 2 P 1 S 3 P 2 P 3 S 1 P 2 C old substituable par C new? P 1 S 2 P 2 S 4 P 3 S 1 C new Fig. 7.1 La compatibilité verticale et horizontale permet d exprimer la connexion entre un service fourni par un composant et un service requis par un autre composant (C old est utilisé par C client dans la figure 7.1). Pour substituer le composant C old par le composant C new, il faut vérifier que le composant C client peut utiliser les services fournis par C new de la même façon qu il utilisait ceux fournis par C old, et que les nouveaux services fournis ne sont pas en conflits avec les composants du système Définition de la substituabilité Pour expliquer notre approche de substituabilité, nous commençons par des définitions des deux principales formes de substituabilité : la substituabilité stricte indépendamment du contexte et substituabilité contextuelle par rapport à un certain contexte. Les définitions qui sont présentées ci-dessous sont inspirées de [Bra03]. Définition 7.1 (Substituabilité stricte) Un composant C old est substituable strictement par un composant C new si ce dernier peut remplacer C old dans tous les contextes. Définition 7.2 (Substituabilité contextuelle) Un composant C old est substituable contextuellement par un composant C new dernier peut remplacer C old dans au moins un contexte. si ce

149 Formalisation de la substituabilité 139 old old new new old new cas 1 cas 2 cas 3 old new cas 4 Fig. 7.2 Comparaison entre les services fournis et requis de C old et C new Substituabilité des composants Pour décider si un composant C new peut être remplacé par un composant C old, il faut comparer ce qu ils exigent et ce qu ils fournissent. En effet, le substituant C new peut fournir (ou exiger) moins, la même chose ou plus que le substitué C old. Pour cela, nous étudions les différents cas de figure. cas 1 : l ensemble des services fournis (resp. requis) de C new est inclus dans l ensemble des services fournis (resp. requis) de C old ; cas 2 : l ensemble des services fournis (resp. requis) de C new et C old sont égaux ; cas 3 : l ensemble des services fournis (resp. requis) de C old est inclus dans l ensemble des services fournis (resp. requis) de C new ; cas 4 : les deux ensembles sont différents les uns des autres et peuvent avoir éventuellement des services en commun. Nous avons quatre cas pour les services fournis et quatre cas pour les services requis (cf. la figure 7.2), la combinaison de ces différents cas nous donne seize possibilités. Afin d illustrer ces différents cas, supposons que le composant C old fournit deux services P S 1 et P S 2 et requiert les services RS 1 et RS 2. La table 7.1 représente les différents cas de figure, selon les éléments fournis et requis du substituant C new. 7.2 Formalisation de la substituabilité Dans cette section, nous présentons la formalisation de la substituabilité dans le cadre de notre système de déploiement. Cette formalisation va être issue d une analyse des seize cas possibles présentés dans la table Interprétation dans notre système Une analyse plus précise permet de simplifier les seize cas et de construire la table 7.2. Celle-ci contient les huit cas possibles qui utilisent seulement trois conditions de

150 140 Mise à jour des composants Fournir Exiger plus autant moins différent RS 1 P S 1 RS 1 P S 1 RS 1 P S 1 RS 1 P S 1 plus RS 2 RS 3 P S 2 P S 3 RS 2 RS 3 P S 2 P S 3 RS 2 RS 3 P S 2 P S 3 RS 2 RS 3 P S 4 RS 1 P S 1 RS 1 P S 1 RS 1 P S 1 RS 1 P S 1 autant RS 2 RS 3 P S 2 P S 3 RS 2 RS 3 P S 2 P S 3 RS 2 RS 3 P S 2 P S 3 RS 2 RS 3 P S 4 RS 1 P S 1 RS 1 P S 1 RS 1 P S 1 RS 1 P S 1 moins RS 2 RS 3 P S 2 P S 3 RS 2 RS 3 P S 2 P S 3 RS 2 RS 3 P S 2 P S 3 RS 2 RS 3 P S 4 RS 1 P S 1 RS 1 P S 1 RS 1 P S 1 RS 1 P S 1 différent RS 4 RS 3 P S 2 P S 3 RS 4 RS 3 P S 2 P S 3 RS 4 RS 3 P S 2 P S 3 RS 4 RS 3 P S 4 Tab. 7.1 Les différentes possibilités de substituabilité substituabilité : NR (New Requirements) : il faut vérifier les nouvelles exigences (ligne 1 de la table 7.1, RS 3 est-il satisfait?) NC (New Conflicts) : il faut vérifier que les nouveaux services fournis ne sont pas en conflit avec le contexte (colonne 1 de la table 7.1, P S 3 est-il en conflit avec le système). NON (NO Necessarily) : il faut vérifier que les services précédemment fournis par C new et qui ne sont plus fournis par C old ne sont pas nécessairement utilisés dans le contexte (colonne 3 de la table 7.1, P S 2 est-il utilisé?). Dans la table 7.1, chaque case contient les conditions à vérifier pour déterminer la possibilité de substitution. Fournir Exiger plus autant moins différent autant/moins NC NON NC+NON différent/plus NR+NC NR NR+NON NR+NC+NON Tab. 7.2 Les condition de substituabilité Dans cette table, nous retrouvons les deux formes de substituabilité. La seule case couvrant la substituabilité stricte est la case vide. La condition est que C new exige la même chose ou moins. Les sept autres cas représentent des substituabilités qui dépendent du contexte. Ainsi, il est possible de donner des conditions nécessaires et

151 Formalisation de la substituabilité 141 suffisantes pour les deux formes de substituabilité. CNS 1 (Substituabilité stricte) Un composant C old est substituable strictement par un composant C new ssi ils fournissent exactement les mêmes services et C new exige moins ou autant de services que C old. CNS 2 (Substituabilité contextuelle) Un composant C old est substituable par un composant C new dans un contexte Ctx ssi : toutes les nouvelles exigences de C new sont vérifiées dans Ctx (NR) aucun des nouveaux services fournis (s il y en a) n est en conflit avec Ctx (NC). aucun des services fournis par C old et pas fournis par C new n est nécessairement utilisé dans Ctx (NON). Pour déterminer la substituabilité dans notre système, il faut : être capable de déterminer dans quel cas on se trouve ; évaluer les conditions correspondantes NR, NC, NON. La première tâche est facile pour ce qui est des services fournis (condition NON), il suffit de cumuler tous les membres droits des dépendances. En revanche, déterminer s il y a plus ou moins d exigences est complexe car il s agit de comparer des prédicats. Pour cette raison, nous vérifions la substituabilité en utilisant les services fournis seulement comme suit : 1. NR et NC : représentent respectivement la vérification des nouvelles exigences et la vérification des nouveaux conflits. Ce qui peut être assuré par la condition d installabilité du nouveau composant (C new ). Cette condition correspond à : Ctx C new : D new, elle assure d une part que toutes les exigences du composant sont remplies (NR) et d autre part la compatibilité des services fournis avec le contexte (NC). 2. NON : cette condition utilise l ensemble des services fournis calculés à partir de la partie droite de la dépendance. Donc, pour chaque service fourni par C old et non par C new nous devons vérifier qu il n est pas utilisé nécessairement dans le contexte (l ensemble des dépendances obligatoires MD est vide, cf. la définition 6.5 page 130) ou il est utilisé par des services optionnels qui ne possèdent pas d exigences (cf. la définition 6.8 page 131). En effet, cette condition correspond à celle de la désinstallation. L ensemble des services qui appartiennent à C old.p s et n appartiennent pas à C new.p s est noté par la suite : C old.p s \ C new.p s. La condition NON peut être exprimée comme suit : {(MD(Ctx.G, Cold.s) s (C old.p s \ C new.p s )} = avec c.p s = (c, P s,, ) Ctx.C Ainsi, nous utilisons la table 7.3 qui résume les conditions de la substituabilité de la table 7.2. Les différentes conditions de substitution pour les quatre cas illustrés dans la figure 7.2 et la table 7.3 sont interprétées comme suit :

152 142 Mise à jour des composants Fournir plus autant moins différent Conditions NR+NC NR NR+NON NR+NC+NON Tab. 7.3 Résumé des conditions de substituabilité plus (cas 3) : C new est installable (NR+NC) ; autant (cas 2) : C new est installable (NR) ; moins (cas 1) : C new est installable (NR) et C old.p s \ C new.p s ne sont pas utilisés (NON) ; différent (cas 4) : C new est installable (NR+NC) et C old.p s \ C new.p s pas utilisés (NON). Puisque les services fournis dépendront de l évaluation de la dépendance du composant dans le contexte, les services fournis changeront en fonction de la disponibilité des exigences des dépendances dans le contexte Algorithme de substitution La substituabilité traitée dans le cadre de notre travail est contextuelle. D abord, le contexte Ctx doit être calculé sans le composant C old (Ctx.C\C old ), c est-à-dire, calculer l effet de la suppression du composant C old avec son quadruplet (C old, P s, F s, F c ) du contexte Ctx (cf. la définition 7.3). Ensuite, l installabilité du composant C new dans le nouveau contexte (Ctx.C \ C old ) doit être vérifiée. Définition 7.3 Le complément d un ensemble «\» Le complément du composant C old dans Ctx, notée Ctx.C \ C old est défini comme suit : Ctx.C \ C old = { c (c Ctx.C) (c C old )} La description formelle de la substituabilité contextuelle est présentée comme suit : Définition 7.4 Substituabilité contextuelle Un composant C old est substituable par un composant C new dans un contexte Ctx ssi : C new est installable dans Ctx.C \ C old ; tous les services fournis par C old et qui ne sont pas fournis par C new ne doivent pas être utilisés obligatoirement dans le contexte (la condition NON) : {(MD(Ctx.G, Cold.s) s (C old.p s \ C new.p s )} = avec c.p s = (c, P s,, ) Ctx.C La substituabilité est vérifiée suivant le diagramme présenté dans la figure 7.3. Tout d abord, le nouveau contexte Ctx est calculé sans l ancien composant C old. Ctx représente donc Ctx sans l ensemble des services fournis, l ensemble des services interdits et l ensemble des composants interdits de C old. Par la suite, l installabilité du composant C new dans Ctx est vérifiée par les règles d installabilité, c est-à-dire, tous les besoins de C new sont vérifiés et tous ses services fournis ne sont pas en conflits avec Ctx (cf. la règle CTriv de la figure 6.2 page 122). Une fois l installation du nouveau composant

153 Deux exemples de mise à jour 143 Calcul de Ctx = Ctx.C \ c old oui C new est installable dans Ctx? non Calcul de C new.p s C old.p s oui C old.p s \ C new.p s = non oui condition NON non C old est substituable C old pas substituable Fig. 7.3 Les phases de substituabilité est possible dans le nouveau contexte, l effet de son installation est calculé à partir de sa description de dépendances en utilisant les règles d installation présentées dans la figure 6.4 page 126. Cette phase est illustrée dans le diagramme de la figure 7.3 par le calcul de C new.p s. Les deux principales phases de substituabilité sont la vérification de l installabilité et le calcul des services fournis (phase d installation). Cette phase se base sur la description du contexte et la description de la dépendance. Une fois le composant est installable les services fournis dépendront de la disponibilité des services requis par la dépendance dans le cas des dépendances optionnelles (?) et disjonctive ( ). Par la suite, les services fournis par C old sont comparés avec ceux fournis par C new. C old est substituable dans deux cas : soit l ensemble des services fournis auparavant par C old et qui ne sont plus fournis par C new est vide, soit tous les services de cet ensemble ne sont pas utilisés obligatoirement par d autres composants dans le contexte. 7.3 Deux exemples de mise à jour La figure 7.4 illustre l architecture d un serveur mail différent de celui présenté 5.3 page 106. Ce serveur contient en plus des composants déjà présentés (POSTFIX, FETCHMAIL, PROCMAIL et THUNDERBIRD), le composant ORGANIZER. Ce dernier permet de personnaliser l organisation des mails en les triant, les listant, etc. Nous illustrons la substituabilité de composant par deux scénarios. Le premier concerne le cas où le nouveau composant fournit moins de services. Le second concerne

154 144 Mise à jour des composants le cas où le nouveau composant fournit plus. FDS 852 FETCHMAIL FDS 1508 THUNDERBIRD lib2 popclient lib4 MDA MUA MTA spell-dict corrector POSTFIX PROCMAIL ORGANIZER FDS 1380 popclient MUA manager MT A lib1 MTA lib3 FDS 248 MDA liborg amavis AntiVirus spam AntiSpam MTA MDA MUA AntiVirus AntiSpam corrector manager Fig. 7.4 Exemple d un serveur mail avec le composant ORGANIZER Mise à jour par un composant fournissant moins Pour des raisons d optimisation des ressources, on souhaite parfois remplacer un composant par un autre qui a besoin de moins de ressources et fournit moins de services (par exemple, THUNDERBIRD par SYLPHEED). Supposons que le service THUNDERBIRD.corrector (un correcteur d orthographe) soit le seul service qui n est pas fourni par SYLPHEED. Le système doit assurer la condition NON, c est-à-dire, ce service n est pas utilisé par d autres composants. Nous pouvons constater que dans le graphe de dépendance du serveur mail présenté dans la figure 7.5 le service THUNDERBIRD.corrector représente une feuille. En effet, ce service n est pas utilisé par un autre composant et la condition NON est donc vérifiée. Le composant THUNDERBIRD peut être remplacé par le composant SYLPHEED qui fournit moins de services si ce dernier est installable, c est-à-dire, ses services requis sont disponibles et l ensemble de ses services fournis n est pas en conflit avec le contexte (inclus dans ceux de THUNDERBIRD). La figure 7.6 présente cette substitution. Le seul service requis de SYLPHEED est la librairie C6.lib6 (la librairie lib6 fournie par le composant C6) Mise à jour par un composant fournissant plus L exemple suivant traite le cas de la substitution par un composant qui fournit plus de services. Par exemple, remplacer THUNDERBIRD par SEAMONKEY qui possède des services de mail supplémentaires comme le service chat (cf. la figure 7.7).

155 Quelques travaux connexes 145 POSTFIX PROCMAIL AMAVIS.amavis POSTFIX.AntiVirus SPAM.spam PROCMAIL.AntiSpam THUNDERBIRD C1.lib1 POSTFIX.MTA FETCHMAIL.popclient PROCMAIL.MDA SEAMONKEY.MUA THUNDERBIRD.corrector C2.lib2 C3.lib3 C7.lib7 SPELL.spell Dict FETCHMAIL ORGANIZER.manager Mandatory dependency (M) Optional dependency (O) C5.libOrg ORGANIZER Fig. 7.5 Le graphe de dépendance du serveur mail de la figure 7.4 La vérification de la substituabilité consiste à vérifier la disponibilité des services requis par SEAMONKEY (C7.lib7, IRC.ircclient, SPELL.spell-Dict, etc.) et assurer que les nouveaux services fournis ne sont pas en conflit avec le contexte. Le graphe de dépendance relatif est présenté dans la figure 7.8. Selon le diagramme de la figure 7.3, nous devons vérifier en premier lieu les conditions d installabilité du nouveau composant. La condition la plus importante est celle de la vérification de l effet de l installation du composant dans le contexte avant de l installer. En effet, la substitution ne sera pas possible si le composant SEAMONKEY est en conflit avec le contexte. Supposons que le service chat fourni par SEAMONKEY soit interdit dans le contexte, la condition d installabilité n est donc pas vérifiée et la substitution n est plus possible. Nous pouvons également avoir des invariants dans le contexte qui doivent être maintenus. Par exemple, dans le cas où le système veut maintenir le niveau de sécurité, l installation d un service qui peut influencer le niveau de sécurité du système (le diminuer) est interdite (comme le service ftp par exemple). Supposons que nous voulons substituer le composant C old par le composant C new qui fournit le service ftp. La substitution ne sera pas possible vue que le service ftp possède un niveau de sécurité assez bas et ne préserve pas l invariant du système. 7.4 Quelques travaux connexes Cette section décrit brièvement quelques travaux qui traitent la notion de substituabilité. D abord, nous allons commencer par ceux qui abordent d une façon plus générale le principe de sous typage qui est étroitement liée a la substituabilité. Ensuite, nous étudions quelques travaux sur la vérification de la substituabilité et l interopérabilité des composants logiciels. En programmation orientée objet, le principe de substitution de Liskov est une

156 146 Mise à jour des composants POSTFIX PROCMAIL AMAVIS.amavis POSTFIX.AntiVirus SPAM.spam PROCMAIL.AntiSpam C1.lib1 POSTFIX.MTA FETCHMAIL.popclient PROCMAIL.MDA SYLPHEED.MUA SYLPHEED C2.lib2 FETCHMAIL C3.lib3 C6.lib6 ORGANIZER.manager Mandatory dependency (M) Optional dependency (O) C5.libOrg ORGANIZER Fig. 7.6 Substitution de THUNDERBIRD par SYLPHEED SEAMONKEY FDS 2508 MDA lib7 ircclient spell-dict MUA Chat corrector Fig. 7.7 Le composant SEAMONKEY définition particulière de sous-type qui a été introduite dans [LW99]. Cette notion de sous-type est fondée sur la notion de substituabilité. C est-à-dire que si S est un soustype de T alors on peut substituer des objets de type S à des objets de type T sans altérer les propriétés désirables d un programme. Cependant, malgré son approbation dans [SC00], les règles basées sur le sous-typage sont assez restrictives. Pour cela, nous optons pour une approche plus flexible permettant de faire des choix selon le cas de figure, le besoin et les exigences du contexte. Dans [Geo05], une classification hiérarchique pour le sous-typage est présentée dans le but de proposer des bases essentielles d un typage réellement adapté aux composants. Cette classification se base sur deux axes orthogonaux manifestant deux problématiques complémentaires : l axe horizontal représente le niveau de description des propriétés d un composant (syntaxique, sémantique, non fonctionnel), l axe vertical permet une comparaison dans un contexte de plus en plus hétérogène entre deux composants. Dans le cadre de notre étude, nous ne nous intéressons pas au niveau de conformité. Dans [LA05] la notion de substitution n est pas définie par rapport au substitué et au substituant mais par le maintient des compatibilités entre le composant substitué et

157 Quelques travaux connexes 147 POSTFIX PROCMAIL AMAVIS.amavis POSTFIX.AntiVirus SPAM.spam PROCMAIL.AntiSpam SEAMONKEY IRC.ircclient SEAMONKEY.chat C1.lib1 POSTFIX.MTA FETCHMAIL.popclient PROCMAIL.MDA SEAMONKEY.MUA SPELL.spell Dict SEAMONKEY.corrector C2.lib2 FETCHMAIL C3.lib3 C7.lib7 ORGANIZER.manager Mandatory dependency (M) Optional dependency (O) C5.libOrg ORGANIZER Fig. 7.8 Substitution de THUNDERBIRD par SEAMONKEY ses pairs auxquels il est relié. Dans le cadre de notre travail, nous avons défini en plus de la substituabilité contextuelle, la substituabilité stricte par rapport au substitué et substituant indépendamment du reste du contexte. La compatibilité étudiée dans [LA05] est définie au niveau des opérations, des interfaces, des ports puis au niveau du composant. Pour qu une opération soit compatible avec une autre opération, il est nécessaire qu elle soit compatible au niveau syntaxique, sémantique et pragmatique. La notion de substituabilité dans [Bra03] est définie pour les composants boite noire, le principe est de vérifier que la substitution du composant conserve la consistance de la configuration préalable. Les notions de contexte de déploiement, substituabilité stricte et substituabilité contextuelle sont définies. Les représentations des spécifications des composants et du contexte de déploiement se basent sur un modèle ENT (Export, Needs, Ties). La définition de la substitution stricte est différente de la notre dans le sens où, il considère que dans ce cas le nouveau composant doit fournir au moins la même chose et exige au plus la même chose (généralisation des besoins et spécialisation des offres). Cependant, dans notre cas, les services fournis en plus ne doivent pas être en conflit avec d autres services du contexte. Donc dans [Bra03], il n y pas de vérification des nouvelles exigences ou des nouveaux services fournis s ils existent. En effet, de leur point de vue, fournir plus de services n a pas d effet sur l environnement. Une classification des types de substitution est présente dans [Bra03] : substituabilité stricte complète pour assurer le remplacement entier du composant, substituabilité contextuelle complète pour une mise à jour d une application, ou une substitution contextuelle de données pour adapter juste quelques liens opérationnels dans l application. Le modèle ENT permet également de définir plusieurs niveaux de substituabilité partielle. Notre approche est différente dans le sens où on ne peut pas autoriser toujours la substitution d un composant avec un autre qui fournit des services plus spécialisés. En effet, le système peut être en conflit avec les services qui sont spécialisés. Un modèle de substitution orienté composant est proposé dans [BFS06], il prend

158 148 Mise à jour des composants en compte les propriétés fonctionnelles et non fonctionnelles. Il calcule la distance de substitution entre le substituant et le substitué en fonction d un poids de comparaison et d une pénalité. Ce travail s intéresse plus au calcul des composants idéaux ayant la meilleure qualité de service, ce qui n est pas exactement notre objectif. De plus, leur approche est basée sur les besoins, c est-à-dire, l écoute des besoins de l application et le contexte repose sur le composant idéal qui modélise ces besoins et qui doit être remplacé par un composant concret. Dans notre cas, nous étudions la substituabilité de deux composants concrets. Dans [WR06], une approche basée sur les états pour la spécification de protocole d interaction entre des composants logiciels est présentée. Cette approche a été étudiée en terme de : spécification des possibilités pratiques, vérification de l interopérabilité et la substituabilité. Le modèle proposé est utilisé pour spécifier la classe FileStream de la librairie des classes de.net. La modélisation est faite avec des machines à état fini. L interopérabilité est vérifiée en prenant le langage des interfaces requises A R et en appliquant la fonction r qui ajoute toutes les valeurs des paramètres possibles aux noms de méthodes, ensuite elle les compare avec le langage des interfaces fournies A P. La vérification de la substitution entre deux composants consiste à comparer à chaque fois entre le langage des interfaces requises du premier avec les interfaces requises du second et les interfaces fournies du premier avec les interfaces fournies du second. Chaki et al se concentrent dans [CSS04] sur la substitution du point de vue vérification. Leur objectif est de fournir une procédure de vérification qui décide si le remplacement est possible sans violer la consistance du système. Ils proposent une solution au problème de substituabilité en deux phases. La première consiste à faire un raisonnement compositionnel en utilisant un algorithme dynamique d inférence. La deuxième phase détecte au niveau de chaque composant les comportements qui sont présents avant la mise à jour et qui ne le sont pas après. Dans le cas où le composant n est pas substituable, ces comportements sont utilisés pour la génération des feedback constructifs aux développeurs leur permettant d améliorer les composants. Un composant est considéré comme un langage C communiquant avec les autres composants à travers des messages. Leur approche utilise les automates ce qui la rend plus complexe car la gestion des états des automates n est pas triviale (recensement de tous les états). Il n existe pas de description des contraintes de dépendance, la comparaison est faite au niveau des traces des automates. Par contre, la substituabilité peut être vérifiée au niveau d un assemblage de composants. Une modélisation et vérification de l interopérabilité entre composants est présentée dans [Cho06]. La vérification de l interopérabilité implique la vérification de la compatibilité des interfaces ou la vérification de la substituabilité (équivalence d interfaces entre l ancien et le nouveau composant). La vérification de la compatibilité est faite en deux étapes. La première étape consiste à vérifier en utilisant l atelier que l invariant de l interface utilisée est satisfait par la spécification de l interface offerte appropriée. La deuxième étape consiste a utiliser les spécifications de protocole et les spécifications B des interfaces pour compléter la vérification de la compatibilité des interfaces au niveau des signatures, sémantiques et protocole en vérifiant la relation de simulation entre les systèmes de transitions qui modélisent les comportements du composant. Dans le cas

159 Synthèse 149 de la substituabilité, l approche de vérification est basée sur la méthode B et la vérification de la relation de bissimulation entre les systèmes de transitions des interfaces de l ancien composant et les interfaces du nouveau composant. Dans [CVZ06] la substituabilité est vérifiée en utilisant le formalisme d automates d interaction de composants [VZ05] en se basant sur deux principes. Le premier est la possibilité de remplacer le composant par un nouveau. Le second, est la réutilisation du composant dans n importe quel système dont l implantation satisfait la spécification donnée par l environnement. D une part, ils définissent trois relations : la relation d équivalence, la relation entre la spécification et l implantation et la relation de substituabilité. Ces relations permettent de vérifier le comportement de deux composants avec le respect de la correction de la reconfiguration. D autre part, ils formalisent le problème de la substituabilité pour les composants équivalents et non équivalents ainsi que le problème de la substituabilité de l implantation des composants par rapport à leurs spécifications en utilisant la relation de bissimulation faible. Notre travail est différent puisque pour l instant on ne s intéresse pas à l implantation des composant ni à l aspect comportemental. 7.5 Synthèse Niveau de vérificatiocriptiostituabilité Langage de des- Fonction de sub- [LA05] signature, sémantique, pré et post- remplacer A par B, nonconditions remplacer A par B fonctionnel dans S [Bra03] signature modèle remplacer A par B, remplacer A par B dans S [BFS06] signature, nonfonctionnel basé sur UML trouver A pour S [WR06] protocole machine à états finis remplacer A par B [CSS04] signature, sémantique,comportement automate+ langage remplacer A par B régulier dans S [Cho06] comportement automates+ spécification remplacer A par B B [CVZ06] comportement automates d intéraction [notre travail] signature logique du premier ordre Tab. 7.4 Résumé sur les travaux connexes remplacer A par B, remplacer A par B dans S remplacer A par B dans S

160 150 Mise à jour des composants Nous pouvons classer les travaux qui traitent le problème de la substitution selon trois axes. Le premier axe présente les fonctions de substituabilité : (1) remplacer un composant par un autre indépendamment du contexte (2) remplacer un composant en fonction d un certain contexte. Le second axe représente les niveaux de vérification de la substituabilité au sens de Beugnard [BJPW99] : niveau syntaxique, sémantique, protocole et non-fonctionnel. Le troisième axe concerne les langages de description utilisés : les systèmes de transition étiquetés, la logique d ordre supérieur, la logique temporelle, etc. Une synthèse sur la comparaison de ces travaux selon les trois axes cités est présentée dans le tableau 7.4. Malgré les améliorations apportées aux spécifications au niveau syntaxique, sémantique et protocole, nous pensons qu il n y a pas assez d informations au niveau des interfaces des composants pour réaliser une substitution sûre et flexible. En effet, souvent dans ces travaux la condition de substitution est restrictive car elle consiste à exiger du nouveau composant le même comportement que l ancien. Dans notre approche le niveau d abstraction est supérieur car nous nous sommes intéressés à la vérification des propriétés globales du système sans se préoccuper de la vérification de la compatibilité au niveau sémantique et comportemental. Notre vérification pourra être en amont des autres vérifications pour éliminer les cas qui ne sont pas substituables au niveau interface. Les règles de vérification de la substituabilité se basent sur la vérification des nouveaux besoins, le calcul de l effet de l ajout du nouveau composant dans le contexte en préservant la consistance et la cohérence du système. La flexibilité est caractérisée par la possibilité de remplacer un composant pas forcément équivalent au nouveau, par exemple dans le cas de ressources limitées l ancien composant qui en consomme beaucoup peut être remplacé par un autre qui en consomme moins. La substituabilité peut aussi être dirigée par d autres types de politiques. 7.6 Conclusion Dans ce chapitre, nous avons présenté une formalisation de la mise à jour de composant. Dans le cadre de notre travail, l étude de la mise à jour correspond à l étude du problème de la substituabilité. Le but de cette formalisation est de pouvoir substituer les composants de manière sûre et flexible. Nous avons défini deux types de substitution : la substitution stricte et la substitution contextuelle. Nous nous sommes concentrés uniquement sur la substitution contextuelle. Le principe est en plus de comparer les descriptions des dépendances de l ancien et du nouveau composant, il faut vérifier la faisabilité de l installation du nouveau composant et son effet sur le contexte. L objectif est d assurer une substitution sûre et flexible. La sûreté de la substituabilité est caractérisée par la vérification des besoins du nouveau composant et la vérification de l effet de la substitution sur le contexte avec la préservation de ses invariants. La flexibilité de la substituabilité est de ne pas être lié à des règles de sous typage qui sont assez restrictives mais plutôt substituer selon les exigences et le besoin de l utilisateur. Par exemple, substituer un composant ayant beaucoup de services inutilisés avec un composant qui fournit moins de services pour gagner de l espace mémoire. L originalité

161 Conclusion 151 de notre approche de substitution est liée particulièrement à la prise en compte de l effet sur le contexte cible et la possibilité de substituer un composant par un autre sans qu il ait forcément une relation de sous typage.

162 152 Mise à jour des composants

163 Chapitre 8 Extension du système par les propriétés Sommaire 7.1 Description de la mise à jour Définition de la substituabilité Substituabilité des composants Formalisation de la substituabilité Interprétation dans notre système Algorithme de substitution Deux exemples de mise à jour Mise à jour par un composant fournissant moins Mise à jour par un composant fournissant plus Quelques travaux connexes Synthèse Conclusion Dans ce chapitre nous présentons une extension du moteur de raisonnement par l intégration des propriétés. Ces dernières sont décrites dans notre méta-modèle présenté dans le chapitre 4. Elles décrivent l ensemble des caractéristiques des composants, des services et du système cible. Elles peuvent être fonctionnelles ou nonfonctionnelles. L extension des descriptions de dépendances, du contexte ainsi que les règles d installation, de désinstallation et de mise à jour est décrite dans ce chapitre. 8.1 Description des propriétés Les propriétés sont définies dans la section 4.3 page 92, elles sont caractérisées par un nom et une valeur. Elles peuvent être associées à un composant ou un service. Elles sont typées, donc leurs valeurs ont un type particulier. Les types supportés sont les nombres, les chaînes de caractères et les booléens. Un composant peut avoir un ensemble de propriétés. Ces propriétés peuvent être relatives à ses services fournis ou le concernant 153

164 154 Extension du système par les propriétés directement. Ainsi la syntaxe de la définition des services et des composants fournis est étendue pour leur ajouter des ensembles de propriétés (la syntaxe est présentée dans la section suivante). Par exemple, un service s avec une propriété p de valeur v est noté s[p = v]. Un ensemble de propriétés sera manipulé comme un environnement, il est donc noté E. Le domaine de cet environnement représente alors l ensemble des noms des propriétés qu il contient : { dom([]) = dom([p 1 = v 1,..., p n = v n ] = {p 1,..., p n } La syntaxe des exigences est également étendue pour permettre la spécification des contraintes sur les propriétés des composants ou services requis. Une contrainte de propriété ϕ est définie de manière similaire aux propriétés mais en utilisant en plus de l égalité d autres opérateurs de comparaison (>,, <,, =, ). Le domaine d une contrainte de propriété représente le domaine de cette propriété, il est défini comme suit : { dom([]) = dom([p 1 O 1 v 1,..., p n O n v n ] = {p 1,..., p n } Définition 8.1 (Satisfiabilité) Une contrainte ϕ peut être satisfaite par un environnement E. Pour cela, il faut (1) que toutes les propriétés de ϕ aient une valeur dans E et (2) la valeur d une propriété dans E satisfasse toutes les contraintes la concernant dans ϕ. La satisfiabilité est notée par : ϕ E et définie comme suit : ϕ E = (dom(ϕ) \ dom(e) = ) (E(p 1 )O 1 v 1 ) (E(p n )O n v n ) avec ϕ = [p 1 O 1 v 1,..., p n O n v n ] [] E = true La notion de satisfiabilité est utilisé lors de la comparaison d une exigence d un service requis avec une propriété d un service fourni. Par exemple, si la contrainte ϕ vaut [version 3] et E est égal à [version = 4]. La fonction de satisfiabilité consiste à remplacer version dans ϕ par sa valeur dans E. ϕ E vaut alors 4 3 qui est vraie Description des dépendances Les dépendances sont décrites selon la grammaire de la figure 8.1. Cette grammaire étend celle présentée dans la section page 107 en ajoutant des propriétés au niveau des services fournis et des contraintes sur les propriétés au niveau des composants et services requis ou interdits. Le fait d ajouter un ensemble de propriétés implique la possibilité d avoir plusieurs instances de composants ou de services. En effet, nous pouvons avoir les mêmes composants ou les mêmes services mais avec des propriétés différentes donc plusieurs instances possibles. Pour identifier un composant, nous utitilisons le couple (c, num) où c est son nom et num son numéro. Ce numéro est initialisé à 1 et incrémenté à chaque nouvelle instance du composant c (du même nom) installée (cf. la définition 8.2). La fonction CalcNum

165 Description des propriétés 155 D ::= P s P rop D D D # D? D P ::= true P P Q Q ::= Q Q R R ::= Const c Const s Const c Const.s Const s Const P rop ::= [v = val P rop2] Const ::= [v O val Const2] P rop2 ::=, v = val P rop2 Const2 ::=, v O val Const2 O ::=> < = Fig. 8.1 Extension de la grammaire des dépendances utilise une nouvelle forme du contexte différente de celle présentée dans le chapitre 5 page 114. Cette forme est définie par la suite. Définition 8.2 (CalcNum) La fonction CalcN um calcule l identité d un composant. elle est définie comme suit : CalcNum(Ctx, c) = max({0} {n (c, n,,,, ) Ctx.C}) + 1 Un composant peut fournir plusieurs fois le même service avec des propriétés différentes. Il faut donc identifier ces services pour les différencier. L identité d un service est notée id s, c est un quadruplet (c, num, s, E s ), où le couple (c, num) représente l identité de son fournisseur et E s ses propriétés Description du contexte Le Contexte a une forme similaire à celle du système initial, il est juste enrichi pour mémoriser toutes les informations concernant les propriétés et les contraintes. Il est donc composé : 1. des variables d environnement avec leurs valeurs E ; 2. de l ensemble C constitué de l ensemble des éléments (c,num, E c,p s,f s,f c ) décrivant pour chaque composant : c son nom, num son numéro, l ensemble de ses propriétés E c, P s l ensemble de ses services fournis avec leurs propriétés (s, E s ), F s l ensemble de ses services interdits avec leurs contraintes (s, ϕ s ) et F c l ensemble de ses composants interdits avec leurs contraintes (c, ϕ c ) 3. d un graphe de dépendance G représentant les dépendances de services vérifiées. Un nœud du graphe G est l identité d un service disponible (id s = (id c, s, E s )), où id c = (c, num) représente l identité de son composant (fournisseur) et E s représente ses

166 156 Extension du système par les propriétés x,ϕ c,ϕ s propriétés. Un arc est le couple de nœuds id s1 ids2, où id s2 requiert id s1 avec la contrainte ϕ c sur le composant qui fournit le service s 2 et la contrainte ϕ s sur le service requis id s1. Chaque arc est étiqueté également avec le type de la dépendance (au dessus de la flèche, le x), soit obligatoire M (mandatory) soit optionnel O(optional). Les contraintes sont conservées dans le graphe pour les prendre en compte dans le cas de la vérification d autres opérations de déploiement. Par exemple, si un composant a la propriété (NS = 3) est utilisé par un autre avec une contrainte sur son niveau de sécurité (NS 3), ce dernier ne pourra pas être mis à jour par un autre composant qui a la propriété (NS = 2). Pour cela, toutes les contraintes relatives aux composants et aux services sont mémorisées dans le graphe de dépendance. Nous définissons des fonctions qui calculent l ensemble des services disponibles AS, celui des composants disponibles AC, celui des services interdits FS et enfin celui des composants interdits FC. Elles sont définies de la même façon que dans le premier système du chapitre 5 page 103 avec l ajout des propriétés au niveau des services et des composants. Pour simplifier la présentation de notre système, nous ajoutons une cinquième fonction : ASC qui permet de déterminer pour un service fourni par un composant, l ensemble de couples qui constituent ses propriétés et les propriétés de son composant. Elles sont définies comme suit : AS(Ctx) = {P s (,,, P s,, ) Ctx.C} AC (Ctx) = {(c, num) (c, num,,,, ) Ctx.C} ASC(Ctx, c.s) = {(E c, E s ) (c,, E c, P s,, ) Ctx.C (s, E s ) P s } FS(Ctx) = {F s (,,,, F s, ) Ctx.C} FC (Ctx) = {F c (,,,,, F c ) Ctx.C} P s est l ensemble des couples des services avec leurs propriétés (s, E s ) et Ctx.C représente les éléments (c, num, E c, P s, F s, F c ) qui décrivent le composant c avec son identité num, l ensemble de ses propriétés E c, l ensemble de ses services fournis P s, l ensemble de ses services interdits F s et l ensemble de ses composants interdits F c. En ajoutant les propriétés au niveau des composants et des services, et les contraintes sur ces propriétés au niveau des exigences, il est plus complexe de déterminer si un composant ou un service sont disponibles ou interdits. La fonction F orbidden détermine si un composant ou un service fournis sont interdits dans le contexte (cf. la définition 8.3). La fonction Available détermine si un composant ou un service requis sont disponibles dans le contexte (cf. la définition 8.4). Définition 8.3 (Forbidden) La fonction F orbidden vérifie si le composant ou le service fourni ne sont pas interdits dans le contexte. Le principe de cette fonction est de vérifier la satisfiabilité (cf. définition 8.1 page 154) des contraintes existantes au niveau des ensembles FC ou FS avec les propriétés du composant ou du service en question. { F orbidden(ctx, c, Ec ) = (c, ϕ c ) F C(Ctx) (c = c) (ϕ c E c ) F orbidden(ctx, s, E s ) = (s, ϕ s ) F S(Ctx) (s = s) (ϕ s E s ) Définition 8.4 (Available) La fonction Available vérifie si le composant ou le service requis appartiennent au contexte Ctx. Le principe de cette fonction est de vérifier

167 Description de l installation 157 la satisfiabilité (cf. définition 8.1 page 154) des contraintes existantes au niveau des ensembles AC AS ou ASC avec les propriétés du composant ou du service en question. Available(Ctx, c, ϕ c ) = (c, E c ) AC(Ctx) (c = c) ϕ c E c Available(Ctx, s, ϕ s ) = (s, E s ) AS(Ctx) (s = s) ϕ s E s Available(Ctx, c.s, ϕ c, ϕ s ) = (E c, E s ) ASC(Ctx, c.s) (ϕ c E c ) (ϕ s E s ) La fonction CalcIds calcule les identités des services requis et disponibles dans le contexte avec des propriétés vérifiant les contraintes exigées sur elles. Définition 8.5 (CalcIds) La fonction CalcIds calcule l ensemble des identités d un service requis par un composant en fonction des contraintes imposées sur lui (ϕ s ) et sur le composant qui le fournit (ϕ c ) au niveau de Ctx. Elle est définie comme suit : CalcIds(Ctx, c.s, ϕ c, ϕ s ) = {(c, num, s, E s ) (c, num, E c, P s,, ) Ctx.C (s, E s ) P s (ϕ c E c ) (ϕ s E s )} CalcIds(Ctx, s, ϕ s ) = {(c, num, s, E s ) (c, num, E c, P s,, ) Ctx.C (s, E s ) P s (ϕ s E s )} 8.2 Description de l installation De la même façon que nous avons décrit l installation dans la section 6.2 page 120, nous la décrivons dans cette section avec le même principe. La différence se présente dans la granularité des composants et services qui est plus fine. Nous devons prendre en considération en plus des noms des services et des composants leurs propriétés et les contraintes exigées sur elles. La première étape est la vérification de l installabilité du composant. Elle consiste à (1) vérifier que toutes les contraintes imposées sur les propriétés des services requis par ce composant sont disponibles dans le contexte (cf. la définition 8.4) (2) s assurer qu aucun des composants à installer avec leurs propriétés n est interdit et tous les services qu il fournit avec leurs propriétés ne font pas partie de l ensemble des services interdits (cf. la définition 8.3). La deuxième étape consiste à calculer l effet de l installation du composant sur le système en mettant à jour l ensemble des services et des composants disponibles, l ensemble des services et des composants interdits, ainsi que le graphe de dépendance L installabilité Dans cette partie, nous décrivons les règles d installabilité d un composant. Ces règles sont une extension de celles présentées dans le chapitre 6 page 120 par les propriétés. Définition 8.6 (Installabilité) Un composant c avec une dépendance D et un ensemble de propriétés E c est installable dans un contexte Ctx ssi le composant avec

168 158 Extension du système par les propriétés Évaluation des prédicats : PTrue: Ctx P true PAnd: C P P 1 Ctx P P 2 Ctx P P 1 P 2 POrL: Ctx P Q 1 Ctx P Q 1 Q 2 POrR: Ctx P Q 2 Ctx P Q 1 Q 2 PVar: Ctx.E(v 1 ) O V 1... Ctx.E(v n ) O V n Ctx P [v 1 O V 1,..., v n O V n ] PNotS: Available(Ctx, s, ϕ s ) PNotC: Available(Ctx, c, ϕ c ) Ctx P s ϕ s Ctx P c ϕ c PServ: Available(Ctx, s, ϕ s ) PComp: Available(Ctx, c.s, ϕ c, ϕ s ) Ctx P s ϕ s Ctx P c ϕ c.s ϕ s Règles d installabilité : CTriv: Ctx P P F orbidden(ctx, s, E s ) CAnd: Ctx C D 1 Ctx C D 2 Ctx C P s E s Ctx C D 1 D 2 COpt: Ctx C? D COrL: Ctx C D 1 Ctx C D 1 # D 2 COrR: Ctx C D 2 Ctx C D 1 # D 2 Fig. 8.2 Extension des règles d installabilité l ensemble de ses propriétés n est pas interdit et sa dépendance D est vérifiée. La règle générale d installabilité d un composant est définie comme suit : CComp: Ctx C D F orbidden(ctx, c, E c ) Ctx c : D, E c Les règles d installabilité sont présentées dans la figure 8.2. En ce qui concerne l évaluation des prédicats, la différence avec le premier système est dans la vérification de la disponibilité des composants et des services exigés. En effet, la vérification se base sur les noms et la conformité des propriétés avec les contraintes exigées. Au lieu d utiliser les fonctions AS et AC nous utilisons la fonction Available dans les règles PNotS, PNotC, PServ et PComp pour vérifier la disponibilité des services et composants qui garantissent les contraintes exigées. Au niveau des règles d installabilité, il faut s assurer que l effet des services fournis avec leurs propriétés ne sera pas conflictuel (cf. la règle CTriv) L installation Une fois que l installabilité du composant est prouvée, l effet de l installation de ce dernier dans le système cible doit être calculé. Cet effet concerne les nouveaux services

169 Description de l installation 159 GTrue: Ctx G true GAnd: Ctx G P 1 G 1 Ctx G P 2 G 2 Ctx G P 1 P 2 G 1 G 2 GOr: Ctx G Q 1 G 1 Ctx G Q 2 G 2 Ctx G Q 1 Q 2 G 1 G 2 GVar: Ctx, id s G E GNotS: Ctx, id s G s ϕ GNotC: Ctx, id s G c ϕ GServC: CalcIds(Ctx, c.s, ϕ c, ϕ s ) Available(Ctx, c.s, ϕ c, ϕ s ) Ctx, id s G c ϕ c.s ϕ s {id s M,ϕ c,ϕ s id s id s CalcIds(Ctx, c.s, ϕ c, ϕ s )} GServ: CalcIds(Ctx, s, ϕ s ) Available(Ctx, s, ϕ s ) Ctx, id s G s ϕ s {id s M,,ϕ s id s id s CalcIds(Ctx, s, ϕ s )}} Fig. 8.3 Extension des règles de calcul du graphe disponibles avec leurs propriétés, les nouveaux services interdits avec leurs contraintes, les nouveaux composants interdits avec leurs contraintes ainsi que les nouvelles dépendances (représentées par un graphe de dépendance). Avant de présenter les règles d installation, nous décrivons d abord les fonctions qui permettent de calculer l effet de l installation. Définition 8.7 (Calcul du graphe) le graphe de dépendance G est calculé à partir du prédicat P de la dépendance (Ctx, id s G P G) en appliquant les règles présentées dans la figure 8.3. La principale différence dans ces règles avec le premier système est l introduction des identifiants de services au niveau des nœuds du graphe et des contraintes sur les propriétés des composants et des services au niveau des étiquettes de l arc. Les règles GTrue, GAnd, GOr, GVar, GNotS, GNotC sont identiques à celles du premier système. La règle GServC permet de lier l ensemble des identifiants id s (c, num, s, E s ) avec le nœud id s par un arc étiqueté par le triplet (M, ϕ c, ϕ s ) qui sont respectivement la dépendance obligatoire, la contrainte imposée sur le composant et la contrainte imposée sur le service. Elle vérifie que le composant c avec la contrainte ϕ c et son service s avec sa contrainte ϕ s sont satisfaits dans le contexte avec la fonction Available. Les identifiants de services sont calculés par la fonction CalcIds décrite dans la définition 8.5. La règle GServ est similaire mais permet de lier le service id s avec tous les composants c qui fournissent le service s ayant les identifiants id s par l arc (M,, ϕ s ). Définition 8.8 (Installation) L installation d un composant c avec une dépendance D dans un contexte Ctx a un effet sur : l identifiant du composant fourni id c = (c, num), l ensemble des services

170 160 Extension du système par les propriétés fournis P s, l ensemble des services interdits F s, l ensemble des composants interdits F c et le graphe de dépendance G. Ces effets sont calculés par les règles présentées dans la figure 8.4. IComp: Ctx, c, num I D P s, F s, F c, G num = CalcNum(Ctx, c) Ctx I c : D, E c c, num, E c, P s, F s, F c, G Définition 8.9 (CalcF) La fonction CalcF calcule l ensemble des services interdits et l ensemble des composants interdits à partir du prédicat, elle est définie comme suit : CalcF (true) =, CalcF (P 1 P 2 ) = Fs 1 Fs 2, Fc 1 Fc 2 où CalcF (P i ) = Fs, i Fc i CalcF (Q 1 Q 2 ) = Fs 1 Fs 2, Fc 1 Fc 2 où CalcF (Q i ) = Fs, i Fc i CalcF (s ϕ) = CalcF { (c ϕ.s ϕ) = CalcF (ϕ) =, {(s, ϕ)}, si Available(Ctx, s, φs ) CalcF ( sϕ) = {, sinon, {(c, ϕ)}si Available(Ctx, c, φc ) CalcF ( cϕ) =, sinon Les règles d installation sont similaires à celles du premier système avec l ajout des identifiants de composants et de services. L identifiant du composant est calculé par la règle IComp (cf. la définition 8.8), il est utilisé à la place du nom. Comme dans le premier système la règle principale qui permet de calculer l effet de l installation est la règle ITriv. La différence avec le premier système est au niveau de l ensemble des services fournis qui représente le couple des services avec leurs propriétés (s, E s ) et au niveau du graphe de dépendance qui utilise les identifiants de services comme nœuds et les contraintes avec le type de dépendances comme étiquettes des arcs. L ensemble des services et composants interdits sont calculés par la fonction CalcF. Le graphe de dépendances est calculé par les règles de la figure 8.3 qui sont dénotées dans la règle ITriv par ( G ). La fonction F orbidden permet de vérifier si les services fournis par le composant avec l ensemble de ses propriétés ne sont pas en conflit avec le contexte Deux exemples d installation Nous illustrons le processus d installation avec les propriétés par deux exemples. Le premier exemple concerne l installation du composant POSTFIX avec la description des contraintes au niveau des exigences et la description des propriétés au niveau des services fournis. Le deuxième exemple est celui du composant USER-INTERFACE Exemple d installation de POSTFIX Soit le composant POSTFIX avec la dépendance D 1 D 2 : { D1 = [F DS 1380] C SM [v 2] S lib [v 3] S MT A [v = 3] D 2 =?(C A [v 3, NS 2].S amavis [NS 3] S AV [NS = 4])

171 Description de l installation 161 ITriv: Ctx, id s G P G F orbidden(ctx, s, E s ) CalcF (P ) = F s, F c Ctx, id c I P s E s {s, E s }, F s, F c, G INot 1 : Ctx P P Ctx, id c I P s E s INot 2 : F orbidden(ctx, s, E s ) Ctx, id c I P s E s IOpt 1 : Ctx, id c I D Ctx, id c I? D,,, IOpt 2 : Ctx, id c I D P s, F s, F c, G Ctx, id c I? D P s, F s, F c, {s O,ϕc,ϕs s s,ϕc,ϕs s G} IAnd 1 : Ctx, id c I D 1 Ctx, id c I D 1 D 2 IAnd 2 : Ctx, id c I D 2 Ctx, id c I D 1 D 2 IAnd 3 : Ctx, id c I D 1 P 1 s, F 1 s, F 1 c, G 1 Ctx, id c I D 2 P 2 s, F 2 s, F 2 c, G 2 Ctx, id c I D 1 D 2 P 1 s P 2 s, F 1 s F 2 s, F 1 c F 2 c, G 1 G 2 IOrL: Ctx, id c I D 1 P s, F s, F c, G Ctx, id c I D 1 # D 2 P s, F c, F s, G IOrR: Ctx, id c I D 1 Ctx, id c I D 2 P s, F s, F c, G Ctx, id c I D 1 # D 2 P s, F s, F c, G IOr3: Ctx, c I D 1 Ctx, c I D 2 Ctx, c I D 1 # D 2 Fig. 8.4 Extension des règles d installation

172 162 Extension du système par les propriétés Initialement nous supposons que le contexte de l environnement est le suivant : E = {F DS = , OS = LINUX, RAM = 128}; C = {(C 1, 1, [], (S lib [v = 3]),, ), (C A, 1, [v = 4, NS = 3], (S amavis [NS = 3]),, )}; G = La démonstration de la preuve d installabilité et la preuve d installation du composant POSTFIX (C P X ) est présentée ci-dessous. La preuve de l installabilité Les services exigés par POSTFIX ont des contraintes sur les propriétés. Par exemple, le composant C SM avec une version supérieur ou égale à 2 est interdit, la librairie lib avec une version supérieure ou égale à 3 est exigée. La preuve d installabilité est présentée ci-dessous en respectant les règles de vérification de la figure 8.2 page 158. CAnd CComp A Ctx C [F DS 1380] C SM [v 2] S lib [v 3] S MT A [v = 3]?(C A [v 3, NS 2].S amavis [NS 3] S AV [NS = 4]) Ctx C D 1 D 2 F orbidden(ctx, C P X, []) Ctx C P X : D 1 D 2 A = Ctx P F DS 1380 Available(Ctx, C SM, [v 2]) Available(Ctx, S lib, [v 3]) Ctx P C SM [v 2] Ctx P S lib [v 3] Ctx P [F DS 1380] C SM [v 2] S lib [v 3] F orbidden(ctx, S MT A, [v = 3]) Ctx C [F DS 1380] C SM [v 2] S lib [v 3] S MT A [v = 3] La preuve de l installation Une fois le composant POSTFIX est installable, l installation est réalisée. Cette étape consiste à calculer l effet de l ajout du composant POSTFIX (C P X ) dans le contexte. Cet effet consiste à mettre à jour l ensemble des services disponibles, l ensemble des services interdits, l ensemble des composants interdits et le graphe de dépendance. La dérivation de l installation de D 1 est notée A, le prédicat de cette dépendance est représenté par P.

173 Description de l installation 163 A B IAnd3 IComp Ctx, C P X, 1 I D 1 P 1 s, F 1 s, F 1 c, G 1 Ctx, C P X, 1 I D 2 P 2 s, F 2 s, F 2 c, G 2 Ctx, C P X, 1 I D 1 D 2 P 1 s P 2 s, F 1 s F 2 s, F 1 c F 2 c, G 1 G 2 1 = CalcNum(C P X, Ctx) Ctx C C P X : D 1 D 2 (C P X, 1, P 1 s P 2 s, F 1 s F 2 s, F 1 c F 2 c ), G 1 G 2 8 >< >: Ps 1, Fs 1, Fc 1 = {(S MT A, [v = 3])}, {}, {(C SM, [v 2])} G 1 = {(C 1, 1, lib [v = 3]) M,[],[v 3] (P X, 1, S MT A [v = 3]} Ps 2, Fs 2, Fc 2 = {S AV [NS = 4]}, {}, {} O,[v 3,NS 2],[NS 3] G 2 = {C A [v = 4, NS = 3], 1, S amavis [NS = 3] P X, 1, S AV [NS = 4]} Available(Ctx, S lib, [v 3]) Ctx, C PX, 1, S MT A, [v = 3] G S lib [v 3] G 1 Ctx, C PX, 1, S MT A, [v = 3] G C SM [v 2] Ctx, C PX, 1, S MT A, [v = 3] G [F DS 1380] A =ITriv Ctx, C PX, 1, S MT A, [v = 3] G P G 1 F orbidden(ctx, S MT A, [v = 3]) CalcF (P ) =, {(C SM, [v 2])} Ctx, C PX, 1 I (P S MT A, [v = 3]) {(S MT A, [v = 3])},, {(C SM, [v 2])}, G 1 B=IOpt2 Available(Ctx, S amavis, [NS 3]) Ctx, C PX, 1, S AV, [NS = 4] G S amavis [NS 3] G 2 F orbidden(ctx, S AV, [NS = 4]) CalcF (C A [v 3, NS 2].S amavis [NS 3]) =, Ctx, C PX I (C A [v 3, NS 2].S amavis [NS 3] S AV.[NS = 4]) {(S AV, [NS = 4])},,, G 2 Ctx, C PX I?(C A [v 3, NS 2].S amavis [NS 3] S AV.[NS = 4]) {(S AV, [NS = 4])},,, G 2 Le composant POSTFIX est installé et le contexte est mise à jour. Le graphe de dépendance résultant est l union des graphes G 1 et G 2 décrits ci-dessus. L ensemble des composants du contexte est mis à jour avec le composant (C P X,1,[],P s,f c,f s ) : C = {(C 1, 1, [], (S lib [v = 3]),, ), (C A, 1, [v = 4, NS = 3], (S amavis [NS = 3]),, ), (C P X, 1, [], {(S MT A [v = 3]), (S AV, [NS = 4])}, (S SM [v 2]), )} Supposons qu après l installation du composant POSTFIX, nous voulons installer le composant SENDMAIL. Dans le premier système, nous ne pouvons pas installer SENDMAIL. En revanche, avec l extension du système par les propriétés, nous pouvons installer un composant interdit à condition que la valeur de sa propriété ne satisfait pas sa contrainte dans FC Ṗar exemple, dans notre cas, SENDMAIL est interdit avec la contrainte [v 2], si le composant SENDMAIL possède une version strictement inférieur à 2 (la négation de [v 2]) alors il peut être installé.

174 164 Extension du système par les propriétés Autre exemple Nous présentons l exemple d un composant qui a plusieurs instances d un même servive. Il fournit le service user interface S UI avec différentes valeurs des propriétés langage (lg) et interface fournie (gui). Le langage peut être français ou arabe et l interface peut être graphique ou textuelle. Soit le composant USER-INTERFACE avec la dépendance (D 1 D 2 ) (D 3 D 4 ) : D 1 = [F DS 3800] [langue = F r] S libgraph S UI [lg = F r, gui = graph] D 2 = [F DS 1800] [langue = F r] S libtext S UI [lg = F r, gui = text] D 3 = [F DS 4200] [langue = Ar] S libgraph S UI [lg = Ar, gui = graph] D 4 = [F DS 2100] [langue = Ar] S libtext S UI [lg = Ar, gui = text] Preuve d installabilité La preuve d installabilité du composant USER-INTERFACE est présentée ci-dessous : COrL CComp A Ctx C D 1 D 2 Ctx C (D 1 D 2 ) (D 3 D 4 ) F orbidden(ctx, C UI, []) Nous supposons que la dépendance (D 1 COrL. Ctx C UI : (D 1 D 2 ) (D 3 D 4 ) D 2 ) est vérifiée, on applique donc la règle A = Ctx P F DS 3800 F r = F r Ctx P langue = F r Available(Ctx, S lib, []) Ctx P S libgraph Ctx C [F DS 3800] [langue = F r] S libgraph S UI [lg = F r, gui = graph] Ctx C D 2 Ctx C (D 1 D 2 ) Si les exigences de la dépendance (D 1 D 2 ) ne sont pas vérifiées par exemple, dans le cas d un système d exploitation qui ne possède pas la langue française mais uniquement la langue arabe, la dépendance (D 3 D 4 ) est vérifiée et la règle COrR sera appliquée. Preuve d installation La preuve d installation du composant USER-INTERFACE est présentée ci-dessous : IComp IOrL A Ctx, C UI, 1 I (D 1 D 2 ) P 1 s P 2 s, F 1 s F 2 s, F 1 c F 2 c, G 1 G 2 Ctx, C UI, 1 I (D 1 D 2 ) (D 3 D 4 ) P 1 s P 2 s, F 1 s F 2 s, F 1 c F 2 c, G 1 G 2 1 = CalcNum(C UI, Ctx) Ctx C UI : (D 1 D 2 ) (D 3 D 4 ) C UI, 1, P 1 s P 2 s, F 1 s F 2 s, F 1 c F 2 c, G 1 G 2

175 Description de la désinstallation 165 Ctx P F DS 3800 Ctx P langue = F r Available(Ctx, S libgraph,[]) Ctx, C UI, 1, S UI, [lg = F r, gui = graph] G S libgraph G 1 Ctx, C UI, 1 C D 1 P 1 s, F 1 s, F 1 c, G 1 B A = Ctx C D 2 P 2 s, F 2 s, F 2 c, G 2 Ctx, C UI, 1 C (D 1 D 2 ) P 1 s P 2 s,,, G 1 G 2 B = Ctx P F DS 1800 Ctx P langue = F r Available(Ctx, S libtext, []) Ctx, C UI, 1, S UI, [lg = F r, gui = text] G S libtext G 2 Ctx, C UI, 1 C (P S UI [lg = F r, gui = text]) P 2 s, F 2 s, F 2 c, G 2 Ctx, C UI, 1 C D 2 {(S UI [lg = F r, gui = text]),,, G 2 Le contexte est mis à jour après l installation, l ensemble des services fournis, services interdits, composants interdits ainsi que le graphe résultant sont décrits ci-dessous : Ps 1 = S UI [lg = F r, gui = graph] P s 2 = S UI [lg = F r, gui = text] Fs 1 = Fs 2 = Fc 1 = Fc 2 = M,[],[] G 1 = {S libgraph C UI, 1, S UI [lg = F r, gui = graph]} M,[],[] G 2 = {S libtext C UI, 1, S UI [lg = F r, gui = text]} Nous constatons dans cet exemple que suivant la disponibilité de la langue la mémoire et les librairies dans le système, le composant fournit des services adaptés au contexte du système. 8.3 Description de la désinstallation Comme dans le premier système, la désinstallation est réalisée en deux phases. La première consiste à vérifier la faisabilité de la désinstallation et la deuxième étape consiste à calculer l effet de la désinstallation sur le contexte, c est-à-dire, désinstallation du composant et de tous ses services fournis au niveau du contexte, désinstallation des services optionnels qui en dépendaient et qui ne possèdent pas d exigences dans le graphe La désinstallabilité Le principe de vérification est exactement le même que dans le premier système. La différence réside dans la syntaxe des dépendances et la gestion des identifiants (instances) des composants et des services et pas uniquement les noms des composants et des services. En effet, nous pouvons désinstaller une instance d un composant (c, num) si

176 166 Extension du système par les propriétés aucune de ses instances de services fournis id s n est utilisée obligatoirement par d autres composants. Pour cela, pour chaque instance d un service fourni, il faut s assurer qu elle ne possède aucune dépendance obligatoire avec d autres instances de services. Ainsi, un service peut être désinstallé s il n est pas utilisé obligatoirement mais s il est utilisé directement ou indirectement de façon optionnelle, il faut s assurer que les services qui en dépendent de façon optionnelle directement ou indirectement ne possèdent pas d exigences dans le graphe (cf. la définition 8.11). La principale différence est dans la forme du graphe de dépendances. En effet, les nœuds représentent les identifiants des services et les arcs sont étiquetés par le type de dépendance, les contraintes du composant et du service. Cependant, indépendamment de cette forme, les dépendances obligatoires sont calculées de la même façon car on se base seulement sur le type des dépendances et pas sur les contraintes (cf. la définition 8.10). Définition 8.10 (Dépendance obligatoire (MD)) L ensemble des dépendances obligatoires (MD) d un service s fourni par un composant c dans un graphe de dépendance G est l ensemble des services qui en dépendent directement ou indirectement de façon obligatoire. Il est défini comme suit : MD(G, id s ) = {{id s } MD(G, id s ) id s (M,, ) id s G} Définition 8.11 (Désinstallabilité) Un composant c peut être désinstallé du contexte Ctx ssi tous ses services fournis ne sont pas utilisés obligatoirement par d autres composants, i.e. ces services ne sont pas des dépendances obligatoires pour d autres composants : (c, num, E c, P s,, ) Ctx.C {MD(G, (c, num, s, Es )) (s, E s ) P s } = Check-DI: Ctx D (c, num) La désinstallation L effet d une désinstallation est calculé de la même façon que dans le premier système. La différence réside dans la gestion des identifiants des composants et des services. En effet, nous pouvons désinstaller une instance d un composant avec toutes ses instances de services sans désinstaller les autres instances. L identifiant du composant (c, num) en question avec les instances de ses services fournis (id s ), ses services interdits F s, ses composants interdits F c seront désinstallés du contexte. L ensemble des nœuds qui doivent être supprimés du graphe de dépendance contient tous les identifiants des services fournis par ce composant et tous les identifiants des services optionnels qui en dépendent directement et indirectement et qui ne sont une extrémité finale d un arc du graphe. Le calcul des dépendances optionnelles se fait indépendamment de la forme du graphe car on se base seulement sur le type des dépendances et pas sur les contraintes (cf. la définition 8.12). Une fois que la désinstallation est réalisée, Ctx va être mis à jour en supprimant l identifiant du composant concerné ainsi que l ensemble des identifiants des services qui concernent ses services fournis et tous les services calculés par la règle Effet-DI de la définition 8.13.

177 Description de la mise à jour 167 Définition 8.12 (Dépendances optionnelles (OD)) Un ensemble de dépendances optionnelles (OD) d un service s fourni par un composant c dans un graphe de dépendance G est l ensemble des services qui en dépendent directement ou indirectement de façon optionnelle. Il est défini comme suit : OD(G, id s ) = {{id s } OD(G, id s ) id s (O,, ) id s G} Définition 8.13 (Désinstallation) la désinstallation d un composant c a l effet suivant : Effet-DI: (c, num, E c, P s,, ) Ctx.C Ctx E id c {{(s, E s )} id s n, n (,, ) id s G} (s,e s) P s avec {id s } = OD(Ctx.G, (c, num, s, E s )) La règle Effet-DI est identique à celle présentée dans le premier système avec la différence au niveau de la syntaxe des dépendances. Elle calcule l ensemble des nœuds à désinstaller du graphe G. Le graphe résultant de la désinstallation est calculé comme suit : x x n2 G n 1 / N n 2 / N} avec N est l ensemble des nœuds G \ N = {n 1 n2 n 1 calculés par la règle Effet-DI (Ctx E c N). Le même principe de désinstallation s applique donc dans le cas des propriétés. La différence est que l on peut avoir plusieurs composants qui ont le même nom mais avec des identifiants différents selon leurs propriétés. 8.4 Description de la mise à jour Pour décider si un composant C old peut être remplacé par un composant C new, il faut s assurer que les services qui sont fournis par C new avec leurs propriétés vérifient toujours les contraintes exigées par les autres composants qui les utilisent. La principale différence est donc dans la vérification de la satisfiabilité des contraintes exigées par les propriétés fournies Algorithme de substitution Le principe de l algorithme de substitution est le même que celui présenté dans le chapitre 7 page 142 mais la vérification des services fournis ne porte pas seulement sur les services mais sur leur propriétés en respectant les contraintes exigées sur ces propriétés par les composants déjà installés. Cette section se base sur plusieurs définitions décrites dans le chapitre 7. Définition 8.14 Substituabilité contextuelle Un composant C old est substituable par un composant C new dans un contexte Ctx ssi : C new est installable dans Ctx.C \ C old ;

178 168 Extension du système par les propriétés Calcul de Ctx = Ctx.C \ c old oui C new est installable dans Ctx? non Calcul de C new.p s C old.p s C new est compatible avec C old non oui oui NON no C old pas substituable C old est substituable Fig. 8.5 Les phases de substituabilité avec vérification des propriétés tous les services fournis par C old et utilisés obligatoirement sont fournis par C new. Toutes les propriétés de ces services fournis par C new sont vérifiées par les contraintes imposées par les autres composants qui les utilisent. tous les services fournis par C old et qui ne sont pas fournis par C new ne doivent pas être utilisés obligatoirement dans le contexte (la condition NON) : {(MD(G, Cold.s) s (C old.p s \ C new.p s )} = La substitution est vérifiée suivant le diagramme de la figure 8.5. L installabilité de C new est vérifiée par les règles présentées dans la figure 8.2 page 158. L ensemble des services fournis P s par chaque composant est un ensemble de couples représentant les services et l ensemble de leurs propriétés (s, E c ). Il faut vérifier la compatibilité de C new et C old, c est-à-dire, s assurer de deux points : (1) tous les services fournis par C old et qui sont des dépendances obligatoires pour d autres composants déjà installés sont fournis par C new, (2) s assurer que les contraintes exigées par d autres composants sur les propriétés des mêmes services fournis par C new sont vérifiées. Une différence avec l algorithme de substitution présenté dans la page 142 est que la comparaison ne se fait pas uniquement sur les services mais également sur les services avec toutes leurs propriétés. Par ailleurs, il faut maintenir la validité des contraintes des autres composants qui été satisfaites par les services fournis de l ancien composant Exemple Soit l exemple de la figure 8.6 qui représente un lecteur multimédia en ligne pouvant être utilisé sous un navigateur web. Les dépendances de chaque composant qui constitue

179 Conclusion 169 libmp mplayer[v = 3] libgnome[v 1] MPLAYER libmoz Linux libgnome[v = 3] OnlineMP lib[v 2] GNOME mplayer[v 3] MOZILLA Fig. 8.6 Exemple d un lecteur multimédia ce lecteur sont représentées ci-dessous : D GNOME = [OS = Linux] S lib [v 2] S libgnome [v = 3] D MP LAY ER = C GNOME.S libgnome [v 2] S libmp S mplayer [v = 3] D MOZILLA = S libmoz S mplayer [v 3] S OnlineMP Pour pouvoir regarder la chaîne BBC en ligne, nous devons remplacer MPLAYER par REALPLAYER qui est plus performant en terme de streaming. Nous Supposons que la dépendance de REALPLAYER est la suivante : D REALP LAY ER = S libgnome S LibRP mplayer [v = 3] Suivant le diagramme de la figure 8.5, l installabilité du composant REALPLAYER doit être vérifiée, par la suite, il faut vérifier la compatibilité de REALPLAYER avec MPLAYER. En effet, il faut s assurer que la contrainte S mplayer [v 3] imposée par le composant MOZILLA est vérifiée par la propriété du service S mplayer fourni par REALPLAYER. v 3 v = 3 est vrai, les deux composants sont compatibles, MPLAYER est donc substituable par REALPLAYER. 8.5 Conclusion Dans ce chapitre, nous avons présenté une extension de la description du déploiement présentée dans le chapitre 5, le chapitre 6 et le chapitre 7. Cette extension concerne l ajout de la description des propriétés non-fonctionnelles des composants et des services au niveau des services fournis, et des contraintes sur ces propriétés au niveau des exigences. L intérêt majeur de cette extension et de ne pas se limiter aux noms des composants et des services mais de gérer des instances de composants et de services. Un composant ou un service peut avoir plusieurs instances selon ses propriétés. Il est donc primordial d identifier les composants et les services pour les différencier. Par conséquent, les règles d installation de désinstallation et de mise à jour sont étendues.

180 170 Extension du système par les propriétés

181 Troisième partie Mise en œuvre et validation 171

182

183 Chapitre 9 Mise en œuvre de l architecture de déploiement Sommaire 8.1 Description des propriétés Description des dépendances Description du contexte Description de l installation L installabilité L installation Deux exemples d installation Description de la désinstallation La désinstallabilité La désinstallation Description de la mise à jour Algorithme de substitution Exemple Conclusion Nous avons présenté dans la partie précédente l ensemble de nos contributions pour la gestion des dépendances de déploiement. Dans ce chapitre, nous présentons la mise en œuvre de notre architecture de déploiement en Fractal et la mise en œuvre du moteur de raisonnement formel en Ocaml. Enfin, nous présentons la mise en pratique du moteur de raisonnement formel pour la vérification du déploiement des bundles dans OSGi sur un ensemble de nœuds répartis. 9.1 Présentation de l architecture de déploiement Nous commençons par la description de l architecture de déploiement qui est représentée dans la figure 9.1. Elle est divisée en deux parties : la partie du monde réel et la 173

184 174 Mise en œuvre de l architecture de déploiement Monde réel Monde formel Politiques Description de politique Moteur de politiques Ressources Contexte +propriétés Description du contexte Composant +propriétés Dépendances Mécanismes Moteur de déploiement Actions Moteur de raisonnement Règles de déploiement Legende : Données abstraites Données concrètes Traitement Flot de données Fig. 9.1 Monde réel vs monde formel partie du monde formel. Nos travaux dans le cadre de cette architecture concernent le monde formel. Dans la partie du monde réel, nous avons les quatre concepts définis dans la section 4.3 page 92. Nous retrouvons donc des ressources (l environnement du déploiement et le composant ou l application à déployer), des mécanismes (le moteur de déploiement) des politiques de déploiement et des propriétés. Dans le monde formel, nous manipulons les descriptions abstraites des ressources présentées dans le chapitre 5 page 103. Le moteur de raisonnement représente le cœur de notre travail, il utilise des règles pour vérifier les dépendances du composant par rapport à son contexte. Le processus de raisonnement se base donc sur : La description de dépendance avec les propriétés de l entité en utilisant un formalisme logique. La description du contexte avec ces propriétés sous une forme ensembliste avec un graphe de dépendance. Le raisonnement sous la forme de règles de déduction qui permettent (1) de déterminer si l on peut déployer l entité et (2) de calculer l impact de son déploiement sur le contexte.

185 Présentation de l architecture de déploiement 175 User DE RE PC PCtx CA request request get() get() Abstract context Abstract context get() Dependency reasoning DE: Deployment Engine PC: Physical Component PCtx: Physical Context RE: Reasoning Engine CA: Context Analyser Cas 1 : Déploiement impossible User DE RE PC PCtx CA error error Cas 2 : Déploiement concret impossible User DE RE PC PCtx CA possible deploying not possible not possible Cas 3 : Déploiement possible User DE RE PC PCtx CA possible possible update update Abstract context Fig. 9.2 Diagramme de séquence du déploiement

186 176 Mise en œuvre de l architecture de déploiement Les détails sur ces descriptions et ces règles logiques sont présentées dans le chapitre 5 page 103 et le chapitre 6 page 119. Les règles de déploiement peuvent être dirigées par des politiques qui sont gérées par un moteur de politique. Ce dernier va interpréter la dépendance et/ou le contexte suivant la politique utilisée, il va ensuite fournir la nouvelle valeur du contexte et/ou la nouvelle valeur de la dépendance au moteur de raisonnement pour effectuer la vérification du déploiement. Cependant, nous n avons pas encore intégré les politiques dans le raisonnement. Un certain nombre d actions abstraites vont être générées par le moteur de raisonnement, ensuite interprétées dans le monde réel par un ensemble de mécanismes pour être exécutées par le moteur de déploiement. Ces mécanismes vont effectuer des changements au niveau du contexte physique donc la description abstraite du contexte va être également mise à jour par ces nouveaux changements. Nous avons pour l instant ignoré les passages (nécessaires) entre le monde réel et le monde formel. La figure 9.2 représente les diagrammes de séquence décrivant les différents déroulements possibles de l étape d installation effectuée par le moteur de raisonnement. Le cas 1 représente le cas où le déploiement n est pas possible à cause des dépendances non résolues. Dans le cas où les dépendances sont résolues, le moteur de raisonnement calcule l effet du déploiement sur le contexte. Le moteur de raisonnement calcule l effet en générant un ensemble d actions abstraites qui seront interprétées par le moteur de déploiement du monde réel en tant que mécanismes réalisant le déploiement effectif (de bas niveau). Si le déploiement ne s est pas terminé avec succès (un problème matériel par exemple), le déploiement s arrête et le contexte ne sera pas mis à jour (cas 2). Une fois que le déploiement se termine avec succès le contexte physique est mis à jour par le moteur de déploiement et c est à ce moment que le contexte abstrait sera aussi mis à jour (cas 3). 9.2 Mise en œuvre de l architecture de déploiement L un des objectifs de la mise en œuvre de l architecture du déploiement est d avoir une architecture de déploiement flexible que nous pouvons changer selon nos besoins et nos préoccupations. Pour cela, nous avons choisi le modèle de composant Fractal pour mettre en œuvre notre architecture. Le modèle Fractal est un modèle de composant développé par France Telecom R &D dans le cadre du consortium ObjectWeb [BCS03]. Parmi les avantages de ce modèle, nous pouvons citer : Il est générique et pas spécifique à un domaine d application particulier. Son modèle abstrait simple et récursif fait qu il est facile à utiliser. De plus, il offre plusieurs outils permettant le passage de la conception à la réalisation. Il permet de réaliser des reconfigurations de l architecture pendant l exécution de l application. L intérêt de réaliser l architecture de déploiement en Fractal est de pouvoir la reconfigurer. En effet, nous pouvons modifier les composants de l architecture, en rajoutant des fonctionnalités ou en supprimant des composants selon les contraintes et les besoins du déploiement.

187 Mise en œuvre de l architecture de déploiement 177 Fig. 9.3 Architecture du déploiement en Fractal La programmation des composants Fractal peut se faire en deux étapes : définition et création des interfaces, puis implantation de ces interfaces dans les classes des composants. La définition des composants et de leurs dépendances peut être réalisée graphiquement, à l aide de l outil FractalGUI. L architecture présentée dans la figure 9.3 est réalisée en FractalGUI, elle représente l interconnexion de quelques composants déjà présentés dans l architecture de la figure 9.1 page 174. Ces composants communiquent entre eux en s envoyant des messages par le biais d interfaces de communication de type Client/Serveur. Chaque composant est constitué de deux parties : un contrôleur (membrane) et son contenu. Le composant ArchDeploy est un composant composite composé de plusieurs composants primitifs, il représente la membrane. Les différents composants de l architecture sont décrits ci-dessous : SysDep : le système de déploiement fournit l emplacement du paquet compressé au composant Extract. Extract : décompresse le paquet et fournit le fichier qui contient le descripteur de dépendances du composant à déployer fichier.desc au composant Traducteur MotDep : le moteur de déploiement est chargé du déploiement physique du logiciel,

188 178 Mise en œuvre de l architecture de déploiement il renvoie les résultats au Contexte pour la mise à jour du contexte. Traducteur : utilise le fichier de description des dépendances du paquet pour fournir au moteur de raisonnement MotRaiFormel une description dans le langage logique de notre système formel. Contexte : fournit le contexte de l environnement du déploiement. Il est représenté dans un fichier XML. ContexteAna : gestionnaire du contexte qui récupère les informations pertinentes fournies par le composant Contexte et les fournit au MotRaiFormel. MotRaiFormel : le moteur de raisonnement est un composant composite, il analyse la description des dépendances du composant à déployer et la description du contexte. La dépendance est fournie par le composant Traducteur et la description du contexte de l environnement est fournie par le composant Contexte. En fonction de l opération de déploiement le MotRaiFormel prend la décision sur la possibilité de déployer. Toute la vérification est réalisée par des appels à des fonctions du prototype OCaml qui réalise le moteur de raisonnement qui sera détaillé dans la section suivante. Il est composé de deux composants : CheckDeploy : ce composant permet de vérifier la faisabilité de l opération de déploiement. CMaj : permet de calculer l effet de déploiement et mettre à jour le contexte une fois que le déploiement est possible. 9.3 Mise en œuvre du moteur de déploiement La partie la plus importante dans la mise en œuve est le moteur de déploiement qui permet de vérifier et de démontrer les opérations d installation, de désinstallation et de remplacement. Ce moteur est réalisé en OCaml est décrit en détail par la suite. Des scénarios illustratifs sont présentés avec leurs preuves dans la section page Architecture du moteur de déploiement La description de l architecture détaillée du moteur de raisonnement est représentée dans la figure 9.4, elle est implanté en OCaml. Le choix de ce langage est basé sur son aspect fonctionnel, sûr et performant. Sa sûreté est due à son typage fort qui permet une manipulation aisée de structures de données complexes sans se préoccuper de la manipulation explicite de la mémoire. Sa performance est due à la présence d un compilateur natif. De plus, il permet de faire des preuves formelles puisque son aspect fonctionnel lui permet d être intégrer dans des assistants de preuve comme Coq [CDT01] par exemple. Les principaux composants de l architecture su moteur de raisonnement sont deux compilateurs de deux langages proposés, un traducteur d un langage vers un autre, un moteur de raisonnement qui contient un gestionnaire des dépendances, le gestionnaire du contexte et les composants responsables de la vérification et la réalisation de l installation, la désinstallation et la mise à jour. Le premier compilateur compile un

189 Mise en œuvre du moteur de déploiement 179 Compilateur 1 fichier.desc Lexer1 Parser1 Compilateur 2 Traducteur Lexer2 Parser2 Descripteur du contexte Moteur de raisonnement Gestionnaire des dépendances Mise à jour Désinstallation Installation Gestionnaire du contexte Affichage de la preuve Décision Fig. 9.4 Architecture du prototype du moteur de raisonnement en OCaml fichier.desc qui représente la description de la dépendance d un composant donné dans un langage intermédiaire Compilateurs/Traducteur Dans cette partie nous décrivons les compilateurs de deux langages. Le premier langage est un langage intermédiaire qui est utilisable par les producteurs de composants, il est réalisé au sein de notre équipe [Gue06]. Il vise à faciliter l écriture des dépendances qui peuvent être assez complexes dans la syntaxe formelle. Ce langage s inspire d une part des langages de description existants et d autre part de notre langage de dépendance. Le second langage, est celui des dépendances présenté dans le chapitre 5 page 103. Un exemple de description d un serveur de messagerie POSTFIX avec le langage

190 180 Mise en œuvre de l architecture de déploiement intermédiaire est présenté ci-dessous : package POSTFIX { service mta { requires free_space=1380 & lib_post &!mta } optional service antivirus_mta { requires amavis } } Cette description exprime les dépendances de POSTFIX qui sont : des dépendances obligatoires (free_space, lib_post, et ne pas avoir le service mta) pour fournir le service mta (Mail Transport Agent). des dépendances optionnelles (amavis) pour fournir l anti-virus antivirus_mta. Ce langage sera traduit par un traducteur dans notre langage comme suit : (([FDS>=1380]/\ Libpost/\!mta => mta).?(amavis =>antivirus_mta)) Par la suite, le code généré de la description de dépendance va être géré par le moteur de déploiement Moteur de déploiement Le moteur de déploiement traite les opérations d installation, de désinstallation et de mise à jour en se basant sur la description des dépendances et la description du contexte du site cible avec le graphe de dépendance. Une fois que le fichier.desc est compilé, il sera traduit dans le langage de dépendances dont la grammaire est présentée dans le chapitre 5 page 107. Elle est implantée comme suit : type a t = Tsimple of a Tcomplex of Constructor.t * a t list let conjonction dt1 dt2 = Tcomplex(Hconjonction,[dt1;dt2]) let disjonction dt1 dt2 = Tcomplex(Hdisjonction,[dt1;dt2]) let optional dt = Tcomplex(Hoptional,[dt]) let simple p s = Tsimple(p,Service.make s) La grammaire des exigences (prédicats) qui concerne le cas de chaque dépendance simple est implanté comme suit : type raw = Comparison of string * Comparator.t * Value.t

191 Mise en œuvre du moteur de déploiement 181 RequiredServiceAny of Service.t RequiredService of Component.t * Service.t ForbiddenService of Service.t ForbiddenComponent of Component.t type t = True And of (raw list) list Gestionnaire du contexte Le type du contexte cible décrit dans la section 5.3 page 114 est implanté comme suit : type a t = { env : a Env.t; ccl : compconstraints list; dep : Graphdep.t; } type compconstraints = { name : Component.t; ps : ServiceSet.t; fs : ServiceSet.t; fc : ComponentSet.t; } Le type du graphe de dépendance Graphdep est défini comme suit : type kind = M O type node = Component.t * Service.t type t = { nodes : node list; vertices : (node * node * kind) list; } Le moteur de raisonnement a besoin de la description de la dépendance traduite dans notre langage de dépendance et de la description du contexte pour vérifier l installation et la mise à jour. Pour la désinstallation il a juste besoin du contexte qui contient le graphe de dépendances.

192 182 Mise en œuvre de l architecture de déploiement Gestionnaire de dépendances Le gestionnaire de dépendances permet de gérer la description des dépendances et d évaluer son prédicat par rapport à la description du contexte. Pour chaque opération, l analyseur de dépendance, analyse l ensemble des dépendances du composant avec le contexte existant. Par exemple, au niveau de l installabilité, la vérification des exigences est réalisée comme suit : let evaluate ctx p = let evaluateraw = function Comparison(var,c,v) -> Comparator.evaluate c (Context.valueOf var ctx) v RequiredServiceAny s -> Context.isUsableService s ctx RequiredService (c,s)-> Context.isProvidedService c s ctx ForbiddenService s -> not(context.isforbiddenservice s ctx) ForbiddenComponent c -> not(context.isforbiddencomponent c ctx) in let evaluateor = function [] -> failwith "Interdit : Or([])" l -> List.exists evaluateraw l in match p with True -> true And [] -> failwith "Interdit : And([])" And l -> List.for_all evaluateor l Affichage de la preuve de déploiement Cette partie permet d avoir la preuve du déploiement avec l ensemble des règles de déduction et le contexte résultant dans un fichier LATEX Décision Ce composant représente le résultat de la vérification de la faisabilité du déploiement, c est-à-dire, l installabilité, la désinstallabilité et la substituabilité. En se basant sur cette décision, le moteur de raisonnement calculera l effet du déploiement sur le contexte et le gestionnaire de contexte mettra à jour le contexte Quelques exemples d illustration Dans cette partie, nous illustrons quelques exemples d installation de désinstallation et de mise à jour qui sont déjà traités dans la partie vérification formelle du rapport (les chapitres 5, 6 et 7). Dans le cas d installation, la commande utilisée contient l option -i suivi du nom du composant et le chemin de son fichier de description. Dans le cas de la désinstallation, la commande utilisée contient l option -d suivie du nom du composant à désinstaller. Dans le cas de la substitution, l option -s est utilisée suivie du nom du

193 Mise en œuvre du moteur de déploiement 183 composant qu on veut remplacer (substitué) suivie du nom du substituant et enfin le chemin de son fichier de description Exemple d installation Supposons que nous commençons par l installation d un composant LIBRARIES qui fournit des librairies nécessaires à l installation de beaucoup de composants. La description de la dépendance du composant LIBRARIES est fourni dans un fichier. Le description est la suivante : package C_LibPostfix { service S_Libpost { } & service S_Libfetch { } & service S_Libsend { } & service S_Libthund { } & service S_Libice { } } Ce fichier est compilé et traduit dans le langage de dépendance. Dans cette description, le composant LIBRARIES ne possède aucune exigence. La description de sa dépendance est : (D 1 D 2 D 3 D 4 D 5 ) avec : D 1 = true S Libpost D 2 = true S Libfetch D 3 = true S Libsend D 4 = true S Libthund D 5 = true S Libice Pour effectuer l installation, il faut utiliser l option -i et fournir le nom du composant à installer et le chemin de son fichier de description : Entrer le nom du composant à installer LIBRARIES Entrer le chemin de son fichier de description Examples/Libraries processing file... parsing ( ( (true => S_Libpost). (true => S_Libfetch)). (true => S_Libsend)) The component LIBRARIES can be installed Le fichier de description a été compilé et traduit dans le langage de dépendance dans un fichier depend (cf. expression ci-dessus). Une fois que l installation est possible, la preuve est enregistrée dans un fichier result.tex. Supposant que nous voulons installer le serveur mail POSTFIX, le résultat de l installation est le suivant :

194 184 Mise en œuvre de l architecture de déploiement Entrer le nom du composant à installer POSTFIX Entrer le chemin de son fichier de description Examples/postfix processing file... parsing ( ( [dsk>=1380] /\ S_Libpost /\! S_mta => S_mta).? ( S_amavis => S_antivirus_mta)) The component POSTFIX can be installed La preuve de l installation est dans le fichier result.tex. Après compilation de ce dernier, on obtient la description affichée dans la page suivante. Pour des raisons de clarté, les composants sont affichés en majuscule et en bleu et les services sont affichés en minuscule et en vert (COMPOSANT.service).

195 Mise en œuvre du moteur de déploiement 185 Component POSTFIX: context before: Installability proof: ctx d = {(dsk, )(ram, 128)(os, linux)} [(LIBRARIES, {S Libfetch, S Libice, S Libpost, S Libsend, S Libthund}, {}, {})] {{}, {}} ctx [dsk 1380] S Libpost S mta S mta / F S ctx ([dsk 1380] S Libpost S mta S mta) ctx?(s amavis S antivirus mta) ctx ([dsk 1380] S Libpost S mta S mta)?(s amavis S antivirus mta) P OST F IX / F C ctx P OST F IX : ([dsk 1380] S Libpost S mta S mta)?(s amavis S antivirus mta) Installation proof: ctx [dsk 1380] S Libpost S mta S mta / F S ctx, P OST F IX ([dsk 1380] S Libpost S mta S mta) {S mta}, {S mta}, {}, {{LIBRARIES.S Libpost, P OST F IX.S mta}, {LIBRARIES.S Libpost M POSTFIX.S mta}} ctx S amavis ctx, P OST F IX (S amavis S antivirus mta) ctx, P OST F IX?(S amavis S antivirus mta) {}, {}, {}, {{}, {}} ctx, P OST F IX ([dsk 1380] S Libpost S mta S mta)?(s amavis S antivirus mta) {S mta}, {S mta}, {}, {{LIBRARIES.S Libpost, P OST F IX.S mta}, {LIBRARIES.S Libpost M POSTFIX.S mta}} ctx P OST F IX : ([dsk 1380] S Libpost S mta S mta)?(s amavis S antivirus mta) {S mta}, {S mta}, {}, {{LIBRARIES.S Libpost, P OST F IX.S mta}, {LIBRARIES.S Libpost M POSTFIX.S mta}} context after: ctx d = {(dsk, )(ram, 128)(os, linux)} [(P OST F IX, {S mta}, {S mta}, {}); (LIBRARIES, {S Libfetch, S Libice, S Libpost, S Libsend, S Libthund}, {}, {})] {{P OST F IX.S mta, LIBRARIES.S Libpost}, {LIBRARIES.S Libpost M POSTFIX.S mta}} Fig. 9.5 La preuve de l installation de POSTFIX

196 186 Mise en œuvre de l architecture de déploiement Maintenant, pour tester un cas d échec de l installation, nous allons installer le composant SENDMAIL qui fourni le service mta interdit par POSTFIX. Le résultat de l installation est le suivant : Choisissez une autre option : -i, -d, -s, -q, taper -h pour l aide -i Entrer le nom du composant à installer SENDMAIL Entrer le chemin de son fichier de description Examples/sendmail processing file... parsing (([dsk>=1050] /\ S_Libsend /\! S_mta => S_mta).? ( S_amavis => S_antivirus_mta)) The component SENDMAIL cannot be installed Si l on vérifie le résultat après compilation du fichier result.tex, nous allons constater que l échec était au niveau des règles d installabilité après avoir vérifié que le service fourni par le composant SENDMAIL été interdit par le composant POSTFIX Exemple de désinstallation Choisissez une autre option : -i, -d, -s, -q, taper -h pour l aide -d Entrer le nom du composant à désinstaller POSTFIX The component POSTFIX can be deinstalled

197 Mise en œuvre du moteur de déploiement 187 Deinstallation Component POSTFIX: context before: context after: ctx d = {(dsk, )(ram, 128)(os, linux)} [(P OST F IX, {S mta}, {S mta}, {}); (LIBRARIES, {S Libfetch, S Libice, S Libpost, S Libsend, S Libthund}, {}, {})] {{P OST F IX.S mta, LIBRARIES.S Libpost}, {LIBRARIES.S Libpost M P OST F IX.S mta}} ctx d = {(dsk, )(ram, 128)(os, linux)} [(LIBRARIES, {S Libfetch, S Libice, S Libpost, S Libsend, S Libthund}, {}, {})] {{LIBRARIES.S Libpost}, {}} Fig. 9.6 La preuve de la désinstallation de POSTFIX

198 188 Mise en œuvre de l architecture de déploiement Exemple de mise à jour Le principe de la mise à jour est de vérifier que le substituant est toujours installable mais avant de vérifier l installabilité, il faut s assurer que l ensemble des services fournis par le substitué est un sous ensemble de l ensemble des services fournis par le substituant. Dans le cas contraire, c est-à-dire le substituant fournis moins, il faut s assurer que les services manquants ne sont pas utilisés dans le contexte par d autres composants. Supposant que nous voulons substituer le composant THUNDERBIRD par le composant ICEDOVE. L installation de THUNDERBIRD et sa substitution sont effectuées comme suit : Choisissez une autre option : -i, -d, -s, -q, taper -h pour l aide -i Entrer le nom du composant à installer THUNDERBIRD Entrer le chemin de son fichier de description Examples/thunderbird processing file... parsing (([dsk>=1550] /\ S_Libthund => S_mua).?( S_dict => S_spell)) The component THUNDERBIRD can be installed Choisissez une autre option : -i, -d, -s, -q, taper -h pour l aide -s Entrer le nom du composant à remplacer THUNDERBIRD Entrer le nom du nouveau composant ICEDOVE Entrer le chemin de son fichier de description Examples/icedove processing file... parsing ( ( [dsk>=1550] /\ S_Libice => S_mua).? ( S_dict => S_spell)) The component ICEDOVE can be installed The component THUNDERBIRD can be substituted by the component ICEDOVE Le résultat de la preuve de cette substitution est fourni dans le fichier result.tex qui est représenté dans la figure 9.7.

199 Mise en œuvre du moteur de déploiement 189 Deinstallation Component THUNDERBIRD: context before: context after: ctx d = Component ICEDOVE: context before: Installability proof: {(dsk, )(ram, 128)(os, linux)} [(T HUNDERBIRD, {S mua}, {}, {}); (LIBRARIES, {S Libfetch, S Libice, S Libpost, S Libsend, S Libthund}, {}, {})] {{T HUNDERBIRD.S mua, LIBRARIES.S Libthund}, {LIBRARIES.S Libthund M THUNDERBIRD.S mua}} ctx d = ctx d = {(dsk, )(ram, 128)(os, linux)} [(LIBRARIES, {S Libfetch, S Libice, S Libpost, S Libsend, S Libthund}, {}, {})] {{LIBRARIES.S Libthund}, {}} {(dsk, )(ram, 128)(os, linux)} [(LIBRARIES, {S Libfetch, S Libice, S Libpost, S Libsend, S Libthund}, {}, {})] {{LIBRARIES.S Libthund}, {}} ctx [dsk 1550] S Libice S mua / F S ctx ([dsk 1550] S Libice S mua) ctx?(s dict S spell) ctx ([dsk 1550] S Libice S mua)?(s dict S spell) ICEDOV E / F C ctx ICEDOV E : ([dsk 1550] S Libice S mua)?(s dict S spell) Installation proof: ctx [dsk 1550] S Libice S mua / F S ctx, ICEDOV E ([dsk 1550] S Libice S mua) {S mua}, {}, {}, {{LIBRARIES.S Libice, ICEDOV E.S mua}, {LIBRARIES.S Libice M ICEDOV E.S mua}} ctx S dict ctx, ICEDOV E (S dict S spell) ctx, ICEDOV E?(S dict S spell) {}, {}, {}, {{}, {}} ctx, ICEDOV E ([dsk 1550] S Libice S mua)?(s dict S spell) {S mua}, {}, {}, {{LIBRARIES.S Libice, ICEDOV E.S mua}, {LIBRARIES.S Libice M ICEDOV E.S mua}} ctx ICEDOV E : ([dsk 1550] S Libice S mua)?(s dict S spell) {S mua}, {}, {}, {{LIBRARIES.S Libice, ICEDOV E.S mua}, {LIBRARIES.S Libice M ICEDOV E.S mua}} context after: ctx d = {(dsk, )(ram, 128)(os, linux)} [(ICEDOV E, {S mua}, {}, {}); (LIBRARIES, {S Libfetch, S Libice, S Libpost, S Libsend, S Libthund}, {}, {})] {{ICEDOV E.S mua, LIBRARIES.S Libice, LIBRARIES.S Libthund}, {LIBRARIES.S Libice M ICEDOV E.S mua}} Fig. 9.7 la preuve de la substitution de THUNDERBIRD par ICEDOVE

200 190 Mise en œuvre de l architecture de déploiement 9.4 Intégration du moteur de raisonnement dans OSGi Dans cette partie, nous allons présenter la mise en pratique du moteur de raisonnement décrit précédement dans OSGi pour la vérification du déploiement des bundles sur des nœuds répartis. ce travail est réalisé au sein de l équipe dans le cadre du déploiement des applications distribuées basées sur les services au sein d OSGi [Van07] Architecture de déploiement répartie La figure 9.8 décrit l architecture de déploiement des composants répartis en se basant sur l OSGi (présenté dans le chapitre 1). Nœud 1 : une JVM exécutant OSGi Nœud 2 Agent Local Agent Distant XMLRPC AD AL JNI gestion OSGi DM Dependancy Manager en Caml Composants Fig. 9.8 Architecture de déploiement réparti Cette architecture se compose des nœuds répartis. Chaque nœud contient deux agents : un agent local qui prend en charge le déploiement centralisé, effectué sur des bundles locaux. Un agent distant est utilisé pour la transmission les commandes, qui sont définies dans un langage de déploiement entre les nœuds. Lors de la réception d une commande, l agent distant active l agent local pour le déploiement des bundles qui sont récupérés d un dépôt distant. Le module de gestion des dépendances permet de vérifier les dépendances d un composant en se basant sur le prototype Ocaml décrit dans la section 9.3. Le déploiement est effectué après la vérification des dépendances. Les bundles sont décrits en XML, leurs descriptions se trouvent dans un dépôt. Nous utilisons la syntaxe du descripteur du service Repository d Oscar [Obj05a, Obj05b]. Le déploiement dans le système est décrit par l algorithme suivant (cf. la figure 9.9) : 1. Le nœud N 1, qui active le processus, envoie un message de négociation vers les nœuds N i, 2. Chaque nœud N i, après avoir reçu le message de négociation, vérifie le contexte et ses contraintes ; 3. Chaque nœud N i, après avoir vérifier ses contraintes répond au N 1 s il peut être un candidat ; 4. N 1 collecte les réponses des nœuds candidats ; 5. N 1 déploie les bundles sur les nœuds candidats.

201 Node1:Node. Intégration du moteur raisonnement dans OSGi 191 3:ok? 1:deployable? Node2:Node 2 :verify Noden:Node 3:ok? 1:deployable? 2:verify 4:colectcandidates 5:deploy 5:deploy Fig. 9.9 La négociation et le déploiement Langage de déploiement Le prototype gère un langage de déploiement au dessus de OSGi représenté par un ensemble de commandes. Les principales commandes effectuées sur les bundles sont : Installation : deploy install <option> <host> <bundle-name>[ ;<bundle-version>] Mise à jour : deploy update <option> <host> <bundle-name>[ ;<bundle-version>] Désinstallation : deploy uninstall <option> <host> <bundle-name>[ ;<bundle-version>] Démarrage du bundle : deploy start <option> <host> <bundle-name>[ ;<bundle-version>] Arrêt du bundle : deploy stop <option> <host> <bundle-name>[ ;<bundle-version>] Avec <option> : -host <host> : est l adresse du nœud sur lequel les bundles sont déployés -node <host> : l identité du nœud sur lequel les bundles sont déployés -any <number> : nombre de nœuds sur lesquels les bundles sont déployés -all <host> : le déploiement sera effectué si le composant peut être déployé sur tous les nœuds -can <host> : le déploiement sera effectué sur tous les nœuds auxquels le composant peut être déployé.

202 192 Mise en œuvre de l architecture de déploiement La gestion du déploiement Le composant qui réalise de déploiement se base sur le bundle OBR d Oscar [Obj05b]. Il est étendu par le gestionnaire des dépendances qui est décrit précédemment dans le prototype Ocaml et qui est intégré grâce à l interface JNI [Sun03] et l interface C-Ocaml. Le module de gestion des dépendances récupère et analyse une expression logique de la dépendance qui décrit les services requis et les services fournis du bundle. Pour cela, nous avons étendu le fichier manifest du bundle déployé par l en-tête Require-Service. Un exemple de fichier manifest d un bundle est présenté ci-dessous : Manifest-Version : 1.0 Bundle-Name : Deployment manager Bundle-Activator : sauna.deployment.bundle.activator Bundle-Version : Bundle-NativeCode : libdeploy.so ; osname=linux ; processor=x86 Import-Package : org.apache.xmlrpc,com.softsell.open.osgi.xmlrpc Import-Service : com.softsell.open.osgi.xmlrpc.xmlrpcservice Export-Service : org.osgi.service.http.httpservice Export-Package : org.osgi.service.http ; specification-version=1.1 Bundle-Classpath :., kxml.jar, jdom.jar Require-Service : http / shell -> deployment L expression Require-Service indique que ce bundle requiert le service HTTP et le service Shell et fournit le service deployment Interface graphique Une interface de type console (shell) qui hérite du service OSGi Shell Service ainsi qu une interface graphique (cf. figure 9.10) sont construites. Elles permettent de gérer le système et de déployer les bundles de manière visuelle. 9.5 Conclusion Dans ce chapitre, nous avons présenté la mise en œuvre de notre architecture de déploiement en Fractal, la mise en œuvre du moteur de raisonnement en OCaml et la mise en pratique de ce moteur de raisonnement dans une plate-forme de déploiement répartie au dessus d OSGi pour la verification du déploiement des bundles. L architecture du déploiement que nous avons proposée est réalisée en Fractal pour pouvoir être étendue et modifiée plus facilement en cas de besoin. Un prototype OCaml du moteur de déploiement à été réalisé, il représente le coeur de notre architecture de déploiement. Il contient deux compilateurs de deux langages de description que nous avons proposé, un gestionnaire de dépendance de composants, un gestionnaire du contexte cible, un moteur de raisonnement formel pour la démonstration de la faisabilité et la cohérence du système pour les opérations d installation, de désinstallation

203 Conclusion 193 Fig Interface graphique du prototype du déploiement réparti