Vous êtes sur la page 1sur 17

Une architecture conceptuelle pour le

déploiement d’applications à grande échelle

Noëlle Merle — Noureddine Belkhatir

Equipe Adèle, LSR – IMAG


220, rue de la chimie
Domaine Universitaire BP 53
38041 Grenoble Cedex 9 France
{Noelle.Merle, Noureddine.Belkhatir}@imag.fr

RÉSUMÉ. Le déploiement prend en compte diverses activités depuis la fin du développement du


logiciel jusqu’à sa désinstallation, en passant par des activités telles que l’activation ou la
mise à jour. Ce papier présente une architecture conceptuelle pour le support du déploiement
d’applications à grande échelle sur des réseaux distribués. Cette approche est basée sur trois
modèles pivots : le modèle de produit décrit les logiciels des producteurs, le modèle de site
consommateur décrit les ressources et configuration des sites (contexte de déploiement) et le
modèle de procédé exécutable décrit et automatise le procédé de déploiement. En outre,
l’administrateur peut personnaliser le procédé de déploiement selon les besoins de
l’entreprise. La technologie des workflows est utilisée pour automatiser le procédé de
déploiement. Notre environnement ORYA (Open enviRonment to deploY Applications) fournit
un support pour la modélisation et l’exécution de procédés de déploiement. Ce document se
focalise sur l’architecture conceptuelle en présentant les modèles, puis ORYA qui peut être
personnalisé selon les besoins de l’application et de l’entreprise.
ABSTRACT. Deployment takes into account activities from software development to its
uninstall, via others activities like activation or update. This paper presents a conceptual
architecture to support a large scale deployment onto distributed networks. This approach is
based on three main models: product model describes producer’s software, consumer site
model describes site resources and configuration (deployment context) and executable
process model describes deployment process. Moreover, administrator can customize
deployment process according to enterprise needs. Workflow technology provides process
automation. Our environment ORYA (Open enviRonment to deploY Applications) brings
qualities as flexibility or adaptability for user. This paper focuses on the conceptual
architecture and presents ORYA which could be customized allowing enterprise and
applications needs.
MOTS-CLÉS : déploiement, modèle de produit, modèle de site, modèle de procédé, workflow,
ORYA, environnement de déploiement, cycle de vie de déploiement.
KEYWORDS: deployment, product model, site model, process model, workflow, ORYA,
deployment environment, deployment life cycle.

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. Le cycle de vie du déploiement

Le cycle de vie du logiciel comprend plusieurs activités (Jarke et al., 1992)


(Rolland, 1997) : analyse, conception, production, test et déploiement. La phase du
déploiement est composée de diverses sous-activités. On peut alors parler de cycle
de vie du déploiement (Figure 1).

Figure 1. Cycle de vie du déploiement d’un logiciel

Le cycle de vie du déploiement commence lorsqu’une nouvelle version d’une


application est créée. Cette application peut ensuite être installée sur une machine
cliente. Avant de pouvoir l’exécuter, ses composants doivent être activés, c’est-à-
dire prêts à fonctionner.

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

Afin de pouvoir personnaliser et automatiser le procédé de déploiement, des


informations doivent être connues sur l’application, le site client et l’organisation de
l’entreprise. Dans notre approche, nous avons étudié comment formaliser les
informations sur les sites, les applications et les stratégies de déploiement pour
chacune des activités du déploiement. Cette étude a abouti à la définition de
modèles génériques qui permettent d’abstraire les informations du déploiement. De
plus, nous utilisons la technologie des procédés pour rendre les activités du
déploiement génériques et réduire les activités à définir. Ainsi trois modèles ont été
identifiés:
— Le modèle de produit décrit les caractéristiques des applications à déployer.
— Le modèle de site décrit les caractéristiques (logicielles et matérielles) des
sites consommateurs (ressources et configuration) : il s’agit du contexte de
déploiement.
— Le modèle de procédé décrit le procédé de déploiement interprétable par un
moteur de workflow. Ainsi, chaque activité du procédé de déploiement peut être
décomposée en une liste d’étapes ordonnées.
Les modèles de produit, de site et de procédé définissent notre architecture
conceptuelle. Ces informations sont conservées au format XML. Nous allons
explorer chacun de ces modèles en détails.

3.1. Modèle de produit

Le modèle de produit permet d’abstraire l’ensemble des informations liées à la


