Chapitre XX

Architectures de Composants Rpartis

Frdric Peschanski et Jean-Pierre Briot Laboratoire dInformatique de Paris 6

Rsum
Dans ce chapitre, nous discutons du problme de la rpartition dans les architectures de composants logiciels. Pour cela, nous effectuons tout dabord un tour dhorizon des spcificits des systmes rpartis large-chelle, notamment les aspects dhtrognit, de concurrence, de fiabilit et de scurit. Les plateformes intergicielles classiques offrent une vision rpartie de la conception et de la programmation oriente objet. Nous discutons de certaines limites importantes des modles dobjets rpartis ; limites qui conduisent naturellement aux modles de composants. Avant de dcrire les principes de base des modles de composant rpartis, nous discutons des architectures applicatives quils ciblent en priorit. Nous passons du classique et quelque peu dmod client-serveur aux architectures mergentes comme les grilles de calcul ou le pair pair, sans oublier les trs stratgiques architectures 3-tiers. Ces dernires reprsentent de fait le domaine applicatif privilgi - et mme quasiment exclusif - des plateformes industrielles disponibles aujourdhui et notamment les Enterprise Java Beans et les Corba Component Model. Le principe dinversion du contrle forme, selon nous, le fil conducteur des diffrentes architectures proposes dans les modles de composants rpartis. De faon non exhaustive, nous prsentons les approches conteneurs, les plus courantes, les modles hirarchiques trs prometteurs et certains modles plus exotiques rflexifs et/ou gnratifs. La complexit des communications rparties imposent danalyser de faon pousse les principes dinteraction entre composants : interfaage et communication. Le concept architecturel de connecteur est galement discut. Finalement, nous effectuons un plongeon lintrieur des infrastructures pour en dcrire certains aspects fondamentaux dans le cadre de la rpartition ; nous insistons notamment sur les modles de contrle et le dploiement logiciel.

Introduction
Lingnierie du logiciel a connu ces dernires annes un dveloppement trs intense, avec notamment lavnement des technologies objet et, plus rcemment, lessor des approches orientes modle. Les mthodes de dveloppement modernes permettent de faire le lien, de la faon la plus confortable possible, entre les problmatiques de haut niveau des applicatifs - la logique mtier - et les aspects techniques de plus bas niveau - la logique systme. Les plateformes intergicielles telles que CORBA, RMI/Java et DCOM/.NET ont t dveloppes pour rpondre aux besoins spcifiques des architectures rparties. Cependant, et malgr de nombreux efforts investis dans ces technologies intergicielles, les propositions actuelles se rvlent encore limites face la problmatique trs complexe de rpartition large-chelle. Les architectures de composants rpartis jouent ici un rle prpondrant. Ils sont perus par beaucoup comme le point darticulation privilgi entre les problmatiques mtiers et les aspects purement informatiques dont la complexit est dcuple du fait de la nature rpartie de lenvironnement dexcution. Sur le front des composants logiciels rpartis, il nest donc pas tonnant de retrouver les plus grands acteurs du logiciel, notamment lOMG avec les modles de composants CORBA (CCM) et SUN avec les Enterprise Java Beans (EJB).

Principes des systmes rpartis

Les systmes rpartis sont, dans leur dfinition la plus simpliste, des logiciels dont lexcution se droule sur un ensemble dordinateurs distribus gographiquement et relis entre eux par des interconnexions rseau [1] [2].
Figure 1 : Exemple de systme rparti

Erreur ! Liaison incorrecte. Les applications disponibles sur Internet forment une catgorie hautement stratgique de systmes rpartis. La figure 1 ci-dessus reprsente une architecture typique de service Internet, mettant en jeu un serveur mtier (ex. : serveur Web), un serveur de bases de donnes et un certain nombre de clients rpartis gographiquement. Le principe de fonctionnement dune telle application est relativement simple : les clients effectuent des requtes vers le serveur (ex. : afficher une page HTML) qui en retour rpond en accdant potentiellement des informations gres par le serveur de donnes. On le voit sur cet exemple, un systme peut tre rparti pour des raisons physiques , comme ici la sparation gographique naturelle entre clients et serveurs. De nombreux systmes sont ainsi naturellement rpartis : systmes bancaires dont les agences sont rparties gographiquement, systme de contrle de processus industriels rpartis sur plusieurs sites, etc. La miniaturisation des ordinateurs et lmergence des technologies de rseau sans fil haut dbit introduit un nombre sans cesse croissant dapplications de nature intrinsquement rpartie. Dautres considrations, de nature plus logique , sajoutent la problmatique de rpartition gographique. Le choix de sparer sur notre exemple le serveur mtier du serveur de donnes peut notamment sexpliquer par un souci daugmentation des performances du systme. Deux machines (ordinateurs complets ou simples processeurs) physiques fonctionnent gnralement plus vite quune seule machine comparable, cest le postulat de base du paralllisme. Si la machine serveur tombe en panne, lintgrit du serveur de donnes ne sera pas compromise, seules les transactions en cours devront tre annules. La rpartition permet donc daugmenter la fiabilit dun systme. Du point de vue de lorganisation fournissant le service (figure 1), le serveur mtier est en contact avec le monde extrieur. Il est donc soumis aux ventuelles attaques de clients malintentionns. Le serveur de donnes, en revanche est en quelque sorte protg par le serveur mtier, il nest pas directement en contact avec lextrieur. La sparation, ici dordre physique, permet de profiter de matriels spcifiques pour la scurisation du systme ; la protection matrielle tant en gnrale plus efficace quune protection purement logicielle. La rpartition est donc galement un outil important pour renforcer la scurit des systmes.

Large chelle
On distingue en gnral deux catgories de systmes rpartis : les systmes limits en taille et les systmes large chelle. Les dveloppements actuels se concentrent, dans leur crasante majorit, sur les problmes spcifiques de la rpartition large chelle. LInternet, qui relie des millions de machines entre elles par lintermdiaire de rseaux de trs grande complexit, reprsente larchtype des systmes large-chelle.

Htrognit
Les systmes rpartis, part dans des cas trs spcifiques, ne sont pas lapanage dun constructeur donn. Ce sont des systmes hautement htrognes, mettant en uvre des plateformes matrielles et logicielles varies et souvent incompatibles entre elles. Grer cette htrognit passe par le dveloppement de technologies standards et ouvertes permettant lintroprabilit entre systmes diffrents.

Communications asynchrones
Dplacer de linformation prend du temps. Ce phnomne bien connu en sciences physiques prend en informatique tout son sens dans le cadre des systmes gographiquement rpartis, et notamment lorsque les distances entre les diffrents lments du systme sont importantes. Lorsque les temps de communication entre lments rpartis du systme ne peuvent tre prvus de faon prcise et absolue, on dit alors que le systme fonctionne de faon asynchrone. Il sagit dune diffrence fondamentale avec les environnements centraliss dont le fonctionnement synchrone est orchestr par une horloge globale unique.

Contrle concurrent
Chaque machine ou processus dun systme rparti possde, de par son fonctionnement asynchrone, un contrle autonome dit concurrent. Par exemple, sur la figure 1, les clients du systme accdent en mme temps, et potentiellement en trs grand nombre, aux services proposs par le serveur mtier. Ce dernier doit donc entremler les requtes des clients en mettant en uvre une politique de synchronisation pour grer les ventuels conflits entre requtes concurrentes. Les techniques de contrle de concurrence sont parmi les aspects les plus sensibles et les plus complexes dans la conception des applications rparties. Les moniteurs transactionnels forment une catgorie hautement stratgique doutils pour le contrle de concurrence.

Pannes partielles
Les systmes informatiques, comme probablement tous les systmes physiques, peuvent tre victimes de dfaillances. Ainsi un ordinateur peut cesser de fonctionner subitement, et avec lui toutes les applications quil excutait (ex. panne dune machine cliente sur la figure 1). Un processus logiciel peut galement tomber en panne, par exemple cause dun bogue ou par manque de ressources. Les rseaux de communication ont galement leurs pannes spcifiques : pannes de canaux de communication et pannes de message (disparition, rordonnancement ou pire, altration de messages communiqus). Ces pannes dites partielles sont omniprsentes dans les systmes rpartis. Thoriquement, le problme de dcider si un processus est en panne ou alors simplement ralenti est indcidable. Lon peut au mieux souponner une machine dtre en panne quand elle est inactive pendant un temps assez long. Pour la plupart des systmes en ligne, la disponibilit des services est essentielle, toute panne doit tre rpare de faon la plus rapide et la plus transparente possible.

Scurit
La scurisation dun systme centralis est relativement simple. En effet, le bon droulement des applications peut tre supervis assez facilement puisque la vision instantane et complte de lensemble des ressources employes par le systme est possible. Dans un systme rparti de grande taille, la scurisation est une problmatique cruciale et autrement plus difficile. Il est par exemple ncessaire de protger certaines communications sensibles, gnralement par cryptage des informations transmises. Dans lexemple de la figure 1, nous pouvons supposer que des clients transmettent au serveur certaines informations secrtes comme des numros de cartes bancaires. Il faut aussi sassurer des accs aux domaines protgs des systmes. Dans les services Web, il est par exemple dusage de distinguer les clients invits (ou anonymes) accdant la version minimale des services, et les clients authentifis possdant eux des droits daccs tendus. De par leur complexit et leur ouverture au monde extrieur, les systmes rpartis dploys sur lInternet ne peuvent tre totalement infaillibles. Tout est question dquilibre entre la robustesse des protections proposes face lingniosit (sans limites) des attaquants potentiels.

