RECHERCHE

ScalAgent, une plate-forme à composants pour applications asynchrones Vivien Quéma∗ — Roland Balter∗∗1 — Luc Bellissard∗∗2 David Féliot∗∗ — André Freyssinet∗∗ — Serge Lacourte∗∗ ∗

INPG - Laboratoire LSR-IMAG (CNRS, INPG, UJF) - INRIA - projet Sardes ScalAgent Distributed Technologies INRIA Rhône-Alpes, 655 av. de l’Europe, F-38334 Saint-Ismier cedex [email protected] ∗∗

RÉSUMÉ. L’usage généralisé d’Internet et l’intelligence croissante des équipements permettent le

développement de services interactifs coopérant avec les systèmes d’information de l’entreprise. Développer et déployer ces services est un défi à la fois sur le plan des modèles et outils de construction, et sur celui des services systèmes sous-jacents (ou intergiciels). Il est aujourd’hui reconnu que les intergiciels orientés messages sont bien adaptés à ce type d’applications. On leur reproche cependant la pauvreté des modèles de programmation et le manque d’outils pour le développement des applications. Ce papier présente la plate-forme ScalAgent dont l’objectif est de pallier ces lacunes. Cette plate-forme comprend un intergiciel orienté messages, un modèle de composants asynchrones, et un ensemble d’outils permettant la configuration, le déploiement et l’administration d’applications distribuées écrites en termes de composants. ABSTRACT. The use of the Internet as a general purpose communication system is growing very fast in all sectors of activity and multiple forms of equipments are now connected to Internet and have gained increased embedded intelligence. This evolution leads to emerging interactive services that are cooperating with existing enterprise information systems. Developing and deploying these new services is a challenging issue from both the software engineering point of view (development tools) and the run-time point of view (middleware services). It is recognized today that message oriented middleware (MOM) are well-suited to support these services. However MOM-based environments are suffering from a lack of tools for building and operating distributed applications. This paper describes the ScalAgent infrastructure which aims at filling this gap. This infrastructure is based on a MOM and a coherent set of development tools following a component-based approach. MOTS-CLÉS :

composants, intergiciels asynchrones, langages de description d’architecture.

KEYWORDS:

components, asynchronous middleware, architecture description languages.

1. Université Joseph Fourier – Grenoble 1, en délégation dans ScalAgent D.T. 2. Institut National Polytechnique de Grenoble, en délégation dans ScalAgent D.T. RSTI - TSI – 23/2004. Composants et adaptabilité, pages 253 à 274

254

RSTI - TSI – 23/2004. Composants et adaptabilité

1. Introduction L’usage d’internet se généralise dans tous les secteurs d’activité : banque, distribution, santé, domotique, etc. Des équipements de toute nature – assistants personnels, téléphones mobiles, bornes interactives, automates, etc. – sont aujourd’hui accessibles à travers internet et sont dotés d’une intelligence croissante. Grâce à cette double capacité de programmabilité et de connectivité, les équipements deviennent le support d’accès à de nouveaux services interactifs qui coopèrent, via internet, avec les systèmes d’information de l’entreprise. Cette évolution donne naissance à une nouvelle génération d’applications distribuées, caractérisées par un couplage fonctionnel fort, entre des composants logiciels évoluant dans un environnement faiblement couplé dans les deux dimensions espace et temps. En effet, les systèmes hébergeant ces composants logiciels sont potentiellement distribués sur une grande échelle géographique, et sont interconnectés par des réseaux de capacité variable. Par ailleurs, ces applications sont très souvent concernées par un mode de fonctionnement déconnecté, engendré par les usages mobiles et par les pannes temporaires du réseau. Le couplage faible milite en faveur d’un modèle de communication asynchrone, tant au niveau de l’architecture de l’application, qu’au niveau de l’intergiciel sous-jacent. Cette propriété explique l’intérêt croissant des intergiciels asynchrones (ou MOM pour Message Oriented Middleware) [GEI 01, BAN 99]. Aujourd’hui, on reproche principalement à cette classe d’intergiciels le faible niveau d’abstraction fourni au développeur, et le manque d’outils pour construire et déployer des applications réparties. En effet, les MOM se résument trop souvent à une interface de programmation (API) qui prend la forme d’une simple bibliothèque de fonctions d’accès au bus de communication. C’est le cas par exemple de la spécification JMS (Java Messaging Service). Lorsque l’application est de complexité moyenne, cette approche est acceptable. Pour les applications de complexité significative, ce niveau d’interface devient un obstacle rédhibitoire en comparaison avec les modèles et outils disponibles dans les intergiciels de type client-serveur – tels que les langages de description d’interface et les outils de génération de stubs. Dans ce papier, nous présentons la plate-forme ScalAgent dont l’objectif est de fournir une infrastructure d’exécution répartie, bâtie autour d’un MOM, et un ensemble d’outils facilitant la construction, le déploiement et l’administration d’applications réparties regroupant un ensemble de composants logiciels hétérogènes coopérant selon un modèle de communication asynchrone. La plate-forme ScalAgent est composée des éléments suivants : – Un intergiciel orienté messages qui fournit un service de communication asynchrone offrant divers niveaux de qualité de service pour les propriétés de fiabilité (garantie de délivrance des messages), sécurité, ordonnancement, etc. – Un modèle de programmation répartie à base d’agents1 . Les agents sont des objets Java distribués qui ont un modèle d’exécution de type événement-réaction. L’ato1. Le terme « agent » est associé à de nombreux travaux : systèmes multiagents, agents mobiles, agents assistants, etc. Dans cet article, un agent est un objet réactif qui a un comportement proche de celui d’un acteur [AGH 86].

La plate-forme à composants ScalAgent

255

micité des réactions, combinée avec la garantie de délivrance des messages, fournit globalement un premier niveau de construction d’applications réparties tolérant les fautes, utilisé notamment pour construire les outils et services d’administration d’applications réparties présentés plus loin. – Un modèle de composants distribués. Le paradigme agent est insuffisant pour modéliser les applications présentant un niveau de complexité significatif car il ne permet d’exprimer ni les relations et dépendances entre agents, ni les propriétés non fonctionnelles requises par les agents. C’est pourquoi un modèle de composants a été développé afin d’encapsuler les agents dans des unités sémantiquement plus riches, caractérisées, entre autres, par les deux propriétés suivantes : la composabilité, inspirée des travaux de [MAG 93, MAG 89] – qui permet de définir une application comme un assemblage de composants –, et la séparation entre aspects fonctionnels et non fonctionnels. Ces derniers incluent les fonctions de gestion du cycle de vie du composant. – Des outils de construction et déploiement d’applications à base de composants. L’objectif de ces outils est d’assister le programmeur d’application dans le processus de configuration d’une application, et dans les opérations de déploiement des composants sur leur site d’exécution. Ces outils s’appuient sur une description de l’application effectuée à l’aide d’un langage de description d’architecture (ADL). L’article est structuré de la façon suivante : nous présentons l’intergiciel orienté messages et le modèle de programmation associé dans la section 2. La section 3 est consacrée au modèle de composants et au langage de description d’architectures. L’outil de déploiement est décrit dans la section 4. Enfin, la section 5 conclut cet article.

