% Pandora: une plate-forme efficace pour la construction d'applications autonomes
Simon Patarin\fup{*} \andauthor Mesaac Makpangou\fup{**}
Autonomic computing has been proposed recently as a way to address the difficult management of applications whose complexity is constantly increasing. Autonomous applications will have to be especially flexible and be able to monitor themselves permanently. This work presents a framework, Pandora, which eases the construction of applications that satisfy this double goal. Pandora relies on an original application programming pattern --- based on stackable layers and message passing --- to obtain minimalist model and architecture that allows to control the overhead imposed by the full reflexivity of the framework. Besides, a prototype of the framework has been implemented in C++. A detailed performance study, together with examples of use, complement this presentation.
decor04.tex
\documentclass[french]{article-hermes}

%\usepackage[T1]{fontenc}
\usepackage[frenchb]{babel}
\usepackage[latin1]{inputenc}
\usepackage{cite,wrapfig,subfigure,moreverb,verbatimfiles,alltt} 
\usepackage{language,hyperref}

\newif\ifpdf
\ifx\pdfoutput\undefined
    \pdffalse % we are not running PDFLaTeX
\else
    \pdfoutput=1 % we are running PDFLaTeX
    \pdftrue
\fi

\ifpdf
    \usepackage[pdftex]{graphicx}
\else
    \usepackage{graphicx}
\fi

\def\fwidth{0.75\hsize}