Des objets aux composants rpartis

Les questions spcifiques - et difficiles - de linformatique rparties, notamment celles voques dans la section prcdente, sajoutent aux problmes galement trs complexes de lingnierie logicielle des domaines mtier. La confrontation de ces deux mondes, aux intrts trs souvent antagonistes, a conduit

lmergence dune nouvelle catgorie de logiciel, couches intermdiaires entre les applications et le systme dexploitation que lon nomme plateformes intergicielles (en anglais middleware).

Les plateformes intergicielles

Les technologies intergicielles ont pour but de supporter un modle de dveloppement de haut-niveau, focalis sur les questions mtiers dans le cadre dune excution des applications en environnement rparti large-chelle. Le modle de dveloppement de la conception et de la programmation oriente objet occupe une place crasante dans le domaine du gnie logiciel. Les plateformes intergicielles proposes par lindustrie sont donc, sans surprise, focalises sur le support des mthodes de dveloppement base dobjets en environnement rparti. Dans un premier temps, les efforts se sont concentrs sur les problmatiques de portabilit du code applicatif et dinteroprabilit entre applications rparties. Disposer dun code portable permet de saffranchir de lhtrognit des infrastructures matrielles et logicielles sur lesquelles il doit sexcuter. Il existe principalement deux catgories de technologies pour la portabilit du code: 1. 2. Les approches de type machine virtuelle Les approches de type gnration de code

Les technologies de type machines virtuelles standardisent un unique code machine (appel codeoctet ou bytecode) et linfrastructure permettant dinterprter ce code objet. Ce sont notamment les solutions proposes par Sun avec Java et Microsoft avec .NET. En revanche, la norme Corba se veut indpendante du constructeur, la portabilit du code y est propose via gnration de code. Le code (nonportable) dimplmentation est ainsi gnr partir de la description portable du logiciel gnralement sous forme dinterfaces. Ces technologies concurrentes ont chacune leurs avantages et leurs inconvnients. Les approches de type machine virtuelle ont clairement lavantage de la simplicit. En revanche, elles sont confines des constructeurs spcifiques, voire des langages de programmation spcifiques dans le cas de Sun avec Java. La norme CORBA est par principe une norme ouverte, indpendante de constructeurs spcifiques. La gnration de code est galement propice aux performances puisquelle permet de profiter des environnements de compilation natifs des diffrentes plateformes. Notons cependant que les techniques de compilation au vol permettent une augmentation sensible des performances des machines virtuelles. Un autre aspect important des plateformes intergicielles concerne les possibilits dinteroprabilit entre applications dveloppes indpendamment. Ceci passe par la standardisation de la reprsentation des donnes changes entre applications, ainsi que des protocoles supportant ces changes. Le protocole IIOP (Internet Interoperable Object Protocol) de CORBA est probablement la norme la plus aboutie dans ce domaine. La plupart des plateformes permettent linteroprabilit via IIOP.

Les objets rpartis

Les technologies intergicielles proposes dans lindustrie proposent toutes le portage des fondements de la programmation oriente objet en environnement rparti. Parmi ces fondements, nous pouvons citer entre autre lencapsulation du code et des donnes, la modularisation base sur la notion de classe, la spcialisation par hritage, le polymorphisme, etc. Les objets de base deviennent ainsi objets rpartis.
Figure 2 : Principes de bus objets rpartis CORBA

Erreur ! Liaison incorrecte. Pour assurer les services de base de gestion des objets rpartis, les intergiciels introduisent un certain nombre doutils. Parmi ces outils se trouve llment fondamental de toute plateforme intergicielle objet : le bus dobjet rparti (ou ORB en anglais pour Object Request Broker). Ce logiciel ddi, dont larchitecture typique est reprsente sur la figure 2, reprsente la clef de vote de toute larchitecture intergicielle. LORB permet des objets implments dans des environnements varis et localiss sur des machines rparties gographiquement dinteragir entre eux. Il implmente les protocoles fondamentaux pour le bon fonctionnement des objets rpartis, en particulier la gestion du cycle de vie des objets (dploiement sur des sites distants, localisation dinstances, etc.) ainsi que les invocations distantes de mthodes. Le critre fondamental pour un bus dobjet rparti est de proposer ce genre de service de

manire transparente, en sabstrayant dans les plus larges mesures possibles des contraintes lies la nature rpartie et htrogne de linfrastructure sous-jacente. LOMG, travers la norme CORBA, a dmocratis la sparation systmatique entre interfaces et implmentations des objets rpartis. Les interfaces sont dcrites sparment dans un langage standard et portable nomm IDL (Interface Definition Language). Y sont dcrites les classes dobjets, notamment les types et noms des attributs, les signatures des mthodes ainsi que les relations dhritage. Comme indiqu prcdemment, des gnrateurs de code permettent de proposer des squelettes dimplmentations, sur lesquels les dveloppeurs se basent pour implmenter les objets tout en garantissant la satisfaction des interfaces initiales. Pour aborder les questions spcifiques des systmes rpartis, les plateformes intergicielles proposent gnralement des solutions sous la forme de services communs. Ces services couvrent les aspects importants de contrle de concurrence, de gestion de transactions, de scurit, etc. Le plus souvent, ces services sont spcifis par des interfaces normalises. Ceci permet diffrents vendeurs de proposer des implmentations alternatives, condition bien sr de respecter le cahier des charges des spcifications associes. Lensemble de ces services, associ au bus dobjet rparti et aux outils de gnration de code, permet une approche souple et hautement structure de la conception de logiciel rparti.

Limites des objets rpartis

Malgr lindniable succs des technologies industrielles dans certains domaines cls de linformatique dentreprise, on peut affirmer aujourdhui que les objectifs initiaux - et trs ambitieux - dembrasser lensemble de la problmatique de conception du logiciel rparti ne sont pas encore atteints. Des limites tant sur le plan mtier que sur le plan de la rpartition ont t dcouvertes ; limites qui expliquent en grande partie lmergence de la notion mme de composant logiciel. Pour notre tude focalise sur les problmatiques lie la rpartition, nous voquons ci-dessous deux problmes remettant en cause de faon importante le modle des objets rpartis.

Sparation des proccupations

Une tension forte existe entre les aspects mtiers et les aspects systmes au niveau de la conception et de la programmation orientes objet. La vision idaliste des standards objets, au dbut des annes 90, envisageait un monde futur purement objet. Y seraient parfaitement modulariss et interfacs objets purement applicatifs, objets mtiers (banques, domaine mdical, aronautique, etc) ainsi que services purement systme (contrle de concurrence, persistance, etc.). Pourtant, on le sait aujourdhui, cette dcomposition parfaite , selon les prceptes de la sparation des proccupations (separation of concerns) se heurte en pratique de nombreux obstacles. De fait, les interactions fines entre les diffrentes couches applicatives mtier et systme considres sont difficiles modulariser. Des aspects systmes sensibles comme la gestion des activits concurrentes, les politiques de synchronisation et les aspects lis la fiabilit ou la scurisation des systmes ne sabstraient quimparfaitement dans la mtaphore objet. En pratique, le code des objets applicatifs contient de nombreux aspects mtiers, entremls de faon inextricable avec des aspects systmes, ce qui rend le tout fort peu rutilisable et modulaire [3].

Communications synchrones et couplage structurel

Le mdium de communication occupe une place dcisive dans linfrastructure rpartie. Ce medium met en jeu, du fait de la rpartition, des changes naturellement asynchrones. En revanche, le mode de communication incontournable des objets, via invocations de mthodes, est essentiellement synchrone. De plus, dans une invocation de mthode, le client de linvocation connat le serveur qui implmente la mthode ; il en possde une rfrence explicite. Cette connaissance reprsente une forme de couplage structurel (ou spatial) qui fige larchitecture dans le code des objets. Une invocation de mthode reprsente donc une forme de couplage entre la source et la cible de linvocation, tant en termes structurels que du point de vue du contrle. Cette relative inadquation, que lon pourrait penser insignifiante, se rvle particulirement limitante en matire de performance et, plus encore sensiblement, lorsquil sagit de passage lchelle.

Vers les composants logiciels

Il est important de noter que les limites voques prcdemment ne remettent aucunement en question la notion mme dobjet rparti, qui est dsormais acquise. La mise en uvre de motifs de conception (en anglais design patterns) [27] ddis permet de rpondre assez prcisment aux limites voques cidessus. Linconvnient de ces motifs de conception concerne leur complexit : ils ne peuvent tre mis en uvre que par des experts en matire darchitectures logicielles rparties. De plus, parmi les nombreux motifs proposs, certains sont complmentaires et dautres sont en comptition . Il est difficile de faire le tri comme il est parfois difficile de faire le tri entre plusieurs implmentations dun mme algorithme. Lmergence du concept de composant rparti semble ainsi rpondre un besoin duniformisation et de systmatisation face cette profusion de recettes dexperts face aux problmes poss. ceci sajoute galement une volont vidente dextraire certains concepts comme rellement fondamentaux, aussi fondamentaux que la notion dobjet elle-mme. Il est notable que les plateformes intergicielles mettant en uvre les composants rpartis sont gnralement bties sur des technologies intergicielles objets. Cest en particulier le cas pour lObject Management Group qui se base sur CORBA pour proposer le modle des composants CCM. Mais cest galement vrai pour SUN avec les EJB qui reposent beaucoup sur les services du bus dobjets Java RMI. Le cas de Microsoft est un peu part puisque lobjet ubiquitaire nest apparu que rcemment avec le langage C# et la bote--outils .NET (rappelons que les technologies plus anciennes comme COM+ ne sont pas des technologies purement objet). On le voit donc, les plateformes intergicielles base de composants reprsentent essentiellement une volution des plateformes objets de la gnration prcdente.