2. L’intergiciel orienté messages L’intergiciel orienté messages proposé dans la plate-forme ScalAgent [BEL 99] est un exemple d’infrastructure d’intégration de services par les flots de données. On distingue, aujourd’hui, deux types de telles infrastructures : les MOM (pour Message Oriented Middleware) [BAN 99] et les intergiciels à événements (Event-based Middleware [BUC 03]). Dans les deux cas, la caractéristique principale de ces infrastructures est de fournir un canal de communication asynchrone entre émetteurs et destinataires. Les MOM délivrent des messages quelconques à des files de messages ou boîtes aux lettres, dans lesquelles les destinataires viennent retirer les messages. Les MOM présentent deux caractéristiques principales. D’une part, ils garantissent la persistance des messages tant que leur consommation n’a pas été signifiée. D’autre part, la sémantique d’intégration entre producteurs et destinataires est définie par l’analyse du contenu du message. Dans les intergiciels à événements, les messages sont typés et le découplage entre émetteurs et destinataires est assuré par le mécanisme de publication-abonnement (publish-subscribe) . Les émetteurs « publient » des messages typés au sein de l’intergiciel et les destinataires, qui ont préalablement enregistré leur intérêt pour un type

256

RSTI - TSI – 23/2004. Composants et adaptabilité

de messages, les reçoivent de manière automatique : un événement correspond à la notification du message typé. On peut noter que l’effort de recherche porte surtout, aujourd’hui, sur des mécanismes efficaces de dissémination des événements dans des environnements à grande échelle [CAR 01, STR 98]. L’intergiciel de la plate-forme ScalAgent combine certaines des caractéristiques de ces deux types d’intergiciels. Il fournit une infrastructure de communication asynchrone garantissant la délivrance des messages entre émetteurs et destinataires. Les messages sont typés et la communication fiable est réalisée grâce à des files de messages distribuées. Une différence notable avec les intergiciels à messages existants est liée à l’utilisation d’un modèle d’objets distribués pour décrire émetteurs et récepteurs. Ces objets, appelés « agents », communiquent uniquement par messages en utilisant les services du canal de communication asynchrone.

2.1. Les agents Le modèle d’agents est issu du modèle d’objets réactifs [AGH 86]. Les agents se conforment à un modèle de programmation de type « événement → réaction ». Un événement correspond à la notification d’un message typé à un agent qui va se traduire par l’exécution d’une méthode de l’objet. Cette exécution peut, à son tour, provoquer la production d’événements auxquels un ou plusieurs agents vont réagir.

2.2. Les serveurs d’agents L’évolution actuelle des architectures d’intergiciels fait apparaître nettement la distinction entre la structure d’accueil – l’environnement d’exécution – et les entités de traitement [RIV 02]. Les agents s’exécutent au sein d’une structure d’accueil nommée serveur d’agents. Cette structure d’accueil est configurable et fournit différentes politiques de fonctionnement des agents hébergés, par exemple : – l’atomicité des réactions aux événements : les traitements induits par la réception d’une notification sont soit complètement réalisés, soit annulés. – la persistance de l’état des agents : un changement d’état correspond à la complétion d’une réaction. Le lecteur peut avoir un aperçu de la programmation des agents et du développement d’une application à base d’agents en consultant [BEL 99, PAL 00]. L’organisation d’un serveur d’agents est décrite dans la figure 1. Le cœur du serveur est un moteur d’exécution qui contrôle le flot d’exécution des agents. Ce flot est unique et prend la forme d’une boucle qui consiste, pour chaque notification, à exécuter la méthode associée à la réaction de l’agent destinataire. Le flot exécute le code des modules de persistance et d’atomicité s’ils ont été spécifiés dans la configuration initiale de l’intergiciel. Un serveur d’agents contrôle également les flots d’exécution

La plate-forme à composants ScalAgent

257

associés à la gestion des communications au sein d’un sous-système appelé le bus local. Les bus locaux des différents serveurs coopèrent pour fournir une mise en œuvre distribuée d’un bus à messages global. Ce bus à messages global permet la communication entre les différents agents – qu’ils soient hébergés par le même serveur ou non. Chaque bus est constitué de deux types de composants : un canal et un ensemble de composants réseau. – Les composants réseau sont responsables de l’émission de messages provenant du canal à destination des serveurs distants. Il existe différents composants réseau correspondant à différents protocoles. Par ailleurs, il est possible d’adjoindre à un composant réseau des modules logiciels responsables de propriétés diverses : sécurité, fiabilité, ordonnancement causal, etc. Nous ne reviendrons pas sur la mise en œuvre de ces propriétés qui est décrite dans [PAL 00]. – Le canal est chargé de distribuer les messages provenant du moteur d’exécution vers les composants réseau et vice versa. Ce routage est effectué en fonction des propriétés non fonctionnelles nécessaires à la communication. Par exemple, si la communication entre deux agents doit être sécurisée, le canal transmettra le message à un composant réseau utilisant un protocole sécurisé. Serveur d’agents 1

Serveur d’agents 2

Moteur d’exécution

Agent

Agent

Agent Agent

Moteur d’exécution

Composant réseau 2

Agent

Agent

Agent

Canal

Canal Composant réseau 1

Agent

Composant réseau 3

Bus local

Composant réseau 1

Composant réseau 2

Bus à messages global

Bus local

Figure 1. Deux serveurs d’agents interconnectés

2.3. Evaluation de la plate-forme De nombreux produits de type MOM sont disponibles aujourd’hui, en particulier pour réaliser l’intégration d’applications patrimoniales [SON02, MAF 97, MSM02]. Ces intergiciels fournissent tous la communication fiable par files de message avec, pour chaque produit, des variantes au niveau de l’architecture (centralisée ou répartie) et des protocoles de communication utilisés. L’intégration avec les applications est mise en œuvre par une interface de programmation (API) dont la plus connue aujourd’hui est l’interface Java Messaging Service(JMS) [JMS02]. De fait, ils interagissent peu avec les composants logiciels – car ils ne fournissent qu’un canal de communication – et leur intégration au sein d’applications existantes est aisée. Ce découplage fort présente néanmoins un inconvénient majeur, dans la mesure où seuls les trans-

258

RSTI - TSI – 23/2004. Composants et adaptabilité

