CADeComp : plate-forme de déploiement sensible au contexte des applications à base de composants Dhouha Ayed, Chantal Taconet et Guy Bernard Ma pre porte

Plan Introduction Déploiement des applications à base de composants Architecture de CADeComp Modèle de données CADeComp Conclusion et perspectives Ensuite j ’exposerai quelques généralités sur lrs de déploi des applis à base de compos sur lrs problématiques déploiement ...

Constat (1) Les terminaux mobiles sont devenus capables d’héberger une large gamme d’applications Ressources limitées Changement de contexte fréquent: localisation, connexion réseau, environnement physique, etc. L ’utilisation d ’application dans un environnement mobile pose deux problèmes. Non seulement puisqu ’ils changent constamment de

Constat (2) Tâches de déploiement répétitives: installation, configuration, désinstallation, réinstallation, reconfiguration, etc. Ces 2 blèmes amènent l ’utilisateur à effectuer des tâches répétitives En plus des çs comme le contexte de l ’utilisateur est en constant changement l ’utilisateur se trouve obligé de reconfig les applis déployées

Besoins des utilisateurs mobiles Automatisation du déploiement Adaptation de déploiement au contexte Déploiement à la volée Ce constat nous amène à dégager les besoins suivants Pour épargner donc l ’user de ces tâches répétitives le processus de déploiement soit être automatisé, cad que l ’tililisateur ne doit pas intervenir manuellement, lui ile doit que choisirl ’applicatio à déployer, et les étapes d ’installation et de conf doivent être effectué d ’une manière transparente doit pouvoir prendre en compte le contexte d ’utilisation à savoir ….pour pouvoir répondre aux besoins de l ’utilisateur. Enfin id doit être exécuté à la volée, c à dire juste à la demande de l ’utilisateur, et déinstallé dès son activation

Plan de déploiement L’architecture de l’application L’emplacement des composants La version d'implémentation de chaque composant Les valeurs des propriétés des composants Le déploiement des applis à base de composants nécessite la description de ce qu ’on appelle un plan de déploiement. Un plan de déploiement représente des méta données qui décrivent les paramètres de déploiement suivants, qui sont en spécifiant les nœuds sur lequels ces compos doivent être placés, Ce principe de plan de déplo est utilisé par plusieurs outils de dépl telsque CCM, OMG Alors, le pb dans l ’utilisation de ce genre de… c qu ’il est statique, l ’archi est fixée une foàis pour tte qq soit le contexte d ’usation, les nœuds doivent être ou bien choisi manuellement au moment du déploiement ou bien fixé à l ’avance sans étudier l ’états des nœuds specifié. Ce que nous proposons nous donc comme solution pour L ’adaptation du déploiement des applis à base de composants consiste à varier ces 4 params de déploiement en fonction du contexte.

Paramètres variables du déploiement L’architecture de l ’application : présence de composants fonctionnels ou non fonctionnels Le choix des implémentations des composants Le choix des machines d’installation des composants Les propriétés de configuration des composants L ’archi peut être variée en additionnant ou supprimant des compos et des conn selon le contexte Par exemple l'utilisateur peut avoir le choix entre afficher les sorties d'un traitement ou les stocker. Dans le premier cas l'application déployée contiendra un composant de visualisation et dans le second cas, elle contiendra plutôt un composant d'archivage comme une base de données. le choix … peut dépendre aussi du contexte. Par exemple, on n ’installera pas la même implémentation d’un composant interface graphique sur un ordinateur portable ou sur un PDA pour alléger le terminal utilisateur, le déploiement a une latitude pour choisir la machine d'installation de certains composants, , il choisira par exemple la machine de proximité la moins chargée. Enfin, par exple la prop qui représente le language de l’utilisateur dépend ...

Adaptation au contexte Trois étapes: Collection des informations de contexte, Analyse Actions d’adaptation au contexte Dans ce qui suit nous allons voir les moyens avec lesquels nous allons adapter ces différents params au contexte dans CADeComp Généralement