Architectures applicatives
Avant daborder les principes architecturaux des plateformes base de composants rpartis, nous devons nous intresser ceux des applications une fois dployes. Contrairement au cas centralis ou la dcomposition du logiciel peut se faire de faon purement logique, il est ncessaire de rflchir longuement la problmatique de dcomposition architecturale dans le cadre rparti. Des critres tant matriels que logiciels entrent en ligne de compte. Des architectures spcifiques la rpartition ont t proposes et largement mises en uvre, dautres sont encore ltude ou restent encore inventer.

Le client/serveur
Les architectures de type client/serveur ont longtemps t considres comme intrinsques des systmes rpartis, en particuliers dans le milieu industriel. En effet, il est un peu rducteur mais assez consensuel de schmatiser le rle dune entreprise par la fourniture de produits ou de services au plus grand nombre possible de clients. Ces clients sont de plus gnralement physiquement loigns des ressources informatiques du fournisseur de services, qui forment la partie serveur du systme. Depuis les premiers systmes dinformations industriels ou organisationnels (comme les prcurseurs de lInternet, ArpaNet) et jusquaux principaux services Internet dploys lheure actuelle (ex. : le courriel ou le Web), la mtaphore client/serveur est quasiment incontournable. Cette dcomposition minimale a pour principal intrt de se concentrer sur la partie la plus stratgique du modle laune de la rpartition : le serveur. Il ne sagit pourtant pas de la seule dcomposition possible pour les applications rparties, loin sen faut.

Les architectures 3-tiers, N-tiers

On dsigne aujourdhui le client/serveur comme une architecture de type 2-tiers, compose dun tiers client et dun tiers serveur. Le tiers serveur, sur lequel les plus grands efforts de dveloppement sont aujourdhui concentrs, peut videmment tre dcompos son tour.
Figure 3 : Du client-serveur aux architectures 3-tiers

Erreur ! Liaison incorrecte. Comme indiqu sur la figure 3, la dcomposition structurelle du serveur en un tiers mtier et un tiers soccupant exclusivement des aspects systmes est trs motivante pour la sparation des proccupations. Nous le verrons, cette dcomposition nest pas toujours possible en termes purement architecturaux. Elle

est en revanche possible pour une catgorie importante de logiciel : les applications dentreprise orientes donnes. En effet, les serveurs de bases de donnes sont aujourdhui des produits cl en main , sortes de botes noires de haute technicit avec lesquelles on communique essentiellement par des requtes dans des langages de haut niveau (tel SQL), dans le cadre de transactions. Il est donc fort intressant dextraire cet aspect systme stratgique du reste du serveur. Ces architectures 3-tiers orientes donnes sont aujourdhui trs populaires, cibles de faon prioritaire par les technologies componentielles. Cependant, la plupart des acteurs du march sont bien conscients que la dcomposition ct serveur ne sarrte pas en si bon chemin. Les architectures N-tiers gnralisent ainsi le principe de dcomposition de la partie serveur des systmes dentreprise. Dans les technologies Microsoft, le tiers proxy occupe galement une place autonome et importante. En effet, les outils dinteraction client/serveur sont disponibles en grand nombre : messages (MQS), invocations de mthodes (DCOM), scripts et services WEB (ASP, SOAP), etc. Le tiers proxy introduit en tant quentit indpendante permet lintgration souple de ces technologies varies et souvent trs diffrentes, voire incompatibles entre elles, au sein dun serveur dentreprise. Une des problmatiques majeures des fournisseurs de solutions pour linformatique dentreprise concerne linteroprabilit avec les systmes dinformation pr-existants souvent propritaires et parfois archaques mais incontournables ; cest le fameux tiers legacy. Dautres raffinements N-tiers sont ltude lOMG, chez Sun, Microsoft, IBM [28] et de nombreux autres acteurs des infrastructures rparties dentreprise.

Les architectures nouvelles

Les architectures de type N-tiers couvrent essentiellement les besoins de systmes dinformation dentreprise relativement classiques . Mais ces architectures centres serveur semblent parfois quelque peu dmunies face lvolution incessante des technologies informatiques : vitesse, complexit et dynamicit des rseaux, puissance et multiplicit des points daccs, etc.

Le P2P ou la fin du tiers serveur

Le point de vue de la dcomposition - rpute incontournable - en 2-tiers minimaux client et serveur est sensiblement remise en question dans les approches de type pair pair (en anglais peer to peer P2P) [4]. Dun point de vue conceptuel, la principale innovation du P2P est de considrer chaque acteur du systme sur un pied dgalit : chacun peut tour tour occuper le rle dun client ou dun serveur dans la mtaphore traditionnelle des systmes rpartis, et qui perd au passage quelque peu de son sens. En pratique, il sagit dune remise en question de nombreux aspects sous-jacents des technologies de rpartition, notamment sur les aspects de routage rseau (principes dacheminement des informations communiques sur le rseau). Les systmes P2P sont aujourdhui parmi les services Internet les plus employs ; et on leur prte une gamme dapplications de plus en plus varie : outils collaboratifs, partage de contenu multimdia, jeux en ligne, etc.

Les grilles de calcul

Dans un registre diffrent mais tout aussi chaud , le projet de lancement du plus grand acclrateur de particules au monde, le clbre LHC du CERN Genve (l mme o Tim Berners Lee inventa le Web) propose un dfi de taille aux acteurs de la communaut informatique. Jamais une quantit dinformation aussi importante, et produite un rythme si rapide, naura t gnre par un systme numrique. Ce sont des milliers dordinateurs, rpartis sur la plante entire, qui seront ncessaires pour digrer cette norme quantit dinformation. Des systmes spcifiques sont en cours dlaboration, on les appelle les grilles de calcul (les anglo-saxons parlent de grid computing) [5]. L galement lensemble de linfrastructure est revoir, mais cette fois-ci la tendance est inverse. Le client (les scientifiques) est paradoxalement llment le plus coteux du systme. A partir dun flot unique dinformation, des millions de nuds du systme doivent tre fournis en informations correctement formates et dcoupes.

Les approches centres rseau

Dans le logiciel traditionnel , laccent est mis sur les entits qui entrent en interaction (procdures, objets) plus encore que sur leurs modes dinteraction (envois de message, invocations de mthodes, etc.). Les technologies centres sur le rseau, notamment SUN avec Jini [6] ainsi que les spcifications ouvertes de lalliance OSGi [24], prennent de limportance notamment en raison de lessor des technologies sans fil. Ces approches oprent ainsi un autre retournement en se focalisant sur la couche

de communication plutt que sur les entits ralisant les calculs proprement dits (sans pour autant les oublier totalement !). Les rseaux possdent ainsi parfois des capacits de traitement propre (rseaux intelligent et actifs) et proposent galement une dynamique structurelle (rseaux mobiles) qui ont un impact sensible sur les technologies logicielles.

Autres architectures
Au-del des trois exemples proposs ci-dessus, la famille des architectures de systmes rpartis ne cesse de sagrandir. On peut par exemple citer la diffusion de flux multimdias en ligne, les rseaux de capteurs actifs, les systmes multi-agents ou encore les espaces actifs et autres cits numriques, etc. Il est intressant de noter, en outre, que la notion de composant occupe souvent une place de choix dans les approches ddies ces diffrents domaines mergents.

Modles de composants logiciels rpartis

Les plateformes intergicielles bases sur la notion de composant proposent des solutions aux limites des approches objets de la gnration prcdente. Au nombre de ces limites, la sparation des proccupations entre code fonctionnel, ou logique mtier, et code non-fonctionnel, ou logique systme, se trouve rellement au cur des dveloppements centrs sur la notion de composant logiciel. Dans ce but, les modles de composants rpartis sont gnralement architecturs selon le principe de linversion du contrle, galement appel principe dHollywood . Lide est de placer le contrle applicatif, et notamment tout ce qui concerne les interactions entre couches logicielles mtier et systme, sous lautorit dentits extrieures, gres elles au sein de la plateforme intergicielle. Dans le cadre des composants rpartis, plusieurs approches ont t proposes pour raliser cette inversion du contrle : les approches conteneurs, les approches hirarchiques ainsi que des approches plus exprimentales comme les modles rflexifs et/ou gnratifs, notamment certains travaux issus de la programmation par aspects. Il est intressant de noter que ces diffrentes approches ne sont pas incompatibles entre elles ; elles correspondent plutt des points de vue diffrents, et parfois conciliables, sur la ralisation du principe dinversion du contrle.

Modles conteneurs
Dans les plateformes industrielles EJB et CCM, qui ciblent essentiellement les systmes dinformation dentreprise et les architectures 3-tiers, les composants logiciels sont avant tout considrs comme des entits mtier. La notion complmentaire de composant systme commence galement merger. Mais dans tous les cas de figures, les composants sont introduits comme entits spcialises, qui doivent interagir avec dautres concepts indpendants. En particulier, larticulation entre code mtier (implment par les composants) et code systme (implments par les services du tiers systme) est plac sous lautorit dentits indpendantes que lon nomme conteneurs.
Figure 4 : Architectures conteneurs