description des caractéristiques d’une famille (plusieurs versions) d’une application
(ou logiciel). Ces informations sont utilisées pour effectuer un déploiement cohérent
tout au long des différentes activités du cycle de vie du déploiement. Deux
propriétés importantes définissent la cohérence du déploiement :
— La propriété de réussite permet d’assurer que l’application fonctionnera sur
le site, comme cela a été prévu et testé au niveau producteur (par exemple, on
choisit la version à déployer en fonction des caractéristiques du site recevant le
produit).
— La propriété de sûreté permet à une application déployée de ne pas détruire,
par effet de bord, les applications déjà installées. Le partage de composants (comme
des DLL) entre applications peut provoquer de tels effets.
Pour assurer la cohérence, le modèle de produit comprend une abstraction
complète des contraintes et des dépendances du système à déployer, comme :
— des informations générales sur le produit (description, version, icône
d’activation, informations sur la licence, informations de contact…),

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).

3.2. Modèle de site

Le modèle de site offre une vision uniforme d’une machine et de sa


configuration en termes logiciels et matériels. L’ensemble des informations
contenues dans ce modèle est nécessaire aux différentes activités du déploiement
telles que :
— Le choix de la version du logiciel à installer peut dépendre de la
configuration matérielle de la machine.
— Lors d’une installation d’un système avec une dépendance, on doit pouvoir
vérifier si la dépendance est déjà installée ou non.
— Lors d’une mise à jour ou d’une reconfiguration, on doit pouvoir connaître la
version actuellement installée sur la machine.
Le modèle de site est instancié pour chaque site et définit l’état du site. Dans les
approches ad hoc des outils industriels actuels, il existe deux types de mécanismes
pour calculer l’état d’un site : un calcul dynamique à la demande (comme dans
l’outil Autoconf (http://www.gnu.org/software/autoconf/)) et un stockage statique de
l’état dans un fichier spécialisé (comme dans l’approche Registry de Microsoft). Ce
qui permet de définir les activités de déploiement en fonction des informations
recueillies sur les sites.

5
3.3. Modèle de procédé

Le modèle de procédé est une manière de personnaliser le procédé de


déploiement, en choisissant la nature des activités et leur ordonnancement. La
technologie des procédés (Belkhatir et al., 1994) (Derniame et al., 1999) tend à
fournir les concepts et mécanismes nécessaires pour modéliser, analyser, améliorer,
mesurer et supporter raisonnablement l’automatisation d’activités (essentiellement
pour la production de logiciels). Cette technologie a aussi été appliquée, par le biais
des workflows (Workflow Management Coalition Specification, 1995), aux
domaines des affaires (Business activities) et a montré largement son efficacité.
Nous proposons dans notre approche d’appliquer cette technologie aux activités du
déploiement qui sont en générales des candidates adéquates à l’automatisation.
Comme nous l’avons énoncé précédemment, le cycle de vie du déploiement
comprend plusieurs activités. Chacune d’elles peut être décomposée en différentes
étapes. L’ensemble de ces activités constitue le procédé de déploiement.
Le modèle de procédé permet d’éviter de réécrire un procédé pour chaque
produit. Lors de l’exécution de ce procédé (Merle et al., 2004), les informations
contenues dans les modèles de produit et de site sont utilisées. Ce mécanisme
permet ainsi à l’utilisateur de ne définir que les étapes spécifiques à l’installation
d’un produit. Le procédé de déploiement peut alors être automatisé. Il est aussi
reproductible : il peut être recommencé en cas d’erreur ou même repris là où l’erreur
s’est produite.

Figure 2. Procédé de déploiement

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).

Figure 3. Procédé d’installation

La première activité de l’installation (extract) consiste à extraire l’application et


son information du package qui vient d’être transféré sur le site client. Ensuite, un
ensemble d’étapes d’installation sont réalisées : c’est l’activité Install Step qui peut
être réalisée autant de fois que nécessaire.

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.

4. ORYA : un environnement de support de modèles de déploiement

Comme le montre la Figure 4, différentes technologies sont utilisées pour


réaliser le déploiement d’une application. En effet, différents outils permettent
d’exécuter chacune des étapes du déploiement. Par exemple, un outil est
responsable du transfert de l’application, depuis un serveur d’applications vers un
site client.
Le procédé permet de décrire chacune des étapes (transfert, installation, …) du
déploiement. Enfin, des données sont nécessaires pour décrire les applications (nom,
version, etc…) et les sites clients (caractéristiques logicielles et matérielles).

Figure 4. Technologies utilisées dans le déploiement

L’utilisation de ces différentes technologies nous a conduit à baser notre


approche du déploiement sur la technologie des fédérations (Estublier et al., 2003).

8
4.1. La technologie des fédérations

Les fédérations sont une solution proposée au problème de l’interopérabilité. Le


principe est de construire une application en utilisant des outils et les fonctionnalités
des systèmes de procédés. Le noyau de la fédération les fédère et gère les données
communes, sans que les outils ne se connaissent entre eux.
Un procédé décrit la manière d’atteindre un but et automatise sa réalisation. Il
définit les activités et les entités qui les réalisent. Ces entités peuvent être des outils
ou des entités humaines agissant pour effectuer une tâche. Pour exécuter un
procédé, la fédération utilise un moteur de procédés : APEL (Estublier et al., 1998),
développé dans notre équipe. Ainsi, le noyau de la fédération et le procédé
contrôlent comment les outils interagissent.
Les procédés permettent aussi de choisir une stratégie. Dans le cas du
déploiement, l’utilisateur choisit une stratégie de déploiement via le procédé. Les
fonctionnalités des systèmes de workflow offrent aussi la possibilité de définir,
exécuter et surveiller le déroulement du procédé de déploiement.
En utilisant les fédérations dans notre environnement, le but est de définir un
procédé n’ayant aucune connaissance (ou le minimum) sur les outils et les
ressources nécessaires. De plus, le procédé peut être réutilisé dans d’autres scénarios
avec des outils différents. C’est pour cela que nous utilisons le concept de rôle qui
représente une fonctionnalité abstraite (par exemple un rôle TransfertDeFichiers).
Un outil implémente un ou plusieurs rôles. Par exemple un outil qui transfère
des données implémente le rôle TransfertDeFichiers. Les outils ont un
comportement autonome et ne peuvent pas être modifiés. En outre, un outil ne
connaît pas les autres outils : l’inter-opération est réalisée via le noyau de la
fédération.

Figure 5. Les niveaux de la fédération

La fédération utilise un outil seulement par l’intermédiaire du rôle qu’il


implémente (Figure 5). En fait pour réaliser une étape du déploiement, la fédération
fait appel à un outil implémentant un rôle spécifique et non à un outil spécifique.

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

Notre architecture pour le déploiement doit supporter l’intégralité du cycle de


vie du déploiement, depuis l’installation de l’application jusqu’à sa désinstallation,
et l’administration des sites clients. Le système doit pouvoir gérer le déploiement
d’une application sur de nombreuses machines en même temps tout en prenant en
compte les caractéristiques (logicielles et matérielles) spécifiques de chaque
machine.
Trois entités (Figure 6) interviennent dans notre architecture : un serveur de
déploiement, un ensemble de serveurs d’applications et un ensemble de sites clients.

Figure 6. Architecture du système

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.

5. Expérimentation en vraie grandeur

5.1. Présentation du cas d’étude

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

Cette plate-forme est composée de différents composants (Figure 7). Chacun


d’eux a une tâche spécifique et s’exécute sur un serveur en utilisant d’autres
applications. Par exemple, un composant gère les clients et utilise une base de
données Oracle, un autre gère les transactions financières, etc… ORYA est utilisée
pour installer ces composants sur un ensemble de machines clientes.

5.2. Utilisation d’ORYA

La première étape pour réaliser un déploiement est de définir le descripteur de


déploiement de l’application (Figure 8) et de construire le package correspondant.
Deux outils sont disponibles pour assister l’utilisateur dans ces deux tâches. Ensuite,
le producteur ajoute le package parmi ceux fournis par les serveurs d’applications
d’ORYA.
Depuis le serveur de déploiement, l’administrateur peut choisir, à l’aide de
l’interface d’ORYA, de déployer une application spécifique sur un site donné.
Après ce choix, la fédération et le moteur de procédés pilotent le déploiement en
suivant les étapes du procédé de déploiement (défini par l’utilisateur, dans le
descripteur de déploiement). Le noyau de la fédération lance chaque outil quand
cela est nécessaire et l’utilisateur peut contrôler le déploiement sur la fenêtre de
traces associée au procédé.

12
Figure 8. Outil pour la construction d’un descripteur de déploiement

L’administrateur peut aussi choisir trois modes de déploiement différents :


manuel, automatique ou semi-automatique. Le mode automatique ne requiert aucune
intervention de l’utilisateur. Lors d’un déploiement en mode manuel, l’utilisateur
doit valider/invalider manuellement chaque étape du déploiement. Enfin, en mode
semi-automatique, certaines activités seront réalisées automatiquement, d’autres
demanderont à l’utilisateur d’être validées/invalidées.

5.3. Evaluation

L’entreprise Actoll a particulièrement apprécié notre collaboration dans le


domaine du déploiement. En effet, avant d’utiliser notre approche, chaque
déploiement était réaliser manuellement, notamment en exécutant des fichiers de
commandes ou des copies de fichiers. L’utilisation d’ORYA leur a permis de définir
un procédé de déploiement pour chacun de leur composant. Ils ont apprécié le fait
que ce procédé soit reproductible sur un ensemble de machines cibles sans être
modifié.
Ainsi, notre approche démontre que la technologie des procédés basée sur les
fédérations fournit un excellent support pour la gestion du déploiement. De plus,
elle montre comment un système de déploiement peut être défini avec des
techniques spécifiques aux procédés pour répondre aux nouveaux besoins des
entreprises dans ce domaine. Elle démontre aussi que l’architecture du système peut

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.

6. Situation par rapport aux autres travaux académiques et industriels

6.1. Travaux académiques

Parmi les approches académiques, SoftwareDock (Hall et al., 1999) et le modèle


abstrait de Java pour le déploiement (Java, 2002) sont deux modèles basés sur un
modèle conceptuel similaire (architecture à trois niveaux).
Par exemple, dans SoftwareDock, une approche utilisant des agents, le
FieldDock représente le site client, l’InterDock représente le niveau entreprise et le
ReleaseDock concerne le producteur. Les caractéristiques sont spécifiées dans des
fichiers : un pour l’application et un autre pour le site client. Le modèle
d’application contient des propriétés et des contraintes (qui doivent être vérifiées ou
résolues pour déployer l’application). Toutes les activités du cycle de vie du
déploiement sont supportées : installation, mise à jour, reconfiguration et
désinstallation.
D’autre part, le modèle abstrait de Java pour le déploiement utilise trois rôles :
producteur, distributeur et utilisateur final. Un autre rôle est souvent confondu avec
celui du producteur : propriétaire de logiciel. Un AH (Application Helper) s’exécute
sur les plates-formes clients. Il peut être vu comme une interface entre le serveur de
déploiement et le client. De plus, l’environnement client est une description formelle
du site client. Enfin, des politiques de déploiement (fournies par le producteur)
définissent ce qui doit être installé et où cela doit être fait.

6.2. Travaux industriels

Les techniques actuellement utilisées dans l’industrie peuvent être classées en


différentes catégories (Carzaniga et al., 1998) : installateurs , gestionnaires de

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

Notre approche du déploiement à grande échelle est supportée par les


technologies de procédés. Elle apporte différents avantages tels que l’adaptabilité en
utilisant un système d’information pour le déploiement (modèles de produit, de site
et de procédé). Elle apporte aussi de la flexibilité à l’utilisateur. En effet, chaque
client a la possibilité d’utiliser ses propres outils, et, le procédé de déploiement est
conçu selon un modèle qui répond aux besoins des entreprises. Enfin, l’utilisation
des technologies de procédés apporte de l’extensibilité en permettant d’ajouter ou de
supprimer des activités selon les besoins. L’utilisation des technologies de procédés
supportées par les fédérations permet donc un excellent support pour le
déploiement. De plus, l’administrateur peut étendre des fonctionnalités en ajoutant
des composants au noyau de la fédération. Cette caractéristique permet de faire
évoluer l’architecture et d’augmenter les fonctionnalités en personnalisant le
système.

Bibliographie

Belkhatir N., Estublier J., Melo W., “ADELE-TEMPO : An Environment to Support


Modelling and Enaction”, Software Process Modelling and Technology, pages 187-217,
John Willey and Son inc, Research Study Press, Tauton Somerset, England, 1994.
Carney D., “Assembling large systems from COTS components. Opportunities, Caution and
complexities”, SEI Monograph on Use of Commercial Software in Government Systems,
SEI, Pittsburgh, USA, June 1997.
Carzaniga A., Fuggetta A., Hall R., Heimbigner D., van der Hoek A., Wolf A., A
Characterization Framework for Software Deployment Technologies, Technical Report
CU-CS-857-98, University of Colorado, Department of Computer Science, April 1998.
Derniame J.-C., Ali Kaba B., Wastell D., “Software Process : Principles, Methodology, and
Technology”, Springer-Verlag Berlin Heidelberg, 1999.
Estublier J., Le A.-T. and Villalobos J., “Multi-level Composition for Software Federations”,
SC’2003, Warsaw, Poland, April 2003.
Estublier J., Cunin P.-Y., Belkhatir N., “Architectures for Process Support System
Interoperability”, In proceedings of the 5th International Conference on The Software
Process, The International Software Process Association Press, Lisle, IL, June 1998.
Estublier J., Dami S., and Amiour M., “APEL : A graphical yet Executable Formalism for
Process Modelling”, Automated Software Engineering, ASE journal. Vol 5, Issue 1, 1998.
Ewingand M., Troan E., “The RPM Packaging System”, In Proceedings of the First
Conference on Freely Redistributable Software, Cambridge, MA, USA, February 1996,
Free Software Foundation.
Hall R., Agent-based Software Configuration and Deployment, PHD thesis, Department of
Computer Science, University of Colorado, 1999.

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

Vous aimerez peut-être aussi