ferts de messages sont fiabilisés. Or aujourd’hui, fiabiliser uniquement les transferts de messages ne suffit pas : il faut aussi fiabiliser le processus de traitement et de transformation de l’information [BAN 99, GEI 01]. L’intergiciel de la plate-forme ScalAgent apporte un début de réponse à cette limitation majeure grâce à un modèle d’objets distribués (les agents) adapté aux communications asynchrones utilisant un MOM. Les traitements effectués par les agents bénéficient des propriétés conjointes de persistance et d’atomicité des traitements, en complément de la garantie de délivrance des messages fournie par le canal de communication. Ce modèle se limite à la communication point à point, ce qui est un peu contradictoire avec l’utilisation croissante du modèle publication-abonnement, surtout pour les applications présentant un niveau de découplage fort [BAN 99]. Pour combler cette lacune, le modèle de communication publication-abonnement conforme à l’interface JMS a été construit au-dessus de cet intergiciel, en utilisant les agents pour programmer la logique induite : filtrage de messages, topic, files de messages, etc.2 Toutefois, notre expérience dans le développement d’applications fortement distribuées [C3D00, SCA02] nous a amené à constater les limites de ce modèle. La programmation « événement/réaction » se rapproche de la programmation de machines à états [TUR 93], dont la complexité lorsque le nombre de processus/objets communicants augmente est reconnue. De plus, lorsque l’environnement est distribué, s’ajoute à la complexité de la programmation, la complexité de l’architecture, du placement et du contrôle du cycle de vie de l’application. Cette complexité se retrouve avec n’importe quel type d’intergiciel dans lequel les objets sont distribués. Ces constatations nous ont amenés à envisager conjointement deux pistes que nous détaillons dans les sections suivantes : – proposer un modèle de composants pour les communications asynchrones fiables, et utiliser, de concert, un formalisme de description des applications dirigé par l’architecture logicielle [SHA 96]. Ceci oblige le programmeur à se concentrer sur la programmation individuelle des composants, alors que l’architecture globale de l’application est prise en compte par un autre formalisme (et éventuellement un autre intervenant), – implanter des outils de gestion du cycle de vie des applications en environnement distribué, en particulier le déploiement automatisé, en exploitant la description de l’architecture.

3. Un modèle de composants pour applications asynchrones 3.1. Motivations – Travaux connexes Il existe aujourd’hui un certain nombre de modèles de composants qui partagent des concepts communs : un composant est un module logiciel autonome pouvant être 2. L’ensemble regroupant l’intergiciel et l’interface JMS (nom de code JORAM) est disponible en open-source sur www.obje tweb.org.

La plate-forme à composants ScalAgent

259

installé sur différentes plates-formes ; il exporte différents attributs, propriétés et méthodes ; en outre, il peut être configuré et doit être capable de s’auto-décrire. Dans la plupart des modèles, il est possible d’associer aux composants certaines propriétés non fonctionnelles (persistance, protection, duplication, etc.) prises en charge par une entité logicielle encapsulant le composant, appelée conteneur. Les modèles actuels souffrent d’un certain nombre de limitations : ils adoptent souvent un modèle de communication client/serveur. Des efforts sont faits pour intégrer les communications asynchrones : c’est le cas des puits et sources d’événements du modèle de composants de Corba (CCM [MER 01]) ou encore des Message Driven Beans du modèle de composants de Sun [EJB02]. Cependant, ces modèles n’ont pas été conçus initialement pour les communications asynchrones et ne fournissent pas toujours la qualité de service nécessaire comme la fiabilité ou l’ordonnancement des messages échangés. De plus, ces modèles ne permettent souvent que des assemblages plats de composants : la notion de composition n’est pas prise en compte. L’utilisation de modèles hiérarchiques présente le double intérêt de faciliter la conception d’application et de faciliter les fonctions d’administration [PAL 01a]. Des efforts sont actuellement faits dans ce sens par les modèles de composants émergents : le modèle Fractal [BRU 02], par exemple, permet de créer des architectures hiérarchiques par composition de composants. Enfin, si la plupart des conteneurs actuels proposent des fonctionnalités évoluées comme la prise en charge des transactions, il reste encore des efforts à faire sur la prise en charge du déploiement et l’administration du cycle de vie des composants.

3.2. Le modèle des SCBeans Le modèle de composants a été conçu pour faciliter la construction d’applications par assemblage. La principale caractéristique des composants est de communiquer exclusivement par envois de messages. De plus, comme dans la plupart des modèles de composants, le composant est constitué de deux parties solidaires : une partie fonctionnelle en charge des fonctions applicatives propres à ce composant, que l’on appellera désormais SCBean, et un conteneur en charge de certains aspects non fonctionnels comme la liaison, l’activation, etc., que l’on appellera SCContainer. Enfin, ce modèle est hiérarchique : une application est représentée par un assemblage hiérarchique de composants. 3.2.1. La partie fonctionnelle ou SCBean Un composant possède des interfaces fonctionnelles, appelées ports. On distingue les ports d’entrée qui sont associés aux services fournis par un SCBean, des ports de sortie qui correspondent aux services requis par le SCBean. Définition d’un port Un port d’entrée (resp. de sortie) est défini par son type qui est composé de :

260

RSTI - TSI – 23/2004. Composants et adaptabilité

– un identifiant qui est un nom représentant le port, – un rle qui spécifie si le port considéré est un port d’entrée ou de sortie, – une signature qui est l’ensemble des types de messages acceptés par le port en réception (resp. émission). Le type d’un message est la classe Java qui l’implante. Liaison de deux ports Un port de sortie peut être relié à un port d’entrée s’il est conforme à ce dernier. Pour ce faire, l’ensemble des types de messages susceptibles d’être émis par le port de sortie doit être un sous-ensemble de l’ensemble des types et sous-types de messages acceptés par le port d’entrée. En pratique, la définition de « sous-type » de messages est mise en œuvre par la notion d’héritage de classes fournie par le langage Java. 3.2.2. La partie contrôle ou SCContainer La partie contrôle d’un SCBean est mise en œuvre par son SCContainer. Celui-ci garantit la persistance du SCBean qu’il encapsule, ainsi que l’atomicité de son exécution. Par ailleurs, le SCContainer met en œuvre des interfaces qui permettent de procéder à des opérations de configuration et d’administration sur le SCBean. L’interface de liaison permet de lier un port de sortie du SCBean au port d’entrée d’un autre SCBean, à condition que les ports soient conformes. Elle fournit aussi le dual de cette fonction de liaison : la rupture de liaison qui permet de rompre une liaison entre deux ports. L’interface de gestion du cycle de vie permet trois actions sur le SCBean : – son initialisation lors du (re)chargement du composant. Ces chargements ont lieu au déploiement du composant, ou lors de reprises après pannes, – son démarrage qui consiste à lancer le démarrage applicatif du composant, – son arrêt qui consiste à arrêter la distribution des messages destinés au SCBean et donc le fonctionnement du SCBean. L’interface de configuration des attributs permet de configurer les attributs du SCBean. Pour ce faire, le SCBean doit fournir des fonctions de modifications de ses attributs ayant la signature suivante : set). 3.2.3. Les composants composites Le modèle de composants est hiérarchique : un assemblage de SCBean peut être manipulé comme un SCBean appelé composite. Un SCBean composite possède une différence majeure par rapport à un SCBean primitif : il ne possède pas de code fonctionnel ; il ne fait qu’exporter certains ports des SCBean qu’il encapsule. Par ailleurs le code de ses interfaces de contrôle est implanté par les outils d’administration et de déploiement présentés au paragraphe 4.

La plate-forme à composants ScalAgent

261