Erreur ! Liaison incorrecte. Comme le montre la figure 4 ci-dessus, les conteneurs se situent dans les architectures 3-tiers la croise des trois logiques client, mtier et systme. Leur rle primordial est de contrler les composants mtiers, en fonction la fois des requtes client et des ressources systme sous-jacentes. Pour cela, la mise en uvre des conteneurs repose sur deux principes fondamentaux : 1. 2. Mcanismes dinterception Mcanismes de gestion contextuelle

Les interactions entre les clients et le serveur reposent sur des modles de communication varis (cf. suite du chapitre), elles sont conceptualises par la notion de proxy. En plus de grer la communication, les proxys sont galement employs pour distinguer les requtes de nature mtier (ex. : achat dun article en ligne) des requtes systme (ex. : ouverture dune transaction), on parle dans ce cas de rle dinterception. Une partie de la gestion de lidentit et du cycle de vie des composants mtiers est parfois dlgue des entits spcifiques nommes maisons (homes en anglais). Le conteneur est galement responsable des interactions entre les composants mtier et la logique systme sous-jacente. Pour les EJB,

un unique type de conteneur, dit conteneur EJB, englobe lensemble des fonctionnalits systme supportes par la plateforme. Dans les approches les plus rcentes, et notamment CCM, des composants de service sont de plus introduits en tant quintermdiaires supplmentaires dans la couche systme. Les contextes, pour leur part, permettent de conserver au sein du conteneur des informations refltant, en termes de contrle, ltat des composants mtiers. Une partie de cet tat contextuel est visible par le code mtier, le reste tant encapsul de faon opaque dans la logique systme.

Modles hirarchiques
Dans la mtaphore componentielle, la notion de composition hirarchique veille de faon grandissante lintrt des architectes logiciels. La possibilit de crer des composants de haut niveau - dits composites - par composition de composants de niveaux dabstraction infrieurs reprsente un principe de construction logicielle la fois naturel et expressif. Si cette notion fait relativement lentement (mais srement) son apparition dans les approches industrielles, les modles hirarchiques issus du monde de la recherche arrivent maturit. Parmi les nombreuses approches proposes, nous pouvons distinguer les spcifications Fractal qui ont lavantage dtre la fois portables et extensibles [7]. Ces spcifications sont dveloppes au sein du consortium ObjectWeb. Dans ce modle sont distingues trois catgories complmentaires de composants : 1. Composants basiques : ce sont des composants minimaux avec lesquels on communique uniquement par appels de mthodes sur leur interface. Cette couche est avant tout spcifie pour permettre linteroprabilit avec les environnements objet traditionnels. Composant primaires : ils ajoutent aux composants basiques un contrleur charg dun certain nombre de fonctionnalits lies au contrle du composant. Composants composites : ces composants ajoutent aux composant primaires un contenu, sous la forme dune interconnexion de sous-composants, eux-mmes basiques, primaires ou composites.

2. 3.

La grande nouveaut du modle concerne donc la troisime catgorie qui donne corps la notion de composition hirarchique. Un composant composite Fractal possde la structure reprsente sur la figure 5 ci-dessous.
Figure 5 : Modle de composant hirarchique Fractal

Erreur ! Liaison incorrecte. Un composant composite est subdivis en deux parties distinctes : la partie contrleur et la partie contenu. Un contrleur fractal ressemble une gnralisation du principe de conteneur des architectures EJB et CCM, ralisant tout comme ce dernier une inversion du contrle, propice la sparation des proccupations. Les interfaces standards pour les contrleurs sont cependant de plus bas niveau dans le cadre de fractal, elles concernent les proprits non-fonctionnelles suivantes : 1. Lintrospection des interfaces de composant : noms et contenus des interfaces. 2. La gestion du cycle de vie : dmarrage et arrt de composants et sous-composants. 3. Gestion des liaisons extrieures : relations entre interfaces requises et fournies. 4. Gestion des attributs : lecture/criture de proprits. 5. Gestion du contenu pour les composants composites : ajout/retrait de sous-composants. Ces interfaces standards sont loin de couvrir lensemble des besoins en matire de contrle, notamment dans le cadre des systmes rpartis. Mais les spcifications Fractal sont ouvertes et extensibles, ce qui permet de les implmenter sous des formes varies (il existe notamment des implmentations en C et en Java) et dintroduire des interfaces de contrles spcialises diffrents domaines dapplication. Ainsi, la plateforme ProActive ajoute un ensemble dinterfaces de contrles pour les applications de grilles de calcul. Ces interfaces spcialises concernent notamment la concurrence, la communication de groupe ou encore la mobilit [8].

Modles rflexifs et gnratifs

Linversion du contrle, c'est--dire lexternalisation du contrle sur les composants applicatifs, est rptons-le encore, au cur des diffrentes plateformes intergicielles base de composants rpartis. Dans les plateformes traditionnelles , les interfaces de contrle sont fournies par des entits (conteneurs ou autres contrleurs) dont limplmentation est gnralement assez opaque ; elle nest pas - ou peu accessible au dveloppeur applicatif. Dans les modles rflexifs et gnratifs, en revanche, les implmentations des principes dinversion du contrle sont ouvertes. Les modles rflexifs sont bass sur une sparation entre un niveau base, fonctionnel, et un niveau mta, pour la gestion de proprits nonfonctionnelles. Les liens entre ces deux couches reposent sur des principes dintrospection qui permet au niveau mta de dcouvrir les fonctionnalits disponibles au niveau base. En complment, on introduit le principe dintercession qui permet la prise de contrle par le niveau mta certains moments cl de lexcution des applications. Il existe de multiples faons de structurer les niveaux base et mta des architectures rflexives. Dans le cadre des plateformes componentielles, lide est gnralement de fournir les principes de composition (ventuellement hirarchique) la fois au niveau base et au niveau mta (cf. figure 6). La nature des composants mta est variable dune implmentation lautre. Par exemple, dans la plateforme OpenORB dveloppe lUniversit de Lancaster en Grande-Bretagne, on trouve des mta-composants essentiellement ddis aux applications multimdia (streaming, qualit de service, etc.) [9].
Figure 6 : Exemple de modle rflexif

Erreur ! Liaison incorrecte. Les approches gnratives proposent, tout comme les approches rflexives, de rifier certains aspects de limplmentation de fonctionnalits de contrle pour les rendre accessibles au niveau applicatif. En revanche, les technologies sous-jacentes reposent essentiellement sur des principes de gnration de code et/ou de manipulation au vol de code-octet (bytecode). Le domaine trs en vogue de la programmation par aspects repose principalement sur de telles techniques gnratives. Parmi les aspects de contrle les plus frquemment rifis, citons entre autre linterception des invocations de mthodes permettant dencadrer ces invocations par des pr et/ou post-traitements. Un intrt supplmentaire des techniques gnratives est de permettre lintroduction des principes dintercession en tant que primitives de langage de programmation (points de coupure, conseils, etc.). Rcemment, certains principes de la programmation par aspects ont t introduits pour ouvrir limplmentation de conteneurs EJB industriels, notamment dans les conteneurs JBoss [10] et Spring [11].

Principes dinterfaage et modes de communication

Nous avons dcrit les principales approches pour donner corps la notion de composant logiciel rparti. Les architectures proposes sont principalement focalises sur la sparation des proccupations entre logique systme et logique mtier, et reposent essentiellement sur lintroduction de formes varies dinversion du contrle. Dans le domaine de la rpartition, il est important de considrer les modles dinteractions entre composants avec au moins autant dattention que les modles de composant euxmmes. Tout comme pour les objets rpartis, il est important, au pralable, dtablir une distinction prcise entre le niveau conceptuel des interactions et leur ralisation pratique, qui considre plus prcisment la nature rpartie du systme et lomniprsence des rseaux de tlcommunication.

Interfaces de composants
Tout comme pour les objets rpartis, les plateformes intergicielles base de composants introduisent invariablement une notion plus ou moins complexe dinterface. Les interfaces de composants logiciels sont gnralement plus riches que les interfaces classiques dobjets. En premier lieu, les interfaces dcrivant les principes dinteraction avec les composants sont dfinies lextrieur des descriptions des composants eux-mmes. De plus, les modles de composants introduisent gnralement une sparation claire entre interfaces fournies et interfaces requises. Les interfaces fournies dcrivent classiquement les services implments par les composants logiciels. La nouveaut concerne ladjonction dinterfaces requises pour dcrire les services dont les composants ont besoin pour fonctionner. On trouve donc des mcanismes de liaison spcifiques consistant mettre en correspondance des interface requises par

certains composants des interfaces compatibles fournies par dautres composants. Pour effectuer cette liaison, les interfaces sont rifies au statut dentits de premire classe, que lon peut manipuler de faon autonome. Considrons un service de calcul proposant une mthode permettant laddition de deux nombre, dont linterface est la suivante :
Interface AddService { Number Add(Number a, Number b); }

Cette mthode, de nom Add, prend deux nombres a et b (de type Number) et retourne le nombre rsultat de laddition. Supposons un composant de calcul, par exemple dans le domaine de la conception assist par ordinateur, ayant besoin du service daddition. Ce dernier exposera donc linterface AddService comme une interface requise. Ce service pourra tre fourni par un composant de calcul de plus bas niveau qui lui explicitera AddService comme une interface fournie. Pour faire le lien entre ces deux composants et donc le lien entre les interfaces requises et fournies, une possibilit est didentifier chacune de ces interfaces par un nom unique. Ainsi, on pourra utiliser une construction de la forme :
Bind(nom de linterface requise, nom de linterface fournie)

