Architecture à base de composants pour le déploiement adaptatif des applications multicomposants

Documents pareils
Un environnement de déploiement automatique pour les applications à base de composants

CORBA. (Common Request Broker Architecture)

Patrons de Conception (Design Patterns)

Prise en compte des ressources dans les composants logiciels parallèles

Une méthode d apprentissage pour la composition de services web

La démarche MDA. Auteur : Projet ACCORD (Assemblage de composants par contrats en environnement ouvert et réparti)*

Composants Logiciels. Le modèle de composant de CORBA. Plan

IFT2255 : Génie logiciel

- Couches - Éléments - Domaines - ArchiMate et les techniques du BABOK

Vers une approche Adaptative pour la Découverte et la Composition Dynamique des Services

24/11/2011. Cours EJB/J2EE Copyright Michel Buffa. Plan du cours. EJB : les fondamentaux. Enterprise Java Bean. Enterprise Java Bean.

Une architecture conceptuelle pour le déploiement d applications à grande échelle

Université de Bangui. Modélisons en UML

Extensions à la formation. Laurent Pérochon, avril 2008, RMT Modelia, modélisation conceptuelle, formation UML, INRA Castanet Tolosan

Forthcoming Database

Analyse,, Conception des Systèmes Informatiques

Structuration des décisions de jurisprudence basée sur une ontologie juridique en langue arabe

NFP111 Systèmes et Applications Réparties

Principes. 2A-SI 3 Prog. réseau et systèmes distribués 3. 3 Programmation en CORBA. Programmation en Corba. Stéphane Vialle

Alfstore workflow framework Spécification technique

GRIDKIT: Pluggable Overlay Networks for Grid Computing

Information utiles. webpage : Google+ : digiusto/

SHAREPOINT PORTAL SERVER 2013

Meta Object Facility. Plan

INGÉNIERIE DIRIGÉE PAR LES MODÈLES ET COMPOSANTS SENSIBLES AU CONTEXTE

THÈSE. présentée à TÉLÉCOM PARISTECH. pour obtenir le grade de. DOCTEUR de TÉLÉCOM PARISTECH. Mention Informatique et Réseaux. par.

Ingénierie des Modèles. Méta-modélisation

Java Aspect Components (JAC)

basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB Olivier Augereau Formation UML

Plan. Department of Informatics

ECLIPSE ET PDT (Php development tools)

Cycle de vie du logiciel. Unified Modeling Language UML. UML: définition. Développement Logiciel. Salima Hassas. Unified Modeling Language

Conception, architecture et urbanisation des systèmes d information

Projet 2. Gestion des services enseignants CENTRE D ENSEIGNEMENT ET DE RECHERCHE EN INFORMATIQUE. G r o u p e :

THÈSE. Présentée à. en habilitation conjointe avec l Université de Rennes 1. En vue de l obtention du grade de. DOCTEUR de l ENST Bretagne.

Cedric Dumoulin (C) The Java EE 7 Tutorial

1-Introduction 2. 2-Installation de JBPM 3. 2-JBPM en action.7

4. SERVICES WEB REST 46

Introduction au Génie Logiciel

Orchestrer son cloud OpenStack avec Heat

Développement d un interpréteur OCL pour une machine virtuelle UML.

Once the installation is complete, you can delete the temporary Zip files..

Système Principal (hôte) 2008 Enterprise x64

REMOTE DATA ACQUISITION OF EMBEDDED SYSTEMS USING INTERNET TECHNOLOGIES: A ROLE-BASED GENERIC SYSTEM SPECIFICATION

Chapitre I : le langage UML et le processus unifié

18 TCP Les protocoles de domaines d applications

2. MAQUETTAGE DES SOLUTIONS CONSTRUCTIVES. 2.2 Architecture fonctionnelle d un système communicant.

DSI - Pôle Infrastructures

Le cloud computing au service des applications cartographiques à haute disponibilité

Les Architectures Orientées Services (SOA)

