Architecture à base de composants pour le déploiement ...taconet/LibreService/Publis/JC04Dhouha.pdf– Le choix de l’architecture de l’application. Par exemple l’utilisateur

Architecture à base de composants pour ledéploiement adaptatif des applications multi-composants

Dhouha Ayed, Chantal Taconet, et Guy Bernard

GET / INT, CNRS Samovar 51579 rue Charles Fourier91011 É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 utili-sateurs ont besoin d’utiliser le même ensemble d’applications dans des contextes d’exécutionsvariés. Par conséquent, les applications doivent s’adapter aux différentes capacités des termi-naux dès leur installation. Dans cet article, nous proposons une plate-forme pour le déploiementdynamique d’applications multi-composants qui s’adapte au contexte d’utilisation. Cette plate-forme 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’adap-tation au contexte. Ces composants peuvent être rajoutés au modèle de déploiement CCM pourpermettre l’adaptation du déploiement au contexte.

ABSTRACT. With the progress of mobile computer science and terminals’ technology, users needto use the same applications in different contexts. Consequently, when they are installed, appli-cations must adapt to the various capacities of terminals. In this paper, we propose a context-aware deployment platform for multi-components applications which is based on a descriptionof the context having an impact on the deployment of an application and on a set of contextdetection components and context adaptation components. These components can be added tothe 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, assem-blies.

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 descapacités différentes, ce qui introduit de nouveaux besoins d’adaptabilité des servicesau contexte d’utilisation.

Nous définissons le contexte d’utilisation d’une application comme tout attributdétectable et pertinent de son environnement d’exécution [STE 02][RAK 01]. Cecontexte 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 utilisateursd’installer toutes les applications dont ils font usage. Ils ont donc besoin d’un méca-nisme leur permettant de déployer provisoirement une application et la remplacer parune 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 direc-tement utilisable par un utilisateur. Ces activités incluent l’installation, la configura-tion, 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 desapplications puisqu’elle permet d’installer une application sur le site utilisateur quis’adapte à ses besoins et ses contraintes environnementales.

Dans cet article, nous proposons une plate-forme pour le déploiement automatiquedes applications multi-composants sur des machines distribuées. Cette plate-formedoit permettre de déployer dynamiquement des composants qui s’adaptent au contexted’utilisation.

L’article est organisé de la manière suivante. La section 2 présente le modèle dedéploiement proposé par CCM. La section 3 donne une vue générale sur les compo-sants que nous voulons rajouter au modèle de déploiement CCM pour qu’il supportel’adaptation au contexte. La structure de ces composants est par la suite détaillée dansla section 4 qui décrit la plate-forme de déploiement que nous proposons. Enfin, lasection 5 présente quelques travaux connexes et la section 6 conclue cet article enpré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 dedéploiement pour les applications multi-composants en définissant un ensemble d’ob-jets et de descripteurs de déploiement. Le modèle CCM définit quatre descripteurs dedéploiement.

Mode d’emploi de article-hermes.cls 3

– Le descripteur d’assemblage de composants qui décrit l’instanciation des com-posants 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 logiciellessur le composant tels que des informations sur le fournisseur, le fichier IDL du com-posant, 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 at-tributs de configuration.

L’unité de déploiement dans CCM est le paquetage. Le modèle CCM définit deuxtypes de paquetages : le paquetage de composant, associé à un seul composant, contientles implantations du composant, son descripteur de composant CORBA, son descrip-teur de logiciel et ses stubs et squelettes et le paquetage d’assemblage, associé à unassemblage de composants, contient un ensemble de paquetages de composants et undescripteur 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’applica-tion de déploiement commence par installer les paquetages de composants sur les sitescibles en utilisant l’objet

�� de chaque site. Ensuite, elle crée

un objet � �� en utilisant sa fabrique � �� . L’objet � �� valancer l’assemblage de l’application et va coordonner le reste des étapes de déploie-ment. L’assemblage est lancé à travers � �� !�"��#$��%'&)( . � �� crée, parla suite un serveur de composants à travers sa fabrique qui créera une instance duconteneur du composant. Ensuite, il envoie une requête vers le container pour qu’ilcrée les maisons des composants qu’il utilisera pour instancier les composants, puis ilconfigurera ces derniers et les connectera entre eux.

Dans cet article, nous allons proposer des éléments qui peuvent être rajoutés aumodè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éploiementadaptatif