L’intérêt de la composition réside dans le fait qu’elle permet de structurer l’application. En effet, pour lier deux SCBean, le modèle de composants exige que ceux-ci soient encapsulés par un même composite. Par ailleurs, le modèle n’autorise pas le partage de composant : un composant ne peut pas être le fils direct de deux composites. De fait, une application construite en respectant ce modèle sera toujours représentée par une hiérarchie en arbre de composites. Cette hiérarchie est utilisée par les outils d’administration et de déploiement. 3.2.4. Exemple La figure 2 donne l’exemple d’une application suivant le modèle de composants présenté.

Application

partie contrôle interface de contrôle

Client init

init

{Initialisation}

{Initialisation}

Message message_a _envoyer

HelloWorld

partie fonctionnelle port d’entrée

affichage {*}

filtre {*}

port de sortie

filtre {*}

Message

nom du port signature du port attribut du composant

Figure 2. Un exemple d’application suivant le modèle

L’application est représentée par le composite Appli ation. Celui-ci encapsule un composant Client qui a pour rôle d’envoyer des messages au composant HelloWorld. Client possède un attribut qui définit le message qu’il envoie. Celui-ci peut être modifié via son interface de contrôle des attributs. Par ailleurs, il possède un port d’entrée init qui est exporté par le composite Appli ation. Ce port d’entrée n’accepte que les messages du type Initialisation. Sur réception d’un message de ce type, il envoie le message qu’il a en attribut sur son port de sortie affi hage. Ce message est reçu par le port d’entrée filtre du composant HelloWorld. Ce port d’entrée accepte tous les types de message et affiche les messages du type HelloWorld. 3.2.5. Mise en œuvre La mise en œuvre de ce modèle de composants à l’aide d’agents est aisée. Les agents servent à implémenter les SCContainer. Chaque SCContainer encapsule un SCBean. Ce dernier est représenté par un objet Java. A chaque port d’entrée du SCBean est associée une méthode de l’objet qui est appelée par le SCContainer quand un message arrive. Par ailleurs, le SCBean accède à ses ports de sortie via l’interface de contrôle de liaison mise en œuvre par le SCContainer. Enfin, l’objet implémentant le SCBean doit fournir les méthodes utilisées par les interfaces de contrôle du SCContainer : méthodes d’initialisation, d’activation, d’arrêt, etc.

262

RSTI - TSI – 23/2004. Composants et adaptabilité

En pratique, la plate-forme fournit des classes de base de SCContainers. Le développeur de l’application doit donc uniquement développer les classes des SCBeans. Mais il est aussi libre de développer d’autres classes de SCContainers s’il veut des fonctionnalités évoluées. 3.2.6. Un support pour la description d’architectures Pour manipuler le modèle de composants, nous proposons d’utiliser un langage de description d’architectures (ADL). Notre objectif est de construire une application par assemblage de composants. En ce sens, l’utilisation d’un ADL est un pas vers la réutilisation de composants et la « programmation à gros grain » [DER 76]. L’ADL proposé [BEL 00] sert à décrire les différents composants de l’application et à donner des informations sur sa configuration initiale, c’est-à-dire les composants à déployer et la valeur de leurs attributs. Chaque composant est associé à une description. Dans le cas d’un SCBean primitif, on donne la description de ses interfaces fonctionnelles, de ses attributs et de sa mise en œuvre (classe Java du SCBean et du SCContainer). Concernant les SCBean composites, on décrit l’architecture interne du composite, c’est-à-dire l’ensemble des composants encapsulés, leur localisation et leurs interconnexions.

Composant Client {

| Composite Appli ation { | *** Attributs *** | *** Interfa es fon tionnelles *** Message message_a_envoyer; | Port entree { | nom = init ; *** Interfa es fon tionnelles *** | signature = Initialisation ; Port entree { | } nom = init ; | signature = Initialisation ; | *** Composants en apsulés *** } | Client lient = | new Client(zir onium.inrialpes.fr) ; Port sortie { | nom = affi hage ; | HelloWorld helloWorld = signature = * ; | new HelloWorld(strontium.inrialpes.fr) ; } | | *** Liaisons *** *** Mise en oeuvre *** | this.init => lient.init ; SCBean = fr.ClientBean ; | lient.affi hage => helloWorld.filtre ; SCContainer = fr.ClientContainer ; | } | }

Figure 3. La description du composant Client et du composite Appli ation La figure 3 donne deux exemples de description de composants. Celle du SCBean primitif Client spécifie son attribut, ses interfaces fonctionnelles et sa mise en œuvre. La description du composite Appli ation spécifie les interfaces fonctionnelles du composite. De plus, les composants encapsulés sont indiqués avec en paramètre le site de leur déploiement. Enfin, les liaisons entre composants sont spécifiées à l’aide du symbole =>.

La plate-forme à composants ScalAgent

263

4. Outils de la plate-forme 4.1. Motivations – Travaux connexes Le modèle de composants et l’ADL associé ont été conçus pour permettre l’utilisation d’outils facilitant les différentes activités du cycle de vie d’une application. Il existe aujourd’hui deux grandes catégories d’ADL qui diffèrent par l’exploitation qu’elles font de la description d’une application : – génération d’un exécutable : c’est le cas d’ADL comme UniCon [SHA 95], Olan [BEL 00], Aster [ISS 98] ou C2 [MED 99] qui utilisent la description de l’application pour générer une partie du code des composants ; – analyse du système : c’est le cas d’ADL tels que Rapide [LUC 95] ou Wright [ALL 97] qui permettent au développeur de l’application de spécifier le comportement dynamique des différentes entités du système. Ces ADL utilisent la description de l’application pour modéliser et analyser les scénarios envisageables. On peut faire plusieurs reproches aux ADL existants : d’une part, aucun ADL ne propose de déployer une application à partir de sa description. En effet, dans le meilleur des cas, les ADL fournissent une aide à la génération de code de composants, mais ne prennent en charge ni l’installation de ce code sur les différents sites, ni l’interconnexion des composants, ou encore l’activation de l’application. Une autre lacune des ADL existants est qu’ils ne fournissent pas d’aide à la configuration d’une application. Les applications distribuées s’exécutent dans des environnements souvent hétérogènes, et exigent, de fait, un certain nombre de propriétés dites « non fonctionnelles ». Ces propriétés sont aussi bien associées aux composants (persistance, transaction, etc.), qu’aux connecteurs (sécurité, fiabilité, ordonnancement, etc.). Elles sont fournies par l’intergiciel en charge de l’exécution des composants et de leurs communications. La configuration de cet intergiciel est souvent complexe et à la charge du développeur de l’application. Enfin, un dernier reproche que l’on peut formuler est le manque de prise en charge des aspects dynamiques dans les ADL : aucun support n’est fourni pour la reconfiguration dynamique des applications. Nous avons construit des outils visant à combler ces manques. Nous nous focalisons, dans cet article, sur l’outil de déploiement. Le lecteur intéressé trouvera une description de l’outil de reconfiguration dynamique dans [PAL 01b], et une description de l’outil de configuration de l’intergiciel dans [QUE 02].

