Spécification

Afin de pouvoir spécifier le déploiement de composants ubiquitaires Cubik, nous avons opté pour une approche déclarative. Nous avons proposé une extension de Fractal ADL ayant pour principal objet d’autoriser l’expression de contraintes posées sur les machines devant héberger les sous-composants. L’intergiciel de déploiement assure ensuite de manière autonome le lancement des composants sur les machines aptes à les accueillir.

La description des propriétés que les machines cibles doivent satisfaire est donnée dans un descripteur de déploiement dans lequel il est possible de faire figurer des références aux instances de composants qui sont définis dans le descripteur d’architecture. Pour chaque composant, un contexte de déploiement est ainsi spécifié, qui liste toutes les contraintes qu’une machine hôte doit satisfaire. Deux types de contraintes peuvent être employées dans un contexte de déploiement : les contraintes de ressources et les contraintes de localisation. Les contraintes de ressources servent à représenter les besoins matériels et logiciels des composants. Les contraintes de localisation sont utilisées pour guider le placement des composants (on contraindra par exemple deux composants à être placés sur des machines différentes).

Contraintes de ressources Pour définir une contrainte de ressource, il suffit d’associer à

la définition d’un composant un contexte de déploiement qui liste l’ensemble des ressources nécessaires au composant. Nous nous sommes appuyés sur la modélisation des ressources de D-Raje décrite au paragraphe 2.2.4. On pourra donc par exemple imposer que la machine hébergeant un composant possède un minimum de 1 Go de mémoire vive, qu’elle dispose d’une version de la bibliothèque de traitement d’image ImageMagick supérieure à 6.2. De façon similaire, on pourra contraindre une liaison entre deux composants à être supportée par un lien physique caractérisé par un débit nominal d’au moins 100 Mbit/s.

Les contraintes citées ci-dessus sont bien sûr applicables aux composants primitifs. Mais nous avons choisi de permettre d’attacher des contraintes de ressources aussi aux composants composites. Ceci est justifié par le fait que si aucune contrainte n’était posée sur un composite, le déploiement sur une machine, commençant par le composite racine, pourrait progresser dans la hiérarchie en instanciant des membranes, même si au final aucun primitif n’est instanciable localement.

Dans certains cas, il est possible d’inférer des contraintes sur un composite à partir des contraintes posées sur les primitifs qu’il englobe. Par exemple, si un primitif p1requiert une bibliothèque logicielle b1et un autre primitif p2une bibliothèque logicielle b2, il est clair que le composite englobant requiert b1et b2. Toutefois, cet exemple est très difficilement généralisable à toutes les ressources. On peut par exemple imaginer que si p1requiert 1 Go de mémoire et que p2

en requiert 2 Go, le composite englobant nécessite 3 Go (la somme) ou 2 Go (le maximum) selon la manière d’exploiter la mémoire. Notre approche ne fixe pas la façon d’établir les contraintes de ressources sur les composites, l’idée est que la fabrication d’un descripteur de déploiement

devrait être assistée par un outil propre au domaine d’application, qui établirait des règles par défaut de « composition » des contraintes.

Contraintes de localisation Afin de contraindre le placement de composants

indépendam-ment de leurs besoins en ressources, il est possible d’inclure dans le descripteur de déploieindépendam-ment des contraintes dites de localisation attachées à un composant. Dans sa plus simple expression, une telle contrainte impose le placement du composant sur une machine désignée par son nom (ou son adresse IP). On peut également désigner la cible sous forme d’une variable libre qui pourra être utilisée dans d’autres contraintes. En effet, dans le cas général, une contrainte de loca-lisation est une expression faisant intervenir des noms de machines et des variables représentant des machines cibles d’autres composants, combinés avec des opérateurs de comparaison n-aires. On pourra donc exprimer des contraintes comme « ce composant primitif doit être placé sur une machine différente de celle du composantserveur1et celle du composantserveur2» ou « ce composant composite a pour ensemble cible l’ensemble de machines comprenant la machine

zeuset les machines m1, m2et m3, cibles du composant compositemonComposant».

Lorsque l’on considère la hiérarchie de composants Cubik, l’héritage des ensembles cibles est la règle par défaut. Donc, les variables libres spécifiées dans une contrainte de localisation se trouvent finalement liées à un nom de machine par la spécification de contraintes du composant qui l’englobe (directement ou pas). Il est possible de faire apparaître des variables libres au niveau du composant racine. Dans ce cas, la liste des noms de machines effectifs est supposée être passée en paramètre de l’ordre de déploiement.

Exemple La figure 2.12 montre un exemple de descripteur de déploiement de l’application de

photo décrite dans la figure 2.9.

La première colonne contient les contraintes associées au composant composite Document-Search, telles qu’elles pourraient avoir été formulées par le fournisseur de ce composant acquis sur étagère pour bâtir l’application de photo. Ce descripteur contient le contexte de déploiement du composant primitifDocumentFinder(lignes 5 à 14) stipulant que ce composant nécessite un CPU cadencé à au moins 1,2 GHz et incluant une contrainte de localisation destinée simplement à nommer x la machine qui l’hébergera. De même, le contexte associé au composant primitif

DocumentBuffer(lignes 17 à 26) pose une contrainte sur la mémoire de la machine qui peut l’héberger (au minimum 200 Mo), machine qui est nommée y. Enfin, le contexte de déploiement du composantDocumentSearch(lignes 29 à 36) impose, à travers une contrainte de localisation utilisant l’opérateur de différence alldiff, que la machine x soit différente de la machine y.

La deuxième colonne de la figure décrit les contraintes de déploiement du composant racine

PhotoApp. On y retrouve des contraintes de ressources posées sur les composants primitifs Diapo-MakeretPhotoRepository, notamment des contraintes sur la mémoire de stockage (espace disque) minimum requise dans le répertoire/home. On retrouve dans ce descripteur une contrainte de localisation sur le composant compositeDocumentSearch(lignes 61 à 66) indiquant que les machines cibles pour ce composant ne peuvent êtreegilsayetparvati. La dernière partie du descripteur (lignes 70 à 76) donne une contrainte de localisation servant à décrire la plate-forme cible, à travers une liste de noms de machines.

<component name="DocumentSearch"> <component name="DocumentFinder"> <deployment-context>

<resource-constraint> <cpu freq="1.2" unit="GHz" operator="min" /> </resource-constraint> <location-constraint> <target varname="x"/> </location-constraint> </deployment-context> </component> <component name="DocumentBuffer"> <deployment-context> <resource-constraint>

<memory free="200" unit="MB" operator="min" /> </resource-constraint> <location-constraint> <target varname="y"/> </location-constraint> </deployment-context> </component> <deployment-context> <location-constraint> <operator name="alldiff"> <arg varname="this.DocumentFinder.x" /> <arg varname="this.DocumentBuffer.y" /> </operator> </location-constraint> </deployment-context> </component> <component name="PhotoApp"> <component name="DiapoMaker"> <deployment-context> <resource-constraint> <cpu freq="1.5" unit="GHz" operator="min" />

<memory free="50" unit="MB" directory="/home/" operator="min"/> </resource-constraint> </deployment-context> </component> <component name="PhotoRepository"> <deployment-context> <resource-constraint> <memory free="1" unit="GB" directory="/home/" operator="min" /> </resource-constraint> </deployment-context> </component> <component name="DocumentSearch"> <locationconstraint> <operator name="exclude"> <arg value="egilsay" /> <arg value="parvati" /> </operator> </locationconstraint> </component> <deployment-context> <locationconstraint> <target hostname="ambika"/> <target hostname="dakini"/> <target hostname="mafate"/> <target hostname="egilsay"/> <target hostname="parvati"/> </locationconstraint> <deployment-context> </component> 5 10 15 20 25 30 35 40 45 50 55 60 65 70