Pour obtenir ce nom unique dinterface, on peut considrer le nom (ou le nom de type) des composants eux-mmes. Si les composants se nomment respectivement C1 (client de AddService) et C2 (fournisseur de AddService), on pourra effectuer le lien entre les deux interfaces par une construction de la forme :
Bind(C1.AddService, C2.AddService)

Ainsi, chaque invocation au service daddition sur C1 pourra tre automatiquement dlgu au service daddition propos par C2.

Invocation de mthodes distantes

Les invocations de mthodes distantes reprsentent lvolution des anciens appels de procdures distantes ou RPC (Remote Procedure Calls en anglais) vers les technologies dobjets rpartis. Linterface dune mthode est compose, comme le montre lexemple prcdent, au minimum du nom de la mthode, du type de chacun de ses paramtres, et finalement, du type de sa valeur de retour. En termes techniques, la mise en uvre des invocations de mthodes distantes est complexe, notamment du fait de lhtrognit des systmes. Pour illustrer les diffrents mcanismes mis en jeu, considrons les dtails dune invocation la mthode Add de linterface AddService dcrite prcdemment, tels que dcrits sur la figure 7.

Figure 7 : Le mcanisme dinvocation de mthodes distantes

Erreur ! Liaison incorrecte. Du point de vue de linvocation, il est naturel de distinguer le composant client qui ralise linvocation, du composant serveur qui implmente la mthode. Contrairement aux objets rpartis, cette distinction est ici dynamique et ne correspond pas forcment une sparation client/serveur en terme darchitecture. Ainsi, on peut imaginer que le composant serveur de la figure 7 puisse ultrieurement invoquer une mthode du client (il changeront donc leur rle respectif cette occasion). Pour quun client initie une invocation, il doit au pralable possder le fil de contrle ; on parle encore de contrle actif. Ce contrle est suspendu au moment de linvocation, en raison de la nature synchrone du principe dinvocation. Cette nature synchrone est due en partie lattente ventuelle dune valeur de retour de linvocation ou, plus subtilement, au fait que deux invocations successives (mme sans valeur de retour) sont souvent penses comme sexcutant en squence. Ce contrle synchrone correspond, du point de vue de lenvironnement rparti, un couplage fort, pendant toute la dure de linvocation, entre le client et le serveur, ou plus prcisment entre la souche du client et le squelette dimplmentation du serveur, qui grent le code systme. Dun point de vue systme, ce couplage peut poser problme. Il est possible, par exemple, que le destinataire mette un temps trs long, voire infini, pour rpondre. Pendant toute cette priode, le composant client (et ventuellement lui-mme serveur pour dautres composants) restera en attente passive. Lencapsulation ne couvre donc pas le phnomne du contrle. Dun point de vue plus pratique, linvocation de nature synchrone et fiable nest pas trs efficace en terme de systme rparti. Pour la mettre en uvre, il faut changer de nombreux messages de synchronisation et autres subtilits dont on aimerait parfois se passer.

Passage de messages
Les infrastructures rseaux privilgient, du moins large chelle, les changes asynchrones. Le mode de communication dit du passage de message fut le premier tre mis en uvre dans les technologies logicielles pour les systmes rpartis. Sa proximit avec la structure physique du rseau sous-jacent ny est bien sr pas trangre. Les interfaces pour le passage de message se dcomposent plus simplement que les mthodes en parties requises et parties fournies. Ainsi un fournisseur de service de messagerie pourra exposer une mthode Receive retournant les ventuels messages reus, comme ci-dessous :
Interface ProvideMessageService { Message Receive() ; }

Du ct des composants utilisateurs du service, linterface requise sera essentiellement caractrise par une mthode paramtre par le message mettre et son destinataire :
Interface RequireMessageService { Send(Message m, Component dest) ; } Figure 8 : passage de messages

Erreur ! Liaison incorrecte. Comme le montre la figure 8, le principal intrt du passage de message est de permettre un change nonbloquant, ou asynchrone. Au dbut du scnario, la source est dans lactivit dmission dun message vers la destination alors que cette dernire est en attente (passive) de rception dun nouveau message. On pourra galement considrer le cas dun destinataire actif ; le message ne pourrait tre dlivr que lorsque le destinataire se retrouve en tat dattente. Ce qui rclame la mise en uvre de files dattentes de messages, ou botes aux lettres. Aprs avoir mis son message, la source peut naturellement et instantanment continuer son travail. La destination pour sa part sactive pour traiter ce nouveau message reu. Ce type dinteraction est efficace en terme de systme rparti. Le fait que la source puisse continuer fonctionner aprs lmission de son message, indpendamment du fonctionnement de la destination, reflte naturellement le fonctionnement concurrent des diffrents nuds dun systme rparti.

Incontournables dans les couches basses des systmes rpartis (les protocoles de communication de bas niveau sont tous bass sur les changes asynchrones de messages), et contrairement ce que lon pourrait penser, le passage de message est galement intressant un haut niveau dabstraction, notamment dans le cadre des intergiciels orients messages MOM (Message Oriented Middleware) [12]. Ces infrastructures permettent la mise en place de systmes rpartis dont les diffrentes composantes sont fortement dcouples entre elles, la fois dans le temps et dans lespace. Les MOM modernes comme MSMQ (Microsoft Message Queuing) de Microsoft [13], WebSphere MQ dIBM [14] ou JMS (Java Messaging Service) de SUN [15] offrent toute une panoplie de services. Ils permettent par exemple des messages non livrables instantanment dtre stocks temporairement (parfois plusieurs jours), via le stocker et faire suivre (en anglais, store and forward). Dans les systmes embarqus, ce mode dinteraction est particulirement adapt la gestion des dconnexions intempestives. Les MOM sont galement largement employs pour permettre linteroprabilit avec les systmes dinformations dentreprises lecacy [16].

Modes de communications mergents

Les deux prcdents modes de communication identifiaient, de faon explicite, une source/client et un destinataire/serveur pour la communication. Il sagit de modes de communication point--point inspirs pour une bonne part par le modle tlphonique. En complment, de nombreuses variantes jouent sur le nombre dmetteurs et de rcepteurs dinformation ; on parle de cardinalit du modle de communication. Dans la mtaphore du courrier lectronique, le mode de diffusion multipoint (ou multicast) occupe une place stratgique au sein de lInternet. Ces modes de communication gnralisent le passage de message de cardinalit 1-1 (1 metteur associ 1 rcepteur) la diffusion de message de cardinalit 1-N (1 metteur et N rcepteurs). La communication de groupe (utilise notamment pour la rsistance au pannes), les architectures de streaming (ex. : tlvision sur internet, diffusion multimdia, etc.) et les grilles de calcul reposent largement sur cette ide en terme dinfrastructure de communication. En termes dinterfaces, la principale diffrence avec le passage de message concerne labsence de destinataire explicite pendant lenvoi. On pourra par exemple passer un identifiant de groupe explicite :
Interface RequireGroupMessageService { Send(Message m, ComponentGroup destgroup) ; }

La cardinalit 1-N se gnralise encore aux modes de communication de cardinalit M-N o lon trouve un nombre non prdfini dmetteurs dinformations associ un nombre galement non prdfini de rcepteurs. Les communications par vnements typs et les protocoles de type publication/souscription (publish/subscribe) font partie de cette catgorie. Ces modes de communication sont particulirement adapts aux rseaux ubiquitaires et linformatique nomade. Cette fois-ci, cest la nature des informations contenues dans lvnement (message typ) qui dcide de lacheminement. Linformation la plus largement utilise concerne le type de lvnement, on parle alors de publish/subscribe bas sur les types ; il existe galement des services de publish/subscribe bass sur les topiques et/ou le contenu [17]. Du ct du composant publiant lvnement, on dispose ainsi dune interface de la forme suivante :
Interface PublisherService { Publish(Event e) ; }

Les souscripteurs, pour leur part, possdent une interface double permettant la fois de souscrire des catgories dvnements (types, topiques et/ou descripteurs de contenu) et galement de recevoir les vnements comme dans le cadre du passage de message standard :
Interface SubscriberService { Subscribe(EventType t); Event Receive(); }

De faon intressante, les CCM introduisent des concepts de sources et de puits dvnements pour prendre en compte, au niveau du modle abstrait lui-mme, un mode de communication M-N. Lavantage de la communication vnementielle asynchrone est que le dcouplage devient total, en termes aussi bien temporels (asynchronisme) que spatiaux (pas de rfrences explicites de sources et de destinataires).

Concernant le passage lchelle, lexception des architectures particulires du publish/subscribe, les modes de communications introduits jusqu prsent possdent un facteur limitant incarn par le routage dterministe quils sous-entendent. Or toutes ces propositions peuvent tre envisages sous langle du non-dterminisme. Par exemple, un objet dsirant utiliser un service, par exemple par invocation de mthode ou passage de message, identifie statiquement (parfois dynamiquement par lintermdiaire de motifs de conception adequats) un destinataire. Ce destinataire explicite dnote une route prcise pour le rseau sous-jacent, une route potentiellement surcharge, peu fiable, etc. Une autre possibilit consiste en un choix non-dterministe dun destinataire capable de rendre ce service, suivant une route la plus efficace possible. Il sagit probablement du grand apport des technologies pair--pair, pour linstant essentiellement reprsente pas les services dchanges de fichiers mais qui auront sans aucun doute une incidence sur les problmatiques du monde industriel [4].

