\documentclass{article}

\usepackage[left=2cm,top=1cm,right=2cm]{geometry}

\usepackage[french]{babel}
\usepackage[latin1]{inputenc}

\title{Etat de l'art sur la reconfiguration dynamique dans les systèmes répartis : synthèse.}
\author{Guillaume Libersat}


\begin{document}

\bibliographystyle{abbrv}

\maketitle
\tableofcontents

\newpage

\section{Introduction et notions}

\subsection{Dynamisme et reconfiguration}

Les changements technologiques de ces dix dernières années ont
fortement impacté la manière dont les équipement informatiques sont
utilisés et communiquent.

En effet, on tend de plus en plus vers des réseaux distribués de
grande envergure où les noeuds sont à la fois très hétérogènes et
volatiles.

Qu'il s'agisse de fluctuation d'intervenants (panne, déplacement
constant, ...), de leurs ressources (qualité de communication,
puissance liée à l'énergie, etc) ou encore de leurs besoins fonctionnels
(nouveaux besoins au cours du temps, ...), on regroupe ces
spécificités sous le terme de \textit{dynamicité}.

Face à celà, le logiciel doit lui aussi devenir dynamique
dans le sens où il doit constamment s'adapter aux nouvelles
contraintes évoluants au cours de son exécution.

\subsection{Types d'intergiciels}

Les intergiciels peuvent exister sous plusieurs formes, voici les deux
plus répandues :

\begin{enumerate}
\item Courtiers à objets (\textit{synchrone}) : l'intergiciel joue le rôle d'un bus de
  communication (\textit{ORB}) par lequel les demandes/réponses des objets vont être
  acheminées ;
\item Intergiciels orientés messages (\textit{asynchrone}) : L'intergiciel va jouer le rôle
  de boîte au lettre et les applications pourront s'envoyer des
  messages.
\end{enumerate}

\subsection{Le projet INSIDE}

Le but du projet INSIDE est de concevoir et valider une plate-forme
technique pour des services internet utilisant des données
d'équipements de distribution électrique.

Cette architecture met en oeuvre différents types de matériels et est
impactée par tous les critères de dynamicité précédemment évoqués.

Comme il est impensable d'arrêter les applications au cours de leur
exécutions, il sera nécessaire d'utiliser les techniques de
reconfiguration dynamique pour les propriétés non fonctionnelles ainsi
que pour les protocoles de communication.

La suite du document s'intéresse donc aux solutions existantes dans le
domaine de la reconfiguration automatique pour les systèmes
distribués. Ces solutions mettent en oeuvre les composants et la
réflexivité afin de fournir les services attendus.

Nous ne nous intéresserons qu'aux solutions dédiées aux couches
``Intergiciel'' et ``Application''.

\section{Solutions au niveau ``Intergiciel''}

\subsection{Les intergiciels réflexifs}

\subsubsection{CompOSE$|$Q}

CompOSE$|$Q\footnote{CompOSE$|$Q pour \textit{Composable Open Software
  Environment with QoS}} est une implémentation Java de
\textit{TLAM}\footnote{\textit{TLAM} signifie \textit{Two Level Actor Machine}} et
permet la création d'applications réparties lorsqu'il y a des
exigences de \textit{QoS}\footnote{\textit{QoS} pour \textit{Quality
    of Service}}.

TLAM met en oeuvre des acteurs pouvant communiquer par messages et
pouvant réagir lors de la réception d'un message.
TLAM fournit un moyen sûr de composer tous les acteurs et ceci à
l'aide de trois services de bases connus et spécifiés qui peuvent
ensuite être étendus.

Ces trois services de base sont les suivants : (i) la \textbf{création
d'acteurs} à distance, (ii) la \textbf{capture d'état} distribuée (pour
connaître l'état des acteurs distants), (iii) l'\textbf{annuaire}, recensant
les acteurs. Ainsi, l'implémentation CompOSE$|$Q propose en standard des services
dérivés de ceux-ci comme la \textit{migration d'acteurs}, un
\textit{ordonnanceur} ou encore un \textit{service de nom}.

D'un point de vue du respect de la \textit{QoS}, celle-ci est réalisée
via la gestion de la répartition des agents et la gestion des requêtes
adressées aux agents.

Enfin, dans CompOSE$|$Q, la modification dynamique des protocoles de
communication entre les acteurs est réalisée à l'aide de
RCF\footnote{RCF signifie \textit{Reflective Communication
    Framework}.}. Ce framework permet de construire des protocoles (à
l'aide de composition de protocoles élémentaires) et de les utiliser
de manière sûre (en prévenant les conflits avec les autres protocoles
et services utilisés).

\paragraph{Critique}

On peut dire que la force de CompOSE$|$Q réside dans sa possibilité de
pouvoir préciser des contraintes entre éléments et de les faire
respecter.

Cependant, on aimerait par exemple disposer d'un mécanisme
d'assurance de compatibilité entre les protocoles et services ou
encore avoir la possibilité d'exprimer des contraintes distribuées. De
plus, le modèle de communication impose un cheminement des messages
assez long, ce qui peut être gênant pour l'utilisation de CompOSE$|$Q
en environnements à ressources limitées.

La dernière publication date de 2004
(http://www.ics.uci.edu/~dsm/compose/), ce qui indique que Compose$|$Q
n'est plus maintenu ni développé.

\subsubsection{QuO}

QuO est une spécification d'intergiciel permettant de créer des
applications réparties (à objets) ayant des exigences en terme de QoS.
Ces contraintes sont exprimées sur l'ensemble de l'application et des
éléments sont chargés de mesurer et d'adapter l'architecture afin de
fournir la QoS attendue.

L'implémentation la plus aboutie repose sur CORBA et constitue une
couche entre ce dernier et les applications utilisant l'ORB.
Cette couche est composée de trois types d'éléments :
\begin{enumerate}
\item Les \textbf{contrats}, permettant d'exprimer les niveaux de QoS
  attendus/fournis ainsi que l'ensemble des états possibles vis à vis
  de la QoS (et la manière dont il faut passer de l'un à l'autre) ;
\item Les \textbf{délégués}, agissant selon les contrats afin de
  prendre les décisions d'adaptation ;
\item Les \textbf{objets de condition du système}, fournissant une
  interface vers les ressources, les objets et l'ORB (observés par les
  contrats).
\end{enumerate}

A noter que QuO permet aussi de gérer finement des propriétés de la
QoS à travers des éléments spécialisés ou encore de créer et utiliser
des protocoles spécifiques non fournis par l'ORB.

En ce qui concerne la reconfiguration dynamique, QuO la gère soit
\textit{en ligne}, c'est à dire autour des invocations de méthodes, ou
\textit{hors ligne} à l'initiative des contrats et des objets de
condition.

\paragraph{Critique}

Un des points forts de QuO est qu'il fournit des langages pour définir
les contrats et délégués. On peut ainsi avoir une distinction claire
avec le code fonctionnel.

En revanche, QuO ne permet par exemple pas de modifier dynamiquement
les politiques d'adaptation ni de rajouter des fonctionnalités pendant
l'exécution. On n'obtient donc pas une vraie possibilité de
reconfiguration dynamique car il faut travailler avec les éléments
prédéfinis.

La dernière version de QuO
(http://qualityobjects.org/release/latest/index.html) date de
Septembre 2004. Cet intergiciel n'est plus maintenu.

\subsection{Les intergiciels à composants}

\subsubsection{Cactus}

Cactus est une technologie permettant la création d'intergiciels
fiables (grâce à une suite d'outils dédiés) 
et est particulièrement choisie pour la conception de protocoles
réseaux.

Elle n'est pas elle-même une solution permettant d'effectuer de la
reconfiguration dynamique, mais il existe des instances de celle-ci
qui le permettent.

Cactus est composé de modules qui sont eux-mêmes composés de
micro-protocoles. Ces derniers répondent à des événements à travers
des gestionnaires d'événements personnalisés.

Le système fonctionne alors en réagissant aux différents
événements. Cependant, les éléments peuvent aussi communiquer à
travers d'autres mécanismes comme les appels de méthodes.

Cactus s'occupe de vérifier que l'assemblage des composants est valide
en utilisant les relations de propriétés exportées par ces derniers
(conflit, dépendance, ...).


\paragraph{Critique}

On pourra remarquer que le modèle de composition de Cactus est plat
et imposé, ce qui est gênant pour la construction de systèmes
complexes (rendre le modèle récursif résoudrait ce problème).

De plus, il semblerait que les relations entre composants manquent
d'expressivité (pas de notion de temps, ...).

Enfin, selon le site internet, cactus n'a pas eu de mise à jour depuis
2002 (http://www.cs.arizona.edu/projects/cactus/).


\subsubsection{GORDA/Appia}

\textit{GORDA}(FIXME) est une spécification d'intergiciel ayant
pour but la réplication des bases de données. Son implémentation de
référence s'appelle \textit{Sequoia}(FIXME). Cette dernière utilise
Appia(FIXME), un framework pour les communication mettant en oeuvre la
reconfiguration dynamique pour arriver à son but.

Appia est organisé en couches et dispose d'une grande flexibilité. Son
but est la construction de protocoles de communication complexes et
distribués pour les applications. Il est implémenté en Java.

Appia met aussi l'accent sur le respect de la \textit{QoS} et fournit
des mécanismes de synchronisation entre différents canaux de
communication ainsi qu'en ensemble de services utilitaires
(chiffrement, détection d'erreurs, ...).

Pour réussir son pari, Appia utilise la composition et la
réutilisation de composants. Il utilise un design flexible et
modulaire, ce qui permet de reconfigurer les piles de protocoles
dynamiquement.

\paragraph{Critique}

Appia semble être la combinaison de plusieurs projets du domaine. Il
se base particulièrement sur l'expérience d'intergiciels (Cactus) et
de protocoles noyau (Ensemble, Coyote~\cite{bhatti98coyote}, ...)(FIXME!).

A l'heure actuelle, Appia est sorti en version 4.0 il y a un mois et
semble être activement maintenu (FIXME : http://appia.di.fc.ul.pt).

\subsubsection{Une infrastructure pour la modification dynamique d'algorithmes}

Cette infrastructure se découpe en trois couches, selon la répartition
habituelle (Système d'exploitation, Intergiciel et Application).
Il est possible de rendre adaptable chacune de ces couches et ainsi
permettre la modification des algorithmes à la volée et ce, sans
interruption de service.
Chacune des couches rendue adaptable sera alors décomposée en
composants adaptables (\textit{AC}) et un contrôleur d'adaptation sera
en charge de coordonner l'adaptation de ces derniers.

Ces \textit{AC} sont eux-mêmes composés de deux types de modules. Le
premier (appelé \textit{CAM}\footnote{CAM pour Component Adapator
  Module}) permet de choisir le meilleur algorithme (parmi ceux
disponibles) pour une fonctionnalité donnée tandis que le second
(appelé \textit{AAM}\footnote{AAM pour Adaptation-Aware Module})
permet de décrire les différents algorithmes éligibles.

Lorsqu'un changement de configuration intervient, il se déroule selon
ces trois phases :

\begin{enumerate}
\item \textbf{Détection du changement} : A la demande d'un composant, le
  \textit{CAM} évalue les besoins du moment et décide du besoin
  d'un changement d'\textit{AAM} ;
\item \textbf{Accord} : Les \textit{CAM} des différents sites trouvent alors un
  consensus sur le changement d'un \textit{AAM}. A la fin de cette
  phase, chaque \textit{CAM} connaît le remplacement qu'il doit effectuer
  (s'il y a lieu) ;
\item \textbf{Action d'adaptation} : Réalisée en trois étapes, cette phase
  permet le changement d'un \textit{AAM} de manière fluide (pas
  d'interruption, pas de perte de messages, ...) vers le nouvel
  \textit{AAM} élu à l'étape précédente.
\end{enumerate}

\paragraph{Critique}
Parmi ses points forts, on notera qu'elle propose une méthode intégrale
pour l'adaptation et qu'elle a été conçue de manière à permettre des
changements sans perte ni interruption, tout ceci de manière distribuée.

On remarquera pourtant que les travaux, à l'heure actuelle, ne se sont
concentrés que sur les \textit{AC}. La solution n'est donc pas encore
développée intégralement.
Enfin, il n'est ni possible de coordonner les \textit{AC} d'un même
site, ni d'avoir des politiques de choix dynamiques (elles sont figées
au niveau des \textit{CAM}), ni d'organiser les \textit{AC} de manière
hiérarchique (ce qui pose des problème pour le passage à l'échelle).

Pour finir, on notera que toute la dynamicité s'exprime uniquement sur
les algorithmes et non sur la structure et les fonctionnalités de
l'infrastructure.

FIXME: mAJ ?

\subsection{Les intergiciels réflexifs à composants}

\subsubsection{dynamicTAO}

DynamicTAO est un intergiciel écrit en C++ qui se base sur TAO, un ORB
faisant usage des composants et conçu pour les applications
temps réelles. TAO ne possède cependant pas de mécanisme de
reconfiguration dynamique.


DynamicTAO vient ajouter cette fonctionnalité manquante et permet donc
l'introspection et la reconfiguration de l'ORB et de ses objets
serveurs.

Afin de proposer ces mécanismes, dynamicTAO utilise des
\textit{configurateurs de composants} qui gèrent les dépendances entre
composants. Cette notion de dépendance est à la base du processus de
reconfiguration ; il en existe d'ailleurs deux types :

\begin{enumerate}
\item Les \textbf{pré-requis} : les dépendances sur des
  composants matériels et logiciels permanents ;
\item Les \textbf{dépendances dynamiques} : les dépendances sur des composants à un
  moment donné. Elles sont gérées par les \textit{configurateurs de
  composants} qui peuvent manipuler dynamiquement les listes de dépendances.
\end{enumerate}

Les \textit{configurateurs de composants} ont pour rôle primaire de
remplacer un composant de façon sûre. Le remplacement est effectué en
respectant deux propriétés (pas d'utilisation en cours du composant et
transfert de l'ancien vers le nouvel état).

En ce qui concerne l'architecture mise en oeuvre pour effectuer la
reconfiguration, dynamicTAO propose un service de reconfiguration
(``\textit{Dynamic service configurator}'') qui permet de piloter les
concepts offerts de plusieurs façons (comme depuis le réseau).
 
\paragraph{Critique}
Un des points forts de DynamicTAO est la séparation nette des
concepts. Ensuite, il garanti qu'une reconfiguration ne sera effectuée
que si les composants concernés ne sont plus utilisés.

En ce qui concerne ses limitations, on notera sa difficulté de
configuration (due à ses origines) et sa rigidité sur certains aspects
(par exemple, il faut déployer plusieurs instances de l'ORB si on veut
différentes configurations pour les servants). Afin de résoudre ces
problèmes, les auteurs ont développé LegORB, un
micro-ORB, mais ce dernier n'est malheureusement ni complet, ni
maintenu (FIXME: Vérifier!!).

Ensuite, son modèle de réflexivité ne s'oriente que sur l'aspect
structurel et il ne gère pas les dépendances inter-sites.

\subsubsection{OpenORB}

OpenORB est un intergiciel réflexif à composants qui a pour objectif
de fournir un canevas de construction pour intergiciels dynamiquement
reconfigurables (particulièrement dans le domaine des applications
multimédia et mobiles).


Les dernières versions d'OpenORB utilisent le modèle de composants
OpenCOM\footnote{Une extension allégée du modèle de composants COM de
  Microsoft}, qui a été développé avec la création d'intergiciels en
tête. Ce dernier permet de faciliter l'intégration des
méta-modèles avec des extensions dédiées (possibilité d'expliciter les
dépendances entre composants, possibilité d'insérer des intercepteurs,
ajout de mécanismes d'introspections et de mutex\footnote{Un verrou
  garantissant un accès exclusif sur une ressource.} sur les
composants). Ensuite, le modèle incite au regroupement des composants
d'un même domaine ce qui permet, entre autres, de faciliter la
composition de composants.

Une instance d'OpenORB est donc un assemblage de composants
OpenCOM qui peut être modifié en cours d'exécution.

Chaque composant possède un méta-espace qui est structuré en
méta-modèles et offre divers niveaux de réflexion :
\begin{itemize}
\item \textbf{Réflexion structurelle} : Elle fournit une
  représentation du contenu et de l'architecture du composant. Deux
  méta-modèles lui sont associés : (i) \textit{Interface}, donnant
  accès aux interfaces requises et fournies ; (ii)
  \textit{Architecture}, donnant accès aux interconnexions avec les
  autres composants ainsi qu'aux contraintes architecturales.
\item \textbf{Réflexion comportementale} : Cette réflexion permet de
  contrôler les activités du système. Deux méta-modèles la mettent en
  oeuvre : (i) \textit{Interception}, permettant l'ajout dynamique de
  traitements lors des interactions avec les composants ; (ii)
  \textit{Ressources}, permettant de contrôler et d'adapter selon les
  ressources.
\end{itemize}


\paragraph{Critique}

Concernant les défauts d'OpenORB, on notera l'impossibilité de créer
d'autres méta-modèles pour les composants ni de créer des composants
composites. Ensuite, la manière dont l'intergiciel doit être construit est
relativement lourde et peut être pénalisante dans des environnements
contraints.

Enfin, OpenORB ne garanti pas un maintien de l'intégrité du système
d'un point de vue distribué. Il faudrait pour cela adapter OpenCOM
afin de fournir les primitives nécessaires à la communication
inter-sites.

C'est pourquoi, les auteurs d'OpenORB travaillent actuellement(FIXME
http://www.comp.lancs.ac.uk/computing/research/mpg/reflection/ooimpl.php)
sur une nouvelle génération d'ORB qui utilisera OpenCOM2~\cite{coulson04component}.

Celle ci n'est plus basée sur DCOM et devient indépendante de la
plate-forme. De plus, le modèle est intrasèquement reconfigurable et
incorpore les méta-niveaux d'OpenORB2.

\subsubsection{FlexORB}

FlexORB~\cite{flexorb} est un ORB basé sur
Think~\cite{fassino02think}, une implémentation C du modèle de
composants Fractal~\cite{bruneton02recursive}.

Il s'agit d'une réponse aux besoins de mobilité et aux contraintes des
systèmes embarqués vis à vis des ORB. FlexORB dispose donc d'une
empreinte mémoire réduite (env. 120ko), on le classe dans la catégorie des
micro-ORB.


FlexORB est basé sur la plate-forme
\textit{NEVERMIND}, un environnement
d'exécution minimal utilisant la réflexivité à la compilation et
faisons usage d'un \textit{HAL}\footnote{\textit{HAL} pour
  \textit{Hardware Abstraction Level}}. 

C'est grâce à cette plate-forme que FlexORB peut fournir des services
évolués comme l'utilisation de code mobile, le déploiement des
composants ou la reconfiguration dynamique.

\paragraph{Critique}

FlexORB mise sa capacité d'adaptation et son efficacité sur sa
minimalité. Le pari semble être en partie rempli car FlexORB est
capable de s'exécuter sur de nombreuses plate-formes tout en
fournissant une vitesse d'exécution au moins aussi bonne que les ORB
traditionnels.

Cependant, FlexORB ne garanti pas l'intégrité du système lors du
déploiement et des reconfigurations. De plus, les outils fournis par
\textit{NEVERMIND} ne sont pas suffisants et un \textit{DSL}
permettant d'exprimer des règles de garantie d'intégrité et de
sécurité semble nécessaire.

FIXME : maintenance ?

\subsubsection{DREAM}

\textit{DREAM}\footnote{\textit{DREAM} pour \textit{Dynamic REflective
    Asynchronous Middleware}} est un canevas dédié à la création
d'intergiciels orientés messages (\textit{MOM}) dynamiquement
reconfigurables.

Tout d'abord, \textit{DREAM} est basé sur
Fractal~\cite{bruneton02recursive} et fournit un ensemble de
composants fonctionnels et non-fonctionnels (files, routeurs, ...).
Il étend aussi l'\textit{ADL} de Fractal afin de permettre la
reconfiguration structurelle et la reconfiguration
d'implémentation.

Enfin, \textit{DREAM} propose des outils permettant la vérification
(au niveau typage) des échanges ainsi que des outils pour la mise en
oeuvre des éléments développés (configuration, déploiement, ...).

\paragraph{Critique}

Ce canevas a pour avantage de définir les concepts de manière claire
et permet la construction d'intergiciels grâce à la composition
de composants qu'il fournit.
Il a aussi l'avantage de reposer sur un système de composants
flexible et de proposer des outils pour assister le développeur.

Enfin, \textit{DREAM} semble apporter une architecture qui permet de
maintenir une vitesse d'exécution comparable aux intergiciels
traditionnels tout en apportant un niveau de reconfiguration bien plus
élevé.

On pourra toute de même noter que \textit{DREAM} ne permet cependant
pas, à l'heure actuelle, de construire des intergiciels synchrones. De
plus, il serait intéressant que les outils de vérifications puissent
garantir les assemblages des composants.

En ce qui concerne la vivacité du projet, bien qu'il n'y ai pas eu de
release depuis 2005, le dépôt de \textit{DREAM} est actif, ce qui
signifie que le projet est maintenu.

\section{Solutions au niveau ``Application''}

\subsection{Langages de description d'architectures (ADL)}

\subsubsection{Polylith}

Polylith est un ADL qui permet de construire des applications en
assemblant des modules à l'aide d'un langage spécifique
(\textit{MIL}\footnote{\textit{MIL} pour \textit{Module
    Interconnection Language}}).


Il fournit un bus logiciel qui permet d'exécuter l'application
et de faire communiquer les composants. Les connecteurs sont
d'ailleurs automatiquement transcrits vers la forme la plus idéale
(appel de fonction, RPC, etc...).
Le bus fournit aussi des opérations simplifiant les reconfigurations :
création/destruction d'un module à distance, blocage des canaux de
communication, modification des interconnexions et migration de
modules.
A l'aide de ces opérations, il permet des changements de structure
ainsi que des changements de géométrie (migration inter-sites des
modules) pendant son exécution.


\paragraph{Critique}

Un des soucis de Polylith est qu'il a besoin de points de
sauvegarde/restauration qui doivent être déterminés par le
programmeur. Ceci a pour impact de restreindre la flexibilité des
reconfigurations et demande des efforts importants au programmeur.

Enfin, on pourra aussi noter que cet ADL ne permet pas la construction
de modules composites, ce qui peut poser des problèmes de passage à
l'échelle.

FIXME: maj ?

\subsubsection{Darwin}

Darwin fournit un langage permettant de décrire la configuration d'une
application. Un de ses avantages est qu'il permet de spécifier des
configurations complexes et paramétrables.

Darwin distingue deux types de composants : (i) les \textbf{composants primitifs}, contenant le code fonctionnel
  ; (ii) les \textbf{composants composites}, qui encapsulent d'autres
  composants et fournissent une hiérarchisation de l'application.

On notera que le langage permet de décrire des créations dynamiques de
composants (à l'aide d'opérateurs de conditions). La limitation est
qu'un composant ``statique'' ne pourra pas communiquer avec une
instance dynamiquement créée.

En ce qui concerne l'exécution, toutes ces descriptions sont
transformées vers des classes C++ et la communication est réalisée à
l'aide du support d'exécution Regis.

Les reconfigurations sont effectuées en suivant un algorithme mis en
oeuvre par un gestionnaire centralisé. Cet algorithme, pour schématiser,
détermine la liste des composants à geler/rendre passif ; déconnecte
et retire les élus ; crée le nouveau composant et reconnecte/réactive
le tout. Il permet particulièrement d'obtenir un état cohérent avant
d'effectuer des changements.

\paragraph{Critique}

Pour conclure, on remarquera tout de même que si Darwin permet de bâtir
des applications de manière hiérarchique, il a le défaut de n'utiliser
qu'un gestionnaire (ce qui peut poser problème pour le passage à
l'échelle). De plus, ce dernier n'incorpore pas la gestion des pannes.

Ensuite, l'algorithme utilisé a un coût de traitement assez élevé et
provoque une perturbation importante de l'application quand il est mis
en oeuvre.

FIXME: maj ?

\subsubsection{Spécification de la structure logique d'un système}

Il s'agit d'une méthode relativement récente qui propose d'ajouter la
notion de \textit{structure logique} à l'habituelle \textit{structure
technique} (la configuration des composants).
Cette \textit{structure logique} est en fait une description de
l'application d'un point de vue fonctionnel.

Cette méthode utilise la notion de \textit{service} pour ses
composants. Un \textit{service} est une entité sans structure définie
par un ensemble d'interfaces et spécifiant un comportement. Il peut
exprimer des dépendances sur d'autres \textit{services}.

L'utilisation de cette méthode permet des reconfigurations dynamiques
qui consistent à changer l'architecture technique en gardant les mêmes
fonctionnalités (donc la même \textit{structure logique}). Ce sont
d'ailleurs les seules autorisées.
Ces reconfigurations sont effectuées à l'aide de trois opérations :
(i) ajout/retrait de composants, (ii) ajout/retrait d'une liaison et
(iii) migration d'un composant.

\paragraph{Critique}

Cette méthode ne possède aucune implémentation à l'heure actuelle, ce
qui rend difficile la critique par manque de données.

\subsubsection{ADL permettant la vérification de la dynamique des architectures}

Rapide et Wright sont deux \textit{ADL} permettant d'utiliser la description de
l'application pour effectuer des vérifications formelles.

Rapide permet en particulier de simuler l'évolution des applications
et de vérifier des propriétés sur leur exécution. Avec Rapide, une
application est modélisée sous la forme d'un ensemble de composants
pouvant communiquer en manipulant des événements. La simulation est
alors une suite d'événements (appelés \textit{posets}).
En utilisant les relations et propriétés des \textit{posets}, Rapide
peut vérifier de manière formelle les contraintes spécifiées à l'aide
d'un langage dédié. De plus, un outil permet de vérifier que
l'implémentation associée est elle aussi valide.

Wright est un langage ayant le même objectif que Rapide. Il utilise un
calcul proche de \textit{CSP}\footnote{\textit{CSP} pour
  \textit{Communications Sequential Processes}}, qui décrit le
comportement d'une architecture logicielle à travers un modèle
algébrique de processus. En utilisant cette méthode, Wright permet de
vérifier des propriétés (comme l'absence d'interblocage).

\paragraph{Critique}

Bien que ces ADL ne permettent pas de déployer les applications
décrites, les fonctionnalités décrites pourraient être utilisées pour
modéliser et prévoir les changements lors des reconfigurations afin de
vérifier si elles sont valides.

On pourrait cependant exprimer une réserve sur ce modèle : le passage
à l'échelle n'est pas garanti.

\subsection{Utilisation des modèles de composants}

\subsubsection{DCUP/SOFA2}

\textit{DCUP}\footnote{\textit{DCUP} pour \textit{Dynamic Component
    UPdating}} est un modèle de composants récursif disposant d'une
architecture très spécifique et a pour but de permettre des
reconfigurations dynamiques. Il fait partie du projet \textit{SOFA}
(FIXME! http://sofa.objectweb.org/sofa1/index.html).

Une application \textit{DCUP} est une imbrication hiérarchique de
composants, qui sont eux-même composés d'un ensemble d'objets.

Un composant \textit{DCUP} peut être considéré sous plusieurs aspects
:
\begin{itemize}
\item L'aspect ``nature des opérations fournies''
  \begin{itemize}
  \item Partie \textit{fonctionelle} : elle contient des objets, des
    sous-composants et des wrappers ;
  \item Partie \textit{contrôle} : elle contient les outils permettant
    d'effectuer le remplacement des composants dans de bonnes
    conditions (construction/destruction, gestion des références,
    ...).
  \end{itemize}
\item L'aspect ``mise à jour dynamique''
  \begin{itemize}
  \item Partie \textit{permanente} : la partie statique des composants
    (exemple : wrappers) ;
  \item Partie \textit{remplaçable} : la partie composée d'objets
    versionnés.
  \end{itemize}
\end{itemize}

Une mise à jour d'un composant est effectuée selon la procédure
suivante : les gestionnaires des deux versions de composants
coopèrent et la mise à jour est ensuite obtenue auprès du fournisseur
de composants.
Une fois la nouvelle version disponible, les nouvelles classes
nécessaires sont téléchargées, l'ancien composant est détruit (et son
état est sauvegardé) et la nouvelle version est instanciée (et dispose
d'un accès à l'état sauvegardé).

\paragraph{Critique}

De part sa structure, \textit{DCUP} semble bien s'adapter au passage à
l'échelle. Cependant, on notera des points noirs comme le fait que des
parties pouvant remettre la cohérence du système en jeu doivent être
gérées par le développeur. Enfin, si l'on souhaite
reconfigurer une liaison, il est nécessaire de changer le composant
l'encapsulant (et donc tous ses sous-composants), ce qui peut être
coûteux s'il se situe en haut de la hiérarchie.

Depuis 2006, \textit{DCUP} a été remplacé son successeur,
\textit{SOFA2}~\cite{1158398}. Ce dernier est activement maintenu et
améliore l'architecture sous plusieurs aspects (FIXME: Développer!!).

\subsubsection{ScalAgent}

ScalAgent est une plate-forme destinée à la création d'applications
distribuées asynchrones. Elle fournit principalement trois éléments :
(i) un modèle de composants, (ii) une infrastructure d'exécution et
(iii) un ensemble d'outils (déploiement, description, ...).

Le modèle de composants (asynchrone et hiérarchique) décompose ces
derniers en deux parties : (i) la \textit{partie fonctionnelle}, contenant
les fonctions applications et (ii) le \textit{conteneur}, contenant les
éléments non fonctionnels (activation, déploiement, ...).

En ce qui concerne l'infrastructure d'exécution (basée sur
\textit{AAA}\footnote{\textit{AAA} pour \textit{Agent Anytime
    Anywhere}}), elle met en oeuvre des entités appelées ``agents''
qui réagissent aux événements. Ces agents évoluent dans un
\textit{serveur d'agents} qui instaurent les propriétés suivantes :
atomicité des réactions, persistance de l'état et ordonnancement
causal des événements.

D'un point de vue outils, ScalAgent fournit le nécessaire pour aider à la
construction et la gestion des applications. Ils sont basés sur l'\textit{ADL}
\textit{OLAN}\footnote{\textit{OLAN} pour \textit{FIXME!!}} et ont la
particularité de refléter la structure en arbre des applications.

\paragraph{Critique}

Cette plate-forme assure le passage à l'échelle de par sa
hiérarchisation mais ne permet cependant que de construire des
applications asynchrones. On notera aussi l'absence d'outils de
vérifications.

FIXME: maj?

\subsubsection{Fractal}

Fractal~\cite{bruneton02recursive} est un modèle de composant ouvert
et versatile qui se veut modulaire, extensible et indépendant des
langages de programmation.

Le modèle de composant de Fractal est hiérarchique (un composant peut
contenir d'autres composants) et réflexif. Il a aussi la particularité
de permettre le \textbf{partage d'instances} entre composants et de
n'imposer aucun modèle d'exécution.

Un composant Fractal est tout d'abord composé d'une membrane
(\textit{composite} ou \textit{primitive}) qui joue le rôle de
``conteneur''. Ensuite, le composant définit ses interfaces
fournies/requises ainsi que leurs connexions. Un composant dispose
aussi par défaut de plusieurs contrôleurs (s'occupant de l'aspect
non-fonctionnel) qu'il est possible de remplacer si besoin est.

\paragraph{Critique}

Fractal est un modèle de composants moderne regroupant la plupart des
expériences du domaine. On notera qu'il est indépendant des langages,
ce qui lui permet, entre autres, d'être présent à plusieurs niveaux
applicatifs. De part l'organisation de ses contrôleurs et son modèle
hiérarchique, Fractal semble pouvoir réussir aisément un passage à
l'échelle.

On notera cependant que la configuration des composants peut s'avérer
fastidieuse, même avec l'ADL proposé (utilisation d'XML). Cependant,
un certain nombre d'outils commencent à émerger, ce qui permettrait de
résoudre ce problème.

Enfin, Fractal dispose actuellement de plusieurs implémentations pour
divers langages et est activement maintenu et développé.

\subsubsection{OSGi}

\textit{OSGi}\footnote{\textit{OSGi} pour \textit{Open Services Gateway
    Initiative}}(FIXME: Ref) est une initiative industrielle qui a
pour but de produire les spécifications d'une plate-forme de services
basée sur Java.
Une partie centrale de cette plate-forme est le framework qui
implémente un modèle de composants dynamiques. Ces composants et leurs
ressources sont en fait contenus dans des archives \textit{JAR} et
sont appelés ``bundles''.

Les bundles déclarent un ensemble de services requis/fournis selon le
type de correspondant.
Ces bundles peuvent être installés, démarrés, arrêtés, mis à jour et
supprimés à distance sans besoin de redémarrage de l'application. Ces
derniers peuvent d'ailleurs écouter ces événements afin de s'adapter
si nécessaire.
Lors de leur insertion dans le système, les bundles doivent publier
une interface leur correspondant et peuvent adjoindre un ensemble de
propriétés.

Le framework offre aussi la possibilité intéressante de télécharger les
politiques d'adaptation à la volée.

\paragraph{Critique}

Le modèle de composants d'\textit{OSGi} a beaucoup évolué depuis les
dernières versions. Il semble bien s'adapter au passage à l'échelle
vis à vis de sa structure récursive et de la distribution des
services.

Cependant, on notera qu'\textit{OSGi} ne garanti pas l'intégrité du
système lors des remplacements de composants.

Enfin, \textit{OSGi} est activement maintenue et est dotée de
plusieurs implémentations actives.

\subsection{Technologies réflexives}

\subsubsection{DART}

DART fournit un canevas pour la construction d'applications C++
adaptables à objets. Ces dernières s'adaptent aux changements de
ressources dans leur environnement, et ceci grâce à l'utilisation de
la réflexivité.

DART permet de construire deux types de méthodes :
\begin{enumerate}
\item Les \textbf{méthodes adaptables} : elles permettent de fournir plusieurs
  implémentations d'une même méthode. Le choix de la méthode la mieux
  adaptée est réalisée par un \textit{sélecteur}.
\item Les \textbf{méthodes réflexives} : L'objet est associé à un méta-espace
  qui fournit des services. Ces derniers sont représentés par des pré et
  post-traitements au niveau des méthodes. Les services sont fournis
  par les \textit{réflecteurs}.
\end{enumerate}

En ce qui concerne la plate-forme, elle fournit un composant appelé
\textit{gestionnaire} qui est en charge des modifications précédemment
citées. Ces adaptations interviennent lors de la réception d'un
événement qui peut être généré soit par le \textit{gestionnaire} lui
même ou par d'autres objets. Les changements à effectuer sont régis
par les \textit{politiques d'adaptation} contenues dans le
\textit{gestionnaire}.


DART fournit aussi un compilateur qui permet d'automatiser certaines
tâches comme la génération des \textit{sélecteurs} et
\textit{réflecteurs} ou encore de modifier automatiquement les classes
pour leur permettre de communiquer avec les composants systèmes.


\paragraph{Critique}

En ce qui concerne ses limitations, DART ne permet pas de
modifier dynamiquement la structure de l'application et son
utilisation de la réflexivité à un grain fin peut poser des problèmes
de performance. De plus, DART impose au développeur de programmer des
parties non triviales (comme les \textit{politiques d'adaptation}).
Enfin, on notera qu'il aurait pu être intéressant d'avoir une version
distribuée de l'architecture car, pour le moment, la portée des
événements est limitée à un unique site.

FIXME: maj ??

\subsubsection{Ajout de réflexivité à la compilation en Java}

Il s'agit d'une méthode proposant d'ajouter de la réflexivité de manière
transparente aux applications Java. Le but est de réussir à adapter
les services non-fonctionnels (gestion de la distribution, ...) aux
conditions d'exécution.

Un \textit{moteur d'adaptation} prend les décisions de changements à
l'aide de l'observation des ressources physiques (grâce à un système de
représentation en arbre du matériel) et du comportement de
l'application, tout ceci en cohérence avec des \textit{politiques
  d'adaptation}. Ces dernières sont définies dans un fichier
de configuration qui précise l'ensemble des règles à suivre pour
déterminer les actions à mener selon les cas.

Le but des concepteurs est de n'imposer aucune des contraintes du
modèle de composants (pas d'interface, ...). L'application est
simplement compilée à l'aide d'un compilateur dédié qui modifie les
classes (en les encapsulant dans un conteneur).

Ce conteneur va avoir la fonction détourner les appels de méthodes et
les accès aux champs. Il est alors possible d'effectuer des
traitements autour des méthodes (\textit{adjonction de code non
  fonctionnel}) et d'introspecter l'application.

\paragraph{Critique}

En ce qui concerne les limitations de cette méthode, on notera que la
réflexivité est appliquée à un grain très fin, ce qui peut dégrader
considérablement les performances de l'application. Enfin,
l'approche est centralisée (le \textit{moteur d'adaptation} ne prend
en compte que les données locales), on aurait aimé voir une version
capable de s'adapter dans le cadre d'une application distribuée.


FIXME: maj ?

\subsection{Méthodes ad-hoc sur technologies existantes}

\subsubsection{Reconfiguration avec les EJB}

Cette méthode basée sur les \textit{EJB}\footnote{\textit{EJB} pour
  \textit{Enterprise Java Beans}} propose un mécanisme d'ajout
d'opérations de contrôle entre les invocations.
Ces opérations, appelées \textit{services}, interceptent les appels de
méthodes au niveau client et peuvent ainsi effectuer des traitements.

La création d'un \textit{service} se fait à l'aide d'un langage
(\textit{ISL}\footnote{\textit{ISL} pour \textit{Interaction
    Specification Language}}) qui modifie le pattern d'interaction
entre deux composants.
Il est aussi possible de fusionner des patterns afin d'exprimer des
besoins plus complexes. Le comportement résultant de la fusion reste
connu ce qui permet d'utiliser ces informations pour garantir des
propriétés (comme la compatibilité entre patterns).

\paragraph{Critique}

Cette solution est intéressante par le fait est qu'elle repose sur un
standard industriel et qu'elle permet de garantir des propriétés par
simple analyse des patterns.

Cependant, sa portée se limite aux interactions client-serveur et ses
capacités de reconfiguration sont limités (pas de reconfiguration au
niveau structurel, seul le côté client est modifiable, ...).

FIXME : Maintenance ?

\subsubsection{Reconfiguration avec CORBA}

Ce modèle, appelé \textit{DRS}\footnote{\textit{DRS} pour
  \textit{Dynamic Reconfiguration System}} permet d'ajouter de la
reconfiguration dynamique pour les applications utilisant l'ORB CORBA
en mode client/serveur.

Le modèle permet de remplacer les objets serveurs en garantissant des
propriétés d'intégrité (cohérence garantie, impact minimum,
transparence, ...).

Afin de garantir la cohérence des applications reconfigurées, \textit{DRS}
garantie (i) l'intégrité structurale (le nouvel objet sera toujours
compatible), (ii) la consistance mutuelle des états (le fait qu'il n'y aura
pas de rupture de communication lors d'un changement) (iii) le respect
des invariants de l'application.

Pour effectuer ces reconfigurations, \textit{DRS} met en oeuvre un
composant centrale appelé \textit{Reconfiguration Manager}. C'est à
travers lui que les reconfigurations vont être initiées. A l'aide
d'autres services, il va envoyer les ordres de gestion des objets sur
les différents sites. Ces services vont alors garantir que la
migration se passe comme souhaitée.

\paragraph{Critique}

\textit{DRS} présentent des caractéristiques intéressants comme le fait
que les reconfigurations soient transparentes pour le client. Ceci
facilite par ailleurs le développement des composants.

Cependant, cette méthode a l'inconvénient de ne pouvoir s'appliquer
qu'au modèle client/serveur. De plus, l'algorithme utilisé pour
garantir la cohérence de l'état du système lors d'un changement
entraîne une surcharge assez importante du système.

FIXME: maj


\newpage
\bibliography{intergiciels}

\end{document}