Gestion Dynamique des Services Techniques pour Mod�le � Composants
Colombe H�rault \andauthor Sylvain Lecomte
The new applications being intended for more and more heterogeneous environments, it is necessary to propose solutions of development which answer in best the necessities of adaptation of new services. Component-based programming partially answers this aim, allowing easy replacement of software blocks in order to provide the most adapted version of a component. Nevertheless, most of the industrial component-based model implementations do not allow to provide to components the most adapted technical services (naming, trading, security, transaction, etc.). In this paper, we suggest defining technical services themselves under the shape of components. We shall detail our proposition, by basing it on the Fractal component model of Objectweb. Then, we shall bring solutions for the use of these new component-based technical services and shall propose a set of management components which allow to administer in a dynamic and stand-alone way the obtained components. Finally we present the prototype of the proposed solution.
DECOR_04.tex
\documentclass[french]{article-hermes}
\usepackage{epsfig}
\begin{document}

\newcommand{\SNF}{service technique}
\newcommand{\SNFs}{services techniques}
\newcommand{\QoS}{qualit� de service}
\newcommand{\ps}{P1S}
\newcommand{\pss}{P1Ss}
\newcommand{\pe}{L2S}
\newcommand{\pes}{L2Ss}

\title[Gestion dynamique des services techniques]{Gestion Dynamique des Services Techniques pour Mod�le � Composants}
\author{Colombe H�rault \andauthor Sylvain Lecomte}
\address{
    LAMIH / ROI / SID, UMR CNRS 8530\\
    Universit� de Valenciennes - Le Mont Houy,\\
    59313 Valenciennes Cedex 9 - France\\
    [3pt] \{colombe.herault, sylvain.lecomte\}@univ-valenciennes.fr}

\resume{Les nouvelles applications �tant destin�es � des environnements de plus en plus h�t�rog�nes, il est
indispensable de proposer des solutions de d�veloppement qui r�pondent au mieux aux besoins d'adaptation des
nouveaux services. La programmation par composants r�pond en partie � cela, en permettant d'interchanger les
briques logiciels afin de fournir la version d'un composant la plus adapt�e � son contexte d'ex�cution.
N�anmoins, la plupart des implantation industrielles des mod�les � composants ne permettent pas de fournir aux
composants les services techniques (nommage, courtage, s�curit�, transaction, etc.) les mieux adapt�s. Dans cet
article, nous proposons de d�finir les services techniques eux-m�mes sous forme de composants. Nous d�taillerons
notre proposition, en la basant sur le mod�le � composants Fractal de Objectweb. Puis, nous apportons des
solutions pour l'utilisation de ces nouveaux services techniques � base de composants et proposons un ensemble
de composants de gestion qui permettent de g�rer de fa�on dynamique et automatique les composants obtenus. Enfin
nous pr�sentons le prototype du syst�me propos�.} \abstract{The new applications being intended for more and
more heterogeneous environments, it is necessary to propose solutions of development which answer in best the
necessities of adaptation of new services. Component-based programming partially answers this aim, allowing easy
replacement of software blocks in order to provide the most adapted version of a component. Nevertheless, most
of the industrial component-based model implementations do not allow to provide to components the most adapted
technical services (naming, trading, security, transaction, etc.). In this paper, we suggest defining technical
services themselves under the shape of components. We shall detail our proposition, by basing it on the Fractal
component model of Objectweb. Then, we shall bring solutions for the use of these new component-based technical
services and shall propose a set of management components which allow to administer in a dynamic and stand-alone
way the obtained components. Finally we present the prototype of the proposed solution.} \motscles{services
techniques, adaptabilit�, architecture � composants, intergiciel.} \keywords{technical services, adaptability,
component-based architecture, middleware.} 

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