Sciences de Gestion Spécialité : SYSTÈMES D INFORMATION DE GESTION

Network Shutdown Module V3 Extension du Manuel Utilisateur pour architecture Virtualisée Virtual Server de Microsoft

Chapitre 2 - Architecture logicielle et construction d applications client-serveur

Prototype de canal caché dans le DNS

Le modèle client-serveur

Simplifier l intégration des systèmes RH et garantir une version unique des données de l employé. D

Rational Unified Process

WINDOWS SHAREPOINT SERVICES 2007

Génie Logiciel avec Ada. 4 février 2013

NOVA BPM. «Première solution BPM intégr. Pierre Vignéras Bull R&D

Serveur d'application à la juste taille

La virtualisation, si simple!

et dépannage de PC Configuration Sophie Lange Guide de formation avec exercices pratiques Préparation à la certification A+

IFIPS 5 / Nouvelles Architectures Logicielles Projet : Bus de web services avec «moteur» BPEL

OpenPaaS Le réseau social d'entreprise

Refonte front-office / back-office - Architecture & Conception -

Gestion commerciale & marketing avec

Rapport de certification

Fédération : une architecture logicielle pour la construction d applications dirigée par les modèles

Identification du module

Principe de symétrisation pour la construction d un test adaptatif

Rapport de certification

UML est-il soluble dans les méthodes agiles?

Completed Projects / Projets terminés

Software Engineering and Middleware A Roadmap

VERSION 64 BITS DE SAS ET VOS FICHIERS MICROSOFT OFFICE 32-BITS

Problématiques de recherche. Figure Research Agenda for service-oriented computing

Intégration de produits mécatroniques au sein d un système PLM

Nom de l application

CORBA haute performance

Introduction aux «Services Web»

Quick Start Guide This guide is intended to get you started with Rational ClearCase or Rational ClearCase MultiSite.

INF 1250 INTRODUCTION AUX BASES DE DONNÉES. Guide d étude

AGROBASE : un système de gestion de données expérimentales

Cours en ligne Développement Java pour le web

Serveur FTP. 20 décembre. Windows Server 2008R2

Université Paris XI Faculté des sciences d Orsay THÈSE. présentée pour l obtention du grade de Docteur en Sciences de l Université Paris-Sud XI Orsay

Jérémy Dubus. Une démarche orientée modèle pour le déploiement de systèmes en environnements

Documentation technique

RAPPORT DE CONCEPTION UML :

Le Processus RUP. H. Kadima. Tester. Analyst. Performance Engineer. Database Administrator. Release Engineer. Project Leader. Designer / Developer

et Groupe Eyrolles, 2006, ISBN :

en SCÈNE RATIONAL Rational Démonstration SDP : automatisation de la chaîne de développement Samira BATAOUCHE sbataouche@fr.ibm.com

TABLE DES MATIERES A OBJET PROCEDURE DE CONNEXION

Le Guide Pratique des Processus Métiers

Transcription:

Architecture à base de composants pour le déploiement adaptatif des applications multicomposants Dhouha Ayed, Chantal Taconet, et Guy Bernard GET / INT, CNRS Samovar 5157 9 rue Charles Fourier 91011 Évry, France {Dhouha.Ayed, Chantal.Taconet, Guy.Bernard}@int-evry.fr RÉSUMÉ. Avec le progrès de l informatique mobile et de la technologie des terminaux, les utilisateurs ont besoin d utiliser le même ensemble d applications dans des contextes d exécutions variés. Par conséquent, les applications doivent s adapter aux différentes capacités des terminaux dès leur installation. Dans cet article, nous proposons une plate-forme pour le déploiement dynamique d applications multi-composants qui s adapte au contexte d utilisation. Cette plateforme est basée sur une description du contexte auquel le déploiement d une application peut être sensible et elle est supportée par un ensemble de composants pour la détection et l adaptation au contexte. Ces composants peuvent être rajoutés au modèle de déploiement CCM pour permettre l adaptation du déploiement au contexte. ABSTRACT. With the progress of mobile computer science and terminals technology, users need to use the same applications in different contexts. Consequently, when they are installed, applications must adapt to the various capacities of terminals. In this paper, we propose a contextaware deployment platform for multi-components applications which is based on a description of the context having an impact on the deployment of an application and on a set of context detection components and context adaptation components. These components can be added to the CCM deployment model to allow the adaptation of the deployment the context. MOTS-CLÉS : déploiement dynamique, adaptation au contexte, applications multi-composants, assemblage. KEYWORDS: just in time deployment, context-awareness, multi-component applications, assemblies.

