Académique Documents
Professionnel Documents
Culture Documents
1
1. Introduction
Les systèmes logiciels sont devenus de plus en plus complexes avec l’intégration
de composants hétérogènes et distribués sur un réseau d’ordinateurs. Un nouveau
défi est mis sur l’automatisation du déploiement de tels systèmes en offrant toutes
les conditions d’un déploiement cohérent. Par cohérence, nous sous-entendons
d’une part le fonctionnement et d’autre part l’intégrité des sites sur lesquels les
systèmes logiciels sont déployés. Pour assurer un déploiement cohérent, plusieurs
aspects doivent être pris en compte. Ces aspects constituent ce que nous appelons
par la suite le système d’information de déploiement. La section 2 décrit le cycle de
vie du déploiement durant lequel ce système d’information est utilisé. La section 3
présente plus en détails le système d’information de déploiement. Notre
environnement de déploiement ORYA (Open enviRonment to deploY Applications)
est décrit dans la section 4, puis évalué à l’aide d’une expérimentation industrielle
dans le paragraphe suivant. Cet environnement permet d’offrir des fonctionnalités
d’automatisation des activités du cycle de vie du déploiement. Enfin, avant de
conclure, la section 6 situe notre travail par rapport à quelques travaux industriels et
académiques sur le déploiement.
2
Certaines activités ont lieu après le déploiement d'une nouvelle version du
logiciel, comme la mise à jour et la reconfiguration. La mise à jour a lieu lorsque le
producteur propose une nouvelle version de son logiciel. La reconfiguration peut se
produire dans deux cas :
— Les caractéristiques matérielles du site de l'utilisateur changent.
— Des extensions sont faites au niveau entreprise. Si l'utilisateur est concerné
par ces changements, la configuration de sa machine doit être modifiée.
L'activité de désactivation désactive les composants de l’application. Elle est
pratiquée lors d'une mise à jour ou d'une désinstallation : l’application ne peut plus
s’exécuter tant que les composants ne sont pas à nouveau activés. L'activité de
désinstallation consiste à retirer le logiciel du site de l'utilisateur. Lorsque le
producteur ne fournit plus de nouvelles versions du logiciel (logiciel obsolète), mais
que le logiciel reste employé chez ses clients, c'est l'activité de fin de support.
Une autre activité peut aussi être prise en compte dans le cycle de vie du
déploiement : l’adaptation dynamique (Ketfi et al., 2002) (Ketfi et al., 2003). Cette
activité consiste à modifier une application en cours d’exécution. L’adaptation
dynamique permet notamment de mettre à jour des applications qui ne peuvent pas
être interrompues (même temporairement) comme des applications bancaires.
Dans les grandes entreprises, le déploiement prend une grande importance. Le
nombre de machines étant considérable, un support automatisé est nécessaire pour le
déploiement. Il faut alors prendre en compte les aspects d'organisation de
l'entreprise pour définir les stratégies à utiliser. Il est aussi nécessaire de prendre en
compte les caractéristiques (logicielles et matérielles) de chaque machine cible. Il
faut aussi s'occuper des aspects techniques pour supporter le procédé de
déploiement, à différents degrés de complexité. Le développement d’Internet a aussi
augmenté l’importance du déploiement : il est maintenant nécessaire de pouvoir
déployer une application sur des sites clients, via le réseau, directement depuis le
producteur.
Notre environnement supporte une architecture à deux niveaux. Des applications
sont soit développées, soit acquises au niveau entreprise. Pour celles acquises,
l’entreprise peut ensuite ajouter ses propres extensions pour personnaliser
l’application producteur. Ces extensions sont ajoutées avec l'aide des outils de
construction et de tests fournis par le producteur. La nouvelle application ainsi créée
est appelée application entreprise. Le niveau entreprise permet aussi de préparer le
déploiement physique vers les machines des utilisateurs, en prenant des décisions
sur le choix des stratégies de déploiement à adopter. Puis, l’application est
transférée et installée au niveau utilisateur (site consommateur).
3
3. Modélisation d’un système d’information de déploiement
4
— des spécifications sur les sous-systèmes dépendants. On dit qu’un système A
a une dépendance vers un système B lorsque A utilise B. Ainsi, lors du déploiement,
si la dépendance (le système B) n’est pas installée, il est possible de l’installer, de
stopper l’installation du premier système (A) ou de continuer son installation sans
installer la dépendance. L’action effectuée dépend de la stratégie choisie par
l’utilisateur.
— l’ensemble des composants constituant le système logiciel à déployer,
— des ressources. Ces ressources peuvent être des scripts à exécuter, des fichiers
de données et toute autre information nécessaire à l’installation et/ou au
fonctionnement de l’application.
— des méta-informations associées à chaque composant . Ces méta-informations
décrivent les contraintes des composants qui peuvent être logicielles ou
matérielles, comme le langage ou l’espace disque occupé.
L’élaboration de ce modèle de produit peut être plus ou moins complexe. Elle
peut être simple dans le cas d’une structuration du logiciel (un seul composant)
avec des contraintes de déploiement simples. Elle peut aussi être complexe dans le
cas d’un système logiciel composé de plusieurs sous-systèmes et composants
distribués et hétérogènes.
Les informations définies au niveau du modèle de produit constituent la base
pour la configuration des sites. Elles sont intégrées au modèle de site pour définir
l’état de chaque site (contexte de déploiement).
5
3.3. Modèle de procédé
6
La Figure 2 montre notre modèle de procédé de déploiement. La première
activité (Search Control Package) consiste à rechercher un serveur d’applications
fournissant l’application à déployer. Cette information, ainsi que l’ensemble de
l’information qui la concerne, est contenue dans un package.
Le procédé peut alors se poursuivre avec l’activité Résolution de dépendances
(Dependencies resolve). Cette activité commence par déterminer s’il y a des
dépendances. S’il y en a, l’activité détermine ensuite si elles sont déjà installées ou
non sur le site cible. Si elles le sont déjà, le procédé continue avec l’activité
suivante. Sinon, un second procédé de déploiement est lancé pour installer la
dépendance. Si cette dépendance ne peut être résolue, le déploiement est
interrompu.
L’activité de transfert (Transfer) consiste ensuite à transférer le package de
l’application sur le site cible. Enfin, le procédé de déploiement se termine avec
l’activité d’installation (Install). Cette activité est composée de différentes sous-
activités (Figure 3). Elle est instanciée en fonction de chaque application. Le
producteur personnalise ainsi le modèle générique de déploiement en définissant les
étapes à réaliser pour installer son produit. Cette spécification est décrite dans le
descripteur de déploiement (contenu dans le package de l’application).
7
Chaque étape d’installation est constituée d’une activité d’exécution, puis d’un
ensemble d’activités de vérifications (éventuellement aucune). Ces sous-activités
sont liées sémantiquement : la première effectue une opération, et les suivantes
doivent contrôler que cette opération s’est bien déroulée. Par exemple, une activité
d’exécution peut copier un ensemble de fichiers, et les vérifications devront
contrôler l’existence de ces fichiers dans les répertoires appropriés.
Si une vérification échoue (par exemple, un fichier n’existe pas), un retour en
arrière est fait. En fait, chaque activité d’installation est associée à une étape de
undo (undo Step). Ainsi, quand une étape échoue, l’activité de undo correspondante
permet de défaire les opérations déjà effectuées. Afin de conserver une cohérence
maximale, toutes les activités de undo des étapes déjà réalisées sont aussi exécutées.
Le site client se retrouve alors dans un état cohérent : celui d’avant le début du
déploiement.
Si toutes les étapes se sont bien déroulées, la dernière activité (terminate)
consiste à nettoyer les répertoires et fichiers temporaires utilisés lors de
l’installation.
8
4.1. La technologie des fédérations
9
Ainsi, chaque client peut utiliser ses propres outils. Par exemple, pour réaliser le
transfert de l’application, le noyau de la fédération appelle un outil implémentant le
rôle TransfertdeFichiers et deux clients distincts pourront utiliser deux outils
différents pour effectuer le transfert.
Dans notre fédération pour le déploiement, nous utilisons plusieurs composants
(outils), considérés comme des COTS (Carney, 1997). Tous les COTS inter-opèrent
ensuite dans la fédération pour le déploiement. De plus, le procédé de déploiement
est exécuté par un ensemble d’outils (le plus souvent, un outil par activité du
déploiement) et la coopération des outils est transparente pour l’utilisateur.
ORYA est basé sur une architecture à trois niveaux, pour apporter plus de
flexibilité à l’utilisateur.
4.2. Architecture
Un site client est une machine (niveau utilisateur), décrite par son modèle de
site.
Au niveau entreprise, on retrouve deux types de machines : les serveurs
d’applications et un serveur de déploiement. Un serveur d’applications stocke un
10
ensemble d’applications prêtes à être déployées, ainsi que les méta-données qui les
concernent (c’est le modèle d’application). Tous les fichiers (application et méta-
données) nécessaires au déploiement de l’application sont stockées dans un
package.
Un serveur de déploiement gère la communication entre les serveurs
d’applications et les sites clients. Il est aussi responsable de l’exécution du procédé
de déploiement. Le serveur de déploiement a la connaissance de tous les sites et
serveurs d’applications connectés, tandis que les serveurs d’applications et les sites
clients ne se connaissent pas entre eux.
En outre, deux stratégies peuvent être utilisées pour déployer une application :
— La stratégie push consiste à déployer une application sur un site client
directement depuis le producteur.
— La stratégie pull permet au client de décider quand installer l’application sur
son site.
Dans notre environnement, c’est la stratégie push qui est utilisée, puisque c’est
le mode le plus approprié aux entreprises.
Pour évaluer notre approche, nous avons réalisée une expérimentation de notre
prototype en milieu industriel. L’entreprise Actoll
(http://www.actoll.com/en/presentation.htm) travaille sur une plate-forme du
domaine des transports, pour gérer les péages autoroutiers et réseaux de transports
en commun.
11
Figure 7. Architecture de la plate-forme Centr’Actoll
12
Figure 8. Outil pour la construction d’un descripteur de déploiement
5.3. Evaluation
13
être étendue en ajoutant de nouveaux outils au noyau de la fédération : une fois
ajoutés, ces outils inter-opèrent.
La prochaine étape de notre travail est de réaliser la mise à jour. En pré-
condition, le procédé de mise à jour doit vérifier si la version actuelle de
l’application est utilisée par d’autres applications et si la nouvelle version est
compatible avec celles-ci. En fait, cette vérification doit être faite pour chaque
composant de l’application (par exemple, une même DLL peut être utilisée par
plusieurs applications différentes) (Parrish et al., 2001). L’utilisateur devra choisir
une stratégie de mise à jour pour déterminer si les composants d’une application
doivent être partagés ou non. Dans le cas de composants partagés, l’utilisateur devra
aussi choisir s’il veut toujours remplacer le composant par celui proposé par la mise
à jour, le remplacer seulement s’il a une version antérieure à celui de la mise à jour
ou ne jamais le remplacer.
14
package, systèmes de gestion d’application (comme TME-10 de Tivoli
(http://www.tivoli.com)) ou standards de description de système.
Les installateurs (comme InstallShield (http://www.installshield.com/isd/))
packagent un système logiciel dans une archive capable de s’auto-installer. Ensuite,
l’archive est distribuée sur les machines clientes. La plupart de ces outils sont
capables de gérer aussi la désinstallation, mais ont généralement un niveau
d’abstraction assez limité. Le modèle de produit inclut au minimum la liste des
fichiers à installer avec l’information sur la version et la plate-forme. Le modèle de
site contient l’information sur la configuration du site et l’environnement utilisateur.
Ce modèle est souvent spécifique à la plate-forme et le procédé de déploiement peut
difficilement être personnalisé.
Les gestionnaires de package (par exemple, Linux RedHat’ RPM (Ewingand et
al., 1996) ou les commandes HP-UX SD) sont des utilitaires de systèmes
d’exploitation qui assistent les administrateurs dans la gestion des applications. Ils
sont basés sur le concept de package et de repository de site qui stocke l’information
sur l’état de chaque package installé. Un package contient un ensemble de fichiers et
les méta-données décrivant le système. Le modèle de site est une collection de
packages et un repository. Le modèle de produit fournit un ensemble riche
d’attributs dans les méta-données du package.
Une spécification pour le déploiement et la configuration d’applications à
composants distribuées (OMG, 2003) est proposé par l’OMG. Cette spécification
est composée de trois niveaux :
— Le méta-modèle définit l’ensemble des méta-classes.
— Le modèle indépendant de la plate-forme (PIM) définit un ensemble de
classes et d’interfaces nécessaires à l’implémentation de la spécification.
— Les modèles spécifiques à la plate-forme (PSM) constituent l’implémentation
du PIM sur les plates-formes concrètes.
En termes de procédé de déploiement, la spécification définit des pré-conditions
pour chacune des opérations. L’installation est la tâche qui permet d’installer un
logiciel sur un site cible. La configuration consiste à configurer les options avant
l’exécution. La planification définit où et comment le logiciel s’exécutera dans
l’environnement cible. La préparation prépare l’environnement cible à être prêt pour
l’exécution. Enfin, le lancement met l’application dans un état d’exécution.
Beaucoup d’outils essayent de résoudre la problématique du déploiement.
Cependant, la plupart ne prennent pas en compte tout le cycle de vie. Notre
approche apporte un certain nombre d’avantages en permettant de personnaliser le
procédé de déploiement selon les besoins du client. De plus, elle couvre tout le cycle
de vie.
15
7. Conclusion
Bibliographie
16
Jarke M., Mylopoulos J., Schmidt J.W. and Vassiliou Y., “DAIDA - An environment for
evolving information systems”, ACM Transactions on Information Systems, 10, 1, 1992.
JAVA, “An abstract model for deployment”, 2002,
http://java.sun.com/developer/Books/javaprogramming/jnlp/jnlpch02.PDF.
Ketfi A., Belkhatir N., Cunin P.-Y., “Automatic Adaptation of Component-based Software
Issues and Experiences”, PDPTA’02, Las Vegas, Nevada, USA, June 2002.
A. Ketfi, N. Belkhatir, “Dynamic Interface Adaptability in Service Oriented Software”,
WCOP'03, Darmstadt, Germany, July 2003.
Lestideau V., Belkhatir N., Cunin P.-Y., “Towards automated software component
configuration and deployment”, PDTSD’02, Orlando, Florida, USA, July 2002.
Merle N., Belkhatir N., "Open Architecture for Building Large Scale Deployment Systems",
SERP'04, Las Vagas, Nevada, USA, June 2004.
OMG, “Deployment and Configuration of Component-based Distributed Applications
Specification”, June 2003, http://www.omg.org/docs/ptc/03-07-02.pdf .
Parrish A., Dixon B., Cordes D., “A conceptual foundation for component-based software
deployment”, Journal of Systems and Software, Volume 57, Issue 3, pages 193-200, 15
July 2001.
The Workflow Management Coalition Specification, “The Workflow Reference Model”,
January 1995, http://www.wfmc.org/standards/standards.htm.
Rolland C., “A primer for method engineering”, Actes du Congrès INFORSID 1997,
Toulouse, France, June 1997.
17