Chapitre 2 Etat de l’art et synthèse
2.4 Eléments descriptifs pour automatiser le déploiement
Pour pouvoir effectuer le déploiement automatique sensible au contexte, il est assez
courant de se baser sur des éléments descriptifs (modèles et/ou langages). Le descripteur
d'application sert à représenter les ressources nécessaires pour le bon fonctionnement de
l'application. Le descripteur de nœud sert à représenter les ressources offertes par un nœud.
En se basant sur les recherches d’AbdelKarim Beloued [32], nous présentons les principaux
éléments pour décrire les applications et les nœuds de déploiement.
2.4.1 Description des applications
Open Software Description (OSD)
OSD est proposé par le WWW Consortium. Il permet de décrire les paquetages logiciels
dans un fichier XML en respectant une DTD bien définie. Un descripteur d’une application
selon le format OSD contient trois types d’informations (figure 2.1):
<softpkg name="Simulator" version="1,0,0,0"> <title>Simulator</title>
<abstract>Simulator for testing deployment algorithm</abstract> <implementation>
<os value="WinNT">
<osversion value="4,0,0,0"/> </OS>
<processor value="P3"/> <language value ="en" />
<codebase href="/implementation/simulator.cab"/> </implementation> <implementation> <impltype value="Java" /> <codebase href="/implementation/simulator.jar"/> <dependency> <codebase href="/implementation/graph.jar"/> </dependency> </implementation> </softpkg>
Figure 2.1. Descripteur selon le modèle OSD
o Les informations générales sur l'application à savoir son nom, sa version, l'auteur et un
texte descriptif de l'application ;
o Un certain nombre de propriétés décrivant les ressources requises par une
implantation. Une application peut avoir plusieurs implantations. Chaque implantation
est décrite dans un bloc à part ;
o Les informations sur les dépendances logicielles. Cette partie décrit les objets dont
dépend l’application. Ces objets doivent être présents sur le nœud de déploiement.
L'avantage d'OSD est qu'il est extensible en utilisant les namespaces XML. Ceci permet
de rajouter des ressources selon le contexte d'utilisation. Ainsi, après avoir analysé le fichier
OSD, le nœud de déploiement détermine l'implantation qui s'adapte à son contexte.
L'inconvénient d'OSD est qu'il ne permet pas de définir des relations entre les ressources ainsi
que des contraintes sur elles.
Deployable Software Description (DSD)
DSD est un langage utilisé dans le projet Software Dock. Il permet de décrire une
application dans un fichier DSD en respectant un schéma XML bien défini. Un descripteur
d’application selon DSD contient essentiellement les parties suivantes :
o Les informations générales (Family). Ce bloc renseigne sur le nom de l’application, le
producteur, la licence, et la signature ;
o Les propriétés externes qui décrivent les caractéristiques du nœud de déploiement. Les
valeurs ne sont reconnues que pendant le déploiement. DSD permet de garder la trace
des valeurs de propriétés pour reconfigurer ou annuler les opérations précédentes du
déploiement ;
o Les propriétés internes. Ce bloc décrit les propriétés internes de l’application comme
le langage de programmation d’une implantation ;
o Les règles de composition. La définition des relations entre les propriétés se fait dans
ce bloc ;
o Les artéfacts donnent le chemin des fichiers contenant les différentes configurations
du logiciel ;
o Les assertions et les dépendances. Ce bloc permet de définir des contraintes sur les
valeurs des propriétés internes et externes du logiciel. Une contrainte est définie par
une condition qui doit être vérifiée pour que le déploiement ait lieu, au contraire d’une
dépendance qui définit une procédure de résolution de conflit.
D’autres blocs existent comme ceux destinés à définir les interfaces et les services
spécialisés offerts par l’application.
A l’opposé du langage OSD, l’avantage de DSD est qu’il permet de définir des
relations entre les ressources ainsi que les contraintes sur elles. L’originalité de cette
spécification est l’intégration des valeurs des caractéristiques du nœud dans le descripteur
d’application au moment du déploiement. Cela permet d’identifier la configuration
adéquate si elle existe. L’inconvénient principal est qu’il est assez difficilement
compréhensible par un opérateur humain.
Java Network Launching Protocol (JNLP)
JNLP est un langage qui fait partie de l'outil Java Web Start. Pour déployer une
application, il est nécessaire de la décrire par un fichier de lancement au format XML
respectant le protocole JNLP. La figure 2.2 donne un exemple de descripteur JNLP.
<?xml version="1.0" encoding="utf-8"?>
<!-- JNLP File for P2P Context-aware Deployment API--> <jnlp spec="1.0+" codebase="http://www.laas.fr/~ehammami/archives" href="simulator.jnlp"> <information> <title>Deployment Simulator</title> <vendor>LAAS - CNRS</vendor> <homepage href="http://www.laas.fr/~ehammami/adaptatif"> <description>Simulator</description> <description kind="short">Simul</description> <offline-allowed/> </information> <security> <all-permissions/> </security> <resources> <j2se version="1.3+"/>
<jar href="simul.jar" main="true" download="eager"/> <jar href="lib/bcprov-jdk14.jar" download="eager"/>
<jar href="lib/jaxen-core.jar" download="eager"/> </resources>
<application-desc main-class="net.deployment.simulator.Simulator"> </application-desc>
</jnlp>
Figure 2.2. Descripteur selon le modèle JNLP
L’élément <jnlp> constitue l’élément racine du document « .jnlp ». L’élément <title> permet d’indiquer le nom de l’application. L’élément <jar> montre le chemin des archives java nécessaire à l’exécution de l’application. D'autres éléments comme <description> peuvent figurer dans le document. L’avantage de JNLP est qu’il est facile à mettre en œuvre par un opérateur humain. Cependant, il permet seulement d’indiquer les archives nécessaires pour l’exécution de l’application mais pas les ressources matérielles sur le nœud de déploiement.
2.4.2 Description des ressources
Resource Descriptor Framework (RDF)
Plusieurs langages de description des ressources offertes par les nœuds de déploiement
existent. Parmi eux, RDF qui est un modèle de graphe pour décrire les données et les
méta-données. Il permet un traitement automatique des méta-données [33]. Un document structuré
en RDF est un ensemble de triplets. Chaque triplet est une association {sujet, objet, prédicat} :
Figure 2.3. Triplet RDF
o Le sujet fait référence à la ressource à décrire par un URI (Uniform Resource
Identifier) ;
o L’objet représente une autre ressource ou une valeur littérale ;
o Le prédicat définit une propriété du sujet dont la valeur est l’objet.
Prédicat
Objet Sujet
Un document RDF ainsi formé correspond à un graphe orienté étiqueté. Chaque triplet
correspond alors à un arc orienté dont le label est le prédicat, le nœud source est le sujet et le
nœud cible est l'objet. RDF est une des bases du succès du Web sémantique [33]. RDFS (RDF
Schema) permet d’étendre le vocabulaire en définissant le schéma correspondant au domaine
d’utilisation. Un exemple de schéma RDF est donné dans la figure 2.4. Les deux classes
Disque Dur et Mémoire ont une propriété commune : Taille. Nous avons donc ajouté la classe
Support de mémorisation qui a pour propriété Taille. Ainsi les classes Disque Dur et Mémoire
seront des sous-classes de la classe Support de mémorisation.
Figure 2.4. Schéma RDF
Composite Capability/Preference Profiles (CC/PP)
Le deuxième langage que nous étudions, est CC/PP. Proposé par le W3C, ce langage se
base sur RDF pour fournir une description structurée des capacités du terminal et des
préférences utilisateurs conformément au schéma suivant :
Figure 2.5. Schéma CC/PP
o Un profil CC/PP contient un ou plusieurs composants ;
o Un composant contient un plusieurs attributs. Chaque composant désigne une
ressource comme le système d’exploitation ;
o Un attribut est une propriété du composant comme le type ou la version du
système d’exploitation.
Ontology Web Language (OWL)
OWL est un langage de description à base d’ontologie permettant de décrire les classes
de ressources et les relations entre elles. Il a été introduit en parallèle avec les premiers
1, N 1, N 0, 1 Profil Attribut Valeur Composant Système d'exploitation Avoir_DD Mémoire Disque Dur Possède_SE Possède_MEM Littéral Taille Support de mémorisation Sous-classe Littéral Version Littéral Type Sous-classe Noeud