2 Journées Composants Lille 17-18 Mars 2004. 1. Introduction Grâce aux progrès de l informatique mobile et de la technologie des terminaux, les utilisateurs peuvent utiliser les mêmes services à partir de terminaux différents, tels que les PCs portables, les PDAs et les téléphones mobiles. Ces terminaux ont des capacités différentes, ce qui introduit de nouveaux besoins d adaptabilité des services au contexte d utilisation. Nous définissons le contexte d utilisation d une application comme tout attribut détectable et pertinent de son environnement d exécution [STE 02][RAK 01]. Ce contexte peut représenter les capacités du terminal utilisateur, sa connexion au réseau, son environnement externe, sa localisation, son profil, ses préférences, etc. Les capacités limitées des terminaux mobiles ne permettent pas aux utilisateurs d installer toutes les applications dont ils font usage. Ils ont donc besoin d un mécanisme leur permettant de déployer provisoirement une application et la remplacer par une autre lorsqu ils en n ont plus besoin. Ce mécanisme doit être automatique, pour épargner l utilisateur des installations et des configurations manuelles et répétitives. Le déploiement représente toutes les activités qui rendent une application directement utilisable par un utilisateur. Ces activités incluent l installation, la configuration, l activation, la mise à jour et aussi la désinstallation d une application [HAL 97]. L adaptation au contexte joue un rôle important dans le déploiement dynamique des applications puisqu elle permet d installer une application sur le site utilisateur qui s adapte à ses besoins et ses contraintes environnementales. Dans cet article, nous proposons une plate-forme pour le déploiement automatique des applications multi-composants sur des machines distribuées. Cette plate-forme doit permettre de déployer dynamiquement des composants qui s adaptent au contexte d utilisation. L article est organisé de la manière suivante. La section 2 présente le modèle de déploiement proposé par CCM. La section 3 donne une vue générale sur les composants que nous voulons rajouter au modèle de déploiement CCM pour qu il supporte l adaptation au contexte. La structure de ces composants est par la suite détaillée dans la section 4 qui décrit la plate-forme de déploiement que nous proposons. Enfin, la section 5 présente quelques travaux connexes et la section 6 conclue cet article en présentant quelques perspectives. 2. Le modèle de déploiement CCM Le modèle de composants de CORBA, CCM [CCM02] a spécifié un modèle de déploiement pour les applications multi-composants en définissant un ensemble d objets et de descripteurs de déploiement. Le modèle CCM définit quatre descripteurs de déploiement.