4.2. Un outil de déploiement asynchrone hiérarchique L’outil de déploiement exploite la description ADL de l’application pour instancier et déployer les différents SCContainer (et SCBean associés) sur les serveurs d’agents, et réaliser les interconnexions entre SCBean. L’objectif de cet outil de déploiement est (1) d’exploiter la description ADL pour faciliter la prise en compte des contraintes fonctionnelles de l’application à déployer, et (2) d’exploiter la structure hiérarchique

264

RSTI - TSI – 23/2004. Composants et adaptabilité

de l’application à déployer pour distribuer l’intelligence de déploiement. Pour ce faire, l’outil de déploiement met en œuvre un dispositif de type workflow décomposé en activités. Les activités s’exécutent parallèlement ou séquentiellement. Elles sont responsables des différents aspects du déploiement : instanciation, liaison, activation, etc. Ces activités s’exécutent au sein d’entités hiérarchiquement organisées appelées contrôleur de déploiement. Les contrôleurs sont organisés en arbre ; leur hiérarchie est calquée sur celle de l’application : chaque composant composite est associé à un contrôleur. 4.2.1. Architecture d’un contrôleur Principe de fonctionnement Comme on peut le voir sur la figure 4, à l’exception du contrôleur racine, le fonctionnement d’un contrôleur est initié par son contrôleur père. Une session de communication est alors établie entre les deux contrôleurs. A l’ouverture de cette session, une activité est créée au sein du contrôleur pour effectuer les opérations de déploiement.

Contrôleur père

Ouverture de session Opération de contrôle

Acquittement Evénement de contrôle

Contrôleur

Activités

Mise à jour Interrogation Abonnement

Référentiel Evénement

Ouverture de session Opération de contrôle

Acquittement Evénement de contrôle

Contrôleur fils Fabrique de composants Fabrique de liaisons

Figure 4. Architecture d’un contrôleur

Les résultats des opérations effectuées par un contrôleur sont stockés dans un référentiel d’architecture. Suite à certaines mises à jour, le référentiel émet des événements à destination des activités qui y réagissent en effectuant de nouvelles opérations ou en donnant naissance à d’autres activités.

La plate-forme à composants ScalAgent

265

Les activités Une activité est composée de sous-activités, appelées activités primitives, s’exécutant parallèlement ou séquentiellement. On distingue trois activités primitives : – les activités de création dont le rôle est de créer les SCContainer. Le code de ces activités dépend du type de composant à instancier : dans le cas d’un composant composite, l’activité de création crée le contrôleur associé au composite et ouvre une session en donnant la description ADL du composite. Cette session est utilisée par les autres activités pour envoyer des ordres de contrôle. Dans le cas d’un composant primitif, l’activité crée et déploie l’agent représentant le SCContainer. Dans tous les cas, il résulte de cette activité la mise à jour du référentiel maintenu par le contrôleur. Cette mise à jour sert à stocker une référence vers le SCBean créé ainsi que vers ses interfaces. Dans le cas des composites, les références d’interfaces enregistrées dans le référentiel sont celles des composants encapsulés ; – les activités de liaison dont le rôle est de créer une liaison entre composants. Cette activité crée la liaison en utilisant le contrôleur de liaison du SCBean à lier ; – les activités d’activation dont le rôle est d’activer un SCBean par un appel de méthode sur son interface de contrôle d’activation. Dans le cas d’un composite, cette activité utilise la session créée par l’activité de création pour transmettre l’ordre d’activation au contrôleur fils responsable du composite. A l’issue de cette activité, la session avec le contrôleur père est fermée.

Organisation des activités Les différentes activités ayant lieu au sein d’un contrôleur s’exécutent de façon indépendante. Elles se synchronisent par l’intermédiaire des événements générés par le référentiel suite à ses mises à jour. Les activités peuvent s’exécuter parallèlement ou séquentiellement suivant leur type et les composants sur lesquels elles œuvrent. Ainsi, toutes les activités de création s’exécutent parallèlement. En revanche, une activité de liaison s’exécute après que les activités de création des deux composants à lier ont mis à jour le référentiel. De plus, une activité d’activation d’un composant s’exécute après que les ports de sortie du composant ont été liés. Cette organisation des activités garantit une activation « au plus tôt » des différents composants. Ce ne serait pas le cas si on exécutait séquentiellement les activités de création, puis les activités de liaison et enfin les activités d’activation.

Mise en œuvre Les contrôleurs, les activités, ainsi que les référentiels sont implémentés à l’aide d’agents. Lors d’une ouverture de session, l’agent contrôleur destinataire de la session est créé et déployé. Cet agent contrôleur déploie l’agent responsable du référentiel et utilise la description ADL pour déployer les agents responsables des différentes activités : une activité de création et d’activation par composant encapsulé, ainsi qu’une activité par liaison à établir.

266

RSTI - TSI – 23/2004. Composants et adaptabilité

4.2.2. Traitement des pannes L’application de déploiement présentée peut être sujette à des pannes. Dans cette section, nous montrons comment ces pannes sont détectées et traitées. Il est important de noter que nous ne traitons que les pannes franches.

Détection des pannes Deux types de pannes peuvent se produire : soit une activité se bloque – par exemple, elle ne parvient pas à créer un composant –, soit une machine tombe en panne. Dans ce cas, les activités qui dialoguent avec cette machine sont bloquées. De fait, mis à part le cas des pannes du contrôleur racine, tous les autres cas de pannes entraînent le blocage d’une ou plusieurs activités. Pour détecter ces pannes, deux stratégies sont envisageables. La première consiste à borner les temps d’exécution des différentes activités et à propager des messages d’erreur dès lors qu’une activité ne s’est pas terminée dans le délai qui lui était imparti. Cette méthode n’est pas viable pour déployer des applications à grande échelle. La stratégie adoptée est qualifiée d’« optimiste » : aucun message d’erreur n’est propagé. En revanche, chaque contrôleur héberge une activité supplémentaire, appelée activité d’observation dont le rôle est d’observer la progression des activités ayant lieu au sein du contrôleur. Cette activité réagit aux événements produits par le référentiel d’architecture, les filtre et transmet les événements importants au contrôleur père. Les activités d’observation permettent d’avoir, au niveau du contrôleur racine, une connaissance détaillée de l’état du déploiement. L’initiateur du déploiement utilise cette connaissance pour détecter les éventuels blocages et y réagir.

Traitement des pannes Les pannes sont traitées en deux étapes : dans un premier temps, arrêt de tout ou partie du déploiement, puis, dans un second temps, nouvel essai de déploiement. Entre ces deux étapes, il peut y avoir une intervention humaine pour redémarrer un site, modifier la description ADL, etc. Notons que les parties de l’application qui avaient déjà été activées poursuivent leur exécution. Stopper une partie de l’application de déploiement se fait en stoppant un certain nombre de contrôleurs. Pour ce faire, une session ouverte entre un contrôleur et son contrôleur père peut recevoir un ordre d’interruption qui a pour effet de stopper les activités du contrôleur fils associé à la session. Pour procéder à un nouveau déploiement, il faut ouvrir une nouvelle session vers le contrôleur racine et donner un ordre retry avec la nouvelle description ADL. Des sessions retry sont ouvertes vers les contrôleurs fils. Les activités stoppées sont redémarrées (parfois recréées). Elles utilisent le référentiel pour déterminer les actions qu’il reste à effectuer.