Langages de description darchitectures et connecteurs

La liste des modes de communication disponibles sur le rseau ne cesse de grandir. Ainsi nous navons pas voqu le cas des protocoles de haut-niveau comme SOAP ou XML-RPC. Il existe galement des protocoles spcifiques au monde de lembarqu et de la tlphonie, au satellitaire, etc. La plupart des approches du march se contentent dintgrer ces diffrentes technologies au fur et mesure des besoins. Une approche fdratrice permettant de spcifier ces diffrents modes de communication au sein dun mme environnement semble de plus en plus ncessaire. Des chercheurs et industriels proposent dans ce but les langages de description darchitectures (ADL) et les modles de connecteurs pour spcifier, de manire portable et rutilisable, les principes dinterfaages, protocoles de communication et technologies sous-jacentes. Ces connecteurs disposent dun type ainsi que dun ensemble de proprits [18]. Par exemple, les proprits de base de connecteurs pour les modes de communication dcrits dans ce chapitre sont rsumes sur le tableau 1. Le critre de scalabilit (ou de capacit passer lchelle) est bien sr assez subjectif.
Tableau 1 : Type de connecteurs et proprits

Type de connecteur Invocations de mthodes Passage de message Multipoint Pub/sub Pair pair (P2P)

Contrle Sync Async Async Async Tout

Cardinalit 1-1 1-1 1-N N-M Toute

Couplage Temporel/Spatial Oui/Oui Non/Oui Non /Oui Non/Non -/-

Routage Dt Dt Dt Dt Non-dt

Scalabilit Faible Moyenne Moyenne Bonne Excellente

En pratique, de nombreuses autres proprits sont prendre en compte comme le format des donnes changes, les possibilits de persistance, etc. Une fois ralises, de telles spcifications reprsentent une aide inestimable pour les experts architectes, qui peuvent ainsi choisir de manire confortable les infrastructures de communication correspondant le mieux au cahier des charges des applications. Le concept de connecteur est galement trs intressant pour la conception et limplmentation mme des plateformes intergicielles. Rcemment, ce concept a t employ avec succs pour concevoir et implmenter des couches gnriques pour la communication entre les composants rpartis et des services Web ou des systmes dinformation dentreprise anciens et/ou propritaires. Il sagit notamment du J2EE Connector Architecture de Sun [19].

Problmatique de contrle
Linfrastructure de contrle concentre une bonne partie des problmes difficiles lis au dploiement des applications en environnement rparti large chelle. De ce point de vue, nous lavons vu, la principale

rupture avec le monde objet concerne la sparation la plus claire possible, dans les fondements mmes des modles de composant, entre la logique mtier, exprime par les composants eux-mmes et la logique de contrle (ou logique systme), mise en uvre par des concepts et mcanismes ddis. Il nous reste dcrire les diffrents services de contrle proposs dans les platerformes componentielles majeures.

Contrle de concurrence
La concurrence est un problme fondamental pos par le partage de ressources rparties au sein dun systme ; ces ressources pouvant donc tre accdes par plusieurs activits/composants simultanment, depuis plusieurs sites rpartis du systme (cf. figure 9).

Figure 9 : Composants accdant en concurrence une mme ressource

Erreur ! Liaison incorrecte. Le contrle de concurrence est un problme difficile - parmi les plus difficiles - de linformatique rpartie. Trois tensions fondamentales orchestrent la synchronisation dactivits concurrentes. Tout dabord, il sagit doptimiser le degr de concurrence (ou de paralllisme) du systme, cest la proprit defficacit. Il existe un objectif non moins important de sret qui interdit aux applications concurrentes de se retrouver dans un tat inconsistant ou bloqu. Par exemple, si deux activits devant se drouler en exclusion mutuelle se produisent simultanment, alors on enfreint la proprit de sret. Les malencontreusement clbres deadlocks ( verrous mortels ) qui bloquent le systme avant terme sont galement du domaine de la sret. Enfin, il est important de garantir que le systme progresse dans son excution. On parle alors den assurer la vivacit. Un livelock ( verrou vivant ) dans lequel le systme semble avancer (i.e. il change dtat) mais ne produit en fait rien dintressant est un problme typique de vivacit. Toute la difficult du contrle de concurrence rside dans lquilibre entre ces trois proprits, souvent opposes. En effet, la tension entre vivacit et sret est forte, et les algorithmes de contrle de concurrence sont complexes et consommateurs de ressources.

Synchronisation par verrous

Au plus bas niveau des infrastructures, des services systme sont proposer pour dcrire les politiques de synchronisation entre activits concurrentes. Les modles de synchronisation par verrou (lock) forment une catgorie importante pour la synchronisation de grain fin ; il sagit en loccurrence du modle spcifi dans la norme CORBA [20]. Lide est de permettre de bloquer laccs en concurrence par plusieurs activits simultanes une ressource partage par la pose dun verrou sur cette ressource. On trouve des types de verrous diffrents pour le verrouillage en lecture (qui autorise dautres lectures) et en criture (qui interdit toute autre lecture ou criture). Un moyen de systmatiser la pose et le retrait des verrous est de mettre en place deux phases distinctes dans le cadre du 2PL (2-Phase Locking en anglais). Les synchronisations se droulent donc par vagues avec dans un premier temps lacquisition des ressources puis au final leur relchement. Les modles sont encore raffins en structurant hirarchiquement les verrous. Les services de contrle de concurrence propos dans les plateformes intergicielles sont conus pour faire reposer la manipulation des verrous sur limplmentation des composants et non de leurs clients. En revanche, la sparation du code mtier et du code de verrouillage au sein des composants est un problme difficile ; ce qui limite les possibilits de rutilisation de ce code, par exemple par hritage [29]. Des approches exprimentales issues du monde de la recherche ont cependant montr quune certaine modularisation tait possible ce niveau [8] [9]. Les modles de composants hirarchiques, rflexifs et/ou gnratifs offrent tous trois des possibilits pour sparer code mtier et code concurrent. Mais ces travaux nont pas encore rellement franchit les portes des laboratoires de recherche [3][9].

Synchronisation par communication

Une autre catgorie de contrle de concurrence passe par la communication de messages spcifiques de synchronisation. Ce modle est particulirement adapt la nature rpartie des applications puisque la communication ne peut de toute faon se faire que par envoi de messages. Encore une fois, ces modles de bas niveau sont gnralement manipuls dans le code fonctionnel des composants, qui en devient peu rutilisable, difficile comprendre et dboguer. Mais des volutions notables sont en cours galement dans ce domaine, notamment par les techniques de modlisation de processus industriels qui sinspirent des modles de communication. Les normes mergentes du BPELWS (Business Process Execution Language for Web Services) [21] et BPML (Business Process Modeling Language) [22] introduisent, en termes mtiers, des modles de gestion de concurrence bass sur la communication un niveau dabstraction assez lev. Les processus changent des messages pour se mettre daccord sur qui fait quoi, et dans quel ordre. Si lobjectif principal est avant tout du domaine du gnie logiciel pour les systmes dinformation dentreprise, il est clair quen cas de succs de ces modles de processus mtier, de gros efforts devront tre fournis pour les supporter dans les plateformes intergicielles.

Transactions
Dans certains domaines spcifiques, tout particulirement celui de la gestion des donnes, lexpression spare du code concurrent et du code mtier est rendue au moins partiellement possible, par exemple

dans le cadre des transactions. Chaque requte de client est reprsente par une transaction qui est une suite de lectures et dcritures de donnes quil faut raliser en squence. Les transactions sont dlimites par des ordres initiaux douverture et des ordres finaux de validation (les clbres commit). Le problme du serveur revient donc interprter le plus grand nombre possible de transaction dans les temps les plus brefs possibles. Le choix trs sr dinterprter chaque transaction tour de rle est hautement inefficace. Le moniteur transactionnel se charge donc dentremler de multiples transactions de faon savamment orchestre afin de prserver les proprits fondamentales des transactions, savoir les proprits ACID : 1. Atomicit : si une transaction est interrompue (par exemple cause dune panne, une dconnexion, etc.), alors lensemble des oprations effectues jusquau moment de linterruption sont annules. Tout doit se passer comme si la transaction navait jamais exist. Cohrence : chaque base de donnes dispose de rgles strictes concernant les donnes qui peuvent tre stockes. La proprit de cohrence indique quune transaction ne peut pas circonvenir ces rgles. Isolation : si pour le moniteur les transactions sont entremles, pour les clients tout doit se passer comme si les transactions sont totalement indpendantes les unes des autres. Durabilit : une fois valide, les effets lis linterprtation dune transaction sont permanents, on ne peut plus revenir en arrire.

2.

3. 4.

Les moniteurs transactionnels reprsentent - dans le domaine clairement dlimit mais hautement stratgique de la gestion des donnes - une des rares intgrations russies, et hautement efficaces, de la gestion mtier des serveurs de donnes, de leur accs en concurrence par de nombreux clients et mme de la mise en uvre politiques de rsistance aux pannes. Il sagit dun lment hautement stratgique pour les infrastructures dentreprise et le pilier de certaines approches bases sur les composants, notamment les Enterprise Java Beans et Corba CCM.