Adapter est un verbe qui signifie rendre apte à assurer ses fonctions dans des condi-tions particulières ou nouvelles [HAC ]. Adapter le déploiement au contexte permetde déployer une application qui répond aux besoins de l’utilisateur et aux besoinsde 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 pourun composant interface utilisateur, il existe plusieurs implémentations : le déploiementchoisira une implémentation adaptée aux possibilités du terminal utilisateur.


Figure 1. Architecture du déploiement CCM.

– Le choix de la machine d’installation de certains composants. Par exemple pourun 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 exemplela machine de proximité la plus puissante.

– Le choix de l’architecture de l’application. Par exemple l’utilisateur peut avoirle choix entre afficher les sorties d’un traitement ou les stocker. Dans le premier casl’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 proposonsune architecture à base de composants contenant des composants qui assurent des acti-vités de déploiement et des composants qui s’occupent de l’adaptation de ces activitésau contexte de déploiement. Quant aux composants de déploiement, ils utilisent lesinterfaces 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’assem-blage

– 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 im-plémentations de ces composants.

L’adaptation au contexte doit être réalisée en deux étapes : la collection des in-formations de contexte et l’analyse de ces informations pour décider les actions quiassurent l’adaptation à ce contexte. Pour cela, nous proposons deux types de compo-


sants pour adapter le déploiement au contexte :

– des composants de type��

qui collectent des informations decontexte à partir de sources diverses de contexte et identifient celles qui sont perti-nentes

– un composant de type�� %�� qui analyse les contextes

pertinents identifiés par plusieurs��

et décide l’assemblage de l’ap-plication à déployer en choisissant les implémentations des composants qui constitue-ront l’application ainsi que leur emplacement.

Ces deux types de composants d’adaptation au contexte sont à leur tour déployésjuste 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 deciter 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 siteprestataire de déploiement pour adapter le déploiement des applications multicom-posants au contexte. Nous allons commencer par décrire la structure initiale de cetteplate-forme en présentant ses différents éléments. Ensuite, nous allons nous focalisersur 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 multicom-posants, chaque application à déployer a un descripteur d’assemblage abstrait et undescripteur de contexte qui décrit le contexte qui a un impact sur le déploiement decelle-ci (voir la section 4.2). Ces deux descripteurs sont respectivement placés dansun dépositaire d’assemblages et un dépositaire de contexte de déploiement. Les des-cripteurs d’assemblage abstraits ont la structure de descripteurs d’assemblage CCMmais ils sont plus abstrait dans le sens où ils ne décrivent que les types de composantsqui peuvent constituer l’application et leurs connexions sans préciser leurs implémen-tations.

Initialement, les composants des différentes applications à déployer sont placésdans un dépositaire de paquetages.

La plate-forme de déploiement offre un ensemble de serveurs d’exécution pour lesinstances des composants de l’application à déployer qui n’ont pas pu être placées surle terminal utilisateur pour des raisons de limitations de ressources ou des raisons decolocalisation. L’installation des implémentations des composants sur ces serveurs est


assurée par un composant��%��

initialement installé sur chaqueserveur d’exécution. La charge de ces serveurs est enregistrée auprès d’un service derecherche sur propriétés [ODP93] permettant la recherche des serveurs d’exécutionles 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 lo-cales 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érentstypes d’informations de contexte que peut délivrer une source de contextes sont enre-gistrés sur un service de recherche sur propriétés.

Pour déployer une application, le terminal utilisateur doit disposer des différentsservices du bus CORBA, d’un composant

��%��pour installer lo-

calement les différentes implémentations des composants et d’un client de déploie-ment lui permettant de cataloguer les applications qu’il peut déployer, choisir uneapplication 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


pouvant influencer son déploiement. La figure 2 montre un exemple de descripteurde contexte de déploiement. Pour chaque contexte, ce descripteur donne des informa-tions sur le type de ce contexte et son mode d’obtention et indique les informationspertinentes de ce contexte qui affecteront le déploiement de l’application.

Il existe deux types de contextes : des contextes toujours pertinents (AlwaysRele-vant) 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 seraréalisée en conséquence à cet état (

�� ). L’activité dedé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 configurationd’un composant existant. La figure 2 montre deux types de contexte. Le premier décritla localisation de l’utilisateur et le deuxième décrit le langage de l’utilisateur. Le pre-mier 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 parle réseau. Si tel contexte se produit, il faut rajouter à l’application un composant per-mettant à l’utilisateur de travailler sur une copie locale et faire une réconciliation aprèsla reconnexion. Le deuxième contexte est de type � � �� et représente lelangage utilisé par l’utilisateur. La valeur de ce contexte doit être prise en comptedès l’installation de l’application. Si le langage utilisé par l’utilisateur change aprèsl’installation, le composant interface graphique doit être reconfiguré pour supporter celangage.