\maketitlepage
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%D�but de l'article%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\label{section1}Introduction}
L'�mergence des intergiciels fut en grande partie motiv�e par le besoin d'interop�rabilit� dans un contexte
fortement distribu� entre des modules logiciels �crits � des �poques diff�rentes avec des langages h�t�rog�nes.
Ensuite on a voulu apporter une certaine qualit� de service � ces modules logiciels et une plus grande facilit�
de d�veloppement et de r�utilisabilit�. L'une des solutions adopt�es fut de s�parer code fonctionnel et
non-fonctionnel. Ainsi le d�veloppeur se focalise sur la logique applicative et d�l�gue l'implantation des
services techniques (ou non-fonctionnels) � la plate-forme d'ex�cution. Cependant, les terminaux participant aux
applications distribu�es sont de plus en plus h�t�rog�nes: de l'ordinateur tr�s puissant aux cartes �
microprocesseur. A cause de la diversit� de l'offre de terminaux, le programmeur doit assurer la portabilit� de
ses applications. Une solution pour g�rer cette h�t�rog�n�it� au niveau de l'application est d'utiliser le
mod�le de programmation par composants \cite{art30}. Cependant, les mod�les � composants actuels ne permettent
pas d'adapter les \SNFs\ � l'environnement d'ex�cution: le d�veloppeur peut uniquement d�cider d'utiliser ou non
un service. On ne lui offre pas le choix du mod�le implantant le code non-fonctionnel. Les composants qu'il
�crit utilisent donc toujours les m�mes services techniques quel que soit leur environnement. Or, en fonction
des sp�cificit�s de l'environnement, certaines implantations d'un service sont plus efficaces que d'autres. Nous
proposons donc de r�aliser �galement les \SNFs\ � l'aide du mod�le � composants : un \SNF\ devient alors un
assemblage de composants �l�mentaires, que l'on peut remplacer pour faire �voluer le service. On associe � ces
nouveaux services techniques les notions de \pss\ et \pes\ qui facilitent leur description. Cela permet
l'adaptabilit� statique ou dynamique des \SNFs. Afin d'utiliser les \pss\ et \pes, nous sp�cifions �galement un
ensemble de composants de gestion. Un prototype a �t� r�alis� ayant pour but de d�montrer la faisabilit� d'un
tel syst�me.
%--------------------------------SECTION 2-------------------------------------------------------------------
\section{\label{section2}H�t�rog�n�it� et \QoS}
Le but de notre travail est d'apporter aux nouvelles applications distribu�es, sur des environnements
h�t�rog�nes, une \QoS\ dans n'importe quel contexte d'ex�cution, tout en maintenant leur interop�rabilit�, leur
r�utilisabilit� et leur simplicit� d'implantation. En effet, l'�mergence simultan�e des outils informatiques
personnels portables et des r�seaux sans fil a consid�rablement augment� le nombre et les types des terminaux
connect�s aux r�seaux : serveurs puissants,  ordinateurs portables (PDA, t�l�phones mobiles) qui, bien que
connect�s au r�seau et offrant des capacit�s de stockage et de traitement, sont bien moins puissants, terminaux
de t�l�vision num�rique, consoles de jeux. De plus, des r�seaux pair � pair rempla�ant de plus en plus souvent
les architectures classiques client/serveur, les participants de l'application passent successivement du r�le de
client � celui de serveur, pour fournir des donn�e ou des services applicatifs, ceci quelques soient leurs
caract�ristiques propres en terme de connexion et de puissance de calcul. Pour d�velopper des applications
portables sur ces terminaux, il est donc n�cessaire de prendre en compte plusieurs contraintes li�es � leur
h�t�rog�n�it�. Pour le code applicatif, des solutions d'adaptation existent, telles que CESURE \cite{CESURE} ou
ARCAD \cite{ARCAD} : elles reposent sur l'id�e que le d�veloppeur d'application �crit plusieurs versions d'un
composant, chacune adapt�e � son environnement puis d�crit les adaptations. Ces solutions sont tout a fait
int�ressantes mais augmentent fortement le travail du d�veloppeur. Nous proposons de compl�ter cette approche en
limitant le travail du d�veloppeur en adaptant automatiquement le code technique. L'int�r�t �tant que le code
technique, r�utilisable pour de nombreuses applications, est d�velopp� par des sp�cialistes conscients des
particularit�s des environnements d'ex�cution. Comme pour les composants applicatifs, le code non-fonctionnel
doit b�n�ficier de tels m�canismes qui tiennent compte des sp�cificit�s de leur environnement d'ex�cution et du
contexte applicatif. Par exemple, pour les transactions \cite{her04}, il existe diff�rents mod�les th�oriques de
gestion des transactions (plates, imbriqu�es, � flot de t�ches). Chaque mod�le transactionnel s'utilise dans des
contextes applicatifs bien pr�cis, sur des terminaux ayant des capacit�s sp�cifiques : on ne fera pas de
transactions imbriqu�es sur une carte � microprocesseur. Ainsi, un bon nombre de \SNFs\ devront �tre adapt�s aux
participants de l'application afin d'apporter la meilleure \QoS\ possible.
 Pour l'instant, avant l'ex�cution, le choix (d'utiliser ou non un service, le choix du mod�le th�orique ou
encore celui de l'implantation de ce mod�le th�orique) est difficilement possible, car les \SNFs\ dans les
plates-formes � composants industrielles sont fig�s lors du d�veloppement de la plate-forme. Afin de maintenir
l'interop�rabilit�, deux composants, m�me s'ils fonctionnent sur deux ORB diff�rents, utilisent les m�mes
mod�les de \SNFs. De plus, tout au long de l'ex�cution, il n'est plus possible de modifier le choix du mod�le
th�orique des \SNFs\ et de leur implantation. Il y est donc impossible de s'adapter aux changements �ventuels de
l'environnement. Afin de permettre � un composant applicatif
 d'utiliser
n'importe quelle implantation du service transactionnel, \cite{rouvoy} propose une plate forme de d�ploiement:
en aval un adaptateur, sp�cifique � chaque implantation du service technique, fait l'interface entre le service
transactionnel et sa gestion par le conteneur.
%--------------------------------SECTION 3-------------------------------------------------------------------
\section{Intergiciels adaptables et mod�le Fractal}
Nous avons vu qu'une plate-forme proposant une version unique des \SNFs\ n'est pas efficace dans les
environnements h�t�rog�nes. On se propose donc de d�finir des m�canismes permettant de fournir plusieurs
implantations d'un m�me \SNF\ gr�ce � la notion d'intergiciel adaptable et plus particuli�rement sur la
propri�t� de r�flexivit� du mod�le � composants Fractal.
\subsection{\label{Intergiciels adaptables} Intergiciels adaptables} Apr�s avoir �t� employ� dans les langages de
programmation et les syst�mes d'exploitation, l'utilisation de la r�flexivit� s'est largement r�pandue dans les
intergiciels. En effet, le besoin d'adaptation s'est fait ressentir dans de nombreux domaines de la
programmation distribu�e (ex: en programmation orient�e objet avec le projet Mol�ne \cite{art65}). N�anmoins ces
solutions ne tirent pas partie des avantages provenant de la programmation par composants. Dans le domaine des
bus logiciels, il existe dynamicTAO \cite{dynamicTOA}, OpenORB \cite{OpenORB}, OpenCORBA \cite{OpenCORBA},
Flexinet \cite{Flexinet}. Ces intergiciels offrent un grand champ d'adaptations, cependant ils n'int�grent pas
l'id�e d'un nombre ind�termin� de \SNFs\ \cite{art31} et ne proposent pas v�ritablement de repr�sentation
adapt�e des \SNFs. Dans le domaine de la programmation par composants, on trouve le projet ARCAD \cite{ARCAD}
avec l'adaptation transparente des composants Fractal:  exp�rimentation visant � montrer qu'un service (pas
forcement technique), sous forme de composant Fractal, peut �tre dynamiquement adapt�. Comme dans notre
solution, on utilise pour l'adaptation des r�gles ainsi que des informations sur son environnement. A la
diff�rence de notre solution, le traitement de l'adaptation se fait dans le service lui-m�me, cela pourrait
poser des probl�mes de coh�rence entre l'adaptation de diff�rents services. On peut aussi citer l'initiative
ArcticBeans dont la probl�matique est tr�s proche de la n�tre. Cependant, ce projet se concentre sur deux
services (s�curit� et transactions) et ne propose pas de solution g�n�rale. Enfin, le domaine de l'AOP a pour
but la r�utilisation du code et se base sur le principe de s�paration des pr�occupations \cite{art39}. L'AOP
propose de d�composer les pr�occupations transverses de l'application sous la forme d'aspects puis de les
recomposer dans une phase de tissage. L'AOP fournit des solutions statiques (ex : AspectJ \cite{AspectJ}) et
dynamiques (ex : les plates-formes de d�veloppement Prose \cite{Prose}, JAC \cite{JAC}, le serveur applicatif
JBoss \cite{JBoss}). L'AOP, notamment JAC, offre donc une solution pour r�utiliser le code des services
technique et des techniques de tissage tr�s compl�tes (ajout de code avant et apr�s l'ex�cution d'une m�thode
mais aussi lors de l'utilisation d'un objet). Cependant ne faisant pas de distinction cat�gorique entre service
technique et service r�alis� par l'application, l'AOP ne propose donc pas pour l'instant de solution compl�te
pour g�rer efficacement les services techniques.
\subsection{Fractal : r�flexivit� et assemblage de composants}
Le but du mod�le � composants Fractal (\cite{fractal}, \cite{art40}) est d'offrir un cadre architectural global
pour le d�veloppement d'applications � base de composants. Contrairement � d'autres mod�les tels que les EJB,
Avalon et CCM qui offrent un mod�le concret du composant, Fractal regroupe une hi�rarchie ou une famille de
mod�les. On y distingue le mod�le de traitement abstrait qui est la racine de la famille de mod�le et d�finit
peu de concepts (composant, contr�leur, contenu, signal, nom et valeur). Un composant y est d�fini comme la
composition d'un contr�leur et d'un contenu, et le contr�leur d'un composant comme l'incarnation du comportement
de contr�le associ� � ce composant. De plus, ce mod�le d�finit un ensemble de propri�t�s de base du mod�le dont
les propri�t�s d'encapsulation, d'abstraction et de r�cursion. Le mod�le est compl�tement r�cursif et autorise
l'imbrication dynamique et le partage des composants � un niveau arbitraire. La hi�rarchie des mod�les de
Fractal �tant extensible, il est possible de lui ajouter d'autres mod�les (de traitements, de programmation ou
d'ing�nierie). Deux des autres mod�les que nous utiliserons pour d�crire notre solution sont le mod�le de
traitement concret et le mod�le de programmation associ� au framework Julia (i.e. l'implantation de r�f�rence de
Fractal) qui peut �tre utilis� pour la programmation de composants Fractal en Java. Dans ce mod�le, le
contr�leur encapsulant le composant permet de contr�ler la composition et les liaisons d'une composition de
composants. En effet, ces liaisons sont explicites et accessibles. Ainsi le syst�me a une repr�sentation de
lui-m�me. D'autre part, comparativement au conteneur des mod�les � composants de m�tier (EJB, CCM), le
contr�leur propos� dans le mod�le concret de Fractal propose peu de \SNFs\ (la gestion de cycle de vie). En
revanche, il laisse une totale libert� quant � l'ajout de \SNFs.  N�anmoins, il fournit des fonctionnalit�s
minimales permettant l'interception d'appel entrant ou sortant sur un composant, gr�ce aux notions
d'intercepteur et de sous-contr�leur. Un intercepteur peut �tre plac� sur une interface client ou une interface
serveur, il "intercepte" les appels de m�thodes et effectue des appels sur les sous-contr�leurs qui lui sont
associ�s. Les sous-contr�leurs fournissent diff�rentes fonctionnalit�s d'introspection du composant (ex:
sous-contr�leur de contenu du composant ou de ses liaisons). Fractal laisse toute possibilit� d'ajout de
nouveaux intercepteurs et sous-contr�leurs.
%--------------------------------SECTION 4-------------------------------------------------------------------
\section{\label{section5}Gestion des \SNFs\ adaptables}
Nous avons vu dans les sections pr�c�dentes que les \SNFs\ demandaient une plus grande flexibilit�, pour �tre en
ad�quation avec les environnements h�t�rog�nes des applications distribu�es. Or, les \SNFs\ des plate-formes
industrielles ne sont pas con�us sous forme de composants. N�anmoins, il est plus facile d'adapter ces services
aux besoins des applications en les d�finissant gr�ce au mod�le � composants \cite{her04}. En effet, on peut
alors d�finir le \SNF\ comme �tant un assemblage de plusieurs composants �l�mentaires. Pour proposer une version
adapt�e d'un \SNF, le programmeur se contente de r�aliser un assemblage des composants dont il a besoin. De
plus, le \SNF\ sous forme d'un composant alors
g�n�r�, "h�rite" des caract�ristiques positives d'un composant Fractal.\\
Dans \cite{her032}, nous avions aussi montr� comment la d�finition d'un \SNF\ comme une composition de
composants permet d'acc�der au mod�le le plus adapt� d'un ou plusieurs \SNFs, respectivement sous la forme d'une
\ps\ ou d'un \pe. Au niveau d'un seul service (ex: transaction, persistance), la \ps\ ("Personnalit� d'un
Service") permet d'associer � un composant le mod�le d'un \SNF\ le plus adapt�; pour �viter que cette nouvelle
libert� dans le choix du mod�le de \SNF\ n'entra�ne une gestion trop lourde, nous repr�sentons un ensemble de
\SNFs\ coh�rent comme une entit� appel�e \pe\ ("Lot de Services"). Elle simplifie la gestion des \SNFs\ en la
r�sumant, du c�t� composant, au choix d'un \pe\ adapt� � l'environnement d'ex�cution. De plus, elle garantit une
coh�rence s�mantique entre les \SNFs\ d'un m�me \pe.
\\Dans cette partie, nous d�finirons un ensemble de composants pour g�rer la mise en place et la mise � jour de
telles compositions. Tout d'abord nous d�finirons l'utilit� de chacun de ces composants de gestion. Puis nous
d�crirons leur comportement au cours de l'ex�cution des applications. Un derni�re partie sera consacr�e plus
particuli�rement � la d�finition de l'annuaire enregistrant les \SNFs.
\subsection{D�finition des composants de gestion du syst�me}
\begin{figure}[]
\begin{center}
\epsfig{width=7.2cm, file=images/class_diagramme_systeme2.eps} \caption{\label{figure system}Composants de
gestion du syst�me}
\end{center}
\end{figure}
Afin de localiser, choisir, configurer et d'utiliser les personnalit�s \ps\ et \pe, nous d�finissons des
composants de gestion du syst�me: des contrats, un coordinateur du syst�me, un annuaire et des moniteurs (cf.
figure \ref{figure system}). Un {\it contrat} pass� entre des personnalit�s et une application repr�sente le
fait que cette application b�n�ficie des services de ces personnalit�s. De plus, il met � jour cette coop�ration
en trouvant la personnalit� la plus adapt�e par rapport � l'environnement d'ex�cution et aux besoins de
l'application. Le r�le du {\it coordinateur} est tout d'abord de g�rer les contrats. Il les cr�e, les notifie
lorsqu'ils ont besoin d'une mise � jour et les d�truit. Il re�oit les informations concernant l'environnement
gr�ce aux moniteurs auxquels il a souscrit en d�finissant ses pr�f�rences. Un {\it annuaire} de personnalit�s
fournit un service de nommage et courtage afin de trouver les personnalit�s des \SNFs. Il permet au contrat de
trouver une ou plusieurs personnalit�s en fonction de l'environnement d'ex�cution et des besoins de
l'application. Pour cela les personnalit�s doivent s'enregistrer � son service. Un {\it moniteur} re�oit des
informations de son capteur et fait une s�lection en fonction des pr�f�rences que lui a exprim� le coordinateur.
Ainsi le coordinateur n'est pas surcharg� par des informations inutiles. Ensuite il
envoie les informations pertinentes au coordinateur.\\
Durant le d�ploiement, l'administrateur installe les diff�rents composants. A partir de ce moment, concernant
l'{\it adaptabilit� statique}, il n'y a pas de diff�rence avec une approche classique c'est-�-dire que le
composant applicatif b�n�ficie des services des personnalit�s qui ont �t� int�gr�es � sa composition.
\begin{figure}[]
\begin{center}
\epsfig{width=10.3cm, file=images/creation_contrat2.eps} \caption{\label{contract_creation}Cr�ation d'un
contrat}
\end{center}
\end{figure}
Pour l'{\it auto-adaptabilit�}, les composant applicatifs, l'annuaire et les moniteurs s'enregistrent aupr�s du
coordinateur. Les personnalit�s s'enregistrent dans l'annuaire. Les composants applicatifs fournissent au
coordinateur leurs pr�f�rences. Puis pour chaque composant applicatif, le coordinateur cr�e un contrat. Ce
dernier va chercher les personnalit�s adapt�es � ajouter au composant applicatif (cf. figure
\ref{contract_creation}). Pour cela, il pr�vient le coordinateur de la liste des moniteurs qui sont int�ressants
vis-�-vis des pr�f�rences de l'application. Par exemple, si l'application a besoin d'un haut niveau de s�curit�,
il choisira un moniteur de r�seau. Ensuite le coordinateur s'abonne aupr�s de chaque moniteur concern� qui est
alors activ�. Seuls les moniteurs pertinents sont activ�s dans la mesure o� il ne faut pas surcharger le
syst�me. Le moniteur active les capteurs qu'il g�re. Chaque capteur envoie alors des informations qui sont
filtr�es par le moniteur. Le contrat peut alors cr�er les liaisons n�cessaires entre le composant applicatif,
les personnalit�s et le contr�leur. Le composant applicatif peut maintenant s'ex�cuter avec les \SNFs\
appropri�s � ses pr�f�rences et � son
environnement d'ex�cution.\\
Pendant l'ex�cution, l'environnement peut �voluer. Ainsi les contrats doivent �tre ren�goci�s. Le syst�me initie
cette adaptation gr�ce aux informations sur l'environnement qui lui sont donn�es par les moniteurs. Le
coordinateur pr�vient les contrats qui sont concern�s qu'ils doivent �valuer la n�cessit� de leur propre mise �
jour et chercher � nouveau les personnalit�s les plus adapt�es gr�ce � l'annuaire.
\subsection{Focus sur l'annuaire de services techniques}
Nous d�veloppons un nouvel annuaire de services techniques, qui  permet � la plate-forme l'ajout et le retrait
dynamique de service ainsi que la gestion de multiples versions d'un m�me service. Il tient compte de
l'environnement d'ex�cution des services techniques qu'il r�f�rence afin de fournir au composant applicatif qui
le sollicite le service technique le plus adapt� � ses besoins. En effet, gr�ce aux moniteurs (pour les
caract�ristiques dynamiques) et aux informations donn�es par l'administrateur (pour les caract�ristiques
statiques), on conna�t les capacit�s m�moire, r�seau, l'architecture logiciel (type de bus logiciel,
environnement multi-processus), l'architecture mat�rielle (CPU, carte graphique), etc. Les services techniques
s'enregistrent dans cet annuaire en fournissant des renseignements sur l'environnement id�al pour lequel ils
sont adapt�s (ex: l'implantation A du service transactionnel est adapt�e � l'utilisation dans un r�seau de type
Bluetooth c'est-�-dire, entre autre, avec de nombreuses d�connexions). Ces informations, ainsi que les
informations concernant les besoins des composants applicatifs constituent deux demi-contrats dans lesquels les
deux types de composants, applicatifs et techniques, expriment respectivement leurs besoins et les services
qu'ils offrent. Afin de fournir le service technique ad�quat, l'annuaire v�rifie que ces deux demi-contrats sont
bien compatibles pour former un contrat. Afin d'�tablir ce contrat, on fournit � l'annuaire un ensemble de
r�gles qui d�crit les adaptations � effectuer. Ces r�gles peuvent �tre du type "l'implantation A du service de
tol�rance aux fautes offre une plus grande qualit� de service que l'implantation B". Ces r�gles seront notamment
�tablies par le d�veloppeur de services techniques, on laisse la possibilit� � l'administrateur de la
plate-forme d'en ajouter de nouvelles. Afin de d�velopper cet annuaire, nous nous reposons sur des technologies
d�j� existantes telles que les annuaires de nommage et de courtage de CORBA et les annuaires LDAP. Les annuaires
d�j� existants ne sont pas totalement satisfaisants pour r�soudre notre probl�matique: dans CORBA des annuaires
de courtage permettent aux composants de retrouver d'autres composants. Les param�tres de leur requ�te �tant le
nom et les param�tres d'ex�cution de ce service. Cependant, les services techniques n'�tant pas eux m�me
consid�r�s comme des composants, on ne peut pas les retrouver gr�ce � ce m�canisme. Notre d�marche consiste �
dire que les services techniques sont des composants, on peut donc les enregistrer dans ce type d'annuaire. M�me
ainsi ce type d'annuaire n'est pas sp�cialis� pour retrouver ces composants techniques, on ne peut donc pas
tirer partie de leurs particularit�s, des informations connues sur ces services techniques et surtout ils ne
g�rent pas d'information concernant l'environnement d'ex�cution.
%--------------------------------SECTION 5-------------------------------------------------------------------
\section{\label{section6}Prototype}
Cette partie est consacr�e � notre prototype d�velopp� en Java � l'aide du mod�le concret de Fractal nomm� Julia
v 1.0. Notre syst�me fonctionne de la fa�on suivante: on instancie et lie les composants de gestion comme d�crit
dans la figure \ref{composantsdegestion}. Le coordinateur, l'annuaire et le contrat sont des composants (comme
bien entendu le composant applicatif et le service technique). Le moniteur est �crit en langage C et �change les
informations concernant l'environnement � travers un fichier XML. Nous en d�taillons les raisons dans la partie
"le moniteur". Le contrat utilise une r�f�rence sur l'objet sous-contr�leur pour l'ex�cuter (r�f�rence
repr�sent� par une fl�che). Enfin l'annuaire r�f�rence les interfaces des \SNFs\ (r�f�rence repr�sent� par une
fl�che en pointill�). C'est cette r�f�rence qui sera donn�e au contrat comme r�sultat d'une requ�te aupr�s de
l'annuaire.
\begin{figure}[]
\begin{center}
\epsfig{width=6.1cm, file=images/composantsdegestion.eps} \caption{\label{composantsdegestion}Architecture du
prototype.}
\end{center}
\end{figure}
les composants de gestion sont:
\begin{itemize}
\item Le {\it coordinateur} joue le r�le d'usine de contrat. En effet, lorsqu'un nouveau composant applicatif
doit �tre ajout� � l'application, l'administrateur contacte le coordinateur qui fournit un contrat qui est d�s
lors associ� au composant applicatif. Il joue aussi le r�le de d�clencheur de mise � jour du syst�me lorsqu'il
d�tecte une modification de l'environnement d'ex�cution. \item Le {\it contrat} g�re la liaison entre le
composant applicatifs et les \SNFs\ ainsi que l'interrogation de l'annuaire. Lorsqu'il rep�re qu'une \SNF\ n'est
plus adapt� � l'environnement, il interroge l'annuaire pour en trouver un nouveau. Nous commen�ons par
d�velopper une solution qui implante la fonctionnalit� principale du composant contrat: la cr�ation d'une
composition telle que d�crite dans \cite{her04}. Pour le coordinateur prend pour param�tres le composant
applicatif (qui peut �tre une composition de composants) et un fichier d�crivant l'ensemble des \SNFs\ dont il a
besoin (leur nom, ex: persistance, transaction, etc.) et pour chaque \SNF, la \ps\ que l'on veut utiliser (une
\ps\ �tant d�crite ici par le nom de l'interface correspondante). \item Afin d'�crire le {\it moniteur}, nous
avons �valu� diff�rentes solutions. L'ensemble du syst�me �tant �crit avec Julia, nous avons cherch� s'il �tait
possible d'�crire un moniteur en Java afin de l'encapsuler dans un composant Fractal, portable sur de nombreuses
machines. Cependant, le langage Java, dans la mesure o� il n'a pas �t� con�u dans cette optique, ne permet pas
d'acc�der � des donn�es de bas niveau. Nous avons aussi �valuer des solutions tels que l'utilisation du logiciel
Aida32 \cite{aida32}, WMI (Windows Management Instrumentation) pour Windows \cite{WMI} ou encore rechercher des
informations dans les r�pertoires de "/proc" sur Linux mais ces solutions sont d�pendantes du syst�me
d'exploitation et ne nous donnent pas tous les renseignements n�cessaires. Nos recherches se sont donc tourn�es
vers le langage C. Nous avons donc d�velopp� un moniteur en C qui est recompil� suivant l'environnement
d'ex�cution. Pour faire l'interface entre le coordinateur et le moniteur, nous avions alors le choix entre une
interface JNI (Java Native Interface) et l'�change de donn�es � travers un fichier. La premi�re solution �tant
plus complexe � mettre en oeuvre et n'ayant pas plus d'int�r�t que la seconde, nous avons opt� pour la seconde.
Ce moniteur r�cup�re donc un ensemble de donn�es (r�seau, CPU, logiciel, etc) puis les inscrit dans un fichier
XML tel que celui de la figure \ref{exempleXMLenvironnement}.
\begin{figure}[]
\begin{center}
\epsfig{width=6.5cm, file=images/xmlenvironnement.eps} \caption{\label{exempleXMLenvironnement}Exemple de
description de l'environnement fournie par le moniteur.}
\end{center}
\end{figure}
\item L'{\it annuaire} fournit une interface regroupant des op�rations de d'import et d'export. Les op�rations
d'import sont effectu�es par l'administrateur lors de l'ajout de services techniques � la plate-forme. Les
op�rations d'export sont faites par l'annuaire lorsqu'il consulte l'annuaire. Pour ces deux types d'op�rations,
on doit r�pondre � deux questions: comment stocker les donn�es dans notre annuaire et r�pondre � une requ�te.
Nous avons utilis� un annuaire de composants d�velopp� au sein de notre �quipe pour Fractal et en Fractal puis
nous l'avons sp�cialis�. Cet annuaire de base est une adaptation du concept d'annuaire CORBA dans le mod�le
Fractal. Cependant, certaines modifications du concepts ont �t� effectu�es pour �tre en ad�quation avec le
mod�le Fractal telles que le r�f�rencement des patrons et de types. En effet, Dans le mod�le CORBA seules les
instances de composants sont r�f�renc�es dans l'annuaire, les patrons de composants �tant stock�s dans
l'"interface repository". Cela permet � notre annuaire d'instancier un patron s'il juge que le composant ainsi
instanci� r�pondrait mieux aux attentes du syst�me. Dans une seconde phase, nous avons sp�cialis� cet annuaire
pour les services techniques. La structure de stockage adopt�e est un arbre dans lequel une instance de service
technique est le fils d'un patron et un patron le fils d'un type. Pour chaque type et chaque patron, on stocke
un identifiant ainsi que l'ADL correspondant. Pour chaque instance de service technique, on stocke un
identifiant, une r�f�rence. Aux patrons et aux instances, on associe un fichier XML d�crivant le service fourni
(ex: un service transactionnel, fournissant les transactions plates, version 1.3), ensuite on y d�taille les
besoins de \SNF\ en terme de r�seau, environnement d'ex�cution, etc.
\end{itemize}
%--------------------------------SECTION 6-------------------------------------------------------------------
\section{\label{section8}Conclusion}
Cet article propose d'adapter des \SNFs, pour permettre le d�veloppement des architectures � composants dans de
nombreux domaines tels que le M-commerce o� les applications s'ex�cutent dans des environnements divers (pour
l'adaptabilit� statique) et tr�s changeants (pour l'auto-adaptabilit�). Nous avons rappel� la proposition d'une
adaptabilit� � deux niveaux: au niveau d'un seul \SNF, repr�sent�e par la notion de \ps. Elle permet d'offrir
aux composants applicatifs le mod�le du service le plus adapt� � son environnement tout en maintenant
l'interop�rabilit� au sein du syst�me. L'adaptabilit� au second niveau se traduit par le concept de \pe, qui
permet de fournir un ensemble de \SNFs\ coh�rent. Cela facilite �galement la gestion des probl�mes
d'entrelacement des \SNFs. Afin de g�rer les \pss\ et les \pes, nous proposons de fournir plusieurs entit�s: un
annuaire (pour retrouver les \SNFs), un contrat (pour repr�senter l'utilisation par une application d'une
personnalit�), un coordinateur (pour cr�er et mettre � jour les contrats) et des moniteurs qui donnent au
coordinateur des informations concernant l'environnement d'ex�cution. Nous avons d�montr� la faisabilit� des
versions statiques et dynamiques de l'adaptabilit� gr�ce � un prototype bas� sur l'implantation Julia du mod�le
 Fractal. Concernant l'adaptabilit� statique, nous montrons m�me que l'utilisation du mod�le �
composants pour implanter les services techniques et l'utilisation des sous-contr�leurs n'entra�nent
pratiquement aucun surco�t en terme de vitesse d'ex�cution (moins de 0,5\%). Nous avons rencontr� quelques
probl�mes techniques pour la r�alisation de ce prototype (d�finition au pr�alable des sous-contr�leurs, pas
d'interface interne client pour un sous-contr�leur), mais le r�sultat obtenu reste proche de la solution
th�orique envisag�e et surtout il permettra une �volution facile vers la solution th�orique si les prochaines
versions de Julia le permettent. Les b�n�fices d'une telle solution sont l'am�lioration de la \QoS\ et la
r�utilisabilit� du code tout en maintenant les caract�ristiques des composants telles que l'interop�rabilit� et
la facilit� d'implantation. Des probl�mes subsistent, tels que la s�paration des \SNFs\ (m�me si cela est en
partie r�solue par le \pe) ou la description de la \QoS\ fournie par un composant. Cet article donne une
d�finition de l'utilisation des composants de gestion des \SNFs. Des travaux sont en cours pour rendre plus
performant chacun de ces composants. Pour cela, les r�gles de fonctionnement du coordinateur restent �
formaliser. Les modifications du contr�leur dues au contrat sont �galement � pr�ciser. Cela fait l'objet de
travaux en cours. Concernant les moniteurs, on �tudie les ressources suppl�mentaires � surveiller et comment le
faire. Dans nos travaux futurs, on s'int�ressera certainement � l'AOP. En effet, dans la mesure o� certains des
buts fix�s par l'AOP et les nouveaux challenges auxquels la programmation par composants a � faire face sont les
m�mes, on peut imaginer une certaine convergence entre les deux domaines, l'AOP pouvant tirer partie des
recherches sur les composants ayant attrait � la distribution, l'interop�rabilit� et l'h�t�rog�n�it� et la
programmation par composants pouvant s'inspirer des techniques �volu�es de composition des aspects propos�es par
l'AOP.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%Fin de l'article%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\bibliography{DECOR_04}
\end{document}