\newcommand{\eng}[1]{\textit{#1}}
\newcommand{\dfn}[1]{\emph{#1}}
\newcommand{\cf}[1]{\textit{cf.} �~\ref{#1}}

\begin{document}

\title[Pandora]{%
Pandora: une plate-forme efficace pour la construction
d'applications autonomes}
%\date{}
\author{Simon Patarin\fup{*} \andauthor Mesaac Makpangou\fup{**}}
\address{\fup{*}Universit� di Bologna -- Dipartimento di Scienze
  dell'Informazione\\
Mura Anteo Zamboni, 7\\
I-40127 Bologne, Italie\\[3pt]
patarin@cs.unibo.it\\[11pt]
\fup{**}Projet REGAL -- INRIA Rocquencourt\\
Domaine de Voluceau, B.P. 105\\
F-78153 Le Chesnay Cedex, France\\[3pt]
mesaac.makpangou@inria.fr}

\resume{  
  L'informatique autonome a r�cemment �t� propos�e comme une r�ponse �
  la difficult� de g�rer au quotidien des applications dont la
  complexit� ne cesse d'augmenter. Les applications autonomes devront
  �tre particuli�rement flexibles et pouvoir se surveiller en permanence.
  Cette �tude pr�sente une plate-forme, Pandora, qui facilite la
  construction d'applications qui satisfont ce double objectif. 
  Pandora s'appuie sur un mode de programmation original des
  applications --- fond� sur la composition de couches et le passage
  de messages --- pour aboutir � un mod�le et une architecture
  minimalistes qui lui permettent de contr�ler les surco�ts impos�s
  par la compl�te r�flexivit� de la plate-forme. Un prototype
  fonctionnel de la plate-forme a par ailleurs �t� d�velopp� en C++.
  Une �tude d�taill�e des performances, ainsi que des exemples
  d'utilisation, compl�tent cette pr�sentation.
}
\abstract{
  Autonomic computing has been proposed recently as a way to address
  the difficult management of applications whose complexity is
  constantly increasing. Autonomous applications will have to be
  especially flexible and be able to monitor themselves
  permanently. This work presents a framework, Pandora, which eases
  the construction of applications that satisfy this double
  goal. Pandora relies on an original application programming pattern
  --- based on stackable layers and message passing --- to obtain
  minimalist model and architecture that allows to control the
  overhead imposed by the full reflexivity of the framework. Besides,
  a prototype of the framework has been implemented in C++. A detailed
  performance study, together with examples of use, complement this
  presentation.
}
\motscles{Informatique autonome, mod�le de composants, reconfiguration
  dynamique}
\keywords{Autonomic computing, component model, dynamic reconfiguration}

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

\maketitlepage

\section{Introduction}
\label{sec:introduction}

Les applications distribu�es � large �chelle occupent une place
grandissante. Les r�seaux de distribution de contenu, les grilles de
calcul, les syst�mes d'�change de fichiers pair-�-pair, les tables de
hachages distribu�es, les syst�mes omnipr�sents: les exemples sont
nombreux et leur liste augmente constamment. L'environnement dans
lequel ces applications sont d�ploy�es, Internet, dispose de
caract�ristiques originales que sont l'h�t�rog�n�it�, l'�volution
rapide de l'ensemble des acteurs (mat�riels, logiciels, mais aussi
humains) et un relatif manque de fiabilit�. La diversit� des
plates-formes mat�rielles et logicielles rend alors particuli�rement
difficile la configuration de ces applications. Si l'on parvient
malgr� tout � franchir cette premi�re �tape, les �volutions et les
possibles pannes peuvent remettre en question les choix faits au
pr�alable et r�duire � n�ant les efforts pr�c�dents. Il est donc
imp�ratif de faciliter ces op�rations en les automatisant autant que
possible.  Ces constats sont � la base du d�veloppement de
l'informatique autonome (\eng{autonomic computing})\cite{kephart03}
dont le but est d'incorporer aux applications les moyens de
diagnostiquer les difficult�s auxquelles elles font face et d'y
rem�dier elles-m�mes. Les probl�mes � r�soudre avant de parvenir �
une solution satisfaisante sont �videmment tr�s nombreux. Nous nous
consacrons � l'�tude de l'un d'entre eux: le support syst�me
n�cessaire au d�veloppement de telles applications.

Il est possible d'identifier plusieurs fonctionnalit�s qui devront
�tre propos�es par une plate-forme de construction d'applications
autonomes. La premi�re et la plus importante concerne la flexibilit�
des applications: il est en effet inutile d'imaginer l'autonomie d'une
application si celle-ci ne peut pas �tre modifi�e et reconfigur�e
dynamiquement. De nombreux types de reconfiguration sont envisageables
et tous devront �tre support�s: depuis la simple param�trisation �
l'ajout de propri�t�s non fonctionnelles susceptibles de modifier
radicalement le comportement de l'application.  Par ailleurs,
l'application elle-m�me est souvent la mieux plac�e pour collecter les
mesures qui lui permettront d'analyser son comportement: il faut donc
que la plate-forme fournisse les m�canismes n�cessaires � la diffusion
de ces observations. Cette derni�re, enfin, doit faciliter
les interactions entre les diff�rents �l�ments du syst�me, en
particulier donner acc�s � l'�tat courant des applications et aux
mesures effectu�es (ce qui exige donc que la plate-forme soit
parfaitement r�flexive\cite{smith84,maes87}).

Cette flexibilit� que nous requ�rons ne doit pas �tre obtenue au
d�triment des performances; ce n'est cependant pas l'approche retenue
dans les syst�mes actuels o� une seule de ces deux propri�t� est
d�velopp�e au d�triment de l'autre. Ainsi, dans le cas des
plates-formes sp�cifiquement con�ues pour le d�veloppement
d'applications autonomes (comme AutoPilot\cite{ribler98} ou
AutoMate\cite{agarwal03}), la flexibilit� (et donc les possibilit�s de
reconfiguration) des applications est mise � mal et est notamment
insuffisante pour r�pondre � la diversit� des besoins que nous
anticipons. � l'inverse, dans le domaine de la programmation par
aspects\cite{kiczales97} ou celui des syst�mes �
composants\cite{clarke01}, les applications construites peuvent faire
preuve d'une tr�s grande flexibilit�, mais les surco�ts introduits
r�duisent consid�rablement le niveau de performance.

L'approche que nous d�fendons pour r�pondre � ce probl�me repose sur
un compromis original. Plut�t que de transiger sur les possibilit�s de
flexibilit� offertes ou le langage utilis�, nous mettons en avant
l'utilisation d'un mode de programmation alternatif: l'empilage de
composants ind�pendants. Cette approche, m�me si elle n'a encore
jamais �t� employ�e dans ce contexte � notre connaissance, n'est
cependant pas nouvelle et plusieurs projets l'ont exp�riment�e,
soulignant son expressivit�.  Parmi les premiers travaux dans ce
domaine, on retrouve \textit{x}-Kernel\cite{hutchinson91} et
Ficus\cite{heidemann91} (respectivement un syst�me d'exploitation
sp�cialis� dans les communications et une m�thode de construction de
syst�mes de fichiers); plus r�cemment, deux nouvelles architectures
ont �t� propos�es: un routeur flexible, le \eng{Click Modular
  Router}\cite{kohler00} et SEDA\cite{welsh01} qui permet la
construction efficace de services Internet. Alors que la plupart des
syst�mes patrimoniaux doivent instrumenter les appels de proc�dure (ce
qui se r�v�le co�teux et pousse � utiliser un langage interpr�t�), ce
mode de programmation, permet de d�finir le degr� d'intervention voulu
au travers du choix de la granularit� des composants. La plate-forme
que nous pr�sentons, Pandora, s'appuie donc sur ces techniques et
fournit une interface r�flexive qui permet aux applications
ext�rieures, ainsi qu'aux composants eux-m�mes, de reconfigurer
dynamiquement le syst�me entier.

Nous allons maintenant pr�senter (section~\ref{sec:art}) un rapide
panorama des travaux sur lesquels s'appuie cette �tude. Nous d�crivons
ensuite le mod�le de composants de Pandora (section~\ref{sec:modele})
et la grande flexibilit� de la plate-forme qui en r�sulte
(section~\ref{sec:flexibilite}). Nous pr�cisons ensuite la mise en
{\oe}uvre de cette plate-forme et donnons quelques exemples
d'utilisation du prototype (section~\ref{sec:implementation}). Nous
terminons cette �tude par une �valuation des performances de Pandora
(section~\ref{sec:performance}) et quelques remarques de conclusion
(section~\ref{sec:conclusion}).


\section{Travaux comparables}
\label{sec:art}

Comme nous l'avons mentionn�, il existe quelques plates-formes qui
poursuivent des objectifs comparables aux n�tres. Il s'agit par
exemple d'AutoPilot\cite{ribler98} qui se focalise plus
particuli�rement sur la conception de moyens d'observation int�gr�s
aux applications, ou d'AutoMate\cite{agarwal03} qui cible pour sa part
les applications d�ploy�es sur les grilles de calcul. La flexibilit�
de ces plates-formes est relativement limit�e: le param�trage
dynamique autorise, au mieux, le choix entre diff�rentes mises en
{\oe}uvre pour des fonctionnalit�s pr�d�finies et les possibilit�s
d'extension et de modification de propri�t�s non fonctionnelles sont
quasiment inexistantes. Ce manque de flexibilit� nous a pouss� �
consid�rer les approches actuellement propos�es pour r�pondre � ce
probl�me: les syst�mes � composants et la programmation orient�e
aspects.

Les syst�mes � composants patrimoniaux --- .NET, CCM (\textit{Corba
  Component Mo\-del}) ou EJB (\eng{Enterprise Java Beans}) --- sont en
r�alit� relativement peu adapt�s � la conception d'architectures
flexibles. La granularit� importante des composants, les liaisons
entre composants difficilement modifiables dynamiquement et l'ensemble
limit� et pr�d�fini de propri�t�s non fonctionnelles fournies par les
conteneurs de composant y contribuent grandement.  Ceci a favoris� le
d�veloppement de syst�mes plus l�gers (et plus performants). Ainsi, la
plate-forme OpenCOM\cite{clarke01} autorise la reconfiguration
dynamique des composants et des liaisons qui existent entre eux par le
biais d'une interface r�flexive. Un autre exemple est
Gravity\cite{hall03} qui adopte une d�marche originale: le syst�me
�tablit dynamiquement les liaisons entre les composants selon les
interfaces qu'il fournit et celles qu'il requiert. Pour notre
application la principale limitation d'un tel syst�me est l'absence de
support pour les reconfigurations �simples� comme la modification de
la valeur d'un param�tre.

La programmation orient�e aspects\cite{kiczales97} est une
m�thodologie qui promeut la s�paration des pr�occupations
(\eng{separation of concerns}): les fonctionnalit�s transverses �
plusieurs modules d'un programme sont isol�es (ce sont les
\dfn{aspects}) et seront �tiss�es� avec le reste de l'application au
moment de la compilation ou de l'ex�cution. La flexibilit� de ces
architectures provient de la relative ind�pendance entre les
diff�rentes entit�s (modules et aspects) de l'application que cette
approche procure: il est alors possible de modifier un module ou un
aspect sans perturber le reste du programme. C'est la plate-forme
JAC\cite{pawlak02b} (\eng{Java Aspect Components}) qui se rapproche le
plus de nos objectifs. Ici, en effet, les aspects sont encapsul�s sous
la forme de composants et tiss�s � l'ex�cution (ce qui en autorise
donc la reconfiguration dynamique). La principale limitation de cette
plate-forme est son manque de support pour la reconfiguration des
modules eux-m�mes (ceux dont les fonctionnalit�s ne peuvent pas �tre
vues comme des aspects).


\section{Mod�le de composants}
\label{sec:modele}

Pandora s'appuie sur la notion de \dfn{composant} comme unit� de
travail �l�mentaire et ind�pendante; ces composants peuvent �tre
assembl�s sous forme de piles pour ex�cuter des t�ches de plus haut
niveau. Nous allons d�crire plus pr�cis�ment le mod�le de composant
qu'utilise Pandora et nous pr�sentons ensuite --- bri�vement --- le
langage de description d'architecture utilis� pour d�finir et
param�trer ces assemblages de composants.


Contrairement � la plupart des mod�les de composants existants, les
composants utilis�s par Pandora communiquent exclusivement par passage
de message et non par invocation. Cette contrainte contribue
grandement � r�duire la complexit� des composants: un composant ne
d�finit en effet qu'une seule interface, celle qui lui permet de
recevoir un message. Dans la terminologie utilis�e, les messages
�chang�s entre les composants sont appel�s �v�nements, et c'est ce
terme que nous emploierons par la suite.  Les �v�nements sont typ�s et
un composant a la possibilit� d'utiliser cette information pour
d�terminer les traitements qu'il aura � effectuer.

Chaque composant dispose, au maximum, d'un port d'entr�e et d'un
nombre quelconque de ports de sortie. Le transfert d'�v�nements entre
les composants est unidirectionnel, synchrone et se fait par flot
continu.  Ceci signifie, en particulier, que deux composants, une fois
la communication �tablie, sont durablement associ�s l'un � l'autre et
s'oppose � la transmission de messages par \dfn{bo�te aux lettres}
(nous verrons plus loin que ce mode de transmission existe n�anmoins
dans le syst�me). L'ensemble des composants associ�s par de telles
relations est appel� \dfn{pile}. Un nom est associ� � chaque pile et
il est possible de faire coexister plusieurs instances d'une m�me pile
dans le syst�me qu'on peut diff�rencier au moyen de �poign�es�
(\eng{handles}) attribu�es par le syst�me ou bien d'\dfn{alias}
sp�cifi�s explicitement.

Du fait du synchronisme de la transmission des �v�nements au sein
d'une pile, les traitements des composants sont directement associ�s �
la r�ception d'un �v�nement, lesquels peuvent � leur tour entra�ner la
transmission d'un ou plusieurs �v�nements. Ainsi, une fois qu'un
�v�nement est �produit� l'ensemble des traitements g�n�r�s (par
transmission successive d'�v�nements) est trait� s�quentiellement. La
production initiale des �v�nements est assur�e dans chaque pile par un
composant sp�cifique nomm� \dfn{composant initial} qui est ordonnanc�
de mani�re ind�pendante.  Ce composant --- il n'en existe qu'un seul
par pile --- est donc indirectement responsable de l'activit� de
l'ensemble de la pile: s'il cesse de produire des �v�nements, c'est
toute la pile qui est au repos pendant ce temps.

Un autre caract�ristique importante des composants est leur enti�re
ind�pendance: un composant ignore totalement le contexte dans lequel
il sera utilis�. Ainsi les ports d'entr�e et de sortie sont
parfaitement anonymes et un composant n'a pas la possibilit� de
choisir le type des composants avec lesquels il communique; ceci est
d�termin� au moment de la configuration de la pile. Dans le cas
g�n�ral, un composant qui d�sire transmettre un �v�nement le transmet
donc � son \dfn{successeur}, sans conna�tre son identit�. Lorsqu'un
composant dispose de plusieurs ports de sortie, il existe deux
possibilit�s (� l'exclusion l'une de l'autre):
\begin{enumerate}
\item \emph{alternative}: des ports alternatifs sont identifi�s par un
  num�ro d'ordre et il sera possible de configurer la pile pour que
  des composants de nature diff�rente correspondent � chacun des
  ports;
\item \emph{d�multiplexage}: des ports de d�multiplexage permettent �
  un composant de classifier les �v�nements: d�s qu'une nouvelle
  cat�gorie est d�couverte, un nouveau port est cr�� dynamiquement,
  alors que les �v�nements appartenant � une cat�gorie existante sont
  dirig�s vers le port qui y avait �t� pr�c�demment associ�.
\end{enumerate}
Nous voyons alors que chaque composant � sorties multiples doit �tre
configur� � l'aide de �sous-piles� pour chaque port de sortie. Ces
sous-piles sont nomm�es \dfn{branches} et correspondent aux
traitements diff�renci�s des �v�nements au sortir d'un composant �
sorties multiples. Ainsi, tous les �v�nements qui sortent des branches
associ�s � un composant � sortie multiple donn� sont envoy�s sur le
port d'entr�e d'un unique composant qui les multiplexe.

Chaque composant, outre les ports de sortie que nous avons mentionn�,
a la possibilit� de communiquer directement avec une pile, prise dans
son ensemble; le port d'entr�e d'une pile est alors d�fini par le port
d'entr�e de son composant initial. � la diff�rence des communications
entre composants qui sont anonymes, les communications entre piles
sont nomm�es: un composant indique le nom de la pile (ou son
\eng{alias}) � laquelle il souhaite transmettre des �v�nements. Ici,
les communications peuvent �tre, au choix, synchrones ou asynchrones:
ce mod�le de communication peut donc �tre utilis� pour des
transmissions d'�v�nements selon le mod�le des bo�tes aux lettres.
Les composant, enfin, ont la possibilit� de d�clarer explicitement des
param�tres, que nous nommons \dfn{options}, identifi�s par un nom et
dont la valeur peut �tre configur�e pour adapter leur comportement.
Ces options peuvent �tre de tout type et il est possible d'associer un
traitement particulier � l'affectation d'une valeur (par exemple
transformer une cha�ne de caract�res repr�sentant un nom de machine en
adresse IP num�rique).


La sp�cification de l'assemblage des composants au sein des piles,
ainsi que leur param�trisation initiale, se fait au moyen d'un langage
sp�cifique. Afin de faciliter son utilisation et sa compr�hension par
les utilisateurs du syst�me, une repr�sentation compacte des piles
nous a paru pr�f�rable. Il est cependant envisageable d'utiliser des
langages de description de graphe (tel que
\texttt{dot}\cite{ellson02}) ou des langages � balises (de type XML)
pour aboutir � des r�sultats similaires. Nous nous limiterons ici �
pr�senter tr�s bri�vement la grammaire de ce langage
(tableau~\ref{tab:stack_grammar}) et un exemple complet d'utilisation
(figure~\ref{fig:stack_example}), sa compr�hension ne posant pas de
probl�me particulier (voir\cite{patarin03fr}, section 3.4.4 pour une
description d�taill�e).

\begin{table}[htbp]
  \centering
{\small\begin{tabular}{l@{~~::~~}l}
\hline
\multicolumn{2}{c}{} \\
\texttt{pile} &      \texttt{`\%'id alias? `\{' composant* `\}'} \\
\texttt{composant} & \texttt{simple | demux | alternative} \\ 
\texttt{simple} &    \texttt{`@'id alias? options?} \\
\texttt{options} &   \texttt{(`[' option (`,' option)* `]')?} \\
\texttt{alias} &     \texttt{`:'id} \\
\texttt{demux} &     \texttt{simple `<' branche `>}' \\
\texttt{alternative} &    \texttt{simple `(' branche (`|' branche)* `)'} \\
\texttt{branche} &   \texttt{composant+} \\
\texttt{option} &    \texttt{`\$'id alias? (`=' valeur)?} \\
\texttt{id} &        \texttt{[a-zA-Z]([a-zA-Z0-9\_])*} \\
\texttt{valeur} &    \texttt{entier | flottant | bool�en | `"'caract�res`"'} \\
\multicolumn{2}{c}{} \\
\hline
  \end{tabular}}
  \caption{Grammaire du langage de description d'architecture (BNF).}
  \label{tab:stack_grammar}
\end{table}

\begin{figure}[htbp]
  \centering
  {\small \verbatimlisting{stack_example.txt}}
  \caption{Exemple complet de la configuration d'une pile (utilis�e pour
  la capture et la reconstruction du trafic DNS).}
  \label{fig:stack_example}
\end{figure}


\section{Plate-forme flexible}
\label{sec:flexibilite}

Nous avons dit � quel point les applications autonomes avaient
besoin d'�tre fle\-xi\-bles. Ceci s'exprime � la fois dans la capacit� �
les param�trer le plus finement possible, mais �galement dans la
possibilit� de revenir sur ces choix au fur et � mesure que le
contexte dans lequel s'ex�cutent les applications �volue. Plut�t que
de d�crire l'architecture dans son ensemble (d�crite avec pr�cision
dans des travaux pr�c�dents\cite{patarin03fr}), nous allons nous
concentrer sur ce point pr�cis et d�tailler les m�canismes mis �
disposition pour le d�veloppement d'applications autonomes.

\subsection{Degr�s de flexibilit�}

Deux niveaux de flexibilit� apparaissent dans la sp�cification des
syst�mes manipul�s par Pandora: au niveau du param�trage des
composants et au niveau de l'assemblage des composants. La flexibilit�
li�e au param�trage passe par l'utilisation des options et est tout �
fait classique. Elle peut cependant avoir une influence importante
puisqu'il est par exemple envisageable d'utiliser des options pour
sp�cifier un algorithme de d�multiplexage ou bien un port de sortie au
sein d'une alternative.

Pandora expose un second niveau de flexibilit� dans la sp�cification
des assemblages de composants. D'un c�t�, la possibilit� d'avoir
diff�rents composants qui mettent en {\oe}uvre la m�me fonctionnalit�
permet de choisir la solution qui correspond le mieux �
l'environnement dans lequel on se trouve (les algorithmes pour
lesquels il faut trouver un compromis entre utilisation du processeur
et occupation m�moire ne sont pas rares). D'un autre c�t�, le mod�le
autorise l'utilisation de composants non fonctionnels dont l'insertion
dans une pile n'en modifie le comportement g�n�ral mais peut alt�rer
la fa�on dont les traitements sont ex�cut�s ou y adjoindre certains
effets de bord. Ainsi, on peut citer l'exemple de composants assurant
la persistance des �v�nements qu'ils re�oivent, la r�partition des
traitements sur diff�rentes machines, la surveillance de
l'application, la d�tection des pannes, la synchronisation des
traitements, etc. Ce dernier point se rapproche des probl�matiques que
l'on retrouve dans la programmation par aspects: sans modifier
l'application (les composants orignaux), il est possible d'y tisser
certains aspects (par l'adjonction de composants sp�cifiques dans la
d�finition de la pile).


\subsection{Reconfiguration dynamique}
\label{sec:reconfiguration}

L'ensemble de la configuration de la plate-forme, ainsi que son �tat
courant, sont expos�s par son moteur d'ex�cution (qui prend la forme
d'un micro-noyau) au travers d'une interface de r�flection. Ceci
concerne donc aussi bien les d�finitions de piles, que les valeurs des
options ou les listes de ressources: absolument tout ce qui est
configurable par un fichier de configuration l'est �galement au
travers de cette interface. Pour chaque �l�ment, il est en outre
possible de pr�ciser si l'on souhaite modifier les d�finitions
stock�es ou leur repr�sentation active (modifiant ainsi directement le
comportement de la plate-forme). La gestion des piles est �galement
expos�e, de telle sorte qu'il est possible de conna�tre les piles en
cours d'ex�cution ou de demander le d�marrage ou l'arr�t de l'une
d'entre elles.

Parmi ces op�rations, la reconfiguration dynamique des piles occupe
une place particuli�re. En effet, contrairement � toutes les autres,
cette manipulation conduit � modifier des instances de composant
existantes ainsi que les liaisons qui existent entre elles. Les
composants de Pandora sont consid�r�s par d�faut comme porteur d'un
�tat et la plate-forme veille donc � r�duire au strict n�cessaire les
destructions de composants lorsque l'on passe de l'ancienne
description � la nouvelle.


\subsection{Modes de contr�le}
%\label{sec:controle}

Ces diff�rentes op�rations sont rendues accessibles pour les
applications externes � la plate-forme au travers d'un protocole �
meta-objets (\eng{Meta-Object Protocol}). Pandora fournit une
interface � ce protocole sp�cifique dans diff�rents langages de
programmation, notamment C, C++, Perl et Guile\cite{guile}. Il est
ainsi possible d'�crire de v�ritables �scripts de contr�le�, ce qui
favorise le d�veloppement rapide d'applications autonomes.

Nous souhaitons �galement que les applications puissent s'analyser et
se reconfigurer elles-m�mes. L'utilisation du protocole que nous
venons de d�crire n'est alors pas optimale en termes de performance,
nous avons donc introduit un m�canisme sp�cifique de \dfn{capteurs} et
de \dfn{moniteurs} pour r�pondre � ce probl�me. Cette technique permet
� un objet (le moniteur) d'appliquer des traitements sur un ensemble
de valeurs (expos�es par les capteurs) de mani�re efficace.  Un sch�ma
de nommage simplifi� permet en effet de r�duire consid�rablement les
surco�ts qui sont li�s dans l'approche pr�c�dente � la localisation
des param�tres au sein du syst�me (� chaque acc�s il faut en effet
identifier la pile, puis le composant dans la pile et enfin le
param�tre dans le composant). De plus, les capteurs supportent
plusieurs modes de fonctionnement: un mode \dfn{passif} o� les
moniteurs d�cident eux-m�mes de proc�der aux traitements et un mode
\dfn{actif} o� la modification de la valeur d'un capteur d�clenche les
traitements.


\section{Mise en {\oe}uvre}
\label{sec:implementation}

Nous avons d�velopp� une plate-forme logicielle qui met en {\oe}uvre
cette architecture. Elle repr�sente environ 50\,000 lignes de code en
C++ et comprend, outre le noyau, plus d'une centaine de composants.
Environ le tiers de ces composants fait partie des composants �de
base�: ce sont des composants qui mettent en {\oe}uvre des propri�t�s
non fonctionnelles et peuvent �tre utilis�s dans toute pile.

Pandora est utilisable sur un grand nombre de syst�mes dont
Linux, FreeBSD, NetBSD, Solaris, Digital Unix (Tru64) et, pour le
noyau et les composants de base uniquement, Win32. La plate-forme est
distribu�e dans sa version la plus r�cente sous une licence
\eng{open-source} de l'INRIA (libre pour une utilisation non
commerciale) � l'adresse suivante:
\url{http://www-sor.inria.fr/projects/relais/pandora/}.


La plate-forme a d�j� �t� utilis�e dans plusieurs
projets\cite{patarin03fr, patarin03a, lefessant03, patarin04a}.
L'application n�anmoins qui met le mieux en valeur la flexibilit� de
Pandora et les possibilit�s qu'elle offre pour construire des
applications autonomes est C/SPAN\cite{ogel03}. C/SPAN est un cache
Web autonome qui s'appuie d'une part sur C/NN\cite{ogel01}, un cache
flexible, et sur une pile d'observation du trafic HTTP au-dessus de
Pandora d'autre part. Dans ce syst�me, C/NN et Pandora forment une
boucle d'interaction rapproch�e: C/NN, en fonction de son
environnement (espace disque, taux de requ�tes, etc.) ajuste le
comportement de Pandora en utilisant son interface r�flexive, tandis
que Pandora reconfigure le cache en fonction de ses observations.


\section{�valuation des performances}
\label{sec:performance}

\begin{figure}
  \centering
  \subfigure[Comparaison des temps d'ex�cution de diverses
  fonctions avec le temps de travers�e d'un composant.]{%
    \includegraphics[width=.49\hsize]{perf_compcall} 
    \label{fig:perf_compcall}}\hfill 
  \subfigure[Comparaison des m�canismes d'introspection de Pandora
  avec ceux fournis en standard avec Java et C\#.]{%
    \includegraphics[width=.49\hsize]{perf_reflect}
    \label{fig:perf_reflect}}
  \caption{�valuation des performances}
  \label{fig:perf}
\end{figure}

Dans cette �valuation des performances de la plate-forme, nous nous
sommes concentr�s sur deux points particuliers: le co�t du d�coupage
en composants et celui des op�rations d'introspection. 

L'ensemble de ces tests a �t� r�alis� sur une m�me machine munie d'un
Pentium~IV cadenc� � 2,4~GHz qui ex�cute la version 2.6 du syst�me
d'exploitation Linux. Les mesures que nous pr�sentons ici sont
calcul�es � partir de la moyenne des valeurs obtenues pour 50
�valuations successives; � aucun moment l'erreur standard associ�e �
ces moyennes n'a d�pass� 1\,\%. Les temps d'ex�cution des proc�dures
ont �t� calcul�s � partir d'une boucle qui les r�p�te un million de
fois chacune: le temps total exprim� en millisecondes indique alors le
co�t d'une it�ration, exprim� en nanosecondes.

Pour �valuer le co�t du d�coupage en composants, nous avons mesur� le
temps de travers�e d'un composant, c'est-�-dire le temps n�cessaire �
la transmission d'un �v�nement d'un composant � son successeur. Les
r�sultats pr�sent�s figure~\ref{fig:perf_compcall} montrent que ce
temps est d'environ 50\,ns. D'apr�s les autres mesures que nous avons
effectu�es, nous voyons que ce temps est certes sup�rieur au temps
n�cessaire � l'appel de fonctions de biblioth�ques simples mais est
inf�rieur, par exemple, � celui utilis� pour effectuer une op�ration
flottante ou un appel syst�me. Ceci nous indique donc que pour des
applications non triviales, le surco�t li� au d�coupage en composants
reste tr�s limit�, voire n�gligeable.


Pour surveiller son propre comportement, une application autonome
examine en permanence les capteurs dont elle dispose. Les modifications
ne sont en effet suppos�es intervenir que lors de circonstances
exceptionnelles. C'est donc l'op�ration de lecture d'un capteur qui
est la plus critique en termes de performance, et c'est elle que nous
avons donc choisi d'�valuer. � titre de comparaison, nous avons mesur�
le temps n�cessaire � la lecture d'une variable en utilisant les
interfaces r�flexives de deux langages couramment utilis�s dans la
construction d'applications autonomes: Java et C\#.  L'op�ration
effectu�e consiste ici � lire la valeur d'un champ entier d'un objet
de la mani�re la plus simple (le code tient, dans les deux cas, en une
seule ligne). Pour Java nous avons utilis� diff�rentes machines
virtuelles, avec et sans compilation dynamique (\eng{Just In Time});
nous avons �galement compil� le programme en code natif en nous
servant du compilateur GNU\cite{gcj}. Pour C\#, c'est l'environnement
Mono\cite{mono} que nous avons employ�, dont la machine virtuelle
supporte � la fois la compilation dynamique et statique (avant
l'ex�cution). Les r�sultats de ces diff�rents tests sont pr�sent�s
figure~\ref{fig:perf_reflect}.  Plut�t que de nous �tendre sur les
performances relatives des compilateurs ou des machines virtuelles les
uns par rapport aux autres, ce sont les ordres de grandeurs qui nous
int�ressent ici. Il appara�t que l'utilisation des capteurs --- en
mode passif --- de Pandora (\cf{sec:controle}) est environ 20 fois
plus rapide que le code Java compil�. Le temps d'ex�cution de ce
dernier correspond en revanche � celui requis lorsque l'on utilise les
options de Pandora au travers de l'interface externe. L'utilisation
d'une machine virtuelle d�grade encore un peu les performances et
l'absence de compilation dynamique les rend tout � fait
catastrophiques. Ceci montre donc que l'utilisation de Pandora permet,
� charge �gale, de supporter simultan�ment un nombre bien sup�rieur
(un ou deux ordres de grandeur) de capteurs et donc d'applications,
compar�s aux langages traditionnellement utilis�s dans ce domaine.
C'est la sp�cialisation de Pandora dans ces t�ches (la plate-forme a
�t� sp�cialement con�ue et optimis�e pour cela) par opposition � la
n�cessaire g�n�ricit� d'un langage de programmation qui explique ces
diff�rences.


\section{Conclusion}
\label{sec:conclusion}

Nous avons pr�sent� Pandora, une plate-forme pour la construction
d'applications autonomes. Pandora s'appuie sur un mode de
programmation original, l'empilage de composants, qui offre un bon
compromis entre flexibilit� et performance. En effet, le mod�le de
composants de Pandora qui en r�sulte est nettement plus simple que les
approches les plus couramment utilis�es qui proc�dent par appel de
proc�dure. Le langage de description d'architecture que nous avons
con�u permet de d�finir les assemblages de composants de fa�on
compacte et claire pour les utilisateurs de la plate-forme.
L'architecture du syst�me est organis�e autour d'un micro-noyau qui
expose une interface r�flexive et propose les abstractions n�cessaires
au programmeur d'application pour permettre la configuration et
reconfiguration du syst�me tout entier. Cette architecture a �t� mise
en {\oe}uvre au travers d'un prototype fonctionnel --- disponible
librement sur Internet --- qui a d�j� eu de nombreuses applications.
Enfin, une �valuation des performances du syst�me a montr� que sa mise
en {\oe}uvre soutenait notre objectif initial de concilier flexibilit�
et performance.

\let\tilda\~

\bibliography{decor04}

\end{document}

decor04.bbl
\begin{thebibliography}{}

\bibitem[AGA~03]{agarwal03}
\textsc{Agarwal M.}, \textsc{Bhat V.}, \textsc{Li Z.}, \textsc{Liu H.},
  \textsc{Khargharia B.}, \textsc{Matossian V.}, \textsc{V.Putty},
  \textsc{Schmidt C.}, \textsc{Zhang G.}, \textsc{Hariri
  S.}\andname{}\textsc{Parashar M.}, \guilo{}AutoMate: Enabling Autonomic
  Applications on the Grid\guilf{},
\newblock \Inname{} \textit{Proceedings of the Autonomic Computing Workshop
  {(AMS 2003)}}, Seattle, WA, \Jun{} 2003.

\bibitem[BOT~04]{gcj}
\textsc{Bothner P.}, \textsc{Haley A.}, \textsc{Levy W.}\etalter{},
\newblock \guilo{}The GNU Compiler for the Java Programming Language\guilf{},
\newblock software, 2004,
\newblock \url{http://gcc.gnu.org/java/}.

\bibitem[CLA~01]{clarke01}
\textsc{Clarke M.}, \textsc{Blair G.~S.}, \textsc{Coulson
  G.}\andname{}\textsc{Parlavantzas N.}, \guilo{}An Efficient Component Model
  for the Construction of Adaptive Middleware\guilf{},
\newblock \textit{Lecture Notes in Computer Science}, \volumename\ 2218, 2001.

\bibitem[ELL~02]{ellson02}
\textsc{Ellson J.}, \textsc{Gansner E.}, \textsc{Koutsofios L.}, \textsc{North
  S.~C.}\andname{}\textsc{Woodhull G.}, \guilo{}Graphviz --- Open Source Graph
  Drawing Tools\guilf{},
\newblock \textit{Lecture Notes in Computer Science}, \volumename\ 2265, 2002.

\bibitem[FES~03]{lefessant03}
\textsc{Fessant F.~L.}\andname{}\textsc{Patarin S.}, \guilo{}{MLdonkey, a
  Multi-Network Peer-to-Peer File-Sharing Program}\guilf{},
\newblock Research Report \numbername RR-4797, \Apr{} 2003, INRIA.

\bibitem[HAL~03]{hall03}
\textsc{Hall R.~S.}\andname{}\textsc{Cervantes H.}, \guilo{}Gravity: supporting
  dynamically available services in client-side applications\guilf{},
\newblock \Inname{} \textit{Proceedings of the 9th European software
  engineering conference held jointly with 10th ACM SIGSOFT international
  symposium on Foundations of software engineering}, ACM Press, 2003,
  \pagesname{} 379--382.

\bibitem[HEI~91]{heidemann91}
\textsc{Heidemann J.~S.}, \guilo{}Stackable Layers: An Architecture for File
  System Development\guilf{},
\newblock \technicalreportname{} \numbername UCLA-CSD 910056, \Jul{} 1991,
  University of California, Los Angeles, CA ({USA}).

\bibitem[HUT~91]{hutchinson91}
\textsc{Hutchinson N.~C.}\andname{}\textsc{Peterson L.~L.}, \guilo{}The {{\it
  x}-K}ernel: An Architecture for Implementing Network Protocols\guilf{},
\newblock \textit{IEEE Transactions on Software Engineering}, \volumename\ 17,
  \numbername\ 1, 1991,  \pagesname{} 64--76, IEEE Computer Society.

\bibitem[ICA~04]{mono}
\textsc{de~Icaza M.}, \textsc{Molaro P.}, \textsc{Pratap R.}, \textsc{Porter
  D.}\etalter{},
\newblock \guilo{}The Mono project\guilf{},
\newblock software, 2004,
\newblock \url{http://www.go-mono.com/}.

\bibitem[JAF~02]{guile}
\textsc{Jaffer A.}, \textsc{Carrette G.}, \textsc{Stachowiak M.}\etalter{},
\newblock \guilo{}Guile, Project GNU's extension language\guilf{},
\newblock software, 2002,
\newblock \url{http://www.gnu.org/software/guile/}.

\bibitem[KEP~03]{kephart03}
\textsc{Kephart J.}\andname{}\textsc{Chess D.}, \guilo{}The Vision of Autonomic
  Computing\guilf{},
\newblock \textit{Computer Magazine, IEEE}, , 2003.

\bibitem[KIC~97]{kiczales97}
\textsc{Kiczales G.}, \textsc{Lamping J.}, \textsc{Mendhekar A.}, \textsc{Maeda
  C.}, \textsc{Lopes C.}, \textsc{Loingtier J.-M.}\andname{}\textsc{Irwin J.},
  \guilo{}Aspect-Oriented Programming\guilf{},
\newblock \Inname{} \textsc{Aksit M.}\andname{}\textsc{Matsuoka S.},
  \editornames{}, \textit{ECOOP'97 --- The 11th European Conference on
  Object-Oriented Programming}, \volumename{} 1241 \ofname{} \textit{Lecture
  Notes in Computer Science}, Jyv{\"{a}}skyl{\"{a}}, Finland, \Jun{} 1997,
  Springer-Verlag,  \pagesname{} 220--242.

\bibitem[KOH~00]{kohler00}
\textsc{Kohler E.}, \textsc{Morris R.}, \textsc{Chen B.}, \textsc{Jannotti
  J.}\andname{}\textsc{Kaashoek M.~F.}, \guilo{}The Click modular
  router\guilf{},
\newblock \textit{{ACM} Transactions on Computer Systems}, \volumename\ 18,
  \numbername\ 3, 2000,  \pagesname{} 263--297.

\bibitem[MAE~87]{maes87}
\textsc{Maes P.}, \guilo{}Concepts and experiments in computational
  reflection\guilf{},
\newblock \textit{ACM SIG{\-}PLAN Notices}, \volumename\ 22, \numbername\ 12,
  1987,  \pagesname{} 147--155.

\bibitem[OGE~03]{ogel03}
\textsc{Ogel F.}, \textsc{Patarin S.}, \textsc{Piumarta
  I.}\andname{}\textsc{Folliot B.}, \guilo{}{C/SPAN: a Self-Adapting Web Proxy
  Cache}\guilf{},
\newblock \Inname{} \textit{Proceedings of the Autonomic Computing Workshop
  (AMS 2003)}, Seattle, WA, \Jun{} 2003.

\bibitem[PAT~03a]{patarin03fr}
\textsc{Patarin S.}, \guilo{}Pandora: support pour des services de m\'etrologie
  \`a l'\'echelle d'{I}nternet\guilf{},
\newblock PhD thesis, Universit\'e Pierre et Marie Curie -- Paris 6, \Jun{}
  2003.

\bibitem[PAT~03b]{patarin03a}
\textsc{Patarin S.}\andname{}\textsc{Makpangou M.}, \guilo{}{On-line
  Measurement of Web Proxy Cache Efficiency}\guilf{},
\newblock Research Report \numbername RR-4782, \Mar{} 2003, INRIA.

\bibitem[PAT~04]{patarin04a}
\textsc{Patarin S.}, \textsc{Salamatian K.}\andname{}\textsc{Friedman T.},
\newblock \guilo{}The {P}andora Network Monitoring Platform\guilf{}, \May{}
  2004,
\newblock Submitted for publication.

\bibitem[PAW~02]{pawlak02b}
\textsc{Pawlak R.}, \textsc{Duchien L.}, \textsc{Florin
  G.}\andname{}\textsc{Seinturier L.}, \guilo{}JAC : un framework pour la
  programmation orient�e aspect en Java\guilf{},
\newblock \textit{L'Objet}, \volumename\ 8, \numbername\ 4, 2002,  \pagesname{}
  135--158, Hermes.

\bibitem[PIU~01]{ogel01}
\textsc{Piumarta I.}, \textsc{Ogel F.}, \textsc{Baillarguet
  C.}\andname{}\textsc{Folliot B.}, \guilo{}Applying the VVM kernel to Flexible
  Web Caches\guilf{},
\newblock \Inname{} \textit{Proceedings of the IEEE Workshop on Hot Topics in
  Operating Sy stems, HOTOS-VIII}, Schloss Elmau, Germany, \May{} 2001,
  \pagename{} 155.

\bibitem[RIB~98]{ribler98}
\textsc{Ribler R.~L.}, \textsc{Vetter J.~S.}, \textsc{Simitci
  H.}\andname{}\textsc{Reed D.~A.}, \guilo{}Autopilot: Adaptive Control of
  Distributed Applications\guilf{},
\newblock \Inname{} \textit{Proceedings of the The Seventh IEEE International
  Symposium on High Performance Distributed Computing}, IEEE Computer Society,
  1998,  \pagename{} 172.

\bibitem[SMI~84]{smith84}
\textsc{Smith B.~C.}, \guilo{}Reflection and semantics in LISP\guilf{},
\newblock \Inname{} \textit{Proceedings of the 11th ACM SIGACT-SIGPLAN
  symposium on Principles of programming languages}, ACM Press, 1984,
  \pagesname{} 23--35.

\bibitem[WEL~01]{welsh01}
\textsc{Welsh M.}, \textsc{Culler D.~E.}\andname{}\textsc{Brewer E.~A.},
  \guilo{}{SEDA}: An Architecture for Well-Conditioned, Scalable Internet
  Services\guilf{},
\newblock \Inname{} \textit{18th Symposium on Operating Systems Principles},
  Lake Louise, Canada, \Oct{} 2001,  \pagesname{} 230--243.

\end{thebibliography}