4.3. Structure des composants du déploiement adaptatif

Dans ce qui suit, nous présentons la structure et les fonctionnalités des compo-sants 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èsla réception d’une requête de déploiement venant de l’utilisateur, il commence pardé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éploiementde l’application à déployer à partir du dépositaire de contexte. Pour chaque contextedécrit dans ce descripteur, il extrait son type et procède à la recherche d’une source decontexte locale ou distante qui fournit des informations de contexte de ce type à l’aidedu 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-


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 decontexte pertinente est vérifiée. Enfin,

� ��connecte tous les composants��

et��%��

(se trouvant initialement sur le termi-nal utilisateur) à DeploymentContextAdaptor comme décrit dans la figure 7 et lancele déploiement de l’application en activant chaque composant instancié.

Si le terminal utilisateur manque de ressources,� ��

peut utiliser le ser-vice 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’as-semblage, 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.


Ce composant place localement sur un site le source d’implémentation d’un com-posant suite à la demande d’un composant

�� %�� .La figure 4montre la structure du composant

��%��en IDL3.


Figure 4. La structure IDL3 de AssemblyDeployer et ComponentDownloader.


Un composant de type��

collecte des informations de contexte etfiltre les contextes pertinents selon des règles établies dans le descripteur de contextede 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énementreçu à partir d’une source de contexte,

�� vérifie le type de contexte,

s’il est de type � � �� ou de type��

et que lanouvelle valeur de contexte vérifie la condition de pertinence, il envoie un événementde type ContextInfo à

�� %�� lui indiquant la nouvelle valeurdu 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 consti-tuer.

�� %�� construit un descripteur d’assemblage CCM àpartir du descripteur d’assemblage abstrait du dépositaire d’assemblage. Le descrip-teur d’assemblage construit ne contient que les composants dont l’utilisateur a be-soin pour un contexte donné et indique les différentes implémentations choisies descomposants ainsi que les machines les hébergeant. La figure 6 montre la structure ducomposant

�� %�� en IDL3.

Le composant�� %�� détient une liste de structures de

contextes représentant les contextes pertinents auxquels le déploiement de l’applica-


Figure 6. La structure IDL3 du composant DeploymentContextAdaptor.

tion est sensible ; chaque contexte pertinent est caractérisé par un ensemble d’activitésde déploiement potentielles à appliquer sur un ensemble de composants qui constitue-ront l’application et un ensemble de valeurs de propriétés qui configureront ces com-posants. Les valeurs de ces structures sont initialisées par les éléments contenus dansl’é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 uneliste de propriétés de configuration à partir du contenu des structures de contexte cor-respondantes aux informations de contexte reçues. La liste d’activités de déploiementainsi construite, permet à

�� %�� de déterminer les compo-sants qui constitueront l’application à déployer en appliquant un ET logique entre lescomposants de cette liste et la liste de composants se trouvant dans le descripteurd’assemblage abstrait récupéré du dépositaire d’assemblage. Par contre, la liste depropriétés lui permet de rechercher une implémentation qui s’adapte au contexte et deconfigurer les composants. Le descripteur d’assemblage construit à partir de ces infor-mations, permettra la création d’un � �� pour déployer l’application.

�� %�� utilise le service de recherche sur propriétés pourchoisir les serveurs d’exécution de proximité les moins chargés afin de placer les com-posants de l’application à déployer et appelle ensuite l’opération install du composant�� %��

sur chacun des serveurs choisis en leur indiquant le paque-tage de composant et l’implémentation à installer.

Dans cette section, nous avons proposé une plate-forme de déploiement de compo-sants basée sur les objets et les descripteurs de déploiement CCM. Cette plate-formeprend en compte le contexte d’utilisation grâce à des composants d’adaptation per-mettant de choisir les composants adéquats à l’environnement logiciel et matériel duterminal utilisateur. La figure 7 montre un schéma récapitulatif qui décrit l’assemblagedes différents composants d’adaptation du déploiement au contexte.


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 pourle déploiement des applications multi-composants. La solution que nous avons propo-sée vient compléter ce modèle pour le rendre adaptable au contexte. D’autres travauxde recherche sur le déploiement existent. Parmi eux, nous pouvons citer les solutionsde déploiement pour les applications monolithiques installées sur une seule machinecomme InstallShield [INS ] et rpm packaging system [EWI 96]. Ces solutions neprennent pas en compte l’environnement sur lequel vont être installées les applica-tions.