CADeComp : architecture générale Context-aware Application Component Middleware Context-aware deployment service DeploymentAdapter Classical deployment tool Deployer Pour pouvoir réaliser ces étapes, l ’architecture de CADeComp ressemble à la suivante: le service de déploiement qui est intégré au niveau middleware composant est placé au dessus d ’un middleware context dans l’idée de séparer entre l’adaptation du déploiement au contexte et la gestion des informations de contexte. CA middleware s’occupe de communiquer avec les sources d’informations du contexte pour leur acquisition, leur transformation afin d’en obtenir des informations de contexte de haut niveau et lesmettre à disposition des applications et de notre service. Cadecomp représente une couche qui se place au-dessus d’un outil de déploiement classique qui implémente les activités de déploiement élémentaire des applications à base de composants à savoir l’instanciation des composants, leur configuration et leurs connexions. Notre service déclenche l’exécution des ces activités d’une manière conditionnée par les informations de contexte. Context-aware Infrastructure

CADeComp: architecture détaillée User Terminal Prestataire du service de déploiement Application Comp Comp Comp Comp Dépositaire méta-données Dépositaire de Paquetages Deployer Component Middleware Serveur d’exécution Serveur d’exécution Deployment Adapter Voici donc l ’archi détaillée, ce qui est représenté en rose est la couche infrastructure de contexte, …., on a donc dit que l ’I se charge de la collecte des infos de contexte. Par contre, L’étape d’analyse des informations de contexte et la décision des activités d’adaptation du déploiement est réalisée grâce à un ensemble de composants dont une partie est placée sur le terminal utilisateur et la seconde est placée au niveau du fournisseur du service de déploiement – Un dépositaire de paquetages contenant les paquetages de composants des applications à déployer. Un paquetage de composant contient les différentes implémentations d’un composant ainsi que son descripteur de propriétés par défaut. Chaque version d’implémentation est dédiée à un environnement d’exécution particulier. – Un dépositaire de méta-données contenant les descripteurs nécessaires au déploiement Le fournisseur du service de déploiement dispose d’un ensemble de serveurs d’exécution qui offrent un environnement d’exécution pour les instances de composants qui n’ont pas pu être Le Gestionnaire de Contexte de déploiement joue le rôle de passerelle entre le service de déploiement sensible au contexte et l’infrastructure sensible au contexte. Le composant Adaptateur de Déploiement analyse les contextes pertinents notifiés par le Gestionnaire de Contexte de déploiement et détermine l’assemblage de l’application à déployer en utilisant le descripteur de déploiement sensible au contexte pour décider les instances de composants qui constitueront l’application, les connexions entre eux, la version d’implémentation, l’emplacement et la configuration de chaque composant et produire ainsi un plan de déploiement final de l’application.; Le terminal utilisateur dispose d’un Client de Déploiement qui lance le processus de déploiement en envoyant une requête vers le composant Pré-Deployeur et d’un composant Deployeur qui représente un outil de déploiement préexistant assurant l’instanciation des composants, leur configuration et connexion. Deployment Client Context-Manager Context-Manager Context-aware Infrastructure

Modèle de données de CADeComp Règles communes à tous les composants d’une application Description des instances de composants Les conditions d’existence dans le plan de déploiement final des composants et leurs connexions Les emplacements possibles selon le contexte Les choix possibles des différentes implémentations selon le contexte Les différentes valeurs possibles des propriétés de configuration selon le contexte Nous décrivons dans cette section le modèle des méta-données utilisées par. Les méta-données sont placées dans des descripteurs qui décrivent les règles d’adaptation devant être appliquées si certains états de contexte sont vérifiés Ce descripteur permet à l’Adaptateur de Déploiement d’agir sur les quatre paramètres de déploiement décrits dans la section 2 afin de déterminer, selon le contexte courant, les composants qui constitueront l’application, leur emplacement et leurs connexions. Les règles communes à ce niveau, peuvent spécifier pour un contexte donné un emplacement général pour tous les compos de l ’appli ou une valeur à une propriété qui est commune à tous les composants de l ’appli. Je peux donner un exple : le langage utilisé par l ’utilisateur. Pour chaque instance on a une description

Description de contextes pertinents J’ai dit donc que ces règles sont appliquées dans un état contexte bien déterminé on dira que cet état représsente un contexte paertinant pour … et on le décrira de la manière suivante Pour chaque application: descripteurs de Pertinence de contexte pour le déploiement qui lescrit les états de contexte qui affecteront le déploiement de l’application parmi les infos collectés. +++Un contexte pertinenseat est associé à un contexte donné et il est définit par une valeur pertinente de ce contexte et un opérateur Exple état r ce contexte pertinent est vérifié lorsque ce contexte est égal à la valeur ... <relevantcontext id= ”NearNonCoveredZone" contextref= "UserConnectionZone" > <operator value="equal"> <relevantvalue>nonCoveredZone</ relevantvalue > </operator> </relevantcontext >

Modification de l’architecture de l’application Variation du nombre de composants déployés selon le contexte Notion de composant obligatoire/optionnel Connexion optionnelle/ obligatoire Pour chaque composant optionnel : le contexte pertinent qui conditionne son déploiement Je vais passer maintenant au descripteur sensible au contexte. Parmi les choses que permet de faire ce descripteur c … ***La Modification de l’architecture de l’application nécessite la description de tous les assemblages possibles pour toutes les combinaisons de contextes Pour éviter l ’explosion du nombre d ’assemblages décrits nous introduisons la notion de compo obl et Nous supposons que l ’application comporte des composants obligatoire dont l ’existence dans l ’assemblage final à déployer ne dépends pas du contexte. Et d ’autres Exple le composant panier

Modification de l’architecture de l’application (règles) L’établissement d’une connexion est conditionné par : la vérification du contexte pertinent qui lui est associé l’existence des composants optionnels à connecter. L’établissement de connexion entre deux composants obligatoires ne nécessite aucune vérification de contexte par contre, la connexion de deux composants optionnels ou d’un composant obligatoire et un composant optionnel n’est possible que si les contextes pertinents représentant le contexte d’existence des composants optionnels sont vérifiés. Cela veut dire que

Configuration des propriétés selon le contexte Ça permet de modifier la valeur des propriétés des composants au moment du déploiement Nous avons 2 types de props : des propriétés de configuration et des propriétés non fonctionnelles. Une propriété de configuration représente une propriété fonctionnelle (un attribut) contrôlant le comportement du composant, par contre une propriété non fonctionnelle décrit une propriété de qualité de service tels que sa persistance, son cycle de vie, ses transactions, etc. Les deux types de propriétés ont un type et une valeur conditionnée par un contexte pertinent donné. Il est possible de faire correspondre une valeur de propriété à une valeur de contexte.

CADeComp : Modèle de données Comme pour chaque instance, on a un ensemble de nœuds, de connexions, etc possibles selon le contexte, on ne va pas décrire le plan de déploiement en tant que vrac d ’implemems, puis vrac de moeuds associés à ces implems, etc. Mais plutt sous forme d ’instances et pour chaque instance on a ..

Description d’une instance de composant <componentinstance idref=  "GUIinstance"> <componentfileref idref="fileref"/> <ExistenceContextCondition> < relevantcontextref idref= "noStorage"/> </ExistenceContextCondition > <componentimplementation> <implem implemref= "PDA" relevantcontextref= "PDAref"/> <implem implemref="NormalScreen"relevantcontextref="Nor"/> </componentimplementation> <componentproperties> <property name="UserLanguage" type="string"> <contextmapping contextref="UserLanguage"/> </property> </componentproperties> <destination> <destinationname value="UserTeminal"> </destination> </componentinstance> (peut être enlevé) Comme un descripteur d ’ass classique, ce descripteur mais pour les différentes instances, il spécifie les différents contextes pertinets pour lesquels cette instance est absente ou présnte. Sd Les différents contextes pour lesquels on choisira une implementation donnée ce contexte pertinaent est décrit dans un descripteur … comme j ’ai dit, il n ’est que référencé ici.

Evaluation

Conclusion Nouvelle architecture pour le déploiement adaptatif Prise en compte du contexte transparente par rapport à l’utilisateur déploiement à la volée Pour conclure je peux die que

Perspectives Reconfiguration dynamique de l’assemblage de l’application. Reprise sur erreurs de déploiement. Outils de vérification de la cohérence des règles d ’adaptation Comme prochaines étapes, nous voulons travailler plus sur la reconfiguration dynamiquement l'architecture de l'application déployée en cours d'exécution