La plate-forme à composants ScalAgent

267

4.2.3. Mesures expérimentales Des mesures de performance ont été réalisées afin de valider cette application de déploiement. Elles ont été réalisées sur une grappe de 216 PC linux équipés de processeur Intel Pentium III à 733 MHz, avec 256 Mo de mémoire RAM. Les tests ont consisté à déployer des applications construites suivant le schéma représenté sur la figure 5. Chaque application a une hiérarchie arborescente à trois niveaux : un site central relié à n composants composites, chacun encapsulant un composant régional relié à m composants locaux. Chaque composite local encapsule 10 composants primitifs. Chaque composite régional encapsule 10 composants primitifs ainsi que des composites locaux. Les expériences réalisées évaluent le temps moyen de terminaison du déploiement. La complétion consiste à recevoir, sur le site central, les indicateurs de terminaison du déploiement. Nous avons fait varier plusieurs paramètres : – le nombre de machines physiques sur lesquelles le déploiement est réalisé ; – le nombre de composites locaux. Il faut noter que chaque composite local est exécuté au sein d’un serveur d’agents. Un serveur d’agents est un processus Java. Plus une machine héberge de serveurs d’agents, plus la puissance requise est importante. Dans les applications réelles, on privilégie un petit nombre de serveurs d’agents par machine, et plusieurs composants par serveur ; – le nombre de composites régionaux. Notons qu’une augmentation du nombre de composites régionaux permet de faire diminuer le nombre de composites locaux encapsulés dans chaque composite régional. Ceci engendre une parallélisation des opérations de déploiement.

Figure 5. Architecture de l’application de test du déploiement

268

RSTI - TSI – 23/2004. Composants et adaptabilité

Impact de la distribution

Temps de completion du deploiement (s)

Pour évaluer l’impact de la distribution, nous maintenons un nombre constant de composites régionaux et locaux (m = 10 et n = 100) et nous faisons varier le nombre de machines sur lesquelles l’application est déployée (de 20 à 111). Ceci correspond à l’hébergement de 110 serveurs d’agents, avec approximativement 10 composants par serveurs. Les résultats obtenus sont présentés dans la figure 6. L’augmentation du nombre de machine permet de réduire le nombre de serveurs d’agents hébergés par chaque machine. Cela diminue la charge des machines et améliore les performances du déploiement (entre 20 et 30 machines). En revanche, lorsque le nombre de machine est trop important, les communications entre serveurs d’agents sont moins efficaces (car entre machines distantes), et le temps de déploiement augmente. 60 58 56 54 52 50 48 46 44 42 0

20

40

60

80

100

120

Nombre de machines

Figure 6. Impact de la décentralisation sur le temps de déploiement

Effet de l’architecture hiérarchique de l’application Ce test a pour but d’évaluer l’impact de la hiérarchie de composites au sein de l’application. Rappelons que l’application est un composite contenant m composites régionaux, chacun contenant outre des composants primitifs, n/m composites locaux. La figure 7 montre que, pour des nombres fixes de machines (= 60) et de composants locaux (n = 500), le temps de déploiement atteint un minimum pour m = 10 (ou le rapport n/m = 50). Ceci s’explique par la conception du service de déploiement qui associe à chaque composite un contrôleur en charge de déployer ses souscomposants. Plus le nombre de contrôleurs créés est important, plus le déploiement est parallélisé. Lorsque le déploiement est trop parallélisé, le travail de consolidation du contrôleur de niveau supérieur (ici du site central) est important et peut pénaliser les performances. Cette mesure montre ainsi que le découpage hiérarchique de l’architecture d’une application a une incidence sur les performances de déploiement et ouvre la voie vers des outils d’aide à l’architecture d’une application.

Temps de completion du deploiement (s)

La plate-forme à composants ScalAgent

269

225 220 215 210 205 200 195 190 0

5

10

15

20

25

30

35

40

Nombre de composites regionaux

Figure 7. Evaluation de l’architecture de l’application sur le déploiement

Test de passage à l’échelle

Temps de completion du deploiement (s)

Ce test est le plus important. Son rôle est de vérifier que l’augmentation proportionnelle des paramètres (n, m et le nombre de machines) ne perturbe pas les performances du déploiement. La figure 8 montre que le temps de déploiement reste linéaire, avec des paramètres variant ainsi : n = 10 à 450, m = 1 à 45, machines = 3 à 91.

200

150

100

50

0 0

10

20

30

40

50

60

70

80

90

Nombre de machines

Figure 8. Evaluation du passage à l’échelle de l’application de déploiement

4.2.4. Evaluation de l’outil de déploiement Cet outil de déploiement présente trois caractéristiques intéressantes. D’une part, il n’y a pas de contrôle centralisé du déploiement : l’application de déploiement est hiérarchisée en accord avec la structure de l’application à déployer. Cette hiérarchisation permet d’éviter la création de goulot d’étranglement et facilite le passage à l’échelle

270

RSTI - TSI – 23/2004. Composants et adaptabilité

de l’outil. Par ailleurs, l’exécution parallèle des différentes activités garantit une activation au plus tôt de l’ensemble des SCBeans déployés. En effet, chaque activité ne se synchronise (via le référentiel d’architecture) qu’avec les activités dont elle dépend. Enfin, l’utilisation de la plate-forme ScalAgent facilite la gestion des pannes. En effet, celle-ci permet l’exécution atomique des différentes composantes de l’outil, ce qui garantit la cohérence de l’état des différents sites de déploiement. A notre connaissance, aucune solution proposée à l’heure actuelle ne présente ces trois caractéristiques. Des travaux ont été menés sur le modèle de composants SOFA [KAL 02]. Comme dans l’approche que nous proposons, les concepteurs utilisent un ADL pour déployer l’application. Néanmoins, ce déploiement est centralisé et ne tire pas profit de la structure hiérarchique de l’application : un serveur centralise la connaissance et propage les ordres de création et de liaison. Les chercheurs de l’université du Colorado ont proposé un système de reconfiguration dans le modèle de composants EJB [RUT 02]. Ils proposent BARK (Bean Automatic Reconfiguration FrameworK) qui est un système de gestion du cycle de vie des EJB. Le déploiement distribué des EJB n’est pas prévu dans la spécification du modèle : seule l’installation sur un site à l’aide d’un fichier .jar est prévue. BARK propose de lever cette limitation. Il est constitué d’un ensemble de modules logiciels installés au niveau de chaque serveur d’EJB. Ces modules partagent un répertoire et sont contrôlés par une machine centrale qui détermine les scripts de commandes à effectuer. La démarche proposée rejoint la nôtre du fait que BARK permet d’exhiber les liaisons entre EJB. Il peut ainsi être considéré comme un langage d’assemblage d’EJB. Cependant, les différentes commandes sont centralisées et synchrones. Il est aussi important de mentionner les travaux menés par Hall et al. sur le déploiement de logiciel [HAL 99]. Le système est composé d’un ensemble de serveurs, appelés docks. Ces docks sont utilisés par un ensemble d’agents qui sont des programmes exécutables en charge d’une tâche de déploiement spécifique. Les agents peuvent migrer d’un dock à un autre et communiquent via un système de propagation d’événements. Un point intéressant de ces travaux est l’utilisation de communications asynchrones et d’agents. Cependant, ce système est dédié au déploiement de logiciel et non d’applications à base de composants. Il n’y a pas de déploiement hiérarchique ; de plus, il ne permet pas l’activation anticipée de certaines parties du logiciel. Enfin, aucune précision n’est donnée sur la tolérance aux fautes : contrairement à notre proposition, les agents ne s’exécutent pas de façon atomique. Enfin, citons les travaux menés sur le déploiement d’applications sur Grilles. [BAU 02] propose un modèle de programmation distribué à base d’objets actifs : ProActive. Afin d’ôter du code des objets toute référence vers une machine précise, un répertoire, etc., les concepteurs proposent de référencer dans le code des structures virtuelles. L’association entre structures virtuelles et structures réelles est fait par l’intermédiaire de descripteurs XML. Comme dans l’approche que nous proposons, l’utilisation d’un fichier de description permet de séparer code fonctionnel et code de déploiement. Néanmoins, nous ne visons pas le même type de déploiement : ce système sert à déployer des entités de bas niveau comme des machines virtuelles