Mode d emploi de article-hermes.cls 3 Le descripteur d assemblage de composants qui décrit l instanciation des composants et leurs connexions. Le descripteur de composant CORBA qui décrit les propriétés fonctionnelles (type, ports et maison) et non fonctionnelles du composant. Le descripteur logiciel du composant qui contient des informations logicielles sur le composant tels que des informations sur le fournisseur, le fichier IDL du composant, le descripteur de composant CORBA, des informations sur son implantation, l implantation de sa maison et le point d entrée de la maison. Le descripteur de propriétés du composant qui contient des valeurs pour ses attributs de configuration. L unité de déploiement dans CCM est le paquetage. Le modèle CCM définit deux types de paquetages : le paquetage de composant, associé à un seul composant, contient les implantations du composant, son descripteur de composant CORBA, son descripteur de logiciel et ses stubs et squelettes et le paquetage d assemblage, associé à un assemblage de composants, contient un ensemble de paquetages de composants et un descripteur d assemblage de composants. La figure 1 montre un diagramme de collaboration UML [UML03] qui illustre les étapes de déploiement et l interaction entre les objets de déploiement CCM. L application de déploiement commence par installer les paquetages de composants sur les sites cibles en utilisant l objet de chaque site. Ensuite, elle crée un objet en utilisant sa fabrique. L objet va lancer l assemblage de l application et va coordonner le reste des étapes de déploiement. L assemblage est lancé à travers. crée, par!"#$ %'&)( la suite un serveur de composants à travers sa fabrique qui créera une instance du conteneur du composant. Ensuite, il envoie une requête vers le container pour qu il crée les maisons des composants qu il utilisera pour instancier les composants, puis il configurera ces derniers et les connectera entre eux. Dans cet article, nous allons proposer des éléments qui peuvent être rajoutés au modèle de déploiement CCM pour adapter le déploiement au contexte d utilisation. 3. Vue générale sur l architecture à base de composants pour le déploiement adaptatif Adapter est un verbe qui signifie rendre apte à assurer ses fonctions dans des conditions particulières ou nouvelles [HAC ]. Adapter le déploiement au contexte permet de déployer une application qui répond aux besoins de l utilisateur et aux besoins de l environnement d exécution de l application. Cette adaptation peut affecter le déploiement à plusieurs niveaux. Le choix de l implémentation d un composant de type donné. Par exemple pour un composant interface utilisateur, il existe plusieurs implémentations : le déploiement choisira une implémentation adaptée aux possibilités du terminal utilisateur.

4 Journées Composants Lille 17-18 Mars 2004. Figure 1. Architecture du déploiement CCM. Le choix de la machine d installation de certains composants. Par exemple pour un composant de traitement, qui n utilise pas de ressources autres que du CPU, le déploiement a une latitude pour choisir la machine d installation, il choisira par exemple la machine de proximité la plus puissante. Le choix de l architecture de l application. 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 dans une base de données. Pour assurer l adaptation du déploiement à ces différents niveaux, nous proposons une architecture à base de composants contenant des composants qui assurent des activités de déploiement et des composants qui s occupent de l adaptation de ces activités au contexte de déploiement. Quant aux composants de déploiement, ils utilisent les interfaces CCM de déploiement et sont de deux types : des composants de type qui offrent l interface de CCM et permettent de déployer une application à partir d un descripteur d assemblage des composants de type % qui offrent l interface de CCM. Ces composants sont placés sur les machines où les composants doivent être déployés et permettent d installer localement les implémentations de ces composants. L adaptation au contexte doit être réalisée en deux étapes : la collection des informations de contexte et l analyse de ces informations pour décider les actions qui assurent l adaptation à ce contexte. Pour cela, nous proposons deux types de compo-

