Gestion transactionnelle \\de la reprise sur erreurs dans le d�ploiement
Cristina Marin \andauthor{Noureddine Belkhatir} \andauthor{Didier Donsez}
With the development of the networks and the Internet, the problems of automated deployment on broad scale became increasingly crucial. Software deployment is a complex process covering several activities going from the configuration to the retirement of a software product. During the execution of a deployment process, exceptions can be met which put the site in an incoherent state. To solve them, we propose an approach based on transactional concepts which describes the actions to be undertaken when an exceptional situation is met during the deployment process. The approach guaranties the respect of the site's consistency by preserving part of the work already carried out by the process. This article presents our approach and an experimentation made in an academic deployment system.
DECOR04.tex
\documentclass[french]{article-hermes}
\usepackage{graphicx}


%
%%%% Commandes sp�cifiques � l'article
\newcommand{\cfsect}[1]{(\textit{cf.} section~\ref{#1})}
\newcommand{\cfsectpage}[1]{(\textit{cf.} section~\ref{#1}, page~\pageref{#1})}
\providecommand{\figureref}[1]{\figname~\ref{#1}}
\providecommand{\cftab}[1]{(\textit{cf.} tableau~\ref{#1})}
\newcommand{\cmd}[1]{{\upshape\texttt{\symbol{"5C}#1}}}


\begin{document}

%TITLE PAGE


%\submitted{DECOR'O4}{2}

\title[Vers un d�ploiement transactionnel]
      {Gestion transactionnelle \\de la reprise sur erreurs dans le d�ploiement}

\author{Cristina Marin \andauthor{Noureddine Belkhatir} \andauthor{Didier Donsez}}

\address{%
LSR - Ad�le, 220 Rue de la Chimie\\
Domaine Universitaire, BP 53\\
38041 Grenoble France\\[3pt]
\{cristina.marin,noureddine.belkhatir,didier.donsez\}@imag.fr}

\resume{Avec le d�veloppement des r�seaux et de l'Internet, la probl�matique du d�ploiement automatis� � large �chelle est devenue de plus en plus cruciale. Le d�ploiement est un proc�d� logiciel complexe couvrant plusieurs activit�s allant de la configuration jusqu'� la d�sinstallation du logiciel. Pendant l'ex�cution d'un proc�d� de d�ploiement, des exceptions peuvent �tre rencontr�es qui mettent le site dans un �tat incoh�rent. Pour les r�soudre, nous proposons une approche � base des concepts transactionnels pour d�crire les actions � entreprendre lorsqu'une situation exceptionnelle est rencontr�e � l'ex�cution. L'approche propos�e aide � respecter la coh�rence du site en conservant une partie du travail d�j� effectu� par le proc�d�. Cet article pr�sente notre approche et une exp�rimentation faite dans un syst�me de d�ploiement issu de la recherche acad�mique.}



\abstract{With the development of the networks and the Internet, the problems of automated deployment on broad scale became increasingly crucial. Software deployment is a complex process covering several activities going from the configuration to the retirement of a software product. During the execution of a deployment process, exceptions can be met which put the site in an incoherent state. To solve them, we propose an approach based on transactional concepts which describes the actions to be undertaken when an exceptional situation is met during the deployment process. The approach guaranties the respect of the site's consistency by preserving part of the work already carried out by the process. This article presents our approach and an experimentation made in an academic deployment system.}

\motscles{D�ploiement automatis�, proc�d� de d�ploiement, exceptions, transactions, coh�rence}
\keywords{Deployment, process, exceptions, transactions, consistency}

\proceedings{DECOR'04, D�ploiement et (Re)Configuration de Logiciels}{199}

\maketitlepage

\section{Introduction}

Le d�ploiement est devenu dans ces derni�res ann�es une activit� d'une importance croissante pour les entreprises qui utilisent des logiciels complexes et de taille importante. Le d�ploiement � large �chelle (des milliers des sites) de ce type d'application pose des probl�mes qu'il est difficile de r�soudre sans l'aide d'un support automatis�. 

Le domaine du d�ploiement logiciel s'int�resse au d�veloppement et � la conception de syst�mes destin�s � fournir un support automatis� au d�ploiement massif de logiciels. Il essaie de d�finir des solutions fiables et performantes et des m�canismes  automatis�s pour traiter le d�ploiement. En cons�quence, toutes les activit�s du d�ploiement \cite{Car98} peuvent �tre ex�cut�es avec le minimum d'intervention de la part de l'utilisateur. 

Il existe de nombreuses approches et de nombreux outils de d�ploiement, mais tr�s peu permettent de couvrir enti�rement le cycle de vie du d�ploiement en imposant des contraintes fortes, comme la plate-forme d'ex�cution ou le type de l'application � d�ployer. Ils sont aussi construits de mani�re ad-hoc. La solution propos�e dans notre approche consiste � introduire des abstractions. Une des abstractions est le mod�le d�crivant le proc�d� de d�ploiement. Ce mod�le est ex�cutable. Le syst�me de d�ploiement sera ainsi capable de coordonner l'ex�cution des activit�s de d�ploiement. 

Cependant un proc�d� de d�ploiement peut rencontrer � l'ex�cution des situations exceptionnelles qui peuvent mettre en �chec sa terminaison et la coh�rence des sites sur lesquels les logiciels sont d�ploy�s. La coh�rence des sites est une caract�ristique importante du d�ploiement. Nous l'exprimons par deux propri�t�s : la r�ussite et la s�ret�\cite{Par00}. Ces deux propri�t�s du d�ploiement expriment qu'apr�s l'ex�cution d'un proc�d� de d�ploiement l'application qui vient d'�tre d�ploy�e fonctionne comme sp�cifi� et que le d�ploiement de la nouvelle application n'endommage pas le fonctionnement des autres applications d�j� install�es sur le site. 

Les outils de d�ploiement actuels traitent de mani�re identique les exceptions apparues � l'ex�cution en remettant le site dans l'�tat ant�rieur au d�ploiement. Notre approche consiste � d�finir un mod�le de d�ploiement r�actif qui analyse l'�tat du site et du proc�d� de d�ploiement � l'apparition d'une situation exceptionnelle en cours d'ex�cution et qui choisit une r�action appropri�e pour pr�server la coh�rence du site et une partie du travail d�j� effectu�. 

L'article est organis� de la mani�re suivante. Nous pr�sentons d'abord les concepts principaux du d�ploiement en r�alisant ensuite une synth�se des outils de d�ploiement existants. La partie �tat de l'art pr�sente la technologie des proc�d�s ex�cutables et les diff�rents mod�les de transactions existants. Dans la section \ref{sect1}, nous d�taillons notre probl�matique et pr�sentons notre approche. Afin de le valider, nous pr�sentons une exp�rimentation faite dans un syst�me de d�ploiement acad�mique. Enfin, nous concluons et pr�sentons les perspectives de ce travail.

\section{�tat de l'art}
Cette section pr�sente un survol des trois principaux domaines de notre travail. Il s'agit du th�me central de notre travail de recherche - le d�ploiement  et aussi de la technologie des proc�d�s ex�cutables ainsi que des transactions. Pour chacun d'eux, nous pr�sentons bri�vement les principaux concepts et les travaux le concernant. 

\subsection{D�ploiement}
Le d�ploiement logiciel fait r�f�rence � toutes les activit�s et leurs interactions pendant le cycle de vie d'une application\cite{Car98}. Ces activit�s concernent le versionnement, l'installation, la d�sinstallation, la mise � jour, l'adaptation(la r�configuration), l'activation et la d�sactivation d'une application.

D�s qu'une nouvelle version d'un composant logiciel est cr��e chez un producteur (\textsl{versionnement}), elle peut �tre \textsl{install�e} sur une ou plusieurs sites du client. Pour pouvoir l'ex�cuter, l'application doit �tre \textsl{activ�e}. Quand le producteur dispose d'une nouvelle version d'un composant de l'application, celui-ci peut �tre \textsl{mis � jour}. Si un changement est produit dans l'environnement d'ex�cution de l'application (par exemple le changement de la carte vid�o utilis�e par l'application), l'application peut �tre \textsl{r�configur�e}. Pour pouvoir effectuer des mises � jour ou des adaptations, l'application peut �tre \textsl{d�sactiv�e}. Enfin, quand un utilisateur n'a plus besoin d'une application install�e, celle-ci peut �tre \textsl{d�sinstall�e}. 
Cette pr�sentation du cycle de vie du d�ploiement montre qu'il est compos� de plusieurs activit�s complexes qui peuvent avoir �ventuellement des liaisons entre elles. Chaque activit� ex�cute une t�che pr�cise et difficile. 

Les technologies industrielles actuelles li�es au domaine du d�ploiement logiciel peuvent �tre classifi�es en plusieurs cat�gories\cite{Car98}: \textsl{installateurs} (InstallShield X - ou Java Web Start), \textsl{gestionnaires de} \textit{packages} (RPM de Linux RedHat, 
SD de HP-UX), \textsl{syst�mes de gestion des applications} (TME-10 de Tivoli), \textsl{standards de description de syst�mes}, \textsl{syst�mes de transfert de contenu}. Une �tude plus d�taill�e sur ces cat�gories d'outils peut �tre trouv�e dans \cite{Mar04}.

Ces produits ont �t� classifi�s selon les probl�mes du d�ploiement qu'ils traitent.  Ainsi, m�me si les solutions propos�es sont efficaces, elles restent des solutions partielles qui ne couvrent pas tout le cycle de vie du d�ploiement. Parmi ces produits, certains couvrent une grande partie du processus de d�ploiement, mais imposent des contraintes sur le type de l'application � d�ployer (Java Web Start d�ploie seulement des applications web Java) ou de la plate-forme d'ex�cution (InstallShield accepte que des applications Windows). Un autre d�savantage pour ces outils est qu'en cas d'erreurs � l'ex�cution ils d�font tout le travail d�j� effectu�. Ainsi, le site est mis dans l'�tat ant�rieur � l'ex�cution du proc�d� de d�ploiement. Nous consid�rons cette approche pas toujours convenable. Un expos� des motifs qui nous ont conduit vers cette approche est d�taill� dans la section \ref{sect1}.

D'autres solutions plus acad�miques proposent de d�finir des environnements de d�ploiement qui couvrent enti�rement le cycle de vie du d�ploiement. Parmi ces approches les plus int�ressantes sont SoftwareDock\cite{Hall}, qui est le r�sultat d'un travail de recherche de l'Universit� du Colorado, et \cite{ORYA3}, environnement de d�ploiement g�n�rique d�velopp� dans l'�quipe Ad�le du laboratoire LSR de Grenoble. Ces approches ont �t� mat�rialis�es par le d�veloppement d'environnements de d�ploiement capables de g�rer l'ex�cution des proc�d�s de d�ploiement dans une architecture distribu�e � grande �chelle (SD) ou bien des environnements adaptables aux diverses politiques de d�ploiement qu'une entreprise peut d�finir (ORYA). Les technologies utilis�es pour l'automatisation des activit�s sont diff�rentes : des syst�mes agents mobiles(SD) pour coordonner les activit�s du d�ploiement ou une f�d�ration d'outils existants (ORYA) et un moteur de proc�d�s ex�cutables (APEL). 

\subsection{Transactions}
Les transactions ont �t� introduites dans les syst�mes de gestion de donn�es pour fiabiliser les op�rations pour des applications bancaires et les applications de r�servation de billets d'avion (SABRE) et de train (SOCRATES). Dans ces syst�mes, les applications se caract�risent g�n�ralement par une courte dur�e d'ex�cution (de l'ordre de la dizaine de seconde). La transaction est consid�r�e comme un encha�nement ordonnanc� des op�rations simples (\textit{read/write}) respectant quatre propri�t�s, connues sous le nom de propri�t�s ACID.

Le concept de transaction a ensuite int�ress� les concepteurs d'applications de conception assist�e par ordinateur ou bien d'applications de gestion des documents. Ces applications se caract�risent quand � elles par la n�cessit� d'une dur�e longue d'ex�cution pour une transaction et par le besoin de coop�ration entre transactions. Les propri�t�s ACID se montrent alors trop restrictif.

Pour d�passer cet obstacle, plusieurs mod�les dits avanc�s de transactions ont �t� propos�s\cite{Elg}. L'id�e est de rel�cher les propri�t�s de l'atomicit� et de l'isolation. Pour cela, une transaction longue est d�compos�e en plusieurs sous-transactions. La division va jusqu'� ce que les sous-transactions obtenues soient des op�rations indivisibles (simples). C'est le cas des transactions coop�ratives, ou le cas de Sagas o� les sous-transactions sont ind�pendantes les unes des autres.

Pour rel�cher l'isolation, ces mod�les permettent aux sous-transactions de rendre visible le r�sultat des sous-transactions, comme c'est le cas avec les transactions embo�t�es ouvertes (ONT) ou les transactions Sagas. Pour r�cup�rer un �tat coh�rent des donn�es en cas d'erreur, des m�canismes de contingences et des compensations sont utilis�s(transactions embo�t�es, des alternatives du mod�le Sagas).

Le mod�le ConTract s'int�resse aux longues dur�es d'ex�cution. Il propose de contr�ler l'ex�cution des activit�s de longues dur�es avec une d�finition des �tapes � ex�cuter pour garantir la r�ussite de l'activit�.  

\subsection{Proc�d�s}
La technologie des proc�d�s a pour but de supporter l'ex�cution des proc�d�s en fournissant les moyens de mod�liser, d'analyser, d'am�liorer, de mesurer et d'automatiser les activit�s de production.

La notion de \textit{mod�le de proc�d�} a �t� d�finie comme une repr�sentation abstraite d'une famille de proc�d�s. Un mod�le d'un proc�d� d�crit un proc�d� en termes d'entit�s qui sont les activit�s et leur encha�nement, les ressources, les agents qui ex�cutent des r�les. Chacune de ces entit�s peut �tre elle-m�me mod�lis�e. Pour d�crire les proc�d�s, il est n�cessaire de disposer d'un \textit{langage de mod�lisation} (PML)\footnote{Process Modelling Language}. Tous les proc�d�s ex�cutables d'une famille n�cessitent un environnement qui coordonne leur ex�cution (PSEE)\footnote{Process Sensitive Software Engineering Environment}. Un tel environnement est contr�l� par un moteur de proc�d�s (\textit{Process Engine}). Celui-�i a pour but de contr�ler les flots de donn�es qui transitent durant le proc�d� entre les diff�rents acteurs intervenant � l'ex�cution du proc�d�. 

Dans ces derni�res ann�es, les syst�mes de gestion des proc�d�s sont utilis�s dans une multitude d'applications. Ainsi peut �tre expliqu�e l'apparition d'une gamme assez vari�e de produits commerciaux: ProcessIT (AT\&T), InConcert (Xerox) ou FlowMark (IBM) sont seulement quelques exemples. Le probl�me est que tous ces produits ne r�soudrent pas le traitement des exceptions. Pour cela, les chercheurs ont propos� d'utiliser les transactions pour mod�liser un proc�d� transactionnel\cite{Sheth}.

Pour d�finir un mod�le de proc�d� transactionnel, plusieurs approches ont �t� propos�es bas�es sur une vision diff�rente des projections des concepts. Une premi�re approche est celui qui essaie d'ajouter � un mod�le de proc�d� les concepts transactionnels pour assurer la fiabilit�, la consistance de l'ex�cution. Dans l'autre approche, le mod�le de transaction avanc�e est enrichi des concepts des proc�d�s pour augmenter la fonctionnalit� de l'application en terme de s�ret� de l'ex�cution et des donn�es. Les techniques sont utilis�es de mani�re diff�rente. Par exemple, la technique de reprise en arri�re bas�e sur la compensation a deux modalit�s d'utilisation. D'une part, l'approche statique qui consiste de d�finir le mod�le de compensation dans la phase de d�finition du proc�d�, soit comme partie integrante du proc�d�\cite{Alonso}, soit comme un mod�le � part\cite{Muhlberger}. L'approche dynamique suppose la g�n�ration du plan compensatoire � l'ex�cution, mais son applicabilit� reste trop complexe. 


\section{D�ploiement transactionnel}\label{sect1}
Un syst�me de d�ploiement fiable et performant devra couvrir le cycle de vie du d�ploiement tout en tenant compte aussi des probl�mes pos�s par les domaines adjacents du d�ploiement (les r�seaux, la s�curit�). La coordination et l'ex�cution des activit�s du d�ploiement peuvent �tre support�es par la technologie des proc�d�s ex�cutables. 

Lors de l'ex�cution d'un proc�d� de d�ploiement des situations exceptionnelles peuvent �tre rencontr�es. Celles-ci mettent le succ�s du proc�d� en p�ril et peuvent endommager la coh�rence du site sur lequel le logiciel est d�ploy�. La coh�rence est exprim�e par l'interm�de de deux propri�t�s introduites par Parish dans \cite{Par00} : la \textbf{r�ussite} et la \textbf{s�ret�}. Un proc�d� de d�ploiement est consid�r� comme r�ussi si l'application d�ploy�e fonctionne apr�s l'installation ayant tous ces composants install�s. La s�ret� d'un proc�d� de d�ploiement est garantie si toutes les applications d�j� install�es sur un site continuent de fonctionner de la m�me mani�re apr�s l'ex�cution du proc�d�. Pour pouvoir la garantir, un syst�me de d�ploiement doit contenir des mod�les pour exprimer les r�actions � ex�cuter lorsqu'une exception survient en cours d'ex�cution.

Notre travail propose un mod�le de traitement des situations exceptionnelles pour garantir les deux propri�t�s mentionn�es. 

\subsection{Probl�matique}\label{A}
Les situations exceptionnelles rencontr�es � l'ex�cution d'un proc�d� de d�ploiement peuvent �tre assez h�t�rog�nes. Elles peuvent �tre caus�es par des pannes r�seaux, par exemple l'�chec du transfert d'un paquetage contenant un fragment d'une application vers un des sites sur lesquels il doit �tre d�ploy�, des probl�mes d'incompatibilit� entre les composants install�s sur un site ou des probl�mes d'incompatibilit� mat�rielle d'une application avec la plate-forme sur laquelle elle sera d�ploy�e. 

Le domaine du d�ploiement logiciel traite le cycle de vie d'une application. Une application est compos�e de plusieurs paquetages qui ont des d�pendances entre eux � l'installation et/ou � l'ex�cution. Les composants d'une application peuvent avoir des diff�rents degr�s d'importance pour le fonctionnement d'une application. Prenons par exemple, le cas d'un logiciel tr�s connu: Microsoft Word. Un composant obligatoire � l'ex�cution est l'�diteur de texte, toutefois le composant Dictionnaire n'est pas obligatoire d'�tre install� pour que l'application fonctionne. Ainsi, si � l'ex�cution d'un proc�d� de d�ploiement d'une application � composants, les composants obligatoires ont �t� install�s lorsqu'une exception est lev�e, le proc�d� est mis en �chec. Dans ce cas, plusieurs actions seront � envisager. Premi�rement, la strat�gie adopt�e par tous les outils existants peut �tre appliqu�e; de cette mani�re, les composants install�s devront �tre d�sinstall�s et le site retrouverait un �tat coh�rent. D'autre part, pour gagner en performance en terme de temps, comme tous les composants obligatoires de l'application ont �t� install�s, le proc�d� de d�ploiement pourra �tre consid�r� comme r�ussi. Le d�ploiement des composants optionnels (tel que le dictionnaire) peut �tre consid�r� comme op�ration non-critique pour un proc�d� de d�ploiement, fait qui donnera un �tat de coh�rence partielle du site.

De nos jours, un syst�me de d�ploiement a une architecture distribu�e qui contient plusieurs serveurs d'applications offrant les paquetages des applications � d�ployer, plusieurs sites sur lesquels une application devra �tre d�ploy�e et un serveur de d�ploiement qui g�re l'ex�cution. Notre proc�d� de d�ploiement est compos� de trois activit�s: premi�rement un serveur qui contient le paquetage de l'application est trouv�, puis le paquetage est transf�r� vers le site client o� il est enfin install�. Si pendant l'ex�cution du transfert (activit� 2) le serveur d'applications tombe en panne, le d�ploiement est mis en �chec. Ainsi, la r�ussite ne pourra pas �tre assur�e. Comme souvent un paquetage n'est pas disponible seulement sur un seul serveur d'applications, on peut tout de m�me garantir la r�ussite du d�ploiement en suivant une autre voie d'ex�cution. Le proc�d� ne doit pas �tre abandonn�, mais au contraire repris en compl�tant le chargement depuis un serveur d'applications miroir ou de secours.

Un autre exemple significatif est le cas d'un proc�d� de d�ploiement multiple. Prenons le cas d'un composant logiciel qui doit �tre install� simultan�ment sur un millier de sites. Si l'ex�cution du proc�d� n'est r�ussie que sur une partie importante des sites, le syst�me de d�ploiement devra prendre une d�cision pour traiter cette situation exceptionnelle. Il pourrait appliquer la strat�gie \textsl{tout ou rien}, mais dans ce cas la perte de performance sera trop significative. Il pourrait d'une autre cot� ignorer l'�chec du d�ploiement sur les sites manquantes et choisir ainsi de revenir plus tard et de r�essayer d'installer le composant sur ces sites. Ainsi, les sites sur lesquels le d�ploiement est r�ussi pourront b�n�ficier du paquetage install�.

Les exemples que nous avons �nonc�s montrent le besoin d'avoir des m�canismes de reprise sur panne lorsqu'une exception appara�t en cours d'ex�cution d'un proc�d� de d�ploiement. Ces m�canismes doivent prendre en compte les crit�res de performance du syst�me ainsi que celui de la coh�rence du site. Dans les sections suivantes, nous d�crivons le mod�le que nous proposons pour traiter les probl�mes pos�s par les erreurs sur un proc�d� de d�ploiement.

\subsection{Les propri�t�s ACID pour un proc�d� de d�ploiement}
Pour int�grer le concept de transaction dans le domaine du d�ploiement, nous avons �tudi� l'applicabilit� des mod�les de transactions existants sur un proc�d� de d�ploiement. Pour cela, il �tait important de caract�riser l'ex�cution d'un proc�d� de d�ploiement. Le mod�le d'ex�cution n�cessaire pour notre proc�d� de d�ploiement poss�de les caract�ristiques suivantes: il peut avoir une longue dur�e d'ex�cution (des heures,  m�me des jours); il est compos� de plusieurs activit�s qui peuvent �tre ex�cut�es en s�quentiel (une installation d'une application sur un seul site) ou en parall�le (un proc�d� de d�ploiement multiple, dans lequel une application est d�ploy�e simultan�ment sur plusieurs sites). Ces activit�s peuvent �tre complexes en terme de ressources utilis�es (volume de donn�es transf�r�es,CPU). 

Par rapport au d�ploiement, les propri�t�s ACID d'un proc�d� de d�ploiement vu comme une transaction pourront �tre d�finies de la mani�re suivante. La propri�t� d'atomicit� demande l'ex�cution correcte de toutes les op�rations composant le proc�d� pour que celui-ci puisse valider son ex�cution. Les contraintes demand�es d'�tre respect�es en garantissant la propri�t� de la coh�rence sont celles d�j� mentionn�es - la r�ussite et la s�ret�. Une ex�cution en respectant la propri�t� de l'isolation demande qu'aucune modification interm�diaire ne soit pas rendue visible pour les autres proc�d�s s'ex�cutant en parall�le. Pour respecter la durabilit�, toutes les modifications valid�es par des proc�d�s ex�cut�s avec succ�s devront persister dans le syst�me.

Une ex�cution ACID n'est pas appropri�e pour un proc�d� de d�ploiement. En cas d'erreur, les propri�t�s ACID imposent de d�faire. Un autre proc�d� s'ex�cutant en m�me temps ou m�me des applications install�es sur le site devront attendre la fin du proc�d� pour pouvoir utiliser des donn�es (des fichiers, des composants logiciels) verrouill�es par celui-ci. Les propri�t�s qui devront �tre assur�es � l'ex�cution sont la coh�rence (exprim�e par les deux propri�t�s mentionn�es) et la durabilit�. L'isolation et l'atomicit� ne sont pas n�cessaires pour le proc�d� de d�ploiement mais peuvent �tre demand�es pour une activit� sp�cifique du proc�d�. 

\subsection{Proc�d� transactionnel de d�ploiement}
Nous proposons une approche bas�e sur les concepts issus des mod�les de transactions avanc�es pour traiter les probl�mes qui apparaissent au cours d'ex�cution d'un proc�d� de d�ploiement. L'ex�cution du proc�d� respectera ainsi les propri�t�s CD. Notre approche propose des solutions pour traiter les �ventuelles erreurs. Comme un proc�d� de d�ploiement est un encha�nement de plusieurs activit�s, nous introduisons nos concepts au niveau activit�. Dans ce qui suit, nous pr�sentons les concepts introduits pour exprimer le comportement transactionnel sur un proc�d� de d�ploiement.

\textbf{Activit� critique/non-critique.} Les activit�s composant un proc�d� de d�ploiement peuvent avoir diff�rents degr�s d'importance. Ainsi, le proc�d� peut contenir aussi bien des activit�s obligatoires � �tre ex�cut�es (c.�.d activit�s critiques) que des activit�s non-critiques. Nous d�finissons une \textsl{activit� non-critique} comme �tant une activit� qui ne doit pas �tre obligatoirement termin�e avec succ�s pour que le proc�d� de d�ploiement soit r�ussi. 

\textbf{Point de reprise.} Une des propri�t�s qui doivent �tre assur�es par un proc�d� de d�ploiement est la coh�rence du site. Un proc�d� de d�ploiement en ex�cution peut avoir des �tapes interm�diaires dans lesquels la coh�rence du site est respect�e aussi que des �tapes dans lesquels elle ne l'est pas. Pour caract�riser les �tapes coh�rentes d'un proc�d� de d�ploiement, nous introduisons la notion de point de reprise.  Un point de reprise est associ� � une activit� � la fin de laquelle l'�tat du site est coh�rent. Il est utilis� comme point de retour en arri�re en cas d'erreur � l'ex�cution pour que les modifications d'un proc�d� en �chec ne soient pas d�faites en totalit�.

\textbf{Activit� de contingence.} Une exception apparue pendant l'ex�cution d'un proc�d� de d�ploiement peut mettre en �chec sa r�ussite. Toutefois, il existe des situations pour lesquelles, un autre chemin que celui de l'activit� �chou�e peut aboutir avec succ�s.
Cette nouvelle fa�on de r�aliser la t�che d'une activit� en �chec r�alise la t�che d'une autre activit� alternative, que nous appelons \textsl{activit� de contingence}. 

\textbf{Activit� de compensation.} Pour d�faire en cas d'exception les modifications des activit�s termin�es avec succ�s, nous avons d�fini des activit�s de compensations. Une activit� de compensation d�fait les modifications valid�es de l'activit� � laquelle elle est associ�e.

Tous ces concepts que nous avons d�fini pour un proc�d� de d�ploiement lui conf�rent un comportement transactionnel. Ainsi, lorsqu'une erreur appara�t, l'�chec est ignor� par le proc�d� si l'activit� �chou�e est une activit� non-critique. Pour traiter cet �chec et afin d'assurer la r�ussite, une activit� de contingence est ex�cut�e. Puis, le proc�d� peut �tre poursuivi normalement. Si l'activit� de contingence �choue, afin de garder une partie du travail d�j� effectu� et de retrouver un �tat coh�rent du site pour garantir la s�ret�, un point de reprise du proc�d� est utilis�. Pour retourner le proc�d� en arri�re vers ce point, les compensations sont ex�cut�es. Ainsi, les techniques de reprise sur panne transactionnelles utilis�es sont celles des r�cup�rations en avant et en arri�re. 

De cette mani�re, un syst�me utilisant ces concepts pour un proc�d� de d�ploiement est plus efficace gr�ce � l'introduction des notions d'activit� non-critique et activit� de contingence aidant de ne pas abandonner le proc�d� en pr�sence d'une erreur. 

\section{Meta-mod�le de proc�d� transactionnel}
La figure \ref{fig:1} repr�sente le m�ta mod�le int�grant des concepts transactionnels dans un mod�le de proc�d�s. Le mod�le de proc�d� sch�matis� contient une description des entit�s composant un proc�d� de d�ploiement. Un proc�d� consiste d'un ensemble d'activit�s, simples ou composites(constitu�e d'un enchainement de plusieurs activit�s). Chaque activit� ex�cute un r�le (\textit{Role}) et a des attributs (\textit{Attribute})(par exemple, l'�tat � l'ex�cution). Pour communiquer avec les autres activit�s du proc�d�, les activit�s poss�dent des ports (\textit{Port}) qui re�oivent les produits (\textit{Product}). Les produits repr�sentent les informations n�cessaires pour que l'activit� accomplie sa t�che, par exemple les informations n�cessaires pour trouver le paquetage � d�ployer ad�quat, le site cible, la forme binaire du paquetage. Ces produits sont typ�s(\textit{ProductType}) et circulent d'une activit� � l'autre � travers des flots de donn�es(\textit{Dataflow}).


\begin{figure*}[ht]
 \setlength{\fboxsep}{2mm}
 \fbox{
  \parbox{116mm}{
   \vspace{-20mm}
   \begin{center}
    \small
    \includegraphics[width=0.7\textwidth,angle=-90]{images/procede.eps}
   \end{center}
   \vspace{-20mm}
  }
 }
 \caption{Le meta mod�le de proc�d� transactionnel}\label{fig:1}
\end{figure*}

Nous avons �tendu ce mod�le pour pouvoir int�grer les techniques de reprise sur erreurs d�crites.Une activit� est typ�e. Un point de reprise (\textit{Savepoint}) peut lui �tre associ�. Il repr�sente un �tat interm�diaire coh�rent du proc�d� et contient les donn�es n�cessaires pour pouvoir retourner le proc�d� en arri�re.

Nous introduisons �galement la notion de contexte d'activit�. Le contexte d'une activit� permet de r�cup�rer  � tout moment des informations sur l'activit�. Par exemple, il permet de r�cup�rer au moment de la sortie en erreur des informations comme le taux du transfert pour une activit� de transfert ou le pourcentage des fichiers copi�s sur le disque dur pour une activit� de d�ballage d'un paquetage. Selon la valeur de ces variables, on peut choisir une activit� de reprise de l'erreur car pour certaines situations une strat�gie de r�cup�ration peut �tre plus ad�quate qu'une autre. Par exemple, pour l'activit� de transfert, en fonction de la variable nomm�e, si sa valeur est de 80\% une contingence est plus ad�quate qu'une compensation tandis que si sa valeur est de 10\% la compensation est plus indiqu�e.

\section{Validation}
Pour valider notre travail, nous avons exp�riment� notre approche sur le syst�me de d�ploiement ORYA\cite{ORYA3}. Il s'agit d'un syst�me qui utilise une f�d�ration d'outils progiciels existants pour offrir les fonctionnalit�s d�sir�es et un moteur de proc�d�s ex�cutables, APEL\cite{APEL}. Cet outil offre plusieurs fonctionnalit�s: il coordonne l'ex�cution des proc�d�s, permet de d�finir et de modifier des proc�d�s, permet de visualiser graphiquement l'ex�cution d'un proc�d�. 

ORYA offre un proc�d� de d�ploiement g�n�rique, qui peut �tre personalis� par ses utilisateurs. Le proc�d� d'installation offert par ORYA est constitu� de plusieurs activit�s (la partie haute de l'image \ref{fig:2}). Pour pouvoir installer une application, le paquetage le contenant doit �tre trouv� (Search Control Package). Puis les d�pendances logicielles de l'application sont r�solues (Dependencies Resolve). Le paquetage est ensuite transf�r� (Transfert) vers le site ou il est install� (Install).   


\begin{figure*}[ht]
 \setlength{\fboxsep}{2mm}
 \fbox{
  \parbox{116mm}{
   \vspace{-20mm}
   \begin{center}
    \small
    \includegraphics[width=0.7\textwidth,angle=-90]{images/installation.eps}
   \end{center}
   \vspace{-20mm}
  }
 }
 \caption{Notre proc�d� d'installation}\label{fig:2}
\end{figure*}


Pour valider notre approche, nous avons �tendu le proc�d� g�n�rique que ORYA offre pour l'activit� d'installation. L'extension consiste � r�cup�rer les �ventuelles erreurs/exceptions qui se produisent � l'ex�cution. Pour les r�soudre, il y a deux politiques de traitement possibles. La premi�re consiste � d�finir statiquement avant l'ex�cution les r�actions qui doivent �tre ex�cut�es. Notre d�finition statique du proc�d� d'installation transactionnel contient des activit�s de contingence connect�es sur les ports de sortie en erreur des activit�s (port KO) (la partie base de l'image). Ainsi, chaque fois qu'une exception est lev�e, elle est envoy�e vers le port KO de l'activit� en cours d'ex�cution, d'o� elle est transport�e vers l'activit� suivante. Celle-ci analyse l'erreur et en fonction du contexte ex�cute une contingence ou une compensation. 

La seconde se base sur une fonctionnalit� du moteur de proc�d�s APEL qui permet d'ajouter dynamiquement � l'ex�cution des activit�s. L'approche consiste � analyser les erreurs apparues et en fonction du contexte d'ajouter une activit� de reprise (contingence ou compensation) pour r�soudre le probl�me. Cette approche apporte un gain de complexit� dans le syst�me.

Nous sommes en cours d'exp�rimentation de notre proc�d� statique d'installation que nous avons pr�sent� pour une application OSGi distribu�e sur un parc de passerelles. Pour contr�ler l'installation des \textit{bundles} de l'application sur chaque passerelle, un d�ployeur local est utilis� pour r�cup�rer les �ventuelles exceptions apparues et pour les transmettre vers le gestionnaire d'ex�cution. Le sc�nario d'ex�cution consiste en simuler une panne r�seau entre le serveur de d�ploiement (ORYA) et une des passerelles, pour pouvoir appliquer une contingence qui consiste en l'utilisation d'une passerelle de r�serve pour installer le \textit{bundle} correspondant.

\section{Conclusion}
Cet article pr�sente une approche � base de concepts transactionnels pour r�soudre les situations exceptionnelles apparues en cours d'ex�cution d'un proc�d� de d�ploiement. Ces concepts ont �t� introduits au niveau d'une activit� qui compose un proc�d� de d�ploiement. 

Notre approche aide le syst�me de d�ploiement � gagner en performance. Si une erreur appara�t, pour garantir la r�ussite du d�ploiement une activit� de contingence peut �tre ex�cut�e. Si cela n'est pas possible, la strat�gie adopt�e est de ne pas d�faire tout le travail d�j� effectu�. Ainsi, le syst�me de d�ploiement fait une retour partial en arri�re pour assurer la s�ret� du d�ploiement et pour �conomiser la ressource temps d'ex�cution.

Une des perspectives de ce travail que nous avons exp�riment� que pour l'activit� d'installation, est de compl�ter son validation pour les autres activit�s du cycle de vie ainsi que pour des situations n�cessitant des protocoles plus difficiles de coordination (WS Coordinator,2PC). Une autre perspective de ce travail est de le personnaliser pour les diff�rents mod�les de plate formes dans le cadre du projet OSMOSE\cite{GDF}. 

%\bibliographystyle{biblio-hermes}
\bibliography{DECOR04}

\end{document}
DECOR04.bbl
\begin{thebibliography}{}

\bibitem[ALO~96]{Alonso}
\textsc{Alonso G.}, \textsc{Agrawal D.}, \textsc{Kamath M.}, \textsc{Gunthor
  R.}\andname{}\textsc{Mohan C.}, \guilo{}Advanced Transaction Models in
  Workflows Contexts\guilf{},
\newblock \Inname{} \textit{Twelfth International Conference on Data
  Engineering, IEEE Computer Society}, New Orleans,Louisiana, February 1996.

\bibitem[CAR~98]{Car98}
\textsc{Carganiza A.}, \textsc{Fuguetta A.}, \textsc{Hall R.},
  \textsc{Heimbigner D.}, \textsc{van~der Hoek A.}\andname{}\textsc{Wolf A.},
  \guilo{}A Characterization Framework for Software Deployment
  Technologies\guilf{},
\newblock rapport de recherche \numbername CU-CS-857-98, April 1998, Dept. of
  Computer Science, University of Colorado.

\bibitem[ELM~90]{Elg}
\textsc{Elmagarmid A.~K.}, \textit{Database Transaction Models for Advanced
  Applications},
\newblock Morgan Kaufmann, 1990.

\bibitem[EST~98]{APEL}
\textsc{Estublier J.}, \textsc{Dami S.}\andname{}\textsc{Amiour M.},
  \guilo{}APEL: A graphical yet Executable Formalism for Process
  Modelling\guilf{},
\newblock \textit{Automated Software Engineering.ASE Journal}, \volumename\ 5,
  \numbername\ 1, 1998.

\bibitem[GDF04]{GDF}
\guilo{}OSMOSE-ObjectWeb Generic Deployment Framework specification -
  draft\guilf{},
\newblock http://www-adele.imag.fr/~donsez/ow/owdeploy/doc, June 2004.

\bibitem[HAL~99]{Hall}
\textsc{Hall R.}, \guilo{}Agent-based Software Configuration and
  Deployment\guilf{},
\newblock PhD thesis, University of Colorado, 1999.

\bibitem[MAR~04]{Mar04}
\textsc{Marin C.}, \guilo{}Gestion de la coh�rence et des transactions avanc�es
  li�es au d�ploiement\guilf{},
\newblock rapport de DEA Syst�mes et Logiciels, Universit� Joseph Fourier
  Grenoble, Grenoble, Juin 2004.

\bibitem[MER~04]{ORYA3}
\textsc{Merle N.}\andname{}\textsc{Belkhatir N.},
\newblock \guilo{}A New Architecture for Building Large Scale Deployment
  Systems\guilf{},
\newblock The 2004 International Conference on Software Engineering Research
  and Practice (SERP'04), June 2004.

\bibitem[MUH~99]{Muhlberger}
\textsc{Muhlberger R.}\andname{}\textsc{Orlowska M.}, \guilo{}Backward Step:
  the Right Direction fot Production Workflow Systems\guilf{},
\newblock \Inname{} \textit{Tenth Australasian Database Conference}, Auckland,
  New Zeeland, January 1999.

\bibitem[PAR~00]{Par00}
\textsc{Parish A.}, \textsc{Dixon B.}\andname{}\textsc{Cordes D.}, \guilo{}A
  Conceptual Foundation for Component-Based Software Deployment\guilf{},
\newblock \textit{Systems and Software}, \volumename\ 57, \numbername\ 3, 2000,
   \pagesname{} 193-200.

\bibitem[SHE~93]{Sheth}
\textsc{Sheth A.}\andname{}\textsc{Rusinkiewicz M.}, \guilo{}On Transactional
  Workflows\guilf{},
\newblock \textit{Bulletin of the Technical Committee on Data Engineering, IEEE
  Computer Society}, \volumename\ 16, 1993.

\end{thebibliography}