La plate-forme à composants ScalAgent

271

Java. Nous proposons de déployer des applications à composants utilisant ces machines virtuelles.

5. Conclusion Aujourd’hui, les développeurs sont confrontés au problème de la construction d’applications réparties dans un environnement faiblement couplé à grande échelle. Les intergiciels à messages sont bien adaptés à cette classe d’application. Cependant, la construction, la configuration et le déploiement de telles applications restent des tâches très difficiles du fait de nombreux facteurs : dispersion géographique, nombre important d’entités impliquées dans une application, hétérogénéité des plates-formes, fiabilité, sécurité, etc. L’infrastructure ScalAgent facilite ces tâches en proposant un ensemble d’outils basés, à la fois sur un intergiciel orienté messages et sur une approche orientée composants de la construction des applications. L’intergiciel permet la mise en œuvre d’un modèle de programmation distribué à base d’agents. Il garantit, en outre, des propriétés importantes pour la construction d’applications réparties à grande échelle : fiabilité, ordonnancement, atomicité, etc. Outre les propriétés offertes, cet intergiciel se distingue des autres MOM par le fait qu’il intègre les composants applicatifs et ne se contente pas de fournir une API de communication. Cette intégration de la partie applicative et de l’intergiciel est renforcée par l’élaboration d’un modèle de composants hiérarchique dédié aux applications asynchrones, et par l’utilisation d’un langage de description d’architectures. Les ADL sont utilisés pour permettre une structuration des applications et le développement d’outils facilitant la gestion du cycle de vie d’une application. Nous avons présenté un outil de déploiement permettant d’instancier, de lier et d’activer les composants intervenant dans une application. Cet article montre que cet outil présente le triple avantage d’être asynchrone, hiérarchique et fiable. La technologie qui est à l’origine de la plate-forme présentée dans ce papier a été conçue initalement dans le cadre du GIE Dyade (GIE entre l’INRIA et Bull). La plate-forme est aujourd’hui industrialisée par une jeune société ScalAgent Distributed Technologies, fondée par des membres de l’équipe initiale. Les usages de cette plateforme sont multiples. On citera plus particulièrement la collecte de données d’usage pour la facturation Telecom, la télésurveillance d’équipements de distribution électriques, l’analyse de logs de sécurité dans un réseau privé virtuel.

Remerciements Les auteurs tiennent à remercier les membres du projet Sardes et de la société ScalAgent qui ont contribué à ce travail. Ils tiennent également à remercier Sacha Krakowiak et Jacques Mossière pour leurs précieux commentaires sur cet article.

272

RSTI - TSI – 23/2004. Composants et adaptabilité

6. Bibliographie

[AGH 86] AGHA G. A., Actors : A Model of Concurrent Computation in Distributed Systems, Cambridge, MA, 1986. [ALL 97] A LLEN R., G ARLAN D., D OUENCE R., « Specifying Dynamism in Software Architectures », Proceedings of the Workshop on Foundations of Component-Based Software Engineering, Zurich, Switzerland, September 1997. [BAN 99] BANAVAR G., C HANDRA T., S TROM R., S TURMAN D., « A Case for Message Oriented Middleware », Lecture Notes in Computer Science, vol. 1693, Bratislava, Slovak Republic, September 1999, Distributed Computing 13th International Symposium, p. 1-18. [BAU 02] BAUDE F., C AROMEL D., H UET F., M ESTRE L., VAYSSIÈRE J., « Interactive and Descriptor-based Deployment of Object-Oriented Grid Applications », Proceedings of the 11th International Symposium on High Performance Distributed Computing (HPDC’02), Edinburgh, Scottland, July 2002, p. 93-102. [BEL 99] B ELLISSARD L., DE PALMA N., F REYSSINET A., H ERRMANN M., L ACOURTE S., « An Agent Plateform for Reliable Asynchronous Distributed Programming », Symposium on Reliable Distributed Systems (SRDS’99), Lausanne, Switzerland, October 1999. [BEL 00] B ELLISSARD L., DE PALMA N., F ÉLIOT D., « The Olan Architecture Definition Language », rapport no 24, 2000, C3DS. [BRU 02] B RUNETON E., C OUPAYE T., S TEFANI J.-B., « Recursive and Dynamic Software Composition with Sharing », Proceedings of the 7th ECOOP International Workshop on Component-Oriented Programming (WCOP’02), Malaga, Spain, June 10th-14th 2002. [BUC 03] B UCHMANN A., « Event-Based Middleware », IEEE Distributed Systems Online, , 2003. [C3D00] « C3DS project, Control and Coordination of Complex Distributed Services », 2000, http ://www.newcastle.research.ec.org/c3ds/. [CAR 01] C ARZANIGA A., ROSENBLUM D., W OLF A., « Design and Evaluation of a WideArea Event Notification Service », ACM Transactions on Computer Systems, vol. 19, no 3, 2001, p. 332-383. [DER 76] D E R EMER F., K RON H., « Programming in-the-Large Versus Programming in-theSmall », IEEE Transactions on Software Engineering, vol. 2, no 2, 1976, p. 80-86. [EJB02] « Enterprise JavaBeansTM Specification, Version 2.1 », August 2002, Sun Microsystems, http ://java.sun. om/produ ts/ejb/. [GEI 01] G EIHS K., « Middleware Challenges Ahead », IEEE Computer Magazine, vol. 6, no 34, 2001. [HAL 99] H ALL R., H EIMBIGNER D., W OLF A., « A Cooperative Approach to Support Software Deployment Using the Software Dock », Proceedings of the 21st International Conference on Software Engineering (ICSE’99), Los Angeles, CA, May 1999, p. 174-183. [ISS 98] I SSARNY V., B IDAN C., S ARIDAKIS T., « Achieving Middleware Customization in a Configuration-Based Development Environment : Experience with the Aster Prototype », Proceedings of the 4th International Conference on Configurable Distributed Systems, Annapolis, Maryland, USA, May 1998, p. 207-214. [JMS02] « Java Message Service Specification Final Release 1.1 », March 2002, Sun Microsystems, http ://java.sun.com/products/jms/docs.html.