Mode d emploi de article-hermes.cls 5 sants pour adapter le déploiement au contexte : des composants de type qui collectent des informations de contexte à partir de sources diverses de contexte et identifient celles qui sont pertinentes un composant de type % qui analyse les contextes pertinents identifiés par plusieurs et décide l assemblage de l application à déployer en choisissant les implémentations des composants qui constitueront l application ainsi que leur emplacement. Ces deux types de composants d adaptation au contexte sont à leur tour déployés juste au moment du déploiement de l application demandée par l utilisateur grâce à des composants de type pour pouvoir être configurés selon le contexte actuel. La structure et les fonctionnalités de chacun des composants que nous venons de citer seront expliquées dans la section 4.3. 4. Plate-forme de déploiement adaptatif des applications multi-composants Nous décrivons dans ce qui suit la plate-forme que nous proposons pour un site prestataire de déploiement pour adapter le déploiement des applications multicomposants au contexte. Nous allons commencer par décrire la structure initiale de cette plate-forme en présentant ses différents éléments. Ensuite, nous allons nous focaliser sur les composants réalisant le déploiement adaptatif. 4.1. Plate-forme initiale de déploiement Pour assurer un déploiement dynamique et adaptatif des applications multicomposants, chaque application à déployer a un descripteur d assemblage abstrait et un descripteur de contexte qui décrit le contexte qui a un impact sur le déploiement de celle-ci (voir la section 4.2). Ces deux descripteurs sont respectivement placés dans un dépositaire d assemblages et un dépositaire de contexte de déploiement. Les descripteurs d assemblage abstraits ont la structure de descripteurs d assemblage CCM mais ils sont plus abstrait dans le sens où ils ne décrivent que les types de composants qui peuvent constituer l application et leurs connexions sans préciser leurs implémentations. Initialement, les composants des différentes applications à déployer sont placés dans un dépositaire de paquetages. La plate-forme de déploiement offre un ensemble de serveurs d exécution pour les instances des composants de l application à déployer qui n ont pas pu être placées sur le terminal utilisateur pour des raisons de limitations de ressources ou des raisons de colocalisation. L installation des implémentations des composants sur ces serveurs est

6 Journées Composants Lille 17-18 Mars 2004. assurée par un composant % initialement installé sur chaque serveur d exécution. La charge de ces serveurs est enregistrée auprès d un service de recherche sur propriétés [ODP93] permettant la recherche des serveurs d exécution les moins chargés pour instancier les composants de l application à déployer. Les informations de contextes sont récupérées à partir de sources de contextes locales ou distantes. Ces sources sont des fichiers ou des logiciels cachant la complexité des capteurs de contexte comme les widgets décrits dans [DEY 01]. Les différents types d informations de contexte que peut délivrer une source de contextes sont enregistrés sur un service de recherche sur propriétés. Pour déployer une application, le terminal utilisateur doit disposer des différents services du bus CORBA, d un composant % pour installer localement les différentes implémentations des composants et d un client de déploiement lui permettant de cataloguer les applications qu il peut déployer, choisir une application et initier le déploiement. Le déploiement de toute application sera initié par un composant qui peut être initialement placé sur n importe quel serveur de la plate-forme. 4.2. Descripteur de contexte de déploiement Figure 2. Exemple de descripteur de contexte de déploiement. Pour décrire le contexte auquel le déploiement d une application est sensible, chaque application possède un descripteur de contexte qui décrit plusieurs contextes

Mode d emploi de article-hermes.cls 7 pouvant influencer son déploiement. La figure 2 montre un exemple de descripteur de contexte de déploiement. Pour chaque contexte, ce descripteur donne des informations sur le type de ce contexte et son mode d obtention et indique les informations pertinentes de ce contexte qui affecteront le déploiement de l application. Il existe deux types de contextes : des contextes toujours pertinents (AlwaysRelevant) dont le changement affecte toujours le déploiement et d autres (SpecificChange- Relevant) nécessitant des valeurs particulières pour pouvoir affecter le déploiement. Pour le deuxième type, le descripteur de contexte doit indiquer la condition devant être vérifiée pour que le déploiement soit affecté et l activité de déploiement qui sera réalisée en conséquence à cet état ( ). L activité de déploiement est décrite par un nom d activité et des paramètres. Une activité de déploiement peut être l installation d un composant, sa suppression ou la configuration d un composant existant. La figure 2 montre deux types de contexte. Le premier décrit la localisation de l utilisateur et le deuxième décrit le langage de l utilisateur. Le premier contexte est de type, sa valeur pertinente se traduit par l entrée de l utilisateur dans une zone qui s approche d une zone non couverte par le réseau. Si tel contexte se produit, il faut rajouter à l application un composant permettant à l utilisateur de travailler sur une copie locale et faire une réconciliation après la reconnexion. Le deuxième contexte est de type et représente le langage utilisé par l utilisateur. La valeur de ce contexte doit être prise en compte dès l installation de l application. Si le langage utilisé par l utilisateur change après l installation, le composant interface graphique doit être reconfiguré pour supporter ce langage. 4.3. Structure des composants du déploiement adaptatif Dans ce qui suit, nous présentons la structure et les fonctionnalités des composants jouant le rôle d acteurs principaux dans le déploiement adaptatif ainsi que les événements échangés entre eux. 4.3.1. Le composant Le composant est l initiateur du déploiement d une application. Dès la réception d une requête de déploiement venant de l utilisateur, il commence par déployer les composants nécessaires à l adaptation du déploiement (des composants et un composant % ). La figure 3 montre la structure du composant en IDL3. commence par récupérer le descripteur de contexte de déploiement de l application à déployer à partir du dépositaire de contexte. Pour chaque contexte décrit dans ce descripteur, il extrait son type et procède à la recherche d une source de contexte locale ou distante qui fournit des informations de contexte de ce type à l aide du service de recherche et instancie un composant de type qui va s interfacer avec cette source sur la machine où elle est placée., confi-

