ScalAgent, une plate-forme à composants pour applications asynchrones

Transcription

1 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 Saint-Ismier cedex Vivien.Quema@inrialpes.fr 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

2 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 agents 1. Les agents sont des objets Java distribués qui ont un modèle d exécution de type événement-réaction. L ato- 1. 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].

3 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

4 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 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 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

5 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 Agent Agent Agent Agent Composant réseau 1 Bus local Canal Composant Composant réseau 2 réseau 3 Bus local Composant réseau 1 Canal Composant réseau 2 Bus à messages global 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-

6 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ûûûºó ØÛ ºÓÖ.

7 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 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 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 :

8 260 RSTI - TSI 23/2004. Composants et adaptabilité est un nom représentant le port, est un ÒØ ÒØqui unöð qui spécifie une Ò ØÙÖ qui si le port considéré est un port d entrée ou de sortie, 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 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 г ØØÖ ÙØ µ 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.

9 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 Exemple La figure 2 donne l exemple d une application suivant le modèle de composants présenté. Application Client Message init init message_a _envoyer affichage filtre {Initialisation} {Initialisation} {*} {*} HelloWorld filtre {*} Message partie contrôle interface de contrôle partie fonctionnelle port d entrée port de sortie 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 ÔÔÐ Ø ÓÒ. Celui-ci encapsule un composant Ð ÒØqui a pour rôle d envoyer des messages au composant À ÐÐÓÏÓÖÐ. Ð ÒØ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 Ò Øqui est exporté par le composite ÔÔÐ Ø ÓÒ. Ce port d entrée n accepte que les messages du typeáò Ø Ð Ø ÓÒ. Sur réception d un message de ce type, il envoie le message qu il a en attribut sur son port de sortie. Ce message est reçu par le port d entrée ÐØÖ du composantà ÐÐÓÏÓÖÐ. Ce port d entrée accepte tous les types de message et affiche les messages du type HelloWorld 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 SC- Bean 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.

10 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 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. ÒÓÑ Ò Ø Ò ØÙÖ ÁÒ Ø Ð Ø ÓÒ Ð ÓÑÔÓ ÒØ Ò Ô ÙÐ Ð ÒØÐ ÒØ Ò ØÙÖ ÁÒ Ø Ð Ø ÓÒ ÐÈÓÖØ ÓÖØ ß Å ÒÓ ÙÚÖ ÒÓÑ Ò ØÙÖ À ÐÐÓÏÓÖÐ ÐÐÓÏÓÖÐ Ø º Ò Ø Ð Òغ Ò Ø Ä ÓÒ Ò ÛÀ ÐÐÓÏÓÖÐ ØÖÓÒØ ÙѺ ÒÖ ÐÔ º Öµ Ò Û Ð ÒØ Þ ÖÓÒ ÙѺ ÒÖ ÐÔ º Öµ ÐË ÓÒØ Ò Ö Öº Ð ÒØ ÓÒØ Ò Ö Ë Ò Öº Ð ÒØ Ò Ð Òغ ÐÐÓÏÓÖÐ º ÐØÖ Ð composite ÔÔÐ Ø ÓÒ Figure 3. La description du composant Ð ÒØet du La figure 3 donne deux exemples de description de composants. Celle du SCBean primitif Ð ÒØspécifie son attribut, ses interfaces fonctionnelles et sa mise en œuvre. La description du composite ÔÔÐ Ø ÓÒ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.

11 La plate-forme à composants ScalAgent 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] 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

12 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 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 Evénement Référentiel 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.

13 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.

14 266 RSTI - TSI 23/2004. Composants et adaptabilité 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.

15 La plate-forme à composants ScalAgent 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

16 268 RSTI - TSI 23/2004. Composants et adaptabilité Impact de la distribution 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. Temps de completion du deploiement (s) 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.

17 La plate-forme à composants ScalAgent 269 Temps de completion du deploiement (s) Nombre de composites regionaux Figure 7. Evaluation de l architecture de l application sur le déploiement Test de passage à l échelle 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. Temps de completion du deploiement (s) Nombre de machines Figure 8. Evaluation du passage à l échelle de l application de déploiement 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

18 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

19 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.

20 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, [ALL 97] ALLEN R., GARLAN D., DOUENCE R., «Specifying Dynamism in Software Architectures», Proceedings of the Workshop on Foundations of Component-Based Software Engineering, Zurich, Switzerland, September [BAN 99] BANAVAR G., CHANDRA T., STROM R., STURMAN 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 [BAU 02] BAUDE F., CAROMEL D., HUET F., MESTRE 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 [BEL 99] BELLISSARD L., DE PALMA N., FREYSSINET A., HERRMANN M., LACOURTE S., «An Agent Plateform for Reliable Asynchronous Distributed Programming», Symposium on Reliable Distributed Systems (SRDS 99), Lausanne, Switzerland, October [BEL 00] BELLISSARD L., DE PALMA N., FÉLIOT D., «The Olan Architecture Definition Language», rapport n o 24, 2000, C3DS. [BRU 02] BRUNETON E., COUPAYE T., STEFANI 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 [BUC 03] BUCHMANN A., «Event-Based Middleware», IEEE Distributed Systems Online,, [C3D00] «C3DS project, Control and Coordination of Complex Distributed Services», 2000, http :// [CAR 01] CARZANIGA A., ROSENBLUM D., WOLF A., «Design and Evaluation of a Wide- Area Event Notification Service», ACM Transactions on Computer Systems, vol. 19, n o 3, 2001, p [DER 76] DEREMER F., KRON H., «Programming in-the-large Versus Programming in-the- Small», IEEE Transactions on Software Engineering, vol. 2, n o 2, 1976, p [EJB02] «Enterprise JavaBeansTM Specification, Version 2.1», August 2002, Sun Microsystems, ØØÔ»» Ú º ÙÒºÓÑ»ÔÖÓ ÙØ»». [GEI 01] GEIHS K., «Middleware Challenges Ahead», IEEE Computer Magazine, vol. 6, n o 34, [HAL 99] HALL R., HEIMBIGNER D., WOLF 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 [ISS 98] ISSARNY V., BIDAN C., SARIDAKIS 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 [JMS02] «Java Message Service Specification Final Release 1.1», March 2002, Sun Microsystems, http ://java.sun.com/products/jms/docs.html.