La plate-forme à composants ScalAgent

273

[KAL 02] K ALIBERA T., T UMA P., « Distributed Component System Based On Architecture Description : the SOFA Experience », Proceedings of the 4th International Symposium on Distributed Objects and Applications (DOA’02), Irvine, CA, October 2002. [LUC 95] L UCKHAM D. C., K ENNEY J. J., AUGUSTIN L. M., V ERA J., B RYAN D., M ANN W., « Specification and Analysis of System Architecture Using Rapide », IEEE Transactions on Software Engineering, Special Issue on Software Architecture, vol. 21, no 4, 1995, p. 336-355. [MAF 97] M AFFEIS S., « iBus : The Java Intranet Software Bus », rapport, February 1997, Softwired A.G. [MAG 89] M AGEE J., K RAMER J., S LOMAN M., « Constructing Distributed Systems in Conic », IEEE Transactions on Software Engineering, vol. 15, no 6, 1989, IEEE Computer Society. [MAG 93] M AGEE J., D ULAY N., K RAMER J., « Structuring Parallel and Distributed Programs », IEE Software Engineering Journal, vol. 8, no 2, 1993, p. 73-82. [MED 99] M EDVIDOVIC N., ROSENBLUM D. S., TAYLOR R. N., « A Language and Environment for Architecture-Based Software Development and Evolution », Proceedings of the 21st International Conference on Software Engineering (ICSE’99), 1999, p. 44-53. [MER 01] M ERLE P., Ed., CORBA 3.0 New Components Chapters, OMG TC Document ptc/2001-11-03, November 2001. [MSM02] « Microsoft Message Queuing (MSMQ) », 2002, Microsoft, http ://www.microsoft.com/msmq/. [PAL 00] DE PALMA N., B ELLISSARD L., F ÉLIOT D., F REYSSINET A., H ERRMANN M., L ACOURTE S., « The AAA Agent-Based Message Oriented Middleware », rapport no 30, 2000, C3DS. [PAL 01a] DE PALMA N., « Service d’Administration d’Applications Réparties », PhD thesis, UJF - Grenoble, 2001. [PAL 01b] DE PALMA N., L AUMAY P., B ELLISSARD L., « Ensuring Dynamic Reconfiguration Consistency », The Sixth International Workshop on Component-Oriented Programming (WCOP’01), in association with ECOOP, Budapest, June 2001. [QUE 02] Q UEMA V., B ELLISSARD L., « Configuration de Middleware Dirigée par les Applications », Actes des Journées sur les Systèmes à Composants Adaptables et Extensibles, Grenoble, France, 17-18 octobre 2002. [RIV 02] R IVEILL M., « Programmation par Composition et Déploiement d’Applications Réparties », l’Objet, numéro spécial sur la coopération dans les systèmes à objets, vol. 8, no 3, 2002, p. 91-107. [RUT 02] RUTHERFORD M., A NDERSON K., C ARZANIGA A., H EIMBIGNER D., W OLF A., « Reconfiguration in the Enterprise JavaBean Component Model », Proceedings of the IFIP/ACM Working Conference on Component Deployment (CD’02), Berlin, Germany, June 2002, p. 67-81. [SCA02] « Remote Supervision of Power Supply Devices », 2002, ScalAgent Distributed Technologies, White Paper, http ://www.scalagent.com. [SHA 95] S HAW M., D E L INE R., K LEIN D. V., ROSS T. L., YOUNG D. M., Z ELESNIK G., « Abstractions for Software Architecture and Tools to Support Them », Software Engineering, vol. 21, no 4, 1995, p. 314-335.

274

RSTI - TSI – 23/2004. Composants et adaptabilité

[SHA 96] S HAW M., G ARLAN D., Software Architecture : Perspectives on an Emerging Discipline, Prentice Hall, 1996. [SON02] « sonicMQ », 2002, Sonic software, http ://www.sonicsoftware.com/. [STR 98] S TROM R., BANAVAR G., C HANDRA T., K APLAN M., M ILLER K., M UKHER JEE B., S TURMAN D., WARD M., « Gryphon : An Information Flow Based Approach to Message Brokering », International Symposium on Software Reliability Engineering (ISSRE’98), fast abstract, Paderborn, Germany, November 1998. [TUR 93] T URNER K., Using Formal Description Techniques - An Introduction to Estelle, LOTOS and SDL, Wiley, 1993.

Vivien Quéma a obtenu un diplôme d’ingénieur en télécommunications de l’INP Grenoble en 2002. Actuellement en thèse à l’INP Grenoble, il mène ses travaux de recherche dans le projet SARDES (INRIA, LSR-IMAG). Ses recherches portent sur les intergiciels réflexifs, le déploiement d’applications réparties, et la gestion de ressources dans les systèmes à composants. Roland Balter a obtenu un diplôme d’ingénieur de l’ENSIMAG en 1970, et un doctorat d’état en informatique de l’Université Joseph Fourier (Grenoble 1) en 1985. Après avoir occupé divers postes dans la société Bull, il devient professeur à l’Université Joseph Fourier en 1993. Depuis 2002, il est directeur scientifique de la société ScalAgent Distributed Technologies. Luc Bellissard a obtenu un diplôme d’ingénieur de l’ENSIMAG en 1993, et un doctorat en informatique de l’INP Grenoble en 1997. Maître de conférences à l’INP Grenoble depuis 1998, ses recherches portent sur les intergiciels et les architectures logicielles distribuées. Depuis 2002, il est directeur produits et services de la société ScalAgent Distributed Technologies. David Féliot a obtenu un diplôme d’ingénieur de l’ENSIMAG en 1998. Il est actuellement en charge des projets de recherche et développement au sein de la société ScalAgent Distributed Technologies. Il était auparavant ingénieur dans la société Bull et à l’INRIA où il a travaillé sur les intergiciels asynchrones et les architectures logicielles à composants. André Freyssinet a obtenu un doctorat en informatique de l’Université Joseph Fourier (Grenoble 1) en 1991. Il a occupé différentes fonctions de développement et d’expertise technique au sein de la société Bull, dans le domaine des systèmes d’exploitation et des intergiciels. Depuis septembre 2002, il est directeur technique de la société ScalAgent Distributed Technologies. Serge Lacourte a obtenu un diplôme d’ingénieur de l’Ecole Polytechnique en 1987, et un doctorat en informatique de l’Université Joseph Fourier (Grenoble 1) en 1991. Après avoir occupé divers postes au sein du département Recherche et Développement de Bull, il devient PDG de la société ScalAgent Distributed Technologies en décembre 2001.

Article reçu le 2 décembre 2002 Version révisée le 16 juin 2003 Rédacteur responsable : Michel Riveill