Reconfigurations dynamiques de services dans un intergiciel � composants CORBA CCM
Assia Hachichi
Cyril Martin
Ga\"el Thomas
Simon Patarin
Bertil Folliot
Today, component oriented middlewares are used to design, develop and deploy easily distributed applications, by ensuring the heterogeneity, interoperability, and reuse of the software modules, and the separation between the business code encapsulated in the components and the system code managed by the containers. Several standards answer this definition such as: CCM (CORBA Component Model), EJB (Enterprise Java Beans) and .Net. However these standards offer a limited and fixed number of system services, removing any possibility to add system services or to reconfigure dynamically the middleware. Our works propose mechanisms to� add and to adapt dynamically the system services, based on a reconfiguration language which is dynamically� adaptable to the need of the reconfiguration, and on a tool of dynamic reconfiguration, a prototype was achieved for the OpenCCM platform, that is an implementation of the CCM specification. This work was partially financed by the european project IST-COACH (2001-34445).
biblio.tex

Plusieurs mod�les � composant existent tels que�: Microsoft .Net, les
Entreprise Java Beans de Sun Microsystem ou encore CORBA Component Model de
l'OMG. Ces mod�les sont de plus en plus utilis�s pour concevoir et d�ployer des
applications r�parties. Cependant, ils n'offrent pas la possibilit� d'ajouter
ou de reconfigurer un service syst�me apr�s le d�ploiement initial de l'application.

Les premiers intergiciels n'ont pas �t� con�us pour �tre flexibles. 
Toutefois, des possiblit�s d'adaptation ont �t� propos�es 
tels que les intercepteurs, et le Portable Object Adaptor (POA) dans CORBA~(\cite{coeur}, chapitres 7,8 et 9). 
Les intercepteurs~\cite{intercepteurs-corba} permettent d'inserer du code avant la
r�ception et apr�s l'envoie d'une requ�te.
Le POA permet de contr�ler finement la politique de l'adaptateur d'objet.

Certains travaux visent � rendre CORBA plus flexible.
DynamicTAO~\cite{dynamicTAO, 2K} (bas� sur TAO~\cite{tao}) est 
un environnement CORBA r�flexif.
DynamicTAO r�ifie des �l�ments internes de l'ORB sous la forme de composants
appel�s composants de configuration. 
Deux exemples d'adaptation dynamiques sont pr�sent�s dans~\cite{dynamicTAO}~: 
l'ajout d'un service de monitoring et l'ajout d'un service de s�curit�. 
DynamicTAO permet de garder une compatibilit� avec les applications CORBA 
tout en offrant un haut degr� d'adaptabilit�.
Une des difficult�s que soul�ve ce projet est 
le probl�me de la coh�rence lorsqu'on remplace une politique par une autre~: 
l'exemple donn� est le remplacement d'une gestion de thread. 
Pour passer d'une politique de pool de thread � une autre politique, 
il est n�cessaire que le pool soit vide.
Cette information doit �tre transmise par l'ancienne politique, elle doit donc
avoir �t� con�ue de mani�re � pouvoir �tre remplac�e. 


AspectIX~\cite{hauck98aspectix} pr�sente une architecture d'intergiciel 
bas�e sur le mod�le d'objets � fragments~\cite{makpangou94fragmented}.
Les fragments peuvent masquer la r�plication d'un objet distribu�, imposer des contraintes temps
r�elles au canal de communication, mettre en cache des donn�es de l'objet etc.
Ces aspects non fonctionnels peuvent �tre configur�s 
via une interface g�n�rique de l'objet...
Chaque objet global peut �tre configur� par un profil 
qui sp�cifie les aspects que doivent respecter les fragments.
Quatre profils sont planifi�s, en particulier un profil CORBA 
qui permet de faire interagir les objects AspectIX avec CORBA.
Cette approche permet de s�parer l'application de l'intergiciel dans lequel elle est d�ploy�e.

Une architecture de conteneurs ouverts est propos�e dans~\cite{merle}. 
Cette architecture permet d'adapter et d'�tendre dynamiquement les
fonctions syst�mes,
et elle permet d'exposer un certain nombre de propri�t�s du conteneur 
gr�ce � des m�canismes d'interception, de coordination 
(pour ordonner les appels de fonctions syst�mes) et de contr�le.

Des travaux comme Oopp~\cite{oopp} introduisent un syst�me d'interception 
et de red�finition de l'appel d'op�ration dans un ORB.

JavaPOD~\cite{javapod}, un mod�le de composant proche des EJB, offre 
la possibilit� d'attacher des propri�t�s non fonctionnelles aux composants 
gr�ce � des conteneurs ouverts et extensibles.