Software Dock [HAL 97] supporte le déploiement automatique en prenant en comptela configuration système de l’utilisateur. Mais ne supporte pas la description d’assem-blages des applications.

[MIK 02] décrit une approche pour le déploiement d’applications multi-composantssur des terminaux mobiles en proposant des composants de déploiement et de gestiond’architecture d’applications légers. Cette approche permet la modification de l’archi-tecture de l’application au cours de l’exécution sans description de règles précisantsuite à quels besoins ces reconfigurations d’architectures seront réalisées.

La soumission de spécification de l’OMG du déploiement des applications multi-composants [DEP03] prend en compte les propriétés du domaine et des noeuds sur


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 lecadre de SDI [TAC 03] qui représente une infrastructure pour le déploiement dy-namique des applications multi-composants. SDI prend en compte le contexte d’uti-lisation en se basant sur un service de recherche sur propriétés permettant de trou-ver les serveurs d’exécutions et les implémentations de composants qui s’adaptent aucontexte. 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 encompte du contexte d’utilisation durant le déploiement. L’avantage principal de cetteplate-forme est la description de règles d’adaptation au contexte à l’aide d’un descrip-teur de contexte.

6. Conclusion

L’adaptation au contexte est un facteur clé du déploiement des applications dans unenvironnement mobile. Cet article présente une solution pour l’adaptation au contextedu déploiement des applications multi-composants. Cette solution consiste en un en-semble de composants de détection d’états pertinents de contexte et un ensemble decomposants qui analysent ces états pour décider les activités de déploiement à réali-ser qui s’adaptent au contexte. Les composants assurant l’adaptation du déploiementsont à leur tour dynamiquement déployés au moment du déploiement de l’applicationdemandé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éne-ments et une description du contexte pertinent de déploiement dans un descripteur decontexte de déploiement.

La plate-forme que nous avons proposée offre la possibilité d’héberger les ins-tances de composants hors du terminal utilisateur au cas où ce dernier manque deressources et utilise un service de recherche sur propriétés qui joue un rôle primordialdans 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’utilisationaprès l’installation de l’application et reconfigurer dynamiquement l’architecture del’application déployée en cours d’exécution. Notre but est d’assurer un déploiementdistribué sur plusieurs machines d’exécution, nous devons donc trouver des solutionspour les erreurs de déploiement dues à cette distribution. Le repliement automatiquedes composants qui ont été placés sur les serveurs d’exécution et qui ne sont plusutilisés est aussi à étudier. Enfin, pour obtenir des temps de déploiement acceptables,l’étude de la performance est incontournable dans ce domaine.


7. Bibliographie

[CCM02] OMG, « CORBA Components Version 3.0 : An adopted Specification of the ObjectManagement Group », Juin 2002.

[DEP03] OMG, « Specification for Deployment and Configuration of Component Based Dis-tributed Applications », Mars 2003.

[DEY 01] DEY A., ABOWD G., SALBER D., « A conceptual framework and toolkit for sup-porting the rapid prototyping of context-aware applications », Human-computer Interaction,vol. 16, no 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 forPost-Development Configuraion Management in a Wide-Area Network », The Internatio-nal Conference on Distributed Computing Systems, Mai, 1997.

[INS ] INSTALLSHIELD, http ://www.installshield.com.

[MIK 02] MIKIC-RAKIC M., MEDVIDOVIC N., « Architecture-Level Support for SoftwareComponent Deployment in Resource Constrained Environments », The first InternationalIFIP/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 forReactive Components : An Integrated Use of Context, Roles, and Event Based Coordina-tion », IFIP/ACM International Conference on Distributed Systems Platforms, Heidelberg,Allemagne, Novembre, 2001.

[STE 02] STEPHEN S., YU W., FARIAZ K., « Development of Situation-Aware ApplicationSoftware for Ubiquitous Computing Environments », COMPSAC’02, Angleterre, 2002.

[TAC 03] TACONET C., PUTRYCZ E., BERNARD G., « Context Aware Deployment for MobileUsers », COMPSAC’03, Dallas, Novembre, 2003.

[UML03] OMG, « OMG Unified Modeling Language Specification, version 1.5 », Mars 2003.

Documents

Architecture à base de composants pour le déploiement ...taconet/LibreService/Publis/JC04Dhouha.pdf– Le choix de l’architecture de l’application. Par exemple l’utilisateur