ScalAgent, une plate-forme à composants pour

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.objetweb.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<nom de l'attribut> (<type de
l'attribut>).
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 Appliation. 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 Appliation. 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 affihage.
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 Appliation {
|
*** Attributs ***
| *** Interfaes fontionnelles ***
Message message_a_envoyer;
| Port entree {
|
nom = init ;
*** Interfaes fontionnelles *** |
signature = Initialisation ;
Port entree {
| }
nom = init ;
|
signature = Initialisation ;
| *** Composants enapsulés ***
}
| Client lient =
|
new Client(zironium.inrialpes.fr) ;
Port sortie {
|
nom = affihage ;
| HelloWorld helloWorld =
signature = * ;
|
new HelloWorld(strontium.inrialpes.fr) ;
}
|
| *** Liaisons ***
*** Mise en oeuvre ***
| this.init => lient.init ;
SCBean = fr.ClientBean ;
| lient.affihage => helloWorld.filtre ;
SCContainer = fr.ClientContainer ; |
}
| }
Figure 3. La description du composant Client et du composite Appliation
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 Appliation 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/produts/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