%%%%% quoi est modifi� %%% par qui %% quand %% pour quoi faire %%% sens de environnement
Ces diff�rents travaux augmentent les possibilit�s d'un intergiciel en le
recodant. Le direction prise par nos travaux est assez diff�rente puisque nous
utilisons les propri�t�s actuelles des intergiciels pour permettre � un
administrateur de modifier dynamiquement les propri�t�s de l'application et de
l'intergiciel. Les intergiciels offrent la possibilit� de d�ployer une
application, nous utilisons les m�mes m�canismes pour red�ployer dynamiquement les composants
syst�mes de l'application.


main.tex
\documentclass[french]{article-hermes}
\usepackage[frenchb]{babel}
\usepackage[T1]{fontenc}

\ifx\pdftexversion\undefined
  \usepackage[dvips]{graphicx}
  \DeclareGraphicsExtensions{.eps} % Formats d'images
\else
  \usepackage[pdftex]{graphicx}
  \DeclareGraphicsExtensions{.jpg,.mps,.pdf,.png} % Formats d'images
\fi


\title[Flexibilit� dans OpenCCM]{Reconfigurations dynamiques de services dans
  un intergiciel � composants CORBA CCM}% \footnote{Ce travail a �t�
				% partiellement financ� par le projet europ�en
				% IST-COACH (2001-34445).}}


