Contractualisation des ressources\\pour le d�ploiement des composants logiciels
Nicolas Le Sommer
Software deployment can turn into a baffling problem when the components being deployed exhibit non-functional requirements. If the platform on which such components are deployed cannot satisfy their non-functional requirements, then they may in turn fail to perform satisfactorily. In this paper, we present a contract-based approach to take a specific category of non-functional properties specified by components into account, that is those that pertain to the resources that are necessary for their execution.
decor-2004.tex
\documentclass[french]{article-hermes}
\usepackage[T1]{fontenc}
%\pagestyle{empty}
\usepackage{graphicx}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% LyX specific LaTeX commands.
\newcommand{\noun}[1]{\textsc{#1}}

\usepackage{babel}
\usepackage{times}

\begin{document}
\title[Contractualisation des ressources]{Contractualisation des
  ressources\\pour le d�ploiement des composants logiciels}

\date{}

\author{Nicolas Le Sommer} 

\address{Laboratoire Valoria\\ Universit� de Bretagne Sud\\ Centre de
  recherches Yves Coppens\\ Campus de Tohannic \\ 56000 Vannes, France
  \\ \texttt{Nicolas.Le-Sommer@univ-ubs.fr}}

\resume{Le d�ploiement de composants logiciels peut s'av�rer �tre une
  t�che complexe et difficile � r�aliser d�s lors que les composants
  logiciels exhibent des propri�t�s non-fonctionnelles. En effet, de
  tels composants peuvent ne pas fonctionner de mani�re convenable si
  certaines de ces propri�t�s ne peuvent �tre satisfaites par leur
  plate-forme de d�ploiement.  Dans cet article, nous nous proposons
  de prendre en compte via une approche contractuelle et r�flexive une
  cat�gorie sp�cifique des exigences non-fonctionnelles exprim�es par
  les composants logiciels, � savoir celles portant sur les ressources
  qui sont n�cessaires � leur ex�cution. }

\motscles{Composants logiciels, ressources, contrats, deploiement} 

\abstract{ Software deployment can turn into a baffling problem when
  the components being deployed exhibit non-functional requirements.
  If the platform on which such components are deployed cannot satisfy
  their non-functional requirements, then they may in turn fail to
  perform satisfactorily. In this paper, we present a contract-based
  approach to take a specific category of non-functional properties
  specified by components into account, that is those that pertain to
  the resources that are necessary for their execution. }

\keywords{Software components, resources, contracts, deployment} 

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

\maketitlepage


%%-------------------------------------------------------------------------------
%% Introduction
%%-------------------------------------------------------------------------------


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

De nos jours, les composants logiciels sont devenus des �l�ments
architecturaux incontournables dans le monde du logiciel. Ils doivent
permettre d'assimiler � terme le d�veloppement du logiciel � un simple
processus d'assemblage.  Cet objectif ne pourra �tre atteint qu'� la
condition de disposer de composants logiciels con�us comme de
v�ritables unit�s de d�ploiement fiables, performantes et parfaitement
d�crites tant du point de vue de leurs propri�t�s fonctionnelles que
de leurs propri�t�s non-fonction\-nelles.  Les mod�les de composants
actuels (e.g. \noun{Corba} Component Model, Entreprise Java Beans,
Fractal, \noun{Com}, OSGi) n'offrent pas aux programmeurs le moyen de
sp�cifier toutes les propri�t�s non-fonctionnelles de leurs
composants. Ainsi, les ressources n�cessaires � l'ex�cution des
composants logiciels --qui constituent l'une des principales
cat�gories de propri�t�s non-fonctionnelles pouvant �tre exhib�es par
les composants-- sont actuellement ignor�es dans ces mod�les de
composants. Les composants logiciels n'ont pourtant pas tous les m�mes
besoins vis-�-vis des ressources. Certains composants peuvent
fonctionner avec peu de ressources et avec aucune garantie de
disponibilit� de ressources (e.g. des composants r�alisant des calculs
�l�mentaires), alors que d'autres composants vont exiger de disposer
de ressources en quantit�s importantes et des garanties de
disponibilit� vis-�-vis de ces ressources afin de pouvoir fournir �
leurs utilisateurs un certain niveau de qualit� de service (e.g. des
composants traitant et affichant des flux vid�os).

Dans cet article, nous nous proposons de prendre en compte les besoins
en ressources des composants logiciels avec une approche contractuelle
et r�flexive. Cette approche vise � permettre aux composants logiciels
d'indiquer � leur environnement de d�ploiement qu'ils n'utiliseront
pas plus de ressources que celles dont ils font explicitement la
demande, et � leur permettre de b�n�ficier en retour d'un certain
service de la part de cet environnement d'accueil vis-�-vis de la
disponibilit� des ressources demand�es. Cette approche a �galement
pour objectif d'offrir aux composants logiciels le moyen de raisonner
sur leurs conditions d'ex�cution � travers les contrats qu'ils
souscrivent avec leur environnement de d�ploiement, de pouvoir
modifier ces conditions d'ex�cution en ren�gociant dynamiquement les
modalit�s de leurs contrats, et �ventuellement de pouvoir adapter leur
comportement en fonction des contrats n�goci�s. Nous montrons
�galement dans cet article comment cette approche a �t� mise en \oe
uvre au sein d'une plate-forme de d�ploiement exp�rimentale baptis�e
\noun{Jamus}.

La suite de cet article s'articule de la mani�re suivante. Le
paragraphe~\ref{sec:overview} offre une vue d'ensemble de notre
approche. Le paragraphe~\ref{sec:contrats} propose une mod�lisation
orient�e objet des contrats portant sur les conditions d'acc�s aux
ressources. Le paragraphe~\ref{sec:jamus} pr�sente les m�canismes qui
permettent de g�rer ces contrats de mani�re dynamique, ainsi que la
mise en \oe uvre de ces m�canismes au sein de la plate-forme
\noun{Jamus}. Le paragraphe~\ref{sec:related-work} pr�sente quelques
travaux dont la d�marche ou la finalit� s'apparentent � la n�tre.  En
guise de conclusion, le paragraphe~\ref{sec:conclusion} r�sume les
diff�rents �l�ments cl�s de notre approche et �num�re quelques unes
des perspectives offertes par ce travail.

%%-------------------------------------------------------------------------------
%% Vue d'ensemble de l'approche propos�e
%%-------------------------------------------------------------------------------


\section{\label{sec:overview}Vue d'ensemble de l'approche propos�e}

Certains composants logiciels pr�sentent des besoins en ressources
invariables et parfaitement identifi�s, alors que d'autres exhibent
des besoins en ressources partiels qui �voluent en cours d'ex�cution
(e.g. composants dont les besoins en ressources sont li�s aux choix de
l'utilisateur). Il nous para�t donc essentiel que les composants
logiciels puissent exprimer leurs besoins en ressources dynamiquement.
De la m�me mani�re, pour pouvoir tenir compte des besoins en
ressources exprim�s par les composants logiciels, l'environnement de
d�ploiement des composants doit �tre dot� de m�canismes lui permettant
de d�terminer dynamiquement s'il est en mesure de satisfaire ces
besoins au vu des ressources dont il dispose, et doit �tre pourvu de
m�canismes lui permettant de g�rer ces ressources afin d'en assurer la
disponibilit� le cas �ch�ant.

Dans cette optique, nous avons con�u un cadre de conception qui
d�finit la structure d'un syst�me de contractualisation dynamique des
ressources.  Ce cadre de conception, dont une vue d'ensemble est
pr�sent�e dans la figure~\ref{fig:framework-overview}, est organis� en
deux couches.  Chaque couche peut �tre compl�t�e et �tendue � volont�
par les d�veloppeurs, leur permettant ainsi de concevoir un syst�me de
contractualisation r�pondant pr�cis�ment � leurs besoins.

%
\begin{figure}
\begin{center}\includegraphics[%
  width=0.95\columnwidth]{figures/framework-structure.eps}\end{center}


\caption{\label{fig:framework-overview}Fonctionnalit�s offertes par le cadre
de conception}
\end{figure}


La couche inf�rieure du cadre de conception d�finit la structure d'un
ensemble de fonctionnalit�s con�ues pour offrir une repr�sentation
d'un environnement par r�ification des ressources de ce dernier, et
con�ues pour observer et g�rer ces ressources � travers cette
repr�sentation.  Les fonctionnalit�s de la couche inf�rieure du cadre
de conception ont �t� d�finies ind�pendamment de celles de la couche
sup�rieure.  Elles peuvent donc par exemple �tre utilis�es pour
concevoir des m�canismes de supervision et de contr�le de machines
h�tes ou des composants logiciels adaptatifs.

La couche sup�rieure du cadre de conception d�finit quant � elle la
structure d'une fonctionnalit� de contr�le d'admission, qui permet �
un environnement de d�ploiement de d�terminer s'il est en mesure de
satisfaire les besoins en ressources exprim�s par les composants
logiciels; la structure d'une fonctionnalit� de supervision des
composants, qui permet de v�rifier que les composants utilisent les
ressources conform�ment � leur contrat; et la structure d'une
fonctionnalit� qui offre le moyen de r�ifier les contrats sous la
forme objet, ainsi que de n�gocier et de v�rifier dynamiquement ces
contrats.



%%-------------------------------------------------------------------------------
%% Pr�sentation des contrats
%%-------------------------------------------------------------------------------


\section{\label{sec:contrats}Contrats et  avenants}


\subsection{Contrats}



Les contrats que nous avons d�finis permettent d'exprimer les besoins
en ressources des composants logiciels de mani�re qualitative (e.g.
droits d'acc�s, contraintes de disponibilit�) et quantitative (e.g.
quotas). Ces contrats sont d�finis comme un ensemble de profils
d'utilisation des ressources. Un profil est compos� de quatre
attributs. Le premier attribut identifie une ressource de mani�re
pr�cise. Le deuxi�me attribut et le troisi�me attribut d�finissent
respectivement les droits d'acc�s et les quotas requis par le
composant vis-�-vis de cette ressource. Le quatri�me attribut sp�cifie
quant � lui la mani�re selon laquelle l'environnement de d�ploiement
doit assurer la disponibilit� de cette ressource. Gr�ce � ce dernier
attribut, les composants logiciels peuvent pr�ciser que certaines
ressources doivent leur �tre r�serv�es, alors que d'autres ne doivent
pas n�cessairement l'�tre. Ils peuvent ainsi indiquer � leur
plate-forme de d�ploiement comment ils sont susceptibles de se
comporter en cours d'ex�cution.





� titre d'exemple, consid�rons un composant logiciel baptis�
\emph{JMailer} qui offre le moyen de r�diger et d'envoyer des
courriers �lectroniques.  Ce composant offre � l'utilisateur deux
modes de fonctionnements possibles. Dans le premier mode,
l'utilisateur doit sp�cifier sans aucune assistance l'adresse des
destinataires, le sujet et le contenu du courrier �lectronique. Dans
le second mode, une assistance lui est fournie pour saisir les
adresses �lectroniques � travers l'utilisation d'un carnet d'adresses.
Pour pouvoir fonctionner dans le mode sans assistance, ce composant
logiciel exige de pouvoir lire et �crire jusqu'� 500 Kilo-octets de
donn�es dans le r�pertoire \emph{\textasciitilde{}/.jmailer}, et
demande � disposer de 1 M�ga-octet de m�moire. Pour s'ex�cuter dans le
second mode, le composant \emph{JMailer} demande � pouvoir lire et
�crire jusqu'� 500 Kilo-octets de donn�es dans le r�pertoire
\emph{\textasciitilde{}/.jmailer} et jusqu'� 1 M�ga-octets de donn�es
dans le r�pertoire \emph{\textasciitilde{}/.jaddrbook}, et exige de
disposer de 2 M�ga-octet de m�moire. Pour contractualiser ces
conditions d'acc�s aux ressources, notre composant de d�monstration
\emph{JMailer} pourra par exemple soumettre � son environnement de
d�ploiement les contrats \emph{contract1} et \emph{contract2} de la
figure~\ref{fig:exemple-contrats}.

%
\begin{figure}[t]
\begin{flushleft}\hrule{}~\\
\textsf{\footnotesize ~}\textsf{\scriptsize ~~~~int Ko=1024;
int Mo=1024{*}1024;}\\
\textsf{\footnotesize ~}\textsf{\scriptsize ~~~~ResourceUtilisationProfile
r1, r2, r3, r4;}\\
\textsf{\footnotesize ~}\textsf{\scriptsize ~~~~}\textsf{\emph{\scriptsize //}}
\textsf{\scriptsize }\textsf{\emph{\scriptsize Acc�s en lecture et
�criture au r�pertoire \textasciitilde{}/.jmailer}}\\
\textsf{\footnotesize ~}\textsf{\scriptsize ~~~~}\textsf{\emph{\scriptsize //
quotas = 500 Koctets en lecture et �criture}}\\
\textsf{\footnotesize ~}\textsf{\scriptsize ~~~~}\textsf{\textbf{\scriptsize r1
= new}} \textsf{\scriptsize ResourceUtilisationProfile}\textsf{\textbf{\scriptsize (new}}
\textsf{\scriptsize FilePattern(\char`\"{}\textasciitilde{}/.jmailer\char`\"{}),}\textsf{\textbf{\scriptsize ~new}}
\textsf{\scriptsize FilePermission(FilePermission.ALL), }\\
\textsf{\textbf{\scriptsize ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~new}}
\textsf{\scriptsize FileQuota(500{*} Ko, 500{*}Ko),}\textsf{\textbf{\scriptsize ~new}}
\textsf{\scriptsize BestEffort())); }\\
\textsf{\scriptsize ~~~~~}\textsf{\emph{\scriptsize //}} \textsf{\scriptsize }\textsf{\emph{\scriptsize Acc�s
en lecture et �criture au r�pertoire \textasciitilde{}/.jaddressbook}}\\
\textsf{\emph{\scriptsize ~~~~~// quotas = 1 Moctets en lecture
et �criture}}\\
\textsf{\scriptsize ~~~~~}\textsf{\textbf{\scriptsize r2 = new}}
\textsf{\scriptsize ResourceUtilisationProfile}\textsf{\textbf{\scriptsize (new}}
\textsf{\scriptsize FilePattern(\char`\"{}\textasciitilde{}/.jaddrbook\char`\"{}),}\textsf{\textbf{\scriptsize ~new}}
\textsf{\scriptsize FilePermission(FilePermission.ALL), }\\
\textsf{\textbf{\scriptsize ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~new}}
\textsf{\scriptsize FileQuota(1{*} Mo, 1{*}Mo),}\textsf{\textbf{\scriptsize ~new}}
\textsf{\scriptsize BestEffort())); }\\
\textsf{\scriptsize ~~~~~}\textsf{\emph{\scriptsize //}} \textsf{\scriptsize }\textsf{\emph{\scriptsize r�servation
de 1 Moctets de m�moire}}\\
 \textsf{\scriptsize ~~~~~}\textsf{\textbf{\scriptsize r3 = new}}
\textsf{\scriptsize ResourceUtilisationProfile}\textsf{\textbf{\scriptsize (new}}
\textsf{\scriptsize MemoryPattern(),}\textsf{\textbf{\scriptsize ~new}}
\textsf{\scriptsize MemoryPermission(), }\\
\textsf{\textbf{\scriptsize ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~new}}
\textsf{\scriptsize MemoryQuota(1{*} Mo),}\textsf{\textbf{\scriptsize ~new}}
\textsf{\scriptsize ResourceReservation())); }\\
\textsf{\scriptsize ~~~~~}\textsf{\emph{\scriptsize //}} \textsf{\scriptsize }\textsf{\emph{\scriptsize r�servation
de 2 Moctets de m�moire}}\\
 \textsf{\scriptsize ~~~~~}\textsf{\textbf{\scriptsize r4 = new}}
\textsf{\scriptsize ResourceUtilisationProfile}\textsf{\textbf{\scriptsize (new}}
\textsf{\scriptsize MemoryPattern(),}\textsf{\textbf{\scriptsize ~new}}
\textsf{\scriptsize MemoryPermission(), }\\
\textsf{\textbf{\scriptsize ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~new}}
\textsf{\scriptsize MemoryQuota(2{*} Mo),}\textsf{\textbf{\scriptsize ~new}}
\textsf{\scriptsize ResourceReservation())); }\end{flushleft}{\scriptsize \par}

\begin{flushleft}\textsf{\scriptsize ~~~~~ResourceOrientedContract
contract1=} \textsf{\textbf{\scriptsize new}} \textsf{\scriptsize ResourceOrientedContract
(\{r1, r2, r4\});}\\
\textsf{\scriptsize ~~~~~ ResourceOrientedContract contract2=}
\textsf{\textbf{\scriptsize new}} \textsf{\scriptsize ResourceOrientedContract
(\{r1, r3\});}\\
~\\
\hrule{}\end{flushleft}


\caption{\label{fig:exemple-contrats}Exemple de contrats pouvant �tre soumis
� la plate-forme \noun{Jamus} }
\end{figure}





\subsection{Avenants}

Ainsi que nous l'avons mentionn� pr�c�demment, les besoins en
ressources des composants logiciels sont susceptibles d'�voluer au
cours du temps. Il est donc n�cessaire d'offrir aux composants la
possibilit� de pouvoir ren�gocier dynamiquement les modalit�s du
contrat qu'ils ont pass�es avec leur environnement de d�ploiement. Le
m�canisme d'avenants que nous avons introduit dans notre cadre de
conception offre  aux composants cette possibilit�. En effet, ces
avenants sont d�finis comme un ensemble de clauses qui d�crivent les
op�rations d'ajout, de suppression, de modification de clause d'un
contrat. � l'instar des contrats, les avenants sont r�ifi�s sous la
forme objet afin de pouvoir �tre d�finis et n�goci�s dynamiquement par
les composants et leur environnement.



La figure~\ref{fig:exemple-avenant} pr�sente un exemple d'avenant qui
peut �tre soumis par le composant \emph{JMailer} � son environnement
de d�ploiement pour ren�gocier les modalit�s du contrat qui les lie.
Cet avenant a pour effet d'ajouter un profil d'utilisation des
ressources portant sur les conditions d'acc�s au r�pertoire
\emph{/tmp} dans le contrat \emph{contract2} pr�sent� dans la
figure\emph{~\ref{fig:exemple-contrats}.}



%
\begin{figure}
\begin{flushleft}\hrule{}~\\
\textsf{\scriptsize ~~~~~int Mo=1024{*}1024;}\\
\textsf{\scriptsize ~~~~~ResourceUtilisationProfile r5;}\\
\textsf{\scriptsize ~~~~~}\textsf{\emph{\scriptsize // acc�s
en lecture et en �criture au r�pertoire /tmp}}\\
\textsf{\scriptsize ~~~~~}\textsf{\textbf{\scriptsize r5 = new}}
\textsf{\scriptsize ResourceUtilisationProfile}\textsf{\textbf{\scriptsize (new}}
\textsf{\scriptsize FilePattern(\char`\"{}/tmp\char`\"{},),}\textsf{\textbf{\scriptsize ~new}}
\textsf{\scriptsize FilePermission(FilePermission.ALL), }\\
\textsf{\textbf{\scriptsize ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~new}}
\textsf{\scriptsize FileQuota(2{*} Mo, 2{*}Mo),}\textsf{\textbf{\scriptsize ~new}}
\textsf{\scriptsize BestEffort());}\\
\textsf{\scriptsize ~~~~~AmendmentClause ac1 =~}\textsf{\textbf{\scriptsize new}}
\textsf{\scriptsize AmendmentClause(AmendmentClause.ADD, r5);}\\
\textsf{\scriptsize ~~~~~Amendment a1=} \textsf{\textbf{\scriptsize new}}
\textsf{\scriptsize Amendment (contract2, \{ac1\});}\\
{\scriptsize ~}\\
\hrule{}\end{flushleft}


\caption{\label{fig:exemple-avenant}Exemple d'un avenant pouvant �tre soumis
� la plate-forme \noun{Jamus}}
\end{figure}




Le paragraphe suivant pr�sente les m�canismes qui permettent de g�rer
ces contrats et ces avenants de mani�re dynamique au sein de la
plate-forme \noun{Jamus}.


%%-------------------------------------------------------------------------------
%% Pr�sentation de Jamus
%%-------------------------------------------------------------------------------

\section{\label{sec:jamus}La plate-forme \noun{Jamus}}

\noun{Jamus} (\emph{Java Accommodation of Mobile Untrusted Software})
est une plate-forme exp�rimentale d�di�e � l'h�bergement de composants
mobiles Java capables d'exprimer leurs besoins vis-�-vis des ressources.
\noun{Jamus} a �t� con�ue par sp�cialisation de la couche sup�rieure
de notre cadre de conception. Elle s'appuie sur les fonctionnalit�s
d'observation et de contr�le d'acc�s des ressources offertes par l'environnement
d'ex�cution \noun{Raje} (\emph{Resource-Aware Java Environment}),
environnement que nous avons con�u par sp�cialisation de la couche
inf�rieure du cadre de conception. Cet environnement \noun{Raje}
n'est pas pr�sent� plus amplement dans cet article par manque
de place. Le lecteur pourra toutefois se r�f�rer �~\cite{TheseNico}
pour avoir une pr�sentation d�taill�e de \noun{Raje.}

La plate-forme \noun{Jamus} offre aux composants logiciels le moyen
de contractualiser dynamiquement leurs modalit�s d'acc�s aux ressources.
 En outre, �tant d�di�e � l'h�bergement de composants logiciels potentiellement
non dignes de confiance, la plate-forme \noun{Jamus} soumet chaque
composant h�berg� � une supervision constante au cours de son ex�cution
et interdit toute utilisation des ressources non conforme aux contrats
qu'ils ont souscrits avec elle.   




\subsection{Gestion des contrats}

Dans \noun{Jamus}, les propositions de contrats soumises par les
composants logiciels sont �valu�es par un courtier de ressources.  Ce
courtier impl�mente une fonctionnalit� de contr�le d'admission et un
m�canisme de r�servation des ressources afin d'offrir aux composants
h�berg�s une certaine qualit� de service vis-�-vis de la disponibilit�
des ressources. La figure~\ref{fig:contract-management} montre comment
ce courtier est interrog� par le gestionnaire de contrats de la
plate-forme \noun{Jamus} pour �valuer les contrats. Le processus de
contractualisation des ressources mis en \oe uvre au sein de la
plate-forme \noun{Jamus} comporte deux phases : une phase de
soumission des contrats et une phase de souscription des contrats. Ces
deux phases ont �t� distingu�es afin de permettre aux composants
logiciels de pouvoir soumettre � leur environnement de d�ploiement
plusieurs contrats pour �valuation avant de souscrire un contrat
particulier avec celui-ci.




\subsubsection{Soumission des contrats}

Lors du d�marrage de la plate-forme, le courtier re�oit en param�tre
un ensemble de profils d'utilisation des ressources d�crivant les
ressources disponibles au sein de la plate-forme \noun{Jamus}. Au vu
de ces informations et de celles qu'il a maintenues � jour en fonction
des contrats souscrits avec les composants h�berg�s par la plate-forme
\noun{Jamus}, le courtier de ressources d�cide de la validit� des
contrats soumis par les composants candidats � l'h�bergement.  Un
contrat est d�clar� acceptable par le courtier si toutes les clauses
de celui-ci peuvent �tre satisfaites.  Lorsqu'un contrat est d�clar�
inacceptable par le courtier de ressources, le gestionnaire de
contrats de la plate-forme \noun{Jamus} invoque une nouvelle fois ce
courtier afin de conna�tre les profils qui ne peuvent pas �tre
satisfaits (invocation de la m�thode \emph{getConflictingClause()}).
Sur la base des informations retourn�es par le courtier de ressources,
le gestionnaire de contrats construit un rapport de soumission qu'il
retourne au composant logiciel. Ces informations visent � aider ce
dernier dans la formulation de nouvelles propositions de contrats.

La figure~\ref{fig:contract-management} illustre ces propos en
pr�sentant un sc�nario de n�gociation de contrats entre notre
composant de d�monstration \emph{JMailer} et la plate-forme
\noun{Jamus}.

%
\begin{figure}
\begin{center}\includegraphics[%
  width=0.70\columnwidth,
  height=8cm]{figures/InteractionsWebSurfer.eps}\end{center}


\caption{\label{fig:contract-management}Exemple de n�gociation des modalit�s
d'acc�s aux ressources entre le composant \emph{JMailer} et la plate-forme
\noun{Jamus}}
\end{figure}



\subsubsection{Souscription des contrats }

Lors de la phase de souscription, les contrats sont �valu�s une
nouvelle fois avant que les ressources ne soient r�serv�es pour le
composant par le courtier. Cette r��valuation est n�cessaire dans
\noun{Jamus} car toute ou partie des ressources requises par le
composant candidat � l'h�bergement peuvent avoir �t� allou�es aux
autres composants pr�sents dans la plate-forme \noun{Jamus} au moment
de la souscription du contrat. Lorsque cette r��valuation est pass�e
avec succ�s, le courtier r�serve les ressources pour le composant
logiciel.  Cette r�servation s'effectue en pr�levant sur les quotas
des profils d'utilisation des ressources concern�s les valeurs de
quotas d�finis dans les profils du contrat.

� titre d'exemple, le contrat \emph{contract2} ayant �t� d�clar�
acceptable par le courtier de \noun{Jamus}, le composant
\emph{JMailer} peut initier une phase de souscription du contrat
\emph{contract2} (voir figure~\ref{fig:contract-management}).  Ce
contrat est �valu� une nouvelle fois par le courtier de ressources
afin de d�terminer si les besoins requis par le composant peuvent
toujours �tre satisfaits. Dans le cas pr�sent, nous supposerons qu'ils
le sont. Le gestionnaire de contrats de \noun{Jamus} demande alors au
courtier de ressources de r�server les ressources pour le composant
\emph{JMailer}.




\subsection{Supervision des composants logiciels}

Chaque composant h�berg� par la plate-forme \noun{Jamus} s'ex�cute au
sein d'un conteneur. Le conteneur permet d'isoler un composant en lui
offrant son propre espace de nommage.  Ainsi, les objets cr��s par les
diff�rents composants s'ex�cutant au sein de la plate-forme
\noun{Jamus} ne peuvent �tre partag�s et un composant ne peut acc�der
aux objets manipul�s par d'autres composants.

Chaque conteneur int�gre un registre de ressources qui est charg� de
r�f�rencer les ressources cr��es par le composant logiciel consid�r�,
ainsi qu'un moniteur d'appli\-ca\-tion capable d'extraire des contrats
les profils d'utilisation des ressources, et capable d'instancier en
cons�quence des moniteurs de res\-sour\-ces qui seront charg�s de
s'assurer que l'utilisation qui est faite des ressources demeure
conforme aux modalit�s d'utilisation d�finies par le contrat souscrit
par le composant. La plate-forme \noun{Jamus} int�gre un type de
moniteurs de ressources sp�cifique pour chaque type de ressources
consid�r� dans \noun{Raje}. Chaque conteneur int�gre �galement un
auditeur de registre de res\-sour\-ces (\emph{ResourceTracker}) qui
est charg� d'indiquer aux moniteurs de ressources quelles sont les
ressources qu'ils doivent superviser.

%
\begin{figure}
\begin{center}\includegraphics[%
  width=0.80\columnwidth]{figures/exemple-fonctionnement-conteneur.eps}\end{center}


\caption{\label{fig:fonctionnement-conteneur}Principe de fonctionnement du
conteneur}
\end{figure}


Afin de pr�senter le principe de fonctionnement d'un conteneur,
consid�rons le sc�nario pr�sent� dans la
figure~\ref{fig:fonctionnement-conteneur}.  Lors de la configuration
du conteneur, l'auditeur de registre de ressources s'enregistre en
tant qu'auditeur aupr�s du registre de ressources afin d'�tre inform�
de toute nouvelle cr�ation ou destruction de ressources dans le
conteneur (action 1). Le moniteur d'application instancie quant � lui
des moniteurs de ressources en fonction des profils d'utilisation des
ressources contenus dans le contrat souscrit par le composant
consid�r�. Dans notre exemple, le moniteur d'application va instancier
un moniteur de type \emph{FileMonitor} afin de superviser les acc�s du
composant \emph{JMailer} au r�pertoire de l'utilisateur, ainsi qu'un
moniteur de type \emph{MemoryMonitor} pour v�rifier l'utilisation qui
est faite de la m�moire (action 2). � l'issue de cette phase de
configuration, le conteneur charge le composant \emph{JMailer} et
initie son ex�cution.

Les objets ressources d�finis dans \noun{Raje} sont con�us de mani�re
� s'enregistrer spontan�ment aupr�s du registre de ressources lors
de leur cr�ation. Ainsi, l'objet ressource de type \emph{FileOutputStream}
est capable d'informer automatiquement le registre de ressources (action
3) lors de sa cr�ation (action 4). Le registre de ressources informe
� son tour l'auditeur de registre de ressources de la cr�ation de
cette nouvelle ressource (action 5). Ce dernier invoque alors le moniteur
d'application pour obtenir la liste des moniteurs de ressources instanci�s
(action 6). Sur la base de cette information, l'auditeur du registre
de ressources s�lectionne le moniteur devant superviser cette nouvelle
ressource (le moniteur \emph{FileMonitor}), et l'informe de l'apparition
de celle-ci dans le conteneur (action 7). Le moniteur \emph{FileMonitor}
s'enregistre alors en tant qu'auditeur aupr�s de la ressource \emph{FileOutputStream}
afin que cette derni�re l'informe de toute action du composant \emph{JMailer}
(action 8). Ainsi, lorsque le composant �crit des donn�es sur le flux
de donn�es (action 9), celui-ci informe spontan�ment le moniteur \emph{FileMonitor}
de cette �criture (action 10).  Gr�ce � l'ensemble de ces m�canismes,
la plate-forme \noun{Jamus} est capable de superviser dynamiquement
les ressources utilis�es par les composants logiciels qu'elle h�berge.

Au vu de la complexit� des m�canismes de supervision, on peut
l�gitimement penser que le surco�t de la supervision dynamique est
important. En fait, les �valuations des performances de la plate-forme
\noun{Jamus} que nous avons r�alis�es montrent que ce n'est pas le
cas, puisque dans le contexte d'observation le plus d�favorable, le
temps d'acc�s � une ressource se trouve r�duit d'environ 2\% par
moniteur.  L'ensemble de ces �valuations peuvent �tre consult�es
dans~\cite{TheseNico}.


\subsection{Gestion de la violation des contrats}

La plate-forme \noun{Jamus} offre via les moniteurs d'applications et
les moniteurs de ressources le moyen de superviser les composants
logiciels au cours de leur ex�cution, ainsi que le moyen de
sanctionner les composants ayant viol�s les modalit�s de leur contrat.
Ces moniteurs s'appuient sur les fonctionnalit�s de contr�le d'acc�s
offertes par l'environnement \noun{Raje} pour sanctionner les
composants.

Nous avons identifi� deux cat�gories de sanctions : les sanctions �
effet imm�diat, et les sanctions � effet diff�r�. Ces derni�res sont
assujetties � un avertissement pr�alable qui vise � notifier le
composant responsable de la violation de contrat, et � lui permettre
ainsi de prendre les mesures n�cessaires pour �viter l'application de
la sanction. Ces mesures peuvent impliquer par exemple la
ren�gociation des modalit�s du contrat ou la terminaison du contrat.
La figure~\ref{chap:jamus:sec:jamus:fig:exemple-sanction} pr�sente ces
deux types de sanctions.  La premi�re sanction est une sanction
diff�r�e s'appliquant au r�pertoire de l'utilisateur. Elle consiste �
rejeter les acc�s en lecture ou en �criture du composant � ce
r�pertoire au bout de deux violations successives des modalit�s
d'acc�s relatives � ce r�pertoire.  La seconde sanction est une
sanction de type imm�diate qui porte sur les connexions TCP �tablies
sur le port 80. Cette sanction consiste � verrouiller l'acc�s du
composant � la socket concern�e par la violation.

%
\begin{figure}
\begin{flushleft}\hrule{}~\\
 \textsf{\footnotesize }\textsf{\scriptsize ~~~~~Sanction s1,
s2;}\\
\textsf{\scriptsize ~~~~~}\textsf{\emph{\scriptsize //}} \textsf{\scriptsize }\textsf{\emph{\scriptsize Sanction
diff�r�e s'appliquant au r�pertoire \textasciitilde{}/}}\\
\textsf{\emph{\scriptsize ~~~~~// l'acc�s � la ressource sera
rejet� au bout de 2 violations successives}}\\
 \textsf{\scriptsize ~~~~~}\textsf{\textbf{\scriptsize s1 = new}}
\textsf{\scriptsize DifferedSanction(}\textsf{\textbf{\scriptsize new}}
\textsf{\scriptsize FilePattern(\char`\"{}\textasciitilde{}/\char`\"{}),
Sanction.REJECT, 2); }\\
 \textsf{\emph{\scriptsize ~~~~~// Sanction imm�diate s'appliquant
aux connexion TCP sur le port 80}}\\
\textsf{\scriptsize ~~~~~}\textsf{\textbf{\scriptsize s2 = new}}
\textsf{\scriptsize ImmediateSanction}\textsf{\textbf{\scriptsize (new}}
\textsf{\scriptsize SocketPattern(\char`\"{}{*}\char`\"{}, 80), Sanction.LOCK);}{\scriptsize }\\
{\scriptsize ~}\\
\hrule{}\end{flushleft}


\caption{\label{chap:jamus:sec:jamus:fig:exemple-sanction}Exemple de sanctions
pouvant �tre utilis�es pour configurer la plate-forme \noun{Jamus}}
\end{figure}


%%-------------------------------------------------------------------------------
%% Related work
%%-------------------------------------------------------------------------------

\section{\label{sec:related-work}Travaux apparent�s}


\subsection{Travaux apparent�s relatifs � la qualit� de service}

La prise en compte des besoins en ressources des composants logiciels
et plus g�n�ralement des programmes d'application est une
probl�matique connue dans le domaine de la qualit� de service.
Certains travaux se focalisent uniquement sur l'expression de la
qualit� de service (e.g. QML~\cite{FrolundKoistinen00}), alors que
d'autres proposent � la fois des solutions pour exprimer la qualit� de
service et transposer celle-ci en une expression des besoins en
ressources (e.g.
QuO~\cite{SchantzLoyallRodriguesSchmidt:middleware03},
QosTalk~\cite{WichadakulNahrstedt:cd02},
2k~\cite{WichadakulNahrstedtGuXu:middleware01}).  Cependant, ces
travaux proposent uniquement une expression quantitative et globale
des besoins en ressources des programmes d'application.  Bien qu'�tant
parfaitement suffisante pour assurer la disponibilit� des ressources
pour les applications, cette expression des besoins en ressources
n'est pas assez pr�cise pour pouvoir �tre �galement utilis�e au sein
des m�canismes de s�curit�. Pourtant � l'instar de la plate-forme
\noun{Jamus}, il est possible de confronter les besoins exprim�s par les
composants � la politique de s�curit� mise en \oe uvre au sein de la
plate-forme de d�ploiement afin de d�terminer si le composant peut
�tre d�ploy�, et utiliser les besoins ainsi exprim�s pour superviser
les composants en cours d'ex�cution.


\subsection{Travaux apparent�s relatifs � la s�curit�}

L'environnement d'ex�cution de Java~(JRE \textit{: Java Runtime
  Environment}) met en \oe uvre un mod�le de s�curit� connu sous le
nom de \emph{SandBox}.  Depuis la plate-forme Java~2, ce mod�le de
s�curit� repose sur la notion de domaine de
protection~\cite{JavaSecurityFutureAndPresent}.  Un domaine de
protection constitue un environnement d'ex�cution dont la politique de
s�curit� peut �tre sp�cifi�e sous la forme de permissions.  Le mod�le
de s�curit� mis en \oe uvre dans le JRE repose sur des m�canismes <<
~sans �tat~ >>. Il n'est donc pas possible d'imposer des contraintes
quantitatives sur les ressources manipul�es au sein d'un domaine de
protection. En cons�quence, les dysfonctionnements r�sultant de
l'utilisation abusive des ressources ne peuvent pas �tre
pr�venus.

Des environnements tels que JRes~\cite{JRES} et
KaffeOS~\cite{ProcessesInKaffeOS} apportent un d�but de r�ponse au
probl�me du contr�le quantitatif des ressources pos� par les
environnements Java traditionnels. Ils offrent en effet des m�canismes
permettant de comptabiliser --~et, �ventuellement, de limiter~--
l'utilisation de chaque type de ressources par une entit� active~(un
\emph{thread} dans le cas de JRes et un processus dans le cas de
KaffeOS).  Cependant dans ces environnements, les ressources sur
lesquelles portent la comptabilisation et le contr�le sont des
ressources globales. On peut ainsi comptabiliser les acc�s au r�seau
r�alis�s par un \emph{thread}~(ou processus), mais on ne peut pas
distinguer les transmissions r�alis�es vers une machine donn�e, ou
vers un num�ro de port pr�cis.

Les projets Naccio~\cite{NaccioPDH} et
Ariel~\cite{ArielProvidingFine-GrainedAccessControlForJavaPrograms}
proposent chacun un langage et des m�canismes permettant de d�finir de
mani�re tr�s pr�cise la politique de s�curit� qui doit �tre appliqu�e
� un programme d'application lors de son ex�cution.  L'application
d'une politique de s�curit� est r�alis�e statiquement, par r��criture
du \emph{bytecode} du programme d'application, mais aussi des classes
de l'API de la plate-forme Java.  Cette approche se pr�te donc bien �
la g�n�ration anticip�e d'un ensemble d'API pr�-d�finies garantissant
chacune le respect d'une politique de s�curit� g�n�rique.  En
revanche, elle ne permettrait pas, comme le fait la plate-forme
\noun{Jamus}, d'assurer la supervision d'un programme d'application en
fonction d'une politique de s�curit� d�finie � partir des besoins
exprim�s par ce m�me programme lors de son d�marrage.




%%-------------------------------------------------------------------------------
%% Conclusion
%%-------------------------------------------------------------------------------


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

Dans cet article nous avons pr�sent� un cadre de conception pour la
construction d'un syst�me de contractualisation dynamique des
ressources, ainsi qu'une plate-forme d'accueil d�di�e � l'h�bergement
de composants logiciels qui a �t� mise en \oe uvre � l'aide de ce
cadre de conception. Cette plate-forme nous a permis de mettre en
�vidence la pertinence et la validit� de notre approche. Nous �tudions
actuellement la possibilit� d'int�grer notre approche au sein de
mod�les de composants logiciels existants (e.g. Fractal, OSGi) afin
d'en am�liorer les m�canismes de d�ploiement.

%\bibliographystyle{plain}
\vspace{-0.5cm}
\bibliography{decor-2004}

\end{document}

decor-2004.bbl
\begin{thebibliography}{}

\bibitem[BAC~00]{ProcessesInKaffeOS}
\textsc{Back G.}, \textsc{Hsieh W.~C.}\andname{}\textsc{Lepreau J.},
  \guilo{}{Processes in KaffeOS: Isolation, Resource Management, and Sharing in
  Java}\guilf{},
\newblock \Inname{} \textit{{4th Symposium on Operating Systems Design and
  Implementation}}, \Oct{} 2000.

\bibitem[CZA~98]{JRES}
\textsc{Czajkowski G.}\andname{}\textsc{von Eicken T.}, \guilo{}{JRes: a
  Resource Accounting Interface for Java}\guilf{},
\newblock \Inname{} \textit{{ACM OOPSLA} Conference}, 1998.

\bibitem[EVA~00]{NaccioPDH}
\textsc{Evans D.}, \guilo{}{Policy-Directed Code Safety}\guilf{},
\newblock PhD thesis, {Massachussets Institute of Technology}, \Feb{} 2000.

\bibitem[FRO~00]{FrolundKoistinen00}
\textsc{Frolund S.}\andname{}\textsc{Koistinen J.}, \guilo{}{Quality of Service
  Specification in Distributed Object System Design}\guilf{},
\newblock \Inname{} \textit{4th Usenix Conference on Object-Oriented
  Technologies and Systems (COOTS)}, 2000.

\bibitem[GON~97]{JavaSecurityFutureAndPresent}
\textsc{Gong L.}, \guilo{}{Java Security: Present and Near Future}\guilf{},
\newblock \textit{{IEEE Micro}}, \volumename\ -, 1997,  \pagesname{} 14-19.

\bibitem[LES~03]{TheseNico}
\textsc{Le~Sommer N.}, \guilo{}{Contractualisation des ressources pour les
  composants logiciels : une approche r�flexive}\guilf{},
\newblock M�moire de th�se, Universit� de Bretagne Sud, d�cembre 2003.

\bibitem[PAN~99]{ArielProvidingFine-GrainedAccessControlForJavaPrograms}
\textsc{Pandey R.}\andname{}\textsc{Hashii B.}, \guilo{}{Providing Fine-Grained
  Access Control for Java Programs}\guilf{},
\newblock \Inname{} \textit{The 13th Conference on Object-Oriented Programming,
  ECOOP'99}, Springer-Verlag, \Jun{} 1999.

\bibitem[SCH~03]{SchantzLoyallRodriguesSchmidt:middleware03}
\textsc{Schantz R.~E.}, \textsc{J.P. L.}, \textsc{C. R.}, \textsc{D.C.
  S.}\andname{}\textsc{Krishnamurthy Y.}, \guilo{}{Flexible and Adaptive QoS
  Control for Distributed Real-time and Embedded Middleware}\guilf{},
\newblock \Inname{} \textit{ACM/IFIP/USENIX International Middleware
  Conference}, Rio de Janeiro, Br�zil, \Jun{} 2003.

\bibitem[WIC~01]{WichadakulNahrstedtGuXu:middleware01}
\textsc{Wichadakul D.}, \textsc{Nahrstedt K.}, \textsc{Gu
  X.}\andname{}\textsc{D. X.}, \guilo{}{2KQ+: An Integrated Approach of QoS
  Compilation and Component-Based, Run-Time Middleware for the Unified QoS
  Management Framework}\guilf{},
\newblock \Inname{} \textit{IFIP/ACM International Conference on Distributed
  Systems Platforms (Middleware 2001)}, Heidelberg, Germany, \Nov{} 2001.

\bibitem[WIC~02]{WichadakulNahrstedt:cd02}
\textsc{Wichadakul D.}\andname{}\textsc{Nahrstedt K.}, \guilo{}{ A Translation
  System for Enabling Flexible and Efficient Deplyoment of QoS-aware
  Applications in Ubiquitous Environments}\guilf{},
\newblock \Inname{} \textit{First International IFIP/ACM Working Conference on
  Component Deployment (CD 2002)}, Berlin, Germany, \Jun{} 2002.

\end{thebibliography}