Scurit
Dans les systmes rpartis ouverts, comme Internet, la scurisation des applications est un problme incontournable. Les plateformes intergicielles proposent, sous la forme dun modle de scurit implant par des services du tiers systme, une couche dabstration permettant de rsoudre les problmes de scurisation au niveau des composants. En premier lieu, les services de scurit mettent gnralement en place une politique de contrle daccs aux composants. Il sagit schmatiquement de dcider de qui (ou quoi), par exemple un composant externe, peut accder tel ou tel composant dans le systme. Le contrle daccs peut soprer au niveau : 1. 2. des interfaces de composants des implmentations

Le contrle au niveau des interfaces suffit en gnral implmenter le contrle statique daccs, qui ne change pas au cours du temps. En revanche, les aspects dynamiques (comme le changement de niveau de protection dune ressource) reposent trs souvent sur le code dimplmentation, qui doit donc galement fournir certaines informations en terme daccs. Dans les approches orientes serveur, la session daccs au systme, qui correspond en gros la ralisation dun processus mtier donn (par exemple lachat dun produit dans un service de vente en ligne) reprsente le niveau de granularit privilgi pour traiter des problmes de scurit. Pour reprendre une terminologie usuelle dans les services en ligne, une session daccs peut tre authentifie ou invite. Une session authentifie permet daccder des ressources protges, non-accessibles par les sessions invites. chaque session authentifie est associ un certain nombre dinformation permettant de dcider de lensemble des ressources accessibles pour cette session particulire. Cette dcision repose la fois sur la description par la session de ses capacits daccs (et donc de faon transitive des capacits de lutilisateur du systme), et galement sur la description prcise des proprits daccs pour les ressources protges manipules par le systme. Pour la plupart des approches base de composants modernes, comme les EJB, CCM ou .NET, la politique de contrle daccs peut tre largement dcrite indpendamment du code fonctionnel des composants. Dans les architectures conteneur, le principe dinversion mis en place permet dimplmenter les politiques de contrle daccs en amont des composants mtier. La cohrence de la politique daccs mise en place repose sur deux principes :

1. 2.

La viabilit du modle de scurit et la robustesse de son implmentation Lapplication correcte de la politique daccs

Le deuxime point fait partie du cahier des charges du dveloppeur dapplications. En gnral, des experts en scurit sont ncessaires pour rsoudre ce problme que lon peut ds lors considrer comme essentiellement mtier. Le premier point est lui du domaine de la logique systme et est donc essentiellement du ressort de la plateforme sous-jacente et de son implmenteur. Les plateformes modernes sont gnralement considres comme assez robustes mais non infaillibles (ce que la licence dutilisation du logiciel explicite clairement en gnral). Lexprience montre que seuls le dploiement large-chelle et le test en grandeur nature - en production - des plateformes ainsi que loccurrence (invitable) dvnements malencontreux suivie de lanalyse prcise de la faille exploite conduisent des niveaux de robustesse vraiment acceptables. Cette phase de solidification de la plateforme prend en gnral plusieurs annes.

Rsistance aux pannes

Malgr les nombreux efforts dans ce sens, les services de rsistance aux pannes rellement exploitables ne sont pas encore lgions dans le domaine des composants rpartis. Ceci peut en partie sexpliquer par la grande complexit des problmes poss par les pannes partielles des systmes rpartis. Les services de rsistance aux pannes en cours de dveloppement, par exemple dans le cadre du serveur dentreprise K2 [23], se concentrent sur deux types de pannes de granularit assez importante : 1. 2. 3. Les pannes de processus serveur : occasionnes par exemple par des bogues dans le logiciel, ou encore rsultant dune attaque ou dune manipulation malencontreuse. Les ruptures de connexion entre clients et serveurs. Les pannes matrielles totales : qui occasionnent larrt de tous les processus serveurs tournant sur un ordinateur spcifique

Dans le cadre des applications de type 3-tiers classiques , les serveurs de donnes coupls aux moniteurs transactionnels apportent une aide prcieuse pour la fiabilisation des systmes. En effet, dans le domaine de la gestion des donnes, des technologies avances offrant un haut niveau de rsistance aux pannes sont disponibles. Les serveurs de donnes peuvent tre ainsi rpliqus sur plusieurs machines physiques. Si lune de ces machines tombe en panne, lexcution peut continuer sur lune des rpliques (moyennant de complexes protocoles de synchronisation et de rollback ou retour en arrire). La journalisation permet galement de rejouer des transactions anciennes, prcdemment valides mais dont les effets ont t perdus lors de la panne. Les spcifications CORBA supportent la rsistance aux pannes dans les objets rpartis (et par voie de transitivit, dans les composants CCM) depuis la version 2.5. Lide est de mettre en uvre une rplication par objet offrant une proprit de cohrence forte. Il sagit de garantir que lobjet serveur et toutes ses rpliques, au sein de ce que lon appelle un groupe dobjets, proposent au mme moment exactement le mme tat. Plus prcisment, cest ce quil sagit de faire croire au client puisque les dlais de communication ne permette pas dobtenir ce cas idal en pratique. Malgr lintrt vident de telles approches, il est important de comprendre que la synchronisation forte ncessaire pour maintenir les objets serveurs et leur rpliques jour est trs coteuse ; elle nest envisageable que dans le cadre de systmes de taille rduite, essentiellement en rseau local. Dans le monde du P2P, la rplication est un phnomne naturel. Lorsquun service est rclam sur une infrastructure P2P, on ne se proccupe pas vraiment de qui rpond, le choix du fournisseur tant dpendant du protocole de routage non-dterministe. Ce dcouplage est trs intressant en matire de rsistance aux pannes dans le cadre dapplications large chelle. Il sagit dun domaine de recherche trs actif mais dont les applications concrtes restent encore peu nombreuses.

Autres aspects
Dautres aspects de contrle, qui peuvent prendre une importance capitale dans certains domaines mtiers, comme le temps rel ou la mobilit, sont galement ltude par la communaut scientifique. Certains travaux prototypes sont dores et dj proposs mais le passage au monde industriel largechelle reste ici galement effectuer.

Le dploiement logiciel
Le dploiement applicatif concerne le passage du logiciel de sa forme descriptive (code source/objet, ressources statiques, etc.) sa forme oprationnelle (excution du code, communications, etc.). Dans le cadre rparti, cette phase de dploiement est autrement plus complexe que dans le cadre centralis. Il sagit au minimum de : 1. 2. 3. 4. 5. Dresser la carte des sites dexcution possibles. Installer les implmentations sur les sites choisis. Crer les instances de composants. Configurer les composants et interconnexions entre composants. Arrter et dtruire les composants et les ressources associes.

Pour installer les implmentations des composants, une reprsentation binaire standard doit tre dfinie ; il sagit des paquetages logiciels. Les paquetages contiennent le code applicatif, les ressources statiques ncessaires au fonctionnement de ce code (ex. : des images, du texte, etc.) ainsi que des descripteurs de dploiement qui dcrivent en quelque sorte le contenu et le mode demploi du paquetage. Le descripteur de dploiement est galement loutil privilgi pour dcrire les politiques de scurit associes au bon usage du ou des composants encapsuls dans le paquetage. Le dploiement du logiciel est galement concern par le retrait de composants, ou le remplacement de composants par dautres composants, ou encore par la modification des interconnexions entre composants. Ces aspects souvent considrs comme mineurs sont en fait aussi important que la phase initiale de dploiement.

Gestion du cycle de vie

La terminologie objet spare clairement le pendant conceptuel des objets - leur classe - et leurs reprsentants oprationnels - les instances. Les modles de composants, en revanche, parlent de composants la fois en termes conceptuels et oprationnels. Mais il est tout de mme important de faire une distinction entre la description des composants, on parle parfois de dfinition ou de type de composant, et leur oprationnalisation sous forme dinstances de composants. Le cycle de vie des composants concerne la gestion oprationnelle des instances de composants. Dans les plateformes intergicielles, cette gestion du cycle de vie est complexifie en raison de la nature rpartie du dploiement. Le cycle de vie dun composant peut-tre plus ou moins long. On distingue souvent au moins deux catgories principales ce niveau : 1. 2. Les composants de session qui possdent une dure de vie limite. Les composants entit dont la dure de vie nest pas prcisment dlimite.

Cette terminologie est avant tout spcifique aux architectures 3-tiers ; les composants de session y implmentant les processus mtiers dans une session client et les entits servant dentres persistantes dans les bases de donnes. Dautres types de composants sont ltude comme les composants systme, les composants orients messages, etc. Il est cependant possible de rsumer les phases essentielles du cycle de vie des composants logiciels rpartis, quels que soient leur type, selon le schma de la figure 10.
Figure 10 : Gestion du cycle de vie des composants rpartis

Erreur ! Liaison incorrecte. Linstanciation des composants correspond la cration dinstances de composants partir de leur description sous forme de paquetage. Les instances se divisent gnralement en deux partie, linstance proprement dite, vocation mtier, et son contexte systme. Le principe dinversion du contrle discut prcdemment explique cette subdivision. Aprs cration des instances et contextes de composants, ces derniers doivent tre configurs (cf. section suivante). La rsolution de lidentit du composant permet de le rendre disponible depuis lextrieur. Il peut sagit de la mise en uvre de services simples de nommage, ou de services plus volus de rpertoires partags ou de certificats, si lon dsire protger laccs au composant. Le composant devient alors disponible et est activ lorsque lon interagit avec lui. Les composants sessions sont en gnral actifs pendant toute leur dure de vie mais des variations du