8 Journées Composants Lille 17-18 Mars 2004. Figure 3. La structure IDL3 du composant PreDeployer. gure par la suite, le composant avec les éléments,,, et # du descripteur de contexte de déploiement. Ces paramètres permettent à de filtrer les états de contexte. instancie, par la suite, un composant % sur le terminal utilisateur et lui envoie le contenu de l élément DeploymentActivity- Parameters de chaque contexte pertinent décrit. Cet élément permet à Deployment- ContextAdaptor de décider les activités de déploiement à faire lorsqu une valeur de contexte pertinente est vérifiée. Enfin, connecte tous les composants et % (se trouvant initialement sur le terminal utilisateur) à DeploymentContextAdaptor comme décrit dans la figure 7 et lance le déploiement de l application en activant chaque composant instancié. Si le terminal utilisateur manque de ressources, peut utiliser le service de recherche pour trouver un serveur d exécution de proximité pour instancier %. 4.3.2. Le composant Ce composant permet de déployer une application à partir de son descripteur d assemblage, il offre l interface définie dans CCM. La figure 4 montre la struc- ture du composant en IDL3. La maison de encapsule l interface de CCM. 4.3.3. Le composant Ce composant place localement sur un site le source d implémentation d un composant suite à la demande d un composant %.La figure 4 montre la structure du composant % en IDL3.

Mode d emploi de article-hermes.cls 9 Figure 4. La structure IDL3 de AssemblyDeployer et ComponentDownloader. 4.3.4. Le composant Un composant de type collecte des informations de contexte et filtre les contextes pertinents selon des règles établies dans le descripteur de contexte de déploiement. La figure 5 montre la structure de en IDL3. Figure 5. La structure IDL3 du composant ContextDetector. A chaque fois qu il y a une information de contexte signalée par un événement reçu à partir d une source de contexte, vérifie le type de contexte, s il est de type ou de type et que la nouvelle valeur de contexte vérifie la condition de pertinence, il envoie un événement de type ContextInfo à % lui indiquant la nouvelle valeur du contexte. 4.3.5. Le composant % est le composant principal d adaptation au contexte. Il collecte tous les contextes pertinents et décide l assemblage de l application à déployer ainsi que l implémentation et l emplacement des composants qui vont la constituer. % construit un descripteur d assemblage CCM à partir du descripteur d assemblage abstrait du dépositaire d assemblage. Le descripteur d assemblage construit ne contient que les composants dont l utilisateur a besoin pour un contexte donné et indique les différentes implémentations choisies des composants ainsi que les machines les hébergeant. La figure 6 montre la structure du composant % en IDL3. Le composant % détient une liste de structures de contextes représentant les contextes pertinents auxquels le déploiement de l applica-