DECOR_04.bbl
\begin{thebibliography}{}

\bibitem[aid]{aida32}
\guilo{}http://www.aida32.hu/\guilf{}.

\bibitem[AND~99]{art65}
\textsc{Andr� F.}\andname{}\textsc{Segarra M.-T.}, \guilo{}A Generic Approach
  to Build Mobile Applications.\guilf{},
\newblock \technicalreportname{} \numbername 3723, Juin 1999, INRIA.

\bibitem[BLA~01]{OpenORB}
\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{Parla-vantzas N.}\andname{}\textsc{Saikoski K.}, \guilo{}The design
  and implementation of Open ORB 2.\guilf{},
\newblock \Inname{} \textit{IEEE Distrib. Syst. Online 2}, IEEE, Septembre
  2001.

\bibitem[BRU~02]{art40}
\textsc{Bruneton E.}, \textsc{Coupaye T.}\andname{}\textsc{Stefani J.-B.},
  \guilo{}Recursive and Dynamic Software Composition with Sharing\guilf{},
\newblock \Inname{} \textit{Proceedings of the 7th ECOOP International Workshop
  on Component-Oriented Programming (WCOP'02)}, Malaga, Espagne, 2002.

\bibitem[DUC~02]{art31}
\textsc{Duclos F.}, \guilo{}Environnement de Gestion de Services
  Non-Fonctionnels dans les Applications � Composants\guilf{},
\newblock Th�se de doctorat, Universit� J. Fourier de Grenoble, 2002.

\bibitem[fra]{fractal}


\bibitem[HAY~97]{Flexinet}
\textsc{Hayton R.}, \guilo{}FlexiNet Open ORB Framework.\guilf{},
\newblock \technicalreportname{} \numbername 2047.01.00., 1997, APM ltd,
  Poseidon House, Castle Park, Cambridge, UK.

\bibitem[H�R~03]{her032}
\textsc{H�rault C.}\andname{}\textsc{Lecomte S.}, \guilo{}Adaptabilit� des
  Services Techniques dans un Mod�le � Composants\guilf{},
\newblock \Inname{} \textit{3�me Conf�rence Fran�aise sur les Syst�mes
  d'Exploitation (CFSE)}, La Colle sur Loup, France, Octobre 2003.

\bibitem[H�R~04]{her04}
\textsc{H�rault C.}, \textsc{Nemchenko S.}\andname{}\textsc{Lecomte S.},
  \guilo{}A Component-Based Transactional Service, Including Advanced
  Transactional Models\guilf{},
\newblock \Inname{} \textit{Fourth IEEE International Symposium and School on
  Advance Distributed Systems (ISSADS 04)}, Guadalajara, Jalisco, Mexique,
  Janvier 2004.

\bibitem[JBo]{JBoss}
\guilo{}http://www.jboss.org\guilf{}.

\bibitem[KIC~97]{art39}
\textsc{Kiczales G.}, \textsc{Lamping J.}, \textsc{Mendhekar A.}, \textsc{Maeda
  C.}, \textsc{Lopes C.~V.}, \textsc{Loingtier J.-M.}\andname{}\textsc{Irwin
  J.}, \guilo{}Aspect-Oriented Programming\guilf{},
\newblock \Inname{} \textit{Proceedings of ECOOP}, Springer-Verlag, 1997.

\bibitem[KIC~01]{AspectJ}
\textsc{Kiczales G.}, \textsc{Hilsdale E.}, \textsc{Hugunin J.},
  \textsc{Kersten M.}, \textsc{Palm J.}\andname{}\textsc{Griswold W.},
  \guilo{}Getting started with ASPECTJ\guilf{},
\newblock \textit{Communications of the ACM}, \volumename\ 44, \numbername\ 10,
  2001,  \pagesname{} 59--65, ACM Press.

\bibitem[KON~00]{dynamicTOA}
\textsc{Kon F.}, \textsc{Roman M.}, \textsc{Liu P.}, \textsc{Mao J.},
  \textsc{Yamane T.}, \textsc{Magalhaes L.}\andname{}\textsc{Campbell R.},
  \guilo{}Monitoring, security, and dynamic configuration with the dynamicTAO
  reflective ORB.\guilf{},
\newblock \Inname{} \textit{Proceedings of the IFIP/ACM International
  Conference on Distributed Systems Platforms and Open DistributedProcessing
  (Middleware2000)}, Palisades, NY, Avril 2000, Springer-Verlag,  \pagesname{}
  121-143.

\bibitem[LAV~01]{WMI}
\textsc{Lavy M.}\andname{}\textsc{Meggitt A.}, \guilo{}Windows Management
  Instrumentation (WMI)\guilf{},
\newblock \technicalreportname{} \numbername ISBN: 1578702607, Octobre 2001,
  New Riders Publishing.

\bibitem[LED~99]{OpenCORBA}
\textsc{Ledoux T.}, \guilo{}OpenCORBA: A reflective open broker.\guilf{},
\newblock \Inname{} \textit{Proceedings of Reflection'99}, Saint-Malo, France,
  Juillet 1999, Springer-Verlag,  \pagesname{} 197-214.

\bibitem[PAW~03]{JAC}
\textsc{Pawlak R.}, \textsc{Seinturier L.}\andname{}\textsc{Duchien L.},
  \guilo{}Jac Milestone 2003\guilf{},
\newblock \technicalreportname{} \numbername 2003-4, 2003, LIFL, Universit� des
  Sciences et Technologies de Lille.

\bibitem[PEL~00]{CESURE}
\textsc{Pellegrini M.-C.}, \textsc{Potonni�e O.}, \textsc{Marvie R.},
  \textsc{Jean S.}\andname{}\textsc{Riveill M.}, \guilo{}CESURE : une
  plate-forme d'applications adaptables et s�curis�es pour usagers
  mobiles\guilf{},
\newblock \Inname{} \textit{Special Issue of the french journal Calculateurs
  Parall�les, entitled "�volution des plates-formes orient�es objets
  r�partis"}, Herm�s, 2000,  \pagesname{} 113-120.

\bibitem[Pro]{Prose}
\guilo{}http://prose.ethz.ch\guilf{}.

\bibitem[PRO~03]{ARCAD}
\textsc{Projet RNTL~ARCAD c. T.~L.}, \guilo{}D1.3 Document
  d'architecture\guilf{},
\newblock \technicalreportname{}, 2003.

\bibitem[RIV~02]{art30}
\textsc{Riveill M.},
\newblock \guilo{}Programmation par composition et d�ploiement d'applications
  r�parties\guilf{},
\newblock Coop�ration dans les syst�mes � objets (RSTI-S�rie L'Objet Vol.8 N�
  3), 2002.

\bibitem[ROU~03]{rouvoy}
\textsc{Rouvoy R.}\andname{}\textsc{Merle P.}, \guilo{}Abstraction of
  Transaction Demarcation in Component-Oriented Platforms\guilf{},
\newblock \Inname{} \textit{ACM/IFIP/USENIX International Middleware Conference
  (Middleware'03)}, Rio de Janeiro, Br�sil, Juin 2003.

\end{thebibliography}