modle sont apparues rcemment, comme par exemple les message Beans dans les EJB, qui eux ne sont actifs que lorsquils reoivent un message, et passifs le reste du temps. Les composants entits alternent galement du mode passif au mode actif en raison de leur nature persistante. De nombreuses plateformes raffinent ce schma minimal en ajoutant de nouveaux tats ou de nouvelles transitions entre les tats. Par exemple, les spcifications OSGi Service Platform [24], spcialises dans les applications rseaucentriques, prvoient le fonctionnement en mode dconnect des composants. Un cycle est donc possible au niveau de la rsolution du composant, ce dernier pouvant tre un moment accessible depuis lextrieur et un autre moment dconnect du rseau.

Configuration et assemblage
Dans la section prcdente, la transition du cycle de vie qui fait passer un composant dploy dun mode cr un mode configur occupe une place importante. La configuration dun composant concerne la modification des paramtres - gnralement nomms proprits - qui en rgissent le fonctionnement. Certaines proprits sont statiques, dcides au moment de la dfinition mme du composant, ou plutt au moment de sa mise sous forme de paquetage logiciel. Au-del de cette configuration statique, les composants possdent en gnral des proprits que lon peut configurer, voir modifier, au moment de lexcution. Ce concept de configuration dynamique de proprit, popularis par le modle assez avantgardiste des JavaBeans, offre un surcrot douverture aux composants rpartis. On peut classer les mcanismes de configuration dynamique en deux catgories : 1. 2. Mcanismes dintrospection pour dcrire quels sont les proprits configurables Mcanismes de modification des valeurs de proprits

Le deuxime point passe gnralement par certaines conventions au niveau des interfaces de mthodes de composant, comme par exemple lutilisation standardise de prfixes get et set suivis des noms de proprits configurables. Pour des proprits configurables par des donnes simples comme des entiers ou des chanes de caractres, ces conventions de nommage sont suffisantes mais des mcanismes plus volus dintrospection sont ncessaire dans le cadre gnral. Ces mcanismes reposent gnralement sur des descriptions de haut-niveau, sous la forme de mta-donnes, associes aux descripteurs de dploiement. Au-del de la configuration isole des composants, les plateformes voluent lheure actuelle vers des mcanismes plus gnraux de configuration dassemblages de composants. Il sagit ici de configurer les interconnexions entre les composants. Encore une fois, cette configuration repose la fois sur des principes statiques, comme par exemple la mise en relation dinterfaces requises avec les interfaces fournies correspondantes, et galement, et de plus en plus, sur des principes dynamiques. La configuration dynamique des interconnexions de composants prend gnralement de limportance dans le cadre des modles de communication dcoupls dans lespace comme par exemple les modles de publication/souscription vnementiels. Ainsi, dans les composants CCM, la mise en correspondance entre sources et puits dvnements est essentiellement ralise au moment de lexcution des composants. Les architectures qui considrent les assemblages de composants comme des composants (composites) part entire, comme notamment les spcifications Fractal, disposent semble-t-il dun avantage sur les modles plus plats en matire de configuration dynamique.

Vers ladaptation logicielle

Dans ce qui prcde, nous avons dcrits les principes de dploiement classiques des applications rparties, reposant sur un enchanement purement squentiel des activits du dploiement. Ce cycle, conduisant du dploiement du code jusqu la configuration de lapplication avant son dmarrage, est largement remis en question dans le cadre de ladaptation logicielle [25]. Lide est de pouvoir intervenir sur le fonctionnement du systme aprs la premire phase de dploiement. Ainsi, lon veut pouvoir enrichir le systme en dployant de nouveaux composants, sans pour autant interrompre le fonctionnement actuel du systme. Le remplacement chaud dun composant par un autre est galement une opration intressante. Par exemple, cela permet de remplacer un composant dfectueux par une version corrige. La reconfiguration au vol du systme permet de modifier les paramtres de fonctionnement du systme. Enfin, ladaptation logicielle sintresse la possibilit de modifier dynamiquement les interconnexions entre composants. Si les applications pratiques de ces principes, par ailleurs largement discuts dans le monde de la recherche scientifique, sont encore peu nombreuses, les

grands acteurs des composants rpartis sy intressent de plus en plus. Nous pouvons par exemple signaler le projet autonomic computing dIBM [26]. Les approches bases sur la composition dynamique et hirarchique semblent particulirement attractives pour supporter certaines fonctionnalits adaptatives comme le rassemblage dynamique des applications. Mais les exprimentations en grandeur nature de ces principes adaptatifs semblent encore rares, voire inexistants.

Conclusion
Les architectures de composants logiciels ont pour ambition de devenir la cl de vote technologique des applications rparties large chelle de demain. Pour cela, nous lavons vu dans ce chapitre, de nombreuses questions encore en suspend aujourdhui devront tre discutes. Les modles actuels de gestion de concurrence et de fiabilisation sont encore assez pauvres, voir pratiquement inexistants, dans les plateformes industrielles. Ces plateformes, notamment les composants EJB de SUN, les composants CCM de CORBA et les technologies .NET de Microsoft se concentrent sur la problmatique spcifique des serveurs dentreprise et des architectures N-tiers, lheure actuelle la killer application des technologies componentielles. Mais les domaines mergents de lInternet, notamment les technologies P2P ou centres rseaux montrent que le concept de killer application est assez changeant. Avec lintroduction ininterrompue de nouveauts, comme par exemple les Message Beans pour Sun ou le dveloppement de SOAP chez Microsoft, il est cependant clair que ces technologies couvrent des domaines applicatifs de plus en plus vastes. Cette volution constante se veut plus matrise, plus concentre sur le long terme, lOMG. Les composants CCM intgrent par exemple lorigine beaucoup plus de fonctionnalits que leurs quivalents chez Sun et Microsoft. Ils sarticulent de plus dans une infrastructure trs ambitieuse et de trs grande envergure, couvrant lensemble des besoins du dveloppement informatique, des aspects mtiers des architectures orientes modles jusquaux technologies CORBA de bas niveau. Lexprience des intergiciels objets, qui est loin dtre un chec mais dont le dploiement sest fait en moindre nombre que prvu, montre cependant que la vision long terme est un exercice dlicat en informatique industrielle.

Bibliographie
[1] George Coulouris et al., Distributed Systems Concepts and Design, Prentice-Hall, 2001. [2] IEEE Distributed Systems Online, http://dsonline.computer.org [3] Jean-Pierre Briot, Rachid Guerraoui et Klaus-peter Lhr, Concurrency and Distribution in ObjectOriented Programming, ACM Computing Surveys, 1998 [4] Andy Oram et al. Peer-to-peer, Harnessing the Power of Disruptive Technologies, OReilly & associates, 2001. [5] Fran Berman et al. Grid Computing: Making the Global Infrastructure a Reality, Wiley, 2003. [6] Sun Microsystems, Jini Network Technology, http://wwws.sun.com/software/jini [7] Consortium ObjectWeb, The Fractal Project, http://fractal.objectweb.org [8] Consortium ObjectWeb, ProActive, http://www-sop.inria.fr/oasis/ProActive [9] Gordon S. Blair et al. The Design and Implementation of Open ORB 2, IEEE DS Online, Vol. 2, N6, 2001 [10] JBoss Inc., JBoss Application Server, http://www.jboss.org/product/jbossas [11] Spring, Java/J2EE Application Framework, http://www.springframework.org [12] Guruduth Banavar, et al. A Case for Message Oriented Middleware. Lecture Notes in Computer Science 1693, 1999 [13] Microsoft, Microsoft Message Queuing (MSMQ), http://www.microsoft.com/msmq [14] IBM, WebSphere MQ, http://www-306.ibm.com/software/integration/wmq [15] Sun Microsystems, Java Messaging Service (JMS), http://java.sun.com/products/jms [16] ScalAgent Distributed Technologies, Mediation Suite, http://www.scalagent.com

[17] Patrick Eugster et al. The Many Faces of Publish/Subscribe, ACM Computing Surveys, Vol. 35 N2, Juin 2003 [18] David Garlan et Mary Shaw, Software Architecture: Perspectives on an Emerging Discipline, Prentice-Hall, 1996 [19] Sun Microsystems, J2EE Connector Architecture, http://java.sun.com/j2ee/connector [20] Object Management Group, CORBA Concurrency Service 1.0, http://www.omg.org/technology/documents/formal/concurrency_service.htm [21] IBM et al. Business Process Execution Language for Web Services (BPELWS) 1.1, http://www106.ibm.com/developerworks/library/ws-bpel [22] Business Process Management Initiative, Business Process Modelling Language (BPML) 1.0, http://www.bpmi.org/specifications.esp [23] ICMG, K2 Component Server, http://www.icmgworld.com/corp/k2/k2.overview.asp [24] OSGi Alliance, OSGi Service Platform Release 3, http://www.osgi.org [25] Michel Riveill editeur, Systmes composants adaptables et extensibles, Technique et Science Informatique, Hermes Science, Vol. 23 N2, 2004 [26] IBM, Projet Autonomic Computing, http://www.research.ibm.com/autonomic [27] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns, Addison-Wesley, 1995 [28] Holger Wunderlich, Building Multi-Tier Scenarios for WebSphere Enterprise Applications, IBM Redbooks, 2004 [29] Giuseppe Milicia et Vladimiro Sassone, The inheritance anomaly: ten years after, Symposium on Applied Computing, ACM Press, 2004.