\author{Assia Hachichi, Cyril Martin, Ga\"el Thomas, Simon Patarin, Bertil Folliot}
\submitted{Deploiement et (Re) Configuration de Logiciels}{1}

\address{%
Laboratoire d'Informatique de Paris 6 (lip6)\\
8 rue du Capitaine Scott\\
75015 Paris\\
\{assia.hachichi,gael.thomas,cyril.martin,bertil.folliot\}@lip6.fr, simon.patarin@inria.fr}

\abstract{
Today, component oriented middlewares are used to design, develop and deploy
easily distributed applications, by ensuring the heterogeneity,
interoperability, and reuse of the software modules, and the separation between
the business code encapsulated in the components and the system code managed by
the containers. 
Several standards answer this definition such as: CCM (CORBA Component Model),
EJB (Enterprise Java Beans) and .Net. However these standards offer a limited
and fixed number of system services, removing any possibility to add system
services or to reconfigure dynamically the middleware. 
Our works propose mechanisms to� add and to adapt dynamically the system
services, based on a reconfiguration language which is dynamically� adaptable
to the need of the reconfiguration, and on a tool of dynamic reconfiguration, a
prototype was achieved for the OpenCCM platform, that is an implementation of
the CCM specification. This work was partially financed by the european project
IST-COACH (2001-34445).
}
\keywords{Dynamic adaptation and reconfiguration, adaptable container, CCM, VVM }

\resume{
De� nos jours, les intergiciels � composants sont utilis�s pour concevoir,�
d�velopper, et d�ployer facilement les applications r�parties, et assurer
l'h�t�rog�n�it�, et l'interop�rabilit�, ainsi que la r�utilisation des modules
logiciels, et la s�paration� entre le code m�tier encapsul� dans des composants
et le code syst�me g�r� par les conteneurs. 
De nombreux standards r�pondent � cette d�finition tels: CCM (CORBA Component
Model), EJB (Entreprise Java Beans) et .NET. Cependant ces standards offrent un
nombre limit� et fig� de services syst�mes, supprimant ainsi toute possibilit�
d'ajout de services syst�mes ou de reconfiguration dynamiques de l'intergiciel. 
Nos travaux proposent des m�canismes d'ajout et d'adaptation dynamique des
services syst�mes, bas�s sur un langage de reconfiguration adaptable
dynamiquement aux besoins de la reconfiguration et sur un outil de
reconfiguration dynamique. Un prototype a �t� r�alis� pour la plateforme
OpenCCM, qui est une impl�mentation de la sp�cification CCM de l'OMG. Ce travail a �t�  partiellement financ� par le projet europ�en IST-COACH (2001-34445).
}
\motscles{Adaptation et reconfiguration dynamique, conteneurs adaptables, CCM, MVV}

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


\begin{document}

%\pagestyle{empty}
\maketitlepage

\section{Introduction}
Les syst�mes informatiques sont de plus en plus complexes et difficiles � maintenir et les
diff�rents �l�ments constitutifs d'un environnement sont souvent physiquement r�partis. Les intergiciels
ont �t� introduits pour r�soudre ces difficult�s et pour 
proposer des m�canismes syst�mes g�n�riques communs � la plupart des applications r�parties,
comme la persistance, les transactions ou le nommage.

La derni�re g�n�ration d'intergiciels � base de composant introduit la notion de conteneur. Un conteneur
permet de d�coupler le code m�tier du code syst�me en encapsulant le code m�tier et en g�rant les
services syst�mes de mani�re transparente pour l'application.
Le d�veloppement d'applications bas�es sur des composants est aujourd'hui
largement utilis�, mais ces plateformes sont encore inadapt�es aux besoins
sp�cifiques en terme d'adaptation de services syst�mes~: les conteneurs n'offrent pas de
moyen de reconfigurer, d'ajouter ou de supprimer dynamiquement des services
syst�mes. 
L'adaptation de l'application n�cessite ainsi de modifier un ou plusieurs
code(s) source(s), de recompiler et de red�marrer l'application en cours.


Dans ce contexte, notre travail propose des m�canismes permettant l'ajout
et la gestion des services syst�mes dynamiquement, sans
avoir � modifier ni le code source des composants sur lesquels les
services s'appliquent, ni le code source de l'intergiciel cibl�. Notre approche
est guid�e par la notion de \emph{r�utilisabilit�}~: le but n'est pas de cr�er un nouvel intergiciel
mais bien de proposer une solution pour adapter dynamiquement des applications d�j�
�crites. Les m�canismes d'adaptation
sont bas�s sur un langage de reconfiguration adaptable dynamiquement, et sur un
outil d'adaptation dynamique appel� CVM~(Container Virtual Machine). 

Un premier prototype a �t� r�alis� sur la plateforme OpenCCM~\cite{openccm}, qui est une
plateforme logicielle ouverte impl�mentant la sp�cification des composants
CCM d�finie par le consortium Object Management Group (OMG). Ce prototype
permet l'ajout et la reconfiguration de nouveaux services syst�mes, et offre la possibilit� � un administrateur de
sp�cifier et de d�ployer dynamiquement des propri�t�s syst�mes non pr�vues
initialement.

Lors de ces travaux, nous nous sommes fix� comme objectifs d'offrir des
m�canismes permettant de g�rer les services syst�mes dans les plateformes
actuelles, sans modifier les codes sources, de fa�on dynamique et transparente pour l'application. La
conception de ces m�canismes demande la prise en compte de quatre caract�ristiques
importantes~:

\begin{itemize}
\item d�finir un m�canisme permettant d'int�grer des services syst�mes dans les conteneurs CCM,
\item offrir un langage de reconfiguration extensible dynamiquement et g�n�rique par rapport � l'intergiciel cibl�,
\item d�finir une architecture permettant de reconfigurer dynamiquement des intergiciels, en
int�grant de nouveaux services syst�mes dynamiquement,
\item offrir un moyen d'administrer la reconfiguration dynamique des services � distance.
\end{itemize}

Dans ce qui suit, la section~\ref{stat} pr�sente d'autres propositions permettant de rendre
des intergiciels flexibles. 
Ensuite, notre proposition d'adaptation dynamique est
d�taill�e dans la section~\ref{archi}. La section~\ref{evaluation} d�crit deux
exemples d'adaptation dynamique, la section~\ref{performances} pr�sente les
performances de la solution propos�e, et la section~\ref{perspectives} 
pr�sente les conclusions et perspectives du projet.

\section{Travaux similaires}\label{stat}

\input{biblio.tex}

\section{Architecture}\label{archi}


Actuellement, les plateformes des intergiciels existantes 
sont monolithiques ce qui emp�che toute adaptation dynamique 
des m�canismes internes, et des syst�mes sous-jacent. 
Pour cela nous avons con�u un outil assurant la reconfiguration 
� la vol�e, sans modifier ou r��crire ces plateformes. 
L'id�e principale de la CVM est d'ajouter au d�ploiement initial, 
de fa�on transparente, un point d'entr�e qui peut interagir 
sur la plateforme et l'application cibl�e.

L'architecture de cet outil permet d'agir dynamiquement sur la plateforme
en manipulant ses symboles et ses m�thodes, permettant ainsi d'ajouter
et reconfigurer des services syst�mes non pr�vus initiallement. 

\subsection{D�finition d'un langage de reconfiguration}
L'adaptation dynamique n�cessite la d�finition d'un langage 
et une impl�mentation qui �tendent les op�rations d'acc�s usuels 
pour contr�ler ce qui peut �tre adapt�. 
La d�finition d'un langage de reconfiguration permet de s�parer 
la logique de reconfiguration de sa mise en oeuvre.
Ce langage doit �tre 
� la fois adaptable dynamiquement aux nouveaux besoins de reconfiguration, 
et g�n�rique par rapport � l'intergiciel cibl� dans un but de r�utilisabilit�.
Ceci permet de r�duire les possibilit�s de reconfiguration en
limitant les symboles du langage, 
ou bien au contraire d'�tendre le langage en autorisant 
et l'instrospection de l'environnement et la cr�ation de nouveaux symboles.

La plateforme de reconfiguraton choisie est la Machine
Virtuelle Virtuelle~\cite{ogel03, folliot98}~(MVV), une plateforme hautement adaptable
permettant de construire son environnement d'ex�cution et son langage d�di� dynamiquement.
La MVV permet � la fois de modifier les m�canismes mis en oeuvre pour reconfigurer l'environnement
mais aussi d'�tendre ou modifier le langage associ�.

\subsection{M�canisme de reconfiguration � distance}
Afin de permettre une administration distante, nous avons construit 
un environnement de reconfiguration � distance pour la MVV.
Une reconfiguration initiale doit �tre charg�e sur toutes les MVV.

La MVV est s�par� en deux entit�s distinctes~: la premi�re s'occupe de
parser/lexer des scripts qui reconfigurent l'environnement cible, 
ces scripts sont transform�s en arbre de syntaxe abstraite et envoy�s � la
seconde (Figure~\ref{DVM}).
De l'autre c�t�, la MVV a �t� modifi�e de mani�re � recevoir les arbres sur un
canal de communication (exemple: une socket TCP). L'arbre
est compil� et ex�cut� sur la machine distante.


\begin{figure}[ht]\centering
\includegraphics[width=12cm]{modif.eps}
\caption{M�canisme de reconfiguration � distance\label{DVM}}
\end{figure}

L'administration distante se fait en deux phases~:
\begin{enumerate}
\item {{\bf D�ploiement initial : }
Toutes les MVVs chargent le script de reconfiguration et se mettent en attente de connexion.}
\item {{\bf Reconfiguration : }
Elle suit le mod�le client/serveur, les machines serveurs attendent 
d'�tre reconfigur�es et le client est la console d'administration.
Le client ouvre un canal de communication vers un serveur et lui envoie une s�quence d'instructions.}
\end{enumerate}

Dans le cas de la CVM, les processus serveurs s'ex�cutent dans le m�me environnement qu'OpenCCM.
La machine cliente permet donc d'administrer � distance l'environnement OpenCCM.

\subsection{Int�gration de service}
Deux m�thodologies d'int�gration de service ont �t� propos�es, leurs
r�alisations sont pr�sent�es ci-dessous�:

\begin{itemize}
\item {{\bf  Technologie des intercepteurs :} La sp�cification
  Corba~\cite{Obj02a} d�finit l'interface de l'intercepteur
  portable~\cite{Obj02b}, pour ins�rer des crochets directement dans l'ORB. Ces
  crochets sont actifs pour chaque op�ration effectu�e. 
  Les crochets peuvent �tre localis�s soit du c�t� client soit du c�t�
  serveur. En particulier, il est possible de conna�tre l'identificateur
  unique de la transaction, le nom exact de la m�thode invoqu�e, le nom de
  l'exp�diteur de la requ�te, et le statut de la r�ponse. 
  Il est aussi possible d'associer une donn�e priv�e,�qui est piggybacked, �
  travers chaque invocation de crochet dans la m�me requ�te. Ceci permet, par
  exemple, d'associer un timestamp � l'�tape du traitement de la requ�te.

Naturellement, le passage de toutes les requ�tes par la couche d'intercepteur 
a un surco�t particulier. 
Des travaux \cite{MVB01} montrent que l'activation des intercepteurs portables
augmente la latence par un facteur variant entre 2\% et 10\%, 
et le temps de taitement des requ�tes par un facteur entre 1,5\% et 16\%. 
Ces  r�sultats d�montrent que cette technologie � un impact r�duit 
sur l'ex�cution global des applications. 
Ce co�t est relativement limit�, ce qui nous a motiv� � utiliser
cette technique pour d�ployer et reconfigurer les services syst�mes 
en cours d'ex�cution.

}

\item {{\bf Composant Orient� Syst�mes}
La r�alisation de cette m�thodologie consiste � r�cup�rer la r�f�rence de
l'ORB et du conteneur � adapter, puis � ajouter un composant CCM dont le code
est celui du service syst�me, et � effectuer les connexions n�cessaires avec
les composants sur lesquels ce service va s'appliquer. Le point fort de cette
m�thodologie est qu'elle est g�n�rique, elle peut s'appliquer pour tous les
intergiciels � composants. 
Les m�thodes d'int�gration pr�sent�es seront utilis�es par la suite.

}
\end{itemize}

\subsection{R�alisation de la CVM}
L'id�e principale de l'architecture CVM est d'ajouter un point d'entr�e dans
l'application, au d�ploiement initial.
Dans le cas d'OpenCCM, la r�alisation de ce point d'entr�e se fait � l'aide
d'une m�thode native Java, qui lance la MVV.
L'interfa�age entre la MVV et la JVM standard est r�alis�e 
par JNI~(Java Native Interface~\cite{jni}). 
JNI est une interface entre les fonctions natives et la machine virtuelle Java. 
La MVV est ex�cut�e par un thread Java en concurrence avec ceux de l'application.  
Le langage de la MVV est ensuite enrichi dynamiquement par les fonctions JNI~: 
les scripts �crits pour la MVV peuvent alors interagir directement avec la JVM, 
et la MVV est capable de manipuler les m�thodes et les symboles de l'application Java.

Une reconfiguration est constitu� de deux phases importantes :
\begin{enumerate}
\item La premi�re phase consiste � construire dans la MVV les mots cl�s du langage
  de reconfiguration dynamique d'OpenCCM. 
  Ces mots cl�s permettent de r�cup�rer la r�ference de l'ORB, 
  d'ajouter ou de supprimer des composants, 
  de charger des classes, ou bien d'invoquer des m�thodes. 
\item Le deuxi�me phase consiste � �crire un script MVV contenant 
  les adaptations souhait�es. 
  Ce script est charg� � distance dans la console d'administration et execut�
  dans les CVM. 
  Les scripts peuvent soit �tendre le langage de reconfiguration, soit utiliser
  les mots cl�s d�j� construits pour modifier l'application OpenCCM.
\end{enumerate}

Deux exemples de reconfigurations sont illustr�s dans ce qui suit.
\begin{figure}[ht]\centering
\includegraphics[width=12cm]{cvm1.eps}
\caption{Fonctionnement de la CVM  (Container Virtual Machine)}
\end{figure}

\section{Exemples d'utilisation de la CVM}\label{evaluation}
Dans cette section, deux exemples d'utilisation de la CVM sont pr�sent�s. 
Le premier consiste � ajouter un service de monitoring flexible, bas� sur la
technique d'intercepteur. 
Le second consiste � ajouter un service de cryptage, bas� sur la technique 
de COS (composant orient�e syst�mes), puis de l'adapter dynamiquement.

\subsection{Service de monitoring flexible}
Les services de monitoring sont la base de la gestion des applications
distribu�es complexes. 
Ils permettent, par exemple, d'avoir des informations sur les
ressources utilis�es et de d�finir des statistiques et des profils
utilisateurs.  Ces informations sont n�cessaires pour adapter le logiciel
au nouveau contexte de l'environnement. 
Dans le  cas des applications CCM, qui s'ex�cutent pendant une longue
dur�e et dans un environnement � large �chelle, 
il est souvent utile de reparam�trer un composant sp�cifique 
ou de remplacer l'impl�mentation d'un composant par un �quivalent. 

L'objectif de ce service de monitoring est de pouvoir collecter des
statistiques sur la fa�on dont les composants interagissent, et de rendre
ces informations disponibles � un <<service de reconfiguration>> capable
de les utiliser pour adapter la plate-forme. 
En particulier, cela signifie que l'on s'int�resse exclusivement 
� la r�colte et au tra�tement statistique des donn�es 
et non au sch�ma intelligent qui saurait comment les
interpr�ter et r�agir en cons�quence. Comme on ne veut pas cat�goriser
l'application monitor�e ou le logiciel sp�cifique (ORB, plate-forme CCM, ...)
utilis�, le code source de ceux-ci ne doit pas �tre modifi�.  Cette hypoth�se
est importante car beaucoup d'ORB sont des programmes commerciaux dont le
code source n'est pas toujours disponible. En outre, vu la diversit� des
applications et des environnements vis�s, le service doit �tre flexible. Cette
flexibilit� doit permettre aux programmeurs d'applications et aux
administrateurs syst�mes de d�finir leurs propres param�tres (ou d'adapter des
param�tres existants) et la fa�on dont les donn�es sont collect�es, en fonction
de leurs besoins.
Nous pr�sentons dans ce qui suit les m�triques utilis�es pour impl�menter ce
service de monitoring flexible, puis son impl�mentation dans la plateforme
OpenCCM et son int�gration dynamique dans l'application en cours d'ex�cution.

\subsubsection{M�triques} 
Plusieurs m�triques peuvent �tre extraites des donn�es brutes
obtenues par les intercepteurs portables. Les m�triques
disponibles sont pr�sent�es dans ce qui suit:

\begin{enumerate}

\item{ {\bf M�triques comptables :}
Ce type (simple) de m�trique est bas� sur les compteurs qui tracent les occurrences des op�rations similaires.
\begin{itemize}
\item {{\bf Invocations de m�thode :} compte le nombre de fois o� une m�thode sp�cifique est appel�e. }
\item  {{\bf utilisation composant :} additionne toutes les invocations des m�thodes appartenant au m�me composant.}
\end{itemize}
}

\item{ {\bf M�triques temporelles :}
  Associ�es avec des timestamps pr�cis, qui sont fournis par la plupart des syst�mes d'exploitation modernes, les traces produites peuvent �tre
employ�es pour extraire la m�trique temporelle, mesurant le temps requis pour
  effectuer une op�ration sp�cifique. 

}

\end{enumerate}


\subsubsection{Impl�mentation du service de monitoring dans la plateforme OpenCCM}
Les intercepteurs portables ont d�j� �t� impl�ment�s dans la plateforme
OpenCCM. En effet  les d�veloppeurs d'OpenCCM les utilisent pour
fournir le service de trace. Ce service est activ� en ajoutant $ --trace $ �
n'importe quel programme d�ploy�.
Ce service de trace nous aide de deux fa�ons dans l'impl�mentation du service
de monitoring. Premi�rement il montre pr�cis�ment les informations disponibles
aux intercepteurs portables dans la plateforme OpenCCM. Deuxi�mement, il
simplifie et propose une m�thodologie � suivre pour initialiser les
intercepteurs portables avec OpenCCM.
Les lignes suivantes montrent un exemple des enregistrements produits
par le service~:

{\footnotesize
\begin{verbatim}
     INFO date=2003-09-03 17:48:06,607 thread=Thread pool thread \#1
     topic=org.omg.openccm.core.CORBA.interceptors.server
     class=org.objectweb.corba.trace.PI.TraceSI
     method=send\_reply line=93 request id = 52 operation = create
     arguments = exceptions = response expected = true
     reply status = SUCCESSFUL
     target most derived interface = IDL:DiningPhilosophers/ForkHome:1.0
\end{verbatim}
}

Ce service enregistre dans un fichier journal toutes les informations sur les
requ�tes invoqu�es, scrute p�riodiquement ce journal, puis fournit les
statistiques sur les appels effectu�s.

\subsubsection{Int�gration dynamique du service de monitoring flexible }
L'utilisation de la CVM pour int�grer dynamiquement le service de monitoring,
est consitu�e de deux �tapes: 

\begin{enumerate}
\item Sp�cifer et ajouter les op�rations d'adaptation dans la MVV, tel que
  l'ajout d'url dans le class loader d'OpenCCM, 
  la r�cup�ration de la r�ference de l'ORB, 
  ou l'invocation des m�thodes Java charg�es par le class loader d'OpenCCM.
\item �crire et charger le script MVV permettant d'int�grer le service.
\end{enumerate}
 En exemple le script VVM ajoutant le service de monitoring  dynamiquement :
\begin{small}
\begin{verbatim}
(add_url_classloader "file:/home/user/openccm/Monitor/")
(add_url_classloader "file:/home/user/ORB/OpenCCM_Plugins.jar")

(define clazz "Monitor")
(define sign "(Ljava/lang/Object;)V")
(define mon (runCCM clazz "getInstance" sign))

(define sign  "(Ljava/lang/Object;)Ljava/lang/String;")
(define logfile "/tmp/monitor.log")
(define metric (runCCM "DebugMetric" "DebugMetric" sign log))

(define sign  "(Ljava/lang/Object;)Ljava/lang/Object;")
(define handle (runCCM_arg clazz "registerMetric" sign mon metric))

(runCCM_arg clazz "start" "()V")
\end{verbatim}
\end{small}
\subsection{Service de cryptage}
Soit une application contenant deux composants A et B, qui se trouvent
respectivement dans les conteneurs CA et CB, o� A envoie r�guli�rement des
messages � B. Consid�rons que durant l'ex�cution, l'administrateur d�cide
d'envoyer des messages crypt�s � B. Pour ce faire, l'int�gration d'un service
de cryptage revient � ajouter un composant COS de cryptage en utilisant la
CVM, dans le conteneur CA, puis d'�tablir les connections n�cessaires.
\begin{figure}[ht]\centering
\includegraphics[width=12cm]{crypt.eps}
\caption{Int�gration du service de cryptage}
\end{figure}


\subsubsection{Impl�mentation du COS de cryptage}
L'impl�mentation du COS passe par deux �tapes, qui sont:
\begin{enumerate}
\item {D�finir des op�rations
  n�cessaires � ajouter dans la MVV pour int�grer le COS de cryptage, tels que:

\begin{itemize}
\item {{\bf R�cup�ration de la r�f�rence de l'ORB�:} $(clssLoaderCCM getorb  )$
Cette instruction fait appel � une m�thode Java en utilisant la r�f�rence de
l'environnement JNI. }
\item {{\bf Chargement d'une classe}�: $(jrun~"nameClass")$ 
Cette instruction nous permet de charger dans la JVM de l'application OpenCCM
la classe ��nameClass��. Ce chargement peut se faire soit dans le classLoader
par d�faut ou dans le ClassLoader d'OpenCCM.}
\end{itemize}
\item {�crire puis charger le script MVV qui
  permet d'ajouter le COS dans le conteneur CA, de d�connecter A et B, et
  d'�tablir la connexion de A vers COS et de COS vers B. 
}
}
\end{enumerate}

\subsubsection{Adaptation du service de cryptage}
Adapter le comportament d'un composant peut �tre r�alis� en rempla�ant le
composant par un nouveau.
Cependant il est plus simple et moins co�teux d'adapter le composant en rempla�ant
certaines de ses m�thodes.

Dans le cas de l'adaptation du COS de cryptage, 
il suffit d'adapter la m�thode Java qui impl�mente l'algorithme de cryptage. 
Le standard Java permet le chargement dynamique de classe 
et la surcharge des m�thodes de s�rialisation. 
En couplant la plateforme Java de Sun et la  CVM nous pouvons adapter 
une m�thode Java. 
Prenons l'exemple de la m�thode ��metA�� de la classe A, 
l'adaptation de cette classe se fait en chargeant une nouvelle classe A1 
qui h�rite de A, et qui impl�mente le nouveau code de la m�thode ��metA��, 
puis en redirigeant tous les appels vers la nouvelle m�thode charg�e. 

Cette m�thodologie  permet d'adapter une m�thode statique Java, 
Cependant elle augmente le nombre de classes charg�es en m�moire, 
car la JVM standard ne pr�voit pas le d�chargement des classes. 



\section{Mesures de performances}\label{performances}
Pour les deux exemples cit�s pr�c�demment, nous avons mesur� la moyenne de la
dur�e de la reconfiguration sur un pentium III candens� � 664MHz sous Linux. 
La moyenne de la dur�e d'int�gration du service de monitoring, qui est bas� sur les
intercepteurs portables, est de 8,539 secondes. La moyenne de la dur�e d'ajout du COS de
cryptage est de 2,054 secondes. L'int�gration du COS est l�g�rement plus
rapide que celle des intercepteurs portables. Cependant ce co�t reste limit� et
comme les serveurs restent actifs  pendant cette periode, il n'y a pas de
rupture du service assur�.



\section{Conclusion}\label{perspectives}
Dans cet article, nous fournissons une r�ponse � la probl�matique de
l'adaptation des services syst�mes dans les plateformes actuelles 
qui sont ferm�es. 
D'abord, nous proposons deux m�thodologies pour int�grer 
les services�syst�mes�; l'une bas�e sur la technologie des intercepteurs
portables, et l'autre sur des composants CCM orient�s syst�me. 
Ensuite nous  d�finissons l'architecture d'un outil (appel� 
Container Virtual Machine) permettant  de reconfigurer dynamiquement 
les services syst�mes, sans avoir pour autant � modifier ni le code 
des composants sur lesquels le service s'applique ni le code de l'intergiciel. 
Les modifications se font dynamiquement, sans interruption de service.
Finalement, nous avons pr�sent� la r�alisation du premier prototype
pour la plateforme OpenCCM du LIFL.

L'outil CVM est bas� sur une architecture g�n�raliste par rapport
� l'intergiciel cibl�, il offre un moyen de contr�ler et de red�finir
dynamiquement les op�rations d'adaptation � autoriser, mais il permet aussi
l'int�gration dynamique des services syst�mes. Ces services peuvent �tre �crits
soit en Java, ou bien en MVV ce qui permettra de faire appel � des op�rations de bas
niveau. Nous avons pr�sent�  ces adaptations � l'aide de deux exemples~:
l'ajout dynamique du service de  monitoring et l'int�gration
dynamique d'un composant de cryptage. 

En  conclusion, la CVM offre la possibilit� de sp�cifier les propri�t�s
syst�mes et de les int�grer dynamiquement. 
Ses sp�cifications sont valides pour la norme CORBA CCM, 
et se basent sur un langage de reconfiguration g�n�raliste, 
ind�pendant de l'intergiciel cibl�.


En perspective, nous visons � g�n�raliser notre m�thodologie d'adaptation �
d'autres intergiciels � composants.

\bibliography{main}

\end{document}


main.bbl
\begin{thebibliography}{}

\bibitem[AND~00]{oopp}
\textsc{Andersen A.}, \textsc{Blair G.}\andname{}\textsc{Eliassen F.},
  \guilo{}OOPP: A reflective component-based middleware\guilf{},
\newblock \Inname{} \textit{Norsk Informatikk Konferance}, 2000.

\bibitem[BRU~00]{javapod}
\textsc{Bruneton E.}\andname{}\textsc{Riveill M.}, \guilo{}JavaPod : une
  plate-forme � composants adaptables et extensibles\guilf{},
\newblock Rapport technique 3850, 2000, Inria Rhone-Alpes.

\bibitem[DAN~01]{coeur}
\textsc{Daniel J.}, \textit{Au coeur de Corba},
\newblock 2001.

\bibitem[FOL~98]{folliot98}
\textsc{Folliot B.}, \textsc{Piumarta I.}\andname{}\textsc{Riccardi F.},
  \guilo{}A Dynamically Configurable, Multi-Language Execution
  Platform\guilf{},
\newblock \Inname{} \textit{8th ACM SIGOPS European Workshop}, 1998,
  \pagesname{} 175-181.

\bibitem[HAU~98]{hauck98aspectix}
\textsc{Hauck F.~J.}, \textsc{Becker U.}, \textsc{Geier M.}, \textsc{Meier E.},
  \textsc{Rastofer U.}\andname{}\textsc{Steckermeier M.}, \guilo{}Aspect{IX}:
  An aspect-oriented and {CORBA}-compliant {ORB} architecture\guilf{},
\newblock \technicalreportname{} \numbername TR-I4-98-08, 1998, Univ. of
  Erlangen-Nuernberg, IMMD IV.

\bibitem[KON~00]{dynamicTAO}
\textsc{Kon F.}, \textsc{Rom\'an M.}, \textsc{Liu P.}, \textsc{Mao J.},
  \textsc{Yamane T.}, \textsc{Magalh{\~a}es L.~C.}\andname{}\textsc{Campbell
  R.~H.}, \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 Distributed Processing
  (Middleware'2000)}, \numbername{} 1795 \inname{} LNCS, New York, April 2000,
  Springer-Verlag,  \pagesname{} 121-143.

\bibitem[KON~01]{2K}
\textsc{Kon F.}, \textsc{Campbell R.~H.}, \textsc{Mickunas M.~D.},
  \textsc{Nahrstedt K.}\andname{}\textsc{Ballesteros F.~J.}, \guilo{}2K: A
  Distributed Operating System for Dynamic Heterogeneous Environments\guilf{},
\newblock \Inname{} \textit{Ninth IEEE International Symposium on High
  Performance Distributed Computing (HPDC'00)}, 2001,  \pagename{} 201.

\bibitem[LIA~99]{jni}
\textsc{Liang S.}, \textit{The JavaTM Native Interface: Programmer's Guide and
  Specification},
\newblock Addison Wesley Longman, 1999.

\bibitem[MAK~94]{makpangou94fragmented}
\textsc{Makpangou M.}, \textsc{Gourhant Y.}, \textsc{Narzul
  J.-P.~L.}\andname{}\textsc{Shapiro M.}, \guilo{}\textit{Fragmented objects
  for distributed abstractions}\guilf{},  \pagesname{} 170--186,
\newblock IEEE Computer Society Press, 1994.

\bibitem[MAR~01]{MVB01}
\textsc{Marchetti C.}, \textsc{Verde L.}\andname{}\textsc{Baldoni R.},
  \guilo{}CORBA request portable interceptors: a performance analysis\guilf{},
\newblock \Inname{} \textit{Proceedings of the 3rd International Symposium on
  Distributed Objects and Applications}, Rome, Italy, September 2001.

\bibitem[Obj01]{intercepteurs-corba}
Object Managment Group, \guilo{}Interceptors Published Draft with Corba 2.4+
  Core Chapters\guilf{}, 2001,
\newblock Document Number ptc/2001-03-04.

\bibitem[OGE~03]{ogel03}
\textsc{Ogel F.}, \textsc{Thomas G.}, \textsc{Piumarta I.}, \textsc{Galland
  A.}, \textsc{Folliot B.}\andname{}\textsc{Baillarguet C.},
  \guilo{}\textit{Towards Active Applications: the Virtual Virtual Machine
  Approach}\guilf{},  \pagesname{} 28-47,
\newblock A92 Publishing House, POLIROM Press, 2003.

\bibitem[OMG~02a]{Obj02a}
\textsc{OMG},
\newblock \guilo{}CORBA / IIOP specification 3.0. formal/024206\guilf{},
  December 2002.

\bibitem[OMG~02b]{Obj02b}
\textsc{OMG},
\newblock \guilo{}CORBA 3.0 - portable interceptors chapter.
  formal/020657\guilf{}, June 2002.

\bibitem[ope04]{openccm}
\guilo{}OpenCCM User's Guide\guilf{},
\newblock http://openccm.objectweb.org/doc/0.8.1/user\_guide.html, 04 2004.

\bibitem[SCH~00]{tao}
\textsc{Schmidt D.}\andname{}\textsc{Cleeland C.}, \guilo{}Applying a Pattern
  Language to Develop Extensible ORB Middleware\guilf{},
\newblock \textit{Design patterns in communications software}, , 2000,
  \pagesname{} 393-438.

\bibitem[VAD~01]{merle}
\textsc{Vadet M.}\andname{}\textsc{Merle P.},
\newblock \guilo{}Les containers ouverts dans les plates-formes �
  composants\guilf{},
\newblock Journ�es composants : flexibilit� du syst�me au langage, 10 2001.

\end{thebibliography}
