Support pour la reconfiguration d'implantation dans les applications � composants Java
Jakub Korna\'s \andauthor Matthieu Leclercq \andauthor Vivien Qu\'ema
Jean-Bernard Stefani
Nowadays, numerous component models are used for various purposes: to build applications, middleware or even operating systems. Those models commonly support structure reconfiguration, that is modification of application's architecture at runtime. On the other hand, very few allow implementation reconfiguration, that is runtime modification of the code of components building the application. In this article we present the work we performed on {\julia}, a Java-based implementation of the {\fractal} component model, in order for it to support implementation reconfigurations. We show how we overcame the limitations of Java class loading mechanism to allow runtime modifications of components' implementation and interfaces. We also describe the integration of our solution with the {\julia} ADL.
decor2004.tex
\documentclass[french]{article-hermes}
\usepackage{graphicx}
\newtheorem{definition}{Definition}
\newtheorem{law}{Law}
\newcommand{\julia}{\textsc{Julia}}
\newcommand{\fractal}{\textsc{Fractal}}
\begin{document}

\title[Reconfiguration d'implantation]{Support pour la reconfiguration d'implantation dans les applications � composants Java}

\author{Jakub Korna\'s \andauthor Matthieu Leclercq \andauthor Vivien Qu\'ema\\Jean-Bernard Stefani}

\address{Laboratoire LSR-IMAG (CNRS, INPG, UJF) - INRIA - projet Sardes\\
INRIA Rh�ne-Alpes, 655 av. de l'Europe, F-38334 Saint-Ismier cedex\\
Prenom.Nom@inrialpes.fr}

\resume{
De nombreux mod�les de composants sont aujourd'hui utilis�s � des fins vari�es~: construction d'applications, d'intergiciels, ou encore de syst�mes d'exploitation. Ces mod�les permettent tous des reconfigurations de structure, c'est-�-dire des modifications de l'architecture de l'application. En revanche, peu permettent des reconfigurations d'implantation qui consistent � modifier dynamiquement le code des composants de l'application. Dans cet article nous pr�sentons le travail que nous avons effectu� dans {\julia}, une impl�mentation Java du mod�le {\fractal}, pour permettre le dynamisme d'implantation. Nous montrons comment les limitations du m�canisme de chargement de classes Java ont �t� contourn�es pour permettre de modifier les classes d'impl�mentation et d'interfaces des composants. Nous d�crivons �galement l'int�gration de notre proposition avec l'ADL de {\julia}.
}

\abstract{Nowadays, numerous component models are used for various purposes: to build
applications, middleware or even operating systems. Those models
commonly support structure reconfiguration, that is modification of
application's architecture at runtime. On the other hand, very few allow
implementation reconfiguration, that is runtime modification of the code
of components building the application. In this article we present the
work we performed on {\julia}, a Java-based implementation of the {\fractal}
component model, in order for it to support implementation
reconfigurations. We show how we overcame the limitations of Java class
loading mechanism to allow runtime modifications of components'
implementation and interfaces. We also describe the integration of our
solution with the {\julia} ADL.
}

\motscles{Syst�mes � composants, Java, Reconfiguration dynamique, Class loader, Fractal}

\keywords{Component-based systems, Java, Dynamic reconfiguration, Class loader, Fractal}

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

\maketitlepage

\section{Introduction}

Les mod�les de composants ont fait leur apparition dans les deux derni�res d�cennies. Ils sont d�sormais utilis�s pour construire de nombreux syst�mes, aussi bien au niveau applicatif (EJB~\cite{ejb02}, CCM~\cite{ccm01}) qu'au niveau intergiciel (dynamicTAO~\cite{kon01dynamic}, OpenORB~\cite{blair01design}), o� encore au niveau syst�me (OSKit~\cite{Ford97:OSKit}, THINK~\cite{fassino02think}). Un des apports des composants est qu'ils sont des briques logicielles ind�pendantes pouvant �tre assembl�es dynamiquement pour construire des logiciels complexes. L'aspect dynamique de l'assemblage prend une importance croissante du fait de l'�volution tr�s rapide des �quipements informatiques et des besoins des utilisateurs d'applications.

%Cet attrait des d�veloppeurs pour les composants a deux principales raisons : d'une part, les composants facilitent la construction d'architectures logicielles complexes ; d'autre part, ils facilitent la gestion du cycle de vie des syst�mes construits. En effet, la plupart des mod�les de composants fournissent des outils permettant la construction, la configuration, le d�ploiement, et la reconfiguration d'applications � base de composants.   

Il est aujourd'hui commun�ment admis de distinguer deux formes de reconfiguration dynamique d'applications~\cite{hofmeister94dynamic} : {\it reconfiguration de structure} et {\it reconfiguration d'implantation}. Dans un syst�me � composants, une reconfiguration de structure consiste � ajouter/enlever un composant, modifier une liaison entre composants, ou encore modifier la localisation d'un composant (si l'application est distribu�e). Une reconfiguration d'implantation consiste � mettre � jour le code d'un composant ou d'une ou plusieurs de ses interfaces.

Si les mod�les de composants permettent toujours des reconfigurations de structure, il n'en n'est pas de m�me pour les reconfigurations d'implantation, dont la mise en {\oe}uvre peut �tre tr�s difficile --- voire impossible --- suivant le langage d'implantation du mod�le de composants. Dans cet article, nous nous focalisons sur les mod�les de composants implant�s en Java. Java offre un syst�me dynamique de chargement de classes, appel� {\it class loader}. Celui-ci impose cependant un certain nombre de contraintes d'utilisation qui rendent difficile la mise � jour de code. Il est par exemple impossible de charger deux versions d'une m�me classe, ou encore de d�charger une classe. Deux possibilit�s s'offrent aux d�veloppeurs Java pour fournir des m�canismes de reconfiguration d'implantation : (1) modification du code des classes charg�es pour garantir que deux versions d'une m�me classe portent des noms diff�rents ; (2) utilisation de class loaders diff�rents pour charger les diff�rentes versions d'une m�me classe. La premi�re solution pr�clut l'utilisation d'une partie du langage Java : il n'est, par exemple, plus possible d'utiliser la m�thode de construction de classe {\tt Class.forName(``toto'')}, �tant donn� que celle-ci se base sur le nom de la classe � cr�er --- nom qui peut avoir �t� modifi� lors du chargement. La seconde solution est utilis�e dans plusieurs serveurs J2EE~: ceux-ci utilisent des hi�rarchies en arbre de class loaders, chaque class loader ayant un unique parent auquel il peut �ventuellement d�l�guer le chargement de classes. Ces organisations en arbre ne sont pas assez flexibles, et ne permettent que tr�s peu de reconfigurations d'implantation.      

Dans cet article, nous pr�sentons le travail que nous avons men� au sein de {\julia}~\cite{bruneton04open}, une implantation Java du mod�le de composants {\fractal}, pour permettre la co-existence de multiples versions d'une m�me classe, et donc la reconfiguration d'implantation d'une application � composants. La solution que nous adoptons est d'utiliser une organisation arbitraire de class loaders : cette organisation est construire en se basant sur les fronti�res de composants et les besoins de reconfigurabilit� exprim�s par le d�veloppeur d'applications � l'aide du langage de description d'architecture de {\julia}. Les class loaders sont cr��s et administr�s � l'aide de {\it Module loader}~\cite{hall04policy}, un syst�me permettant de faire coop�rer un ensemble de class loaders.
  
L'article s'organise de la fa�on suivante : nous pr�sentons le mod�le de composants {\fractal} et son implantation, {\julia}, dans la section~\ref{sec:fractal}. La section~\ref{sec:proposition} pr�sente notre proposition pour la reconfiguration d'implantation dans {\julia}. Son impl�mantation est d�crite dans la section~\ref{sec:implementation}. Enfin, nous pr�sentons les travaux connexes dans la section~\ref{sec:travaux_connexes}, avant de conclure cet article.

\section{Le mod�le de composants {\fractal}}\label{sec:fractal}
\begin{sloppypar}
Le mod�le de composants {\fractal}~\cite{bruneton04fractal,bruneton04open} est un mod�le flexible et r�flexif. Contrairement � d'autres mod�les comme Jiazzi~\cite{McDirmid01:Jiazzi} ou ArchJava~\cite{Aldrich02:ArchJava}, {\fractal} n'est pas une extension � un langage, mais une librairie qui permet la cr�ation et la manipulation de composants et d'architectures � base de composants. Dans la suite de cette section, nous pr�sentons {\julia}, une implantation Java de {\fractal}
\end{sloppypar}

\subsection{Le mod�le}

{\julia} distingue deux types de composants : les composants {\it primitifs} sont essentiellement des classes Java standards avec quelques conventions de codage. Les composants {\it composites} encapsulent un groupe de composants primitifs et/ou composites. Une caract�ristique originale du mod�le est qu'un composant peut �tre encapsul� simultan�ment dans plusieurs composites. Un tel composant est appel� composant {\it partag�}.   

Un composant est constitu� de deux parties : la partie de {\it contr�le} --- qui expose les interfaces du composant et comporte des objets contr�leurs et intercepteurs ---, et la partie {\it fonctionnelle} --- qui peut �tre soit une classe Java (pour les composants primitifs), soit des sous-composants (pour les composants composites). 

Les points d'acc�s d'un composant sont appel�s {\it interfaces}. On distingue deux types d'interfaces : les interfaces serveurs sont des points d'acc�s acceptant des appels de m�thodes entrants. Elles correspondent donc aux services fournis par le composant. Les interfaces clients sont des points d'acc�s permettant des appels de m�thodes sortants. Elles correspondent aux services requis par le composant. Ces deux types d'interfaces sont d�crits par une signature Java standard et une indication sur le r�le de l'interface (client ou serveur). 

La communication entre composants {\julia} est uniquement possible si leurs interfaces sont li�es. {\julia} supporte deux types de liaisons : {\it primitives} et {\it composites}. Une liaison primitive est une liaison entre une interface cliente et une interface serveur appartenant au m�me espace d'adressage. Elle signifie que les appels de m�thodes �mis par l'interface cliente doivent �tre accept�s par l'interface serveur. Une telle liaison est dite ``primitive'' car elle est mise en {\oe}uvre de fa�on tr�s simple � l'aide d'une r�f�rence Java. Une liaison composite est un chemin de communication entre un nombre arbitraire d'interfaces de composants. Ces liaisons sont construites � l'aide d'un ensemble de liaisons primitives et de composants de liaisons (stubs, skeletons, adaptateurs, etc). 

\subsection{Exemple}

La figure~\ref{fig:fractal_component} illustre les diff�rents concepts du mod�le de composants {\fractal}. Les rectangles repr�sentent des composants: la partie gris�e correspond � la partie {\it contr�le} des composants~; l'int�rieur du rectangle correpond au contenu des composants. Les fl�ches correspondent aux liaisons entre interfaces (repr�sent�es par des structures en forme de ``T''). Les interfaces externes apparaissant au sommet des composants sont les interfaces de contr�le. Les deux rectangles gris repr�sentent un composant partag�.


\begin{figure}[!htbp]
\centering
\includegraphics[scale=0.6]{pictures/fractal_component_fr.eps}
\caption{Exemple d'application {\fractal}}
\label{fig:fractal_component}
\end{figure}

\subsection{Implantation}
Un composant {\julia} est form� de plusieurs objets Java que l'on peut s�parer en trois groupes (figure~\ref{fig:julia_structures}): 

\begin{figure}[!htbp]
\centering
\includegraphics[scale=0.38]{pictures/julia_structures.eps}
\caption{Implantation d'un composant {\julia}}
\label{fig:julia_structures}
\end{figure}

\begin{itemize}

\item Les objets qui impl�mentent le contenu du composant. Ces objets n'ont pas �t� repr�sent�s sur la figure. Ils peuvent �tre des sous-composants (dans le cas de composants composites) ou des objets Java (pour les composants primitifs).

\item Les objets qui impl�mentent la partie de contr�le du composant (repr�sent�s en noir et en gris). Ces objets peuvent �tre s�par�s en deux groupes : les objets impl�mentant les interfaces de contr�le, et des intercepteurs optionnels qui interceptent les appels de m�thodes entrant et sortant sur les interfaces fonctionnelles. 

\item Les objets qui r�f�rencent les interfaces du composant (en blanc). 
\end{itemize}

La mise en place de ces diff�rents objets est effectu�e par des fabriques de composants. Celles-ci fournissent une m�thode de cr�ation qui prend en param�tres une description des parties fonctionnelles et de contr�le du composant. Dans l'impl�mentation actuelle de {\julia}, toutes les fabriques de composants utilisent le m�me class loader. 

\section{Vers une reconfiguration d'implantation dans {\julia}}\label{sec:proposition}

Tel que d�fini dans la section pr�c�dente, {\julia} fournit un support pour la reconfiguration de structure : en effet, les contr�leurs des composants permettent d'ajouter/retrancher des composants, ou encore de modifier les liaisons entre composants. En revanche, {\julia} ne fournit aucun support pour la reconfiguration d'implantation. En effet, l'ensemble des classes charg�es dans une machine virtuelle Java (i.e. dans le m�me espace d'adressage) sont charg�es par le m�me class loader. En cons�quence, il n'est pas possible de faire co-exister deux versions d'une m�me classe, ce qui exclut les reconfigurations d'implantation. Nous commen�ons cette section par une description des diff�rentes contraintes impos�es par le class loader Java, puis nous d�crivons notre proposition.

\subsection{Les contraintes du class loader Java}

Le class loader Java~\cite{liang98dynamic} permet de charger dynamiquement des classes Java au sein d'une machine virtuelle. Chaque class loader charge les classes � partir d'une source d�finie : syst�me de fichiers, r�seau, etc. Le r�le d'un class loader est de cr�er des objets {\tt Class} � partir de fichiers {\tt .class}. Pour ce faire, chaque class loader impl�mente une m�thode {\tt loadClass(String name)} qui a pour but de charger une classe. Cette m�thode utilise la m�thode {\tt findLoadedClass(String name)} pour v�rifier que la classe n'a pas d�j�  �t� charg�e, auquel cas elle est stock�e dans un cache. Si tel n'est pas le cas, {\tt loadClass} utilise {\tt defineClass} pour construire un objet {\tt Class} � partir d'un tableau d'octets. Notons qu'un class loader peut �galement d�l�guer le chargement d'une classe � un autre class loader.  Ce m�canisme est majoritairement utilis� avec des hi�rarchies en arbre de class loaders : chaque class loader a un p�re auquel il peut d�l�guer le chargement. 

Il est important de noter qu'une classe est li�e au class loader qui l'a charg�e : la m�me classe charg�e par deux class loaders diff�rents est consid�r�e comme deux classes diff�rentes. En cons�quence, l'utilisation d'une classe � la place de l'autre l�ve une exception {\tt ClassCastException}.
 
%Given the above constraints and a fact that class loaders allow the delegation approach, an implementation-level dynamism can be introduced in Java-based software.

\subsection{Les class loaders dans un monde de composants}

%Rappelons que notre objectif est de permettre la mise-�-jour dynamique de code. Deux exemples The {\fractal} model does not address the implementation-level dynamism. Providing it is up to the model implementation's furnisher. As said in the introduction section, implementation-level dynamism is crucial for building component-based software systems that support evolutionary changes of components. Figure 2a presents a typical example of such dynamism, where an "old" server component (C1  version 1) is replaced with its new implementation (C1 version 2).

%\begin{figure}[!htbp]
%\centering
%\includegraphics[scale=0.5]{pictures/impl_dyn.eps}
%\caption{Limitations in Julia}
%\label{fig:julia_limitations}
%\end{figure}


Une application {\fractal} est constitu�e d'un ensemble de composants. Chaque composant est constitu� d'un ensemble de classes (d�crites dans la section~\ref{sec:fractal}). La question � laquelle nous devons r�pondre est~: � quels class loaders faut-il d�l�guer le chargement de chacune des classes~? 

%\subsubsection{Une solution na�ve}

Selon Szyperski~\cite{szyperski98component}, ``un composant est d�ployable ind�pendamment et est sujet � composition par une tierce partie''. Une approche na�ve pour rendre les composants deployables ind�pendamment consiste � charger chaque composant dans un class loader ind�pendant. Cependant de tels composants ne sont pas composables par une tierce partie. En effet, toute tentative de liaison entre les interfaces de deux composants r�sulterait en une exception {\tt ClassCastException}. 

Il appara�t donc logique de s�parer les {\it classes d'interfaces} du composant (fonctionnelles et de contr�le) --- destin�es � �tre utilis�es par les autres composants ---, des {\it classes d'impl�mentation} --- destin�es � l'usage ``priv�'' du composant. Supposons que l'on ait deux composants $C_1$ et $C_2$ qui communiquent via une interface {\tt Push} qui d�finit une m�thode {\tt void push(Message m)}. Les classes {\tt Push} et {\tt Message} doivent �tre charg�es par un class loader commun aux deux composants tandis que les classes d'implantation des composants peuvent �tre charg�es ind�pendamment. 

Cette solution n'est n�anmoins pas suffisante. Supposons que la signature de la m�thode {\tt push} soit diff�rente~: {\tt void push(Object o)}. Il est n�cessaire que toutes les classes des objets transitant via la m�thode {\tt push} soient charg�es dans un class loader commun � $C_1$ et $C_2$. Ces classes, appel�es {\it classes partag�es}, sont un sous-ensemble des classes d'impl�mentation des composants. 

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

Dans cette section, nous pr�sentons la mise en {\oe}uvre de la proposition formul�e dans la section pr�c�dente. Nous d�crivons l'utilisation de {\it Module loader} pour l'int�gration des classes loaders dans {\julia}, puis nous montrons comment l'ADL de {\julia} a �t� �tendu pour permettre la sp�cification de versions d'interfaces, du code partag�, et l'instanciation des diff�rents class loaders. 

%The level of difficulty of implementing the class loaders organization presented in the previous chapter can be reduced by using a framework allowing arbitrary organization of Java class loaders. Such framework is the module loader


\subsection{Module loader}

{\it Module loader}~\cite{hall04policy} est un canevas permettant de construire des organisations arbitraires de class loaders, respectant une logique de chargement d�finie par le d�veloppeur. Les principaux concepts de {\it Module loader} sont~: {\it module}, {\it module manager}, {\it resource source} et {\it search policy}.

\begin{itemize}
\item Le {\bf module} est une unit� logique de groupement de ressources (i.e classes). Chaque module est associ� � un class loader. Par ailleurs, chaque module peut d�finir des m�ta-donn�es. 

\item Un {\bf module manager} g�re un ensemble de modules. Il envoie des notifications quand des modules sont ajout�s ou retranch�s.

\item Une {\bf resource source} est une source � partir de laquelle un module peut charger des classes.  Cette source peut �tre un fichier, une URL, une base de donn�es, etc. Les concepteurs de modules peuvent d�finir leurs propres sources.

\item La {\bf search policy} est le ``cerveau'' du m�canisme de chargement de classes. Il d�finit la fa�on dont un module peut localiser (et donc charger) une classe. La {\it search policy} adapte son comportement en fonction des �v�nements qu'elle re�oit du {\it module manager}. Un exemple typique de {\it search policy} est l'{\it import search policy}~: les modules annoncent (via des m�ta-donn�es) les ressources qu'ils exportent (i.e. fournissent) aux autres modules, et les ressources qu'ils importent (i.e. requi�rent) des autres modules. Un module ne peut �tre cr�� que si les ressources qu'il importe sont pr�sentes.

\end{itemize}

\subsection{Utilisation de Module loader dans {\julia}}

\subsubsection{Les diff�rentes structures de donn�es}

Comme nous l'avons vu dans la section~\ref{sec:proposition}, chaque composant utilise des class loaders diff�rents pour les classes d'impl�mentation, d'interfaces, et les classes partag�es. L'information sur les classes requises par un composant est stock�e dans un module, appel� {\it Info Module}. Un {\it Info Module} ne charge pas de classes. Il d�l�gue le chargement des classes � des {\it Resource Modules}, qui donnent acc�s � des classes et � des informations sur ces classes. Les {\it Resource Modules} sont cr��s en accord avec les r�gles �nonc�es dans la section~\ref{sec:proposition}~: un module par impl�mentation de composant, un module par classe d'interface, et un module pour les classes partag�es. 

La figure~\ref{fig:organisation_modules} pr�sente un exemple d'organisation de modules. L'application fait intervenir deux composants, chacun d'eux �tant impl�ment� par un certain nombre de classes. Les composants communiquent via une interface repr�sent�e par l'interface {\tt CmpItf}. Par ailleurs, les composants �changent une {\it classe partag�e} {\tt ExchangedItf}. L'organisation des modules respecte les r�gles �nonc�es au paragraphe pr�c�dent~: chaque composant est associ� � un {\it Info Module} qui d�l�gue le chargement des classes � diff�rent {\it Resource Modules}. Cette d�l�gation se base sur les m�ta-donn�es de chaque module. 

\begin{figure}[!ht]
\centering
\includegraphics[scale=0.5]{pictures/cl_separation_example.eps}
\caption{Organisation des modules}
\label{fig:organisation_modules}
\end{figure}

\subsubsection{Comportement des modules � l'ex�cution}

Quand un composant est cr��, le class loader de son {\it Info Module} devient le class loader courant. Quand une classe doit �tre charg�e, l'{\it Info Module} cherche un {\it Ressource Module}, parmi ceux qu'il conna�t, qui peut charger la classe requise dans la version appropri�e. Cette classe est charg�e par le class loader associ� au {\it Ressource Module}. 

Par ailleurs, il est n�cessaire que lorsque les composants communiquent, le flot d'ex�cution des requ�tes (i.e le {\it thread}) soit associ� aux class loaders appropri�s. Par exemple, si un appel ``traverse'' quatre composants, il est n�cessaire que lors du transit de l'appel dans chacun des composants, le class loader du flot d'ex�cution soit mis � jour~: pour chaque composant, il doit �tre positionn� sur l'{\it Info Module} du composant. Pour ce faire, nous avons d�velopp� un intercepteur dont le r�le est d'intercepter toutes les requ�tes pour modifier le class loader du flot d'ex�cution. Le m�canisme d'interception engendre un l�ger surco�t des temps d'ex�cution. Ce surco�t est de l'ordre de 3 � 4\%.


\subsection{Extension de l'ADL {\julia}}

Le langage de description d'architecture (ADL) de {\julia} permet de d�crire des applications � base de composants {\julia}. L'ADL a �t� con�u de mani�re extensible~: il est compos� de plusieurs modules, chacun d�finissant une syntaxe pour exprimer un ``aspect'' de l'architecture (interfaces, liaisons, attributs, etc.). Les d�veloppeurs sont libres de cr�er leurs propres modules. 

Une fabrique est en charge d'utiliser la description de l'application pour cr�er l'architecture correspondante (cr�ation et liaison des composants, positionnement des attributs, etc.). De fa�on similaire � l'ADL, cette fabrique a �t� con�ue de mani�re extensible, afin de pouvoir y int�grer du code relatif aux modules ADL d�finis par le d�veloppeur. 

Nous avons cr�� un module permettant de sp�cifier les versions de composants et d'interfaces utilis�es par l'application. Ce module permet �galement de sp�cifier les {\it classes partag�es} de chacun des composants. La figure~\ref{fig:exemple_adl} donne un exemple de description ADL. L'attribut {\tt version} a �t� ajout� aux d�finitions d'interfaces et de contenu. Par ailleurs, l'�l�ment {\tt file} permet de sp�cifier les classes qui sont partag�es, i.e. qui sont �chang�es par les composants, via leurs interfaces. 

\begin{figure}[!htbp]
\centering
\begin{small}
\begin{tabular}{|p{9.8cm}|}
\hline       
%\vspace*{-0.4cm}                     
\begin{verbatim}
<definition name="HelloWorld" version="2.0">
    <interface name="r" role="server" 
               signature="java.lang.Runnable"/>
    <component name="client">
        <interface name="r" role="server" 
                   signature="java.lang.Runnable"/>
        <interface name="s" role="client" 
                   signature="Service" version="1.0"/>
        <content class="ClientImpl" version="1.0"/>
        <file name="Request" version="1.0"/>
    </component>
    <component name="server">
        <interface name="s" role="server" 
                   signature="Service" version="1.0"/>
        <content class="ServerImpl" version="2.0"/>
        <file name="Request" version="1.0"/>
    </component>
    <binding client="this.r" server="client.r"/>
    <binding client="client.s" server="server.s"/>
</definition>
\end{verbatim}
\\
%\vspace*{-0.6cm}\\
\hline
\end{tabular}
\end{small}
\vspace*{6pt}
\caption{Un exemple de description ADL}
\label{fig:exemple_adl}
\end{figure}

Nous avons �galement d�velopp� un module pour la fabrique associ�e � l'ADL. Ce module a la responsabilit� de d�terminer les class loaders n�cessaires, et de cr�er les {\it Info Modules} et {\it Ressources Modules} appropri�s. Le d�veloppeur d'applications peut configurer deux aspects de ce module~: la granularit� des class loader cr��s (en fonction de la granularit� de reconfiguration souhait�e), et les sources des classes requises par l'application. A l'heure actuelle, nous n'offrons la possibilit� que de deux granularit�s~: un seul class loader --- ce qui correspond au comportement de {\julia} et ne permet pas de reconfiguration dynamique ---, et la granularit� d�finie dans les sections pr�c�dentes. Nous sommes en train de d�velopper un module permettant au d�veloppeur de sp�cifier les composants qu'il veut pouvoir charger/d�charger dynamiquement. Concernant la sp�cification des sources de classes, nous ne permettons actuellement que de sp�cifier des fichiers {\tt .class} et des fichiers {\tt.jar}.

\section{Travaux connexes}\label{sec:travaux_connexes}

On peut distinguer trois courants dans les travaux sur le d�velopement de canevas � composants extensibles en Java~: les mod�les de composants, les plates-formes de services, et les serveurs J2EE.

Parmi les mod�les de composants, citons JPloy~\cite{luer04jploy} et SOFA~\cite{hnetynka03fighting}. Ces deux mod�les utilisent des manipulations de bytecode pour garantir que les diff�rentes versions d'une m�me classe sont charg�es avec des noms diff�rents. Ces noms sont g�n�r�s � partir de fichiers de descriptions (comparables � des descriptions ADL) qui sp�cifient les versions des classes utilis�es. L'avantage de cette approche est qu'elle n'engendre aucun surco�t � l'ex�cution. En revanche, elle rend impossible l'utilisation de certaines m�thodes du langage Java. Il n'est, par exemple, pas possible d'utiliser certaines m�thodes de construction de classe par r�flexion (e.g. {\tt Class.forName(String name)}).

Les plates-formes de services sont apparues ces derni�res ann�es avec les travaux men�s sur OSGi~\cite{osgi03}. OSGi permet de d�ployer des applications Java empaquet�es sous formes de {\it bundles}. Un bundle contient des fichiers jar et des m�ta-donn�es sur ces fichiers jar (version, etc.). Le r�le d'une plate-forme OSGi est de g�rer le cycle de vie des bundles (d�ploiement, activation, retrait, etc.). Un des apports d'OSGi pour la communaut� Java est la prise en compte des versions des fichiers jar. N�anmoins, OSGi impose certaines contraintes~: il ne permet, par exemple, pas de faire co-exister deux versions d'une m�me classe. Par ailleurs, le mod�le de composants utilis� dans OSGi est un mod�le plat~: il n'est pas possible de cr�er des bundles ``composites''.

Enfin, de nombreux travaux sont effectu�s sur le chargement de classes dans les serveurs J2EE~\cite{j2ee02} (IBM WebSphere~\cite{webspherecl}, BEA WebLogic~\cite{weblogiccl}, JOnAS~\cite{jonas02cl}, etc.). Le but est de pouvoir isoler les diff�rentes applications d�ploy�es sur un serveur. Les class loaders sont organis�s en arbre, ce qui s'av�re suffisant pour les applications cibl�es, mais qui est trop restrictif dans un mod�le de composants plus flexible comme {\fractal}.

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

Il existe aujourd'hui de nombreux mod�les de composants utilis�s dans des domaines vari�s~: applications pour l'Internet, intergiciels, syst�mes d'exploitation, etc. Si ces mod�les supportent tous le dynamisme de structure --- qui consiste en une modification de l'architecture de l'application s'ex�cutant ---, peu, en revanche, supportent le dynamisme d'implantation --- qui consiste � modifier dynamiquement le code des composants de l'application. 

Dans cette article, nous avons pr�sent� le travail que nous avons effectu� au sein de {\julia}, une impl�mentation Java du mod�le {\fractal}, pour ajouter des capacit�s de reconfiguration d'implantation. Nous avons montr� comment contourner les limitations impos�es par le class loader --- le m�canisme Java de chargement de code --- pour permettre aux composants de modifier leur impl�mentation et leurs interfaces.

La solution que nous proposons est plus flexible que celle mise en {\oe}uvre dans les serveurs J2EE, et ne pr�sente pas les contraintes de celles reposant sur des modification du bytecode des classes des composants. Par ailleurs, l'int�gration de notre proposition dans l'ADL {\julia} la rend transparente au d�veloppeur de composants.  

Nous poursuivons actuellement nos travaux pour permettre au d�veloppeur de sp�cifier le niveau de granularit� qu'il souhaite, c'est-�-dire les composants qu'il souhaite pouvoir charger/d�charger dynamiquement.

\bibliography{decor2004}

\end{document}


decor2004.bbl
\begin{thebibliography}{}

\bibitem[ALD~02]{Aldrich02:ArchJava}
\textsc{Aldrich J.}, \textsc{Chambers C.}\andname{}\textsc{Notkin D.},
  \guilo{}{Architectural Reasoning in ArchJava}\guilf{},
\newblock \Inname{} \textit{Proceedings 16th European Conference on
  Object-Oriented Programming (ECOOP)}, 2002.

\bibitem[BLA~01]{blair01design}
\textsc{Blair G.}, \textsc{Coulson G.}, \textsc{Andersen A.}, \textsc{Blair
  L.}, \textsc{Clarke M.}, \textsc{Costa F.}, \textsc{Duran-Limon H.},
  \textsc{Fitzpatrick T.}, \textsc{Johnston L.}, \textsc{Moreira R.},
  \textsc{Parlavantzas N.}, \textsc{}\andname{}\textsc{Saikoski K.},
  \guilo{}The {D}esign and {I}mplementation of {O}pen {ORB} v2\guilf{},
\newblock \Inname{} \textit{IEEE Distributed Systems Online Journal, vol. 2 no.
  6, Special Issue on Reflective Middleware}, November 2001.

\bibitem[BRU~04a]{bruneton04fractal}
\textsc{Bruneton E.}, \textsc{Coupaye T.}\andname{}\textsc{Stefani J.-B.},
\newblock \guilo{}{The Fractal Component Model, Specifications}\guilf{}, 2004,
\newblock The ObjectWeb Consortium, http://www.objectweb.org.

\bibitem[BRU~04b]{bruneton04open}
\textsc{Bruneton E.}, \textsc{Coupaye T.}, \textsc{Leclercq M.},
  \textsc{Qu\'ema V.}\andname{}\textsc{Stefani J.-B.}, \guilo{}{An Open
  Component Model and its Support in Java}\guilf{},
\newblock \Inname{} \textit{Proceedings of the International Symposium on
  Component-based Software Engineering (CBSE'2004)}, Edinburgh, Scotland, 2004.

\bibitem[ejb02]{ejb02}
\guilo{}{Enterprise JavaBeansTM Specification, Version 2.1}\guilf{}, August
  2002,
\newblock Sun Microsystems, \texttt{http://java.sun.com/products/ejb/}.

\bibitem[FAS~02]{fassino02think}
\textsc{Fassino J.-P.}, \textsc{Stefani J.-B.}, \textsc{Lawall
  J.}\andname{}\textsc{Muller G.}, \guilo{}{THINK: A Software Framework for
  Component-based Operating System Kernels}\guilf{},
\newblock \Inname{} \textit{USENIX Annual Technical Conference}, 2002.

\bibitem[FOR~97]{Ford97:OSKit}
\textsc{Ford B.}, \textsc{Back G.}, \textsc{Benson G.}, \textsc{Lepreau J.},
  \textsc{Lin A.}\andname{}\textsc{Shivers O.}, \guilo{}{The Flux OSKit: A
  Substrate for Kernel and Language Research}\guilf{},
\newblock \Inname{} \textit{ACM Symp. on Operating Systems Principles (SOSP)},
  1997.

\bibitem[HAL~04]{hall04policy}
\textsc{Hall R.~S.}, \guilo{}A Policy-Driven Class Loader to Support Deployment
  in Extensible Frameworks\guilf{},
\newblock \Inname{} \textit{Proceedings of the 2nd International Working
  Conference on Component Deployment (CD'2004)}, Edinburgh, Scotland, 2004.

\bibitem[HNE~03]{hnetynka03fighting}
\textsc{Hnetynka P.}\andname{}\textsc{Tuma P.}, \guilo{}{Fighting Class Name
  Clashes in Java Component Systems}\guilf{},
\newblock \Inname{} \textit{Proceedings of the Joint Modular Language
  Conference (JMLC'2003)}, Klagenfurt, Austria, 2003.

\bibitem[HOF~94]{hofmeister94dynamic}
\textsc{Hofmeister C.}, \guilo{}Dynamic Reconfiguration of Distributed
  Applications\guilf{},
\newblock PhD thesis, University of Maryland, 1994.

\bibitem[j2e02]{j2ee02}
\guilo{}{J2EE: Java 2 Platform, Enterprise Edition}\guilf{}, 2002,
\newblock http://java.sun.com/j2ee/docs.html.

\bibitem[jon]{jonas02cl}
\guilo{}{JOnAS class loader hierarchy}\guilf{},
\newblock \\http://www.huihoo.com/jonas/white\_paper/ClassLoader.html.

\bibitem[KON~01]{kon01dynamic}
\textsc{Kon F.}, \textsc{Yamane T.}, \textsc{Hess K.}, \textsc{Campbell
  R.~H.}\andname{}\textsc{Mickunas M.~D.}, \guilo{}Dynamic {Resource}
  {M}anagement and {A}utomatic {C}onfiguration of {D}istributed {C}omponent
  {S}ystems\guilf{},
\newblock \Inname{} \textit{Proceedings of the 6th USENIX Conference on
  Object-Oriented Technologies and Systems (COOTS'01)}, San Antonio, USA,
  January 2001.

\bibitem[LUE~04]{luer04jploy}
\textsc{Luer C.}\andname{}\textsc{van~der Hoek A.}, \guilo{}{JPloy:
  User-Centric Deployment Support in a Component Platform}\guilf{},
\newblock \Inname{} \textit{Proceedings of the 2nd International Working
  Conference on Component Deployment (CD'2004)}, Edinburgh, Scotland, 2004.

\bibitem[MCD~01]{McDirmid01:Jiazzi}
\textsc{McDirmid S.}, \textsc{Flatt .}\andname{}\textsc{Hsieh W.},
  \guilo{}{Jiazzi: New-age components for old-fashioned Java}\guilf{},
\newblock \Inname{} \textit{Proceedings OOPSLA `01, ACM Press}, 2001.

\bibitem[MER~01]{ccm01}
\textsc{Merle P.}, \editorname{}, \textit{CORBA 3.0 New Components Chapters},
\newblock OMG TC Document ptc/2001-11-03, November 2001.

\bibitem[osg03]{osgi03}
\guilo{}{Open Services Gateway Initiative, OSGi service gateway specification,
  Release 3}\guilf{}, April 2003,
\newblock \texttt{http://www.osgi.org}.

\bibitem[SHE~98]{liang98dynamic}
\textsc{Sheng L.}\andname{}\textsc{Bracha G.}, \guilo{}Dynamic Class Loading in
  the Java Virtual Machine\guilf{},
\newblock \Inname{} \textit{Proceedings of the International Conference on
  Object-Oriented Programming, Systems, Languages, and Applications
  (OOPSLA'98)}, 1998.

\bibitem[SZY~98]{szyperski98component}
\textsc{Szyperski C.}, \textit{{Component Software: Beyond Object-Oriented
  Programming}},
\newblock Addison-Wesley, 1998.

\bibitem[web]{weblogiccl}
\guilo{}{WebLogic Server Application Classloading}\guilf{},
\newblock WebLogic Server 8.1 Documentation,
  http://edocs.bea.com/wls/docs81/programming/classloading.html.

\bibitem[web03]{webspherecl}
\guilo{}{WebSphere Software Information Center, Class loaders}\guilf{}, 2003,
\newblock
  http://publib.boulder.ibm.com/infocenter/wasinfo/topic/com.ibm.websphere.bas%
e.doc/info/aes/ae/\\crun\_classload.html.

\end{thebibliography}
