Déploiement sensible au contexte etreconfiguration des applications dans les sessions collaboratives

Modèles pour automatiser le déploiement 

Pour pouvoir fournir un support automatisé et générique, il est nécessaire de se baser sur une approche orientée modèle. Nous avons défini trois modèles : o Un modèle d’application qui donne les exigences des applications, c’est-à-dire les ressources requises pour le bon fonctionnement de l’application. o Un modèle de session qui décrit de façon abstraite la structure de la session ; o Un modèle du nœud du déploiement qui décrit le contexte local, c’est-à-dire les ressources offertes par le nœud de déploiement ; Ces modèles génériques permettent d’abstraire les informations de déploiement. Le terme générique se justifie par le fait que ces modèles sont indépendants des applications à déployer, du domaine de la session, et du nœud de déploiement. Les caractéristiques de chacun de ces modèles ont été décrites en utilisant le langage UML [37], universellement utilisé pour spécifier des systèmes. L’implantation de chaque modèle se fait en utilisant le langage XML [38]. Dans la suite, nous allons détailler chaque modèle. 

 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 Productrice ou 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 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. 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 QdSRequise Implantation + Nom 1 * RessourceRequise + Optionnelle + Opérateur + Poids + Nom + Valeur Application + ApplicationID + Description + Version + Nom 39 o 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.