10 Journées Composants Lille 17-18 Mars 2004. Figure 6. La structure IDL3 du composant DeploymentContextAdaptor. tion est sensible ; chaque contexte pertinent est caractérisé par un ensemble d activités de déploiement potentielles à appliquer sur un ensemble de composants qui constitueront l application et un ensemble de valeurs de propriétés qui configureront ces composants. Les valeurs de ces structures sont initialisées par les éléments contenus dans l élément envoyé par. Au fur et à mesure qu il reçoit des informations de contexte pertinentes de, % construit une liste d activités de déploiement et une liste de propriétés de configuration à partir du contenu des structures de contexte correspondantes aux informations de contexte reçues. La liste d activités de déploiement ainsi construite, permet à % de déterminer les composants qui constitueront l application à déployer en appliquant un ET logique entre les composants de cette liste et la liste de composants se trouvant dans le descripteur d assemblage abstrait récupéré du dépositaire d assemblage. Par contre, la liste de propriétés lui permet de rechercher une implémentation qui s adapte au contexte et de configurer les composants. Le descripteur d assemblage construit à partir de ces informations, permettra la création d un pour déployer l application. % utilise le service de recherche sur propriétés pour choisir les serveurs d exécution de proximité les moins chargés afin de placer les composants de l application à déployer et appelle ensuite l opération install du composant % sur chacun des serveurs choisis en leur indiquant le paquetage de composant et l implémentation à installer. Dans cette section, nous avons proposé une plate-forme de déploiement de composants basée sur les objets et les descripteurs de déploiement CCM. Cette plate-forme prend en compte le contexte d utilisation grâce à des composants d adaptation permettant de choisir les composants adéquats à l environnement logiciel et matériel du terminal utilisateur. La figure 7 montre un schéma récapitulatif qui décrit l assemblage des différents composants d adaptation du déploiement au contexte.

Mode d emploi de article-hermes.cls 11 Figure 7. Assemblage des composants du déploiement adaptatif. 5. Travaux connexes La solution de déploiement spécifiée dans CCM est le modèle de référence pour le déploiement des applications multi-composants. La solution que nous avons proposée vient compléter ce modèle pour le rendre adaptable au contexte. D autres travaux de recherche sur le déploiement existent. Parmi eux, nous pouvons citer les solutions de déploiement pour les applications monolithiques installées sur une seule machine comme InstallShield [INS ] et rpm packaging system [EWI 96]. Ces solutions ne prennent pas en compte l environnement sur lequel vont être installées les applications. Software Dock [HAL 97] supporte le déploiement automatique en prenant en compte la configuration système de l utilisateur. Mais ne supporte pas la description d assemblages des applications. [MIK 02] décrit une approche pour le déploiement d applications multi-composants sur des terminaux mobiles en proposant des composants de déploiement et de gestion d architecture d applications légers. Cette approche permet la modification de l architecture de l application au cours de l exécution sans description de règles précisant suite à quels besoins ces reconfigurations d architectures seront réalisées. La soumission de spécification de l OMG du déploiement des applications multicomposants [DEP03] prend en compte les propriétés du domaine et des noeuds sur

