Chapitre 3 Spécification de l’algorithme de déploiement
3.3 Modèles pour automatiser le déploiement
3.3.1 Modèle d’application
Le modèle d'application proposé permet à un service de déploiement de choisir une
application plutôt qu’une autre. Trois contraintes influencent ce choix :
o Le rôle d’un participant. Les applications doivent couvrir le rôle du participant. Par
exemple, en utilisant un outil de partage de document, l’enseignant diffuse son
cours vers les étudiants. En même temps, cet enseignant reçoit les commentaires
sous forme textuelle en utilisant un autre outil de dialogue.
o Compatibilité avec l’environnement d’exécution. Le nœud du déploiement doit
offrir les ressources nécessaires pour que les applications puissent fonctionner
correctement.
o Interopérabilité avec les applications déjà déployées sur les nœuds des voisins. Les
membres d’une session collaborative s’échangent des informations. Ainsi, les
applications doivent être interopérables pour qu’elles puissent communiquer sans
ambiguité et opérer ensemble.
Afin de respecter toutes ces contraintes. Nous notons qu’une application peut avoir
plusieurs implantations. Une implantation d’application est toujours complète, dans le sens où
elle couvre tous les composants de l’application. A la différence du déploiement
d’applications à base de composants qui se charge de trouver les implantations de chaque
composant et les nœuds adéquats, nous déployons uniquement l’implantation qui représente
l’application en totalité sur le nœud se connectant à la session. Nous avons mis l’accent sur
une classification des applications par rapport au traitement des flux de données. Nous
retrouvons donc les catégories suivantes :
Application monolithique monomédia unidirectionnelle
Cette catégorie implique que l’application est une seule entitée monolithique conçue
pour produire ou pour consommer un seul type de données. La figure 3.2 illustre les
différentes possibilités d’instanciation d’une application appartenant à cette catégorie.
Figure 3.2. Possibilités d’instanciation (1ère catégorie)
Une application productrice peut supporter ou non la diffusion vers plusieurs
participants. Dans le cas où elle peut supporter la diffusion, on distingue deux situations : (1)
Application ou Productrice Consommatrice Supporte la diffusion vers n utilisateurs Ne Supporte pas
la diffusion Consomme uniquement un seul flux
Consomme plusieurs flux de différentes sources
Même flux Différents flux
t1
l’application envoie le même flux vers n participants. C’est le cas d’un enseignant qui diffuse
son cours vers les étudiants. (2) l’application envoie différents flux vers n participants. C’est
le cas d’un étudiant qui émet des flux textuels vers les autres étudiants. Si l’application ne
supporte pas la diffusion, alors elle produit uniquement un seul flux de données vers un seul
participant.
Dans la deuxième sous-catégorie, on distingue deux situations : (1) l’application est
capable de consommer un seul flux de données. Par exemple, un étudiant reçoit le cours
diffusé par l’enseignant. (2) l’application est capable de consommer plusieurs flux de données
provenant de différentes sources. Par exemple, un étudiant reçoit les messages textuels
envoyés par les autres étudiants.
Application composite monomédia
Cette catégorie comprend des applications formées par une entité logicielle composites
qui se déclinent en deux parties, une partie productrice et une partie consommatrice. Une telle
application n’est capable de traiter qu’un seul type de données. L’application peut être
instanciée en rôle producteur, consommateur ou les deux à la fois (figure 3.3).
Figure 3.3. Possibilités d’instanciation d’une application (2ère catégorie)
Par exemple, une application de dialogue qui produit et qui reçoit des flux textuels fait
partie de cette catégorie.
Application composite multimédia
C’est le cas le plus général. Une application de cette classe est composée d’une
collection d’entités logicielles qui manipulent différents types de données et qui se déclinent
chacune en une partie productrice et une partie consommatrice. Une application de dialogue
sophistiquée qui permet d'échanger du texte et de la parole, fait partie de cette catégorie.
Figure 3.4. Possibilité d’instanciation (3ème catégorie) Application
Productrice Consommatrice Les deux
t1 t2 t1 t3 t1 t2 Application p1 t1 t2 t3 t4 p2
Une représentation formelle de ce modèle est donnée par la figure suivante :
Figure 3.5. Représentation UML du modèle d’application
D’après le modèle, une application peut avoir plusieurs implantations. Une implantation
d’application est toujours complète, dans le sens où elle couvre tous les composants de
l’application. A la différence du déploiement d’applications à base de composants qui se
charge de trouver les implantations de chaque composant et les nœuds adéquats, nous
déployons uniquement l’implantation qui représente l’application en totalité sur le nœud se
connectant à la session.
Pour qu’une implantation d’application fonctionne correctement, il est nécessaire que le
nœud qui va l’accueillir possède les ressources et les services requis pour son bon
fonctionnement. Un descripteur ImplantationID est associé à chaque implantation
d’application. Comme décrit dans l’état de l’art, nous trouvons dans la littérature des langages
comme OSD, JNLP et DSD, permettant de décrire les applications et leurs implantations. Ils
contiennent essentiellement les caractéristiques de l'application. Dans notre cas, les attributs et
les propriétés encapsulés dans le descripteur ImplantationID se divisent en deux familles :
o Qualité de service requise. Si une implantation d’application utilise un service
non fonctionnel tel que la gestion des transactions, et qu’elle possède le code
spécifique réalisant ce service, alors elle peut être déployée sur n’importe quel
nœud. Par contre si l’implantation d’application ne possède pas le code réalisant ce
service mais qu’elle a absolument besoin de ce service, alors elle ne doit être
déployée que sur un nœud offrant le service en question.
+ TypeDonnée + FormatsSupportés + Sens + Diffusion + EnvoiMêmeFlux DonnéeEchangée CompositeMonomédia MonolithiqueUnidirectionel CompositeMultimédia + Chemin + ImplantationID Implantation QdSRequise + Nom
*
1 RessourceRequise + Optionnelle + Opérateur + Poids + Nom + Valeur Application + ApplicationID + Description + Version + Nomo Ressources requises. Une implantation d’application nécessite des ressources
pour s’exécuter comme la puissance de traitement, la taille minimale sur le disque
dur, le type du système d’exploitation. Certaines ressources présentent des
contraintes fortes, d’autres non (attribut optionnel).
Lors de la sélection d’une implantation d’application, le nombre d’instanciations varie
de 1 à N selon le nombre de flux manipulés par l’application associée, et requis par la session.
Ce nombre d’instances sera ainsi déterminé par la classe d’application que l’on déploie et par
la capacité de l’application à traiter plusieurs flux de données (champ Diffusion).
La figure 3.6 montre la représentation XML d’une application monolithique monomédia
unidirectionnelle de dialogue textuel. Cette application produit et consomme un flux textuel
supportant les formats ascii et unicode. Une seule implantation compose l'application. Le
service de persistance est nécessaire pour le fonctionnement de cette implantation. Les
ressources requises sont : une fréquence de microprocesseur supérieur à 1.00 GHz et une
mémoire vive d'au moins 64 Mo. Ces deux ressources sont obligatoires. Par contre la
connexion Internet de 56 ko est optionnelle.
<?xml version="1.0" encoding="utf-8" standalone="no"?> <CompositeMonomedia>
<ApplicationID>md5-d2ab42830caa7a02b36d96a46dd44b8d</ApplicationID> <Nom>Dialogue</Nom>
<Description>Application de dialogue textuel</Description> <Version>1.0</Version> <DonnéesEchangés> <DonnéeEchangé> <TypeDonnée>Texte</TypeDonnée> <FormatsSupportés> <Format>ascii</Format> <Format>unicode</Format> </FormatsSupportés> <Sens>producteur</Sens> <Diffusion>vrai</Diffusion> <EnvoiMêmeFlux>vrai</EnvoiMêmeFlux> </DonnéeEchangé> <DonnéeEchangé> <TypeDonnée>Texte</TypeDonnée> <FormatsSupportés> <Format>ascii</Format> <Format>unicode</Format> </FormatsSupportés> <Sens>consommateur</Sens> <Diffusion>faux</Diffusion> <EnvoiMêmeFlux>faux</EnvoiMêmeFlux> </DonnéeEchangé> </DonnéesEchangés> <Implantations> <Implantation> <ImplantattionID>md5-d9e90367d6bd2edb8d5f2551c2feb202</ImplantationID> <Nom>impl1</Nom> <Chemin>c:\repository\TalkP+C.jar</Chemin> <QdSRequise>persistency</QdSRequise> <RessourcesRequises> <Ressource> <Nom>CPU</Nom> <Type>Integer</Type> <Valeur>1.00</Valeur>
40 <Optionnelle>faux</Optionnelle> <Poids>2</Poids> </Ressource> <Ressource> <Nom>RAM</Nom> <Type>Integer</Type> <Valeur>64</Valeur> <Opérateur>inferiororequal</Opérateur> <Optionnelle>faux</Optionnelle> <Poids>2</Poids> </Ressource> <Ressource> <Nom>Internet</Nom> <Type>Integer</Type> <Valeur>56</Valeur> <Opérateur>inferiororequal</Opérateur> <Optionnelle>vrai</Optionnelle> <Poids>3</Poids> </Ressource> </RessourcesRequises> </Implantation> <Implantations> <CompositeMonomedia>
Figure 3.6. Représentation XML d'une application de dialogue textuel