12 Journées Composants Lille 17-18 Mars 2004. lesquels vont être déployés les composants de l application sans prendre en considération le contexte d utilisation d une manière générale. Notre travail est une suite des travaux de recherches qui ont été réalisés dans le cadre de SDI [TAC 03] qui représente une infrastructure pour le déploiement dynamique des applications multi-composants. SDI prend en compte le contexte d utilisation en se basant sur un service de recherche sur propriétés permettant de trouver les serveurs d exécutions et les implémentations de composants qui s adaptent au contexte. Le code de déploiement de SDI est spécifique à l application à déployer. Dans cet article, nous avons présenté une plate-forme générale pour la prise en compte du contexte d utilisation durant le déploiement. L avantage principal de cette plate-forme est la description de règles d adaptation au contexte à l aide d un descripteur de contexte. 6. Conclusion L adaptation au contexte est un facteur clé du déploiement des applications dans un environnement mobile. Cet article présente une solution pour l adaptation au contexte du déploiement des applications multi-composants. Cette solution consiste en un ensemble de composants de détection d états pertinents de contexte et un ensemble de composants qui analysent ces états pour décider les activités de déploiement à réaliser qui s adaptent au contexte. Les composants assurant l adaptation du déploiement sont à leur tour dynamiquement déployés au moment du déploiement de l application demandée par l utilisateur pour pouvoir prendre en compte le contexte courant. L adaptation au contexte est en grande partie assurée grâce à un système d événements et une description du contexte pertinent de déploiement dans un descripteur de contexte de déploiement. La plate-forme que nous avons proposée offre la possibilité d héberger les instances de composants hors du terminal utilisateur au cas où ce dernier manque de ressources et utilise un service de recherche sur propriétés qui joue un rôle primordial dans l adaptation en permettant de trouver les capteurs de proximité. Cette solution est en cours d implémentation sur la plate-forme OpenCCM [OPE ]. Comme prochaines étapes, nous voulons prendre en compte le contexte d utilisation après l installation de l application et reconfigurer dynamiquement l architecture de l application déployée en cours d exécution. Notre but est d assurer un déploiement distribué sur plusieurs machines d exécution, nous devons donc trouver des solutions pour les erreurs de déploiement dues à cette distribution. Le repliement automatique des composants qui ont été placés sur les serveurs d exécution et qui ne sont plus utilisés est aussi à étudier. Enfin, pour obtenir des temps de déploiement acceptables, l étude de la performance est incontournable dans ce domaine.

Mode d emploi de article-hermes.cls 13 7. Bibliographie [CCM02] OMG, «CORBA Components Version 3.0 : An adopted Specification of the Object Management Group», Juin 2002. [DEP03] OMG, «Specification for Deployment and Configuration of Component Based Distributed Applications», Mars 2003. [DEY 01] DEY A., ABOWD G., SALBER D., «A conceptual framework and toolkit for supporting the rapid prototyping of context-aware applications», Human-computer Interaction, vol. 16, n o 2-4 (special issue on context-aware computing), 2001, p. 97-166. [EWI 96] EWING M., TROAN E., «The RPM Packaging System», February 1996. [HAC ] HACHETTE, «Le dictionnaire universel francophone en ligne», http ://www.francophonie.hachette-livre.fr. [HAL 97] HALL R., HEIMBEIGNER D., VAN DER HOEK A., WOLF A., «An architecture for Post-Development Configuraion Management in a Wide-Area Network», The International Conference on Distributed Computing Systems, Mai, 1997. [INS ] INSTALLSHIELD, http ://www.installshield.com. [MIK 02] MIKIC-RAKIC M., MEDVIDOVIC N., «Architecture-Level Support for Software Component Deployment in Resource Constrained Environments», The first International IFIP/ACM Working Conference on Component Deployment, Berlin, Allemagne, Juin, 2002. [ODP93] «Information Technology - Open Distributed Computing - ODP Trading Function», ISO/IEC JTC1/SC21.59 Draft, ITU-TS-SG 7 Q16 report, Novembre 1993. [OPE ] OPENCCM, http ://openccm.objectweb.org. [RAK 01] RAKOTONIRAINY A., INDULSKA J., LOKE S., ZASLAVSKY A., «Middleware for Reactive Components : An Integrated Use of Context, Roles, and Event Based Coordination», IFIP/ACM International Conference on Distributed Systems Platforms, Heidelberg, Allemagne, Novembre, 2001. [STE 02] STEPHEN S., YU W., FARIAZ K., «Development of Situation-Aware Application Software for Ubiquitous Computing Environments», COMPSAC 02, Angleterre, 2002. [TAC 03] TACONET C., PUTRYCZ E., BERNARD G., «Context Aware Deployment for Mobile Users», COMPSAC 03, Dallas, Novembre, 2003. [UML03] OMG, «OMG Unified Modeling Language Specification, version 1.5», Mars 2003.