Etude de cas

Cette section propose une description rapide de diff´erents projets acad´emiques, c’est-`a-dire des intergiciels asynchrones r´ealis´es en milieu universitaire ou dans les centres de recherche &

d´eveloppement de grandes entreprises ; puis de diff´erentes r´ealisations industrielles, c’est-`a-dire des intergiciels asynchrones d´evelopp´es `a des fins commerciales par de grandes entreprises. Nos ´etudes de cas ne sont pas exhaustives ; bien au contraire, nous nous sommes attard´es `a ne pr´esenter que les cas les plus repr´esentatifs dans leur domaine. Cette section a pour but de dresser un ´etat de l’art sur les intergiciels asynchrones sans forc´ement rentrer dans les d´etails d’impl´ementation de chacun. Nous souhaitons montrer que les projets actuels se concentrent essentiellement sur les mod`eles de commu-nication mais ne se pr´eoccupent pas ou peu des probl`emes d’adaptabilit´e des intergiciels asynchrones, question `a laquelle nous tentons de r´epondre dans les chapitres suivants. Cette ´etude nous permet, en-fin, de mettre en avant l’aspect monolithique des intergiciels asynchrones.

1.3.1 Projets acad´emiques

La notion d’interaction asynchrone est un des plus vieux m´ecanismes de coordination de-puis le d´eveloppement des syst`emes bas niveau reli´e directement aux m´ecanismes d’interruptions mat´erielles. Mais l’absence de structures et de primitives de haut niveau rendait ces syst`emes fra-giles et peu fiables. Dans les ann´ees 70, les premiers mod`eles de communication asynchrone `a base d’´echange de messages ont fait leur apparition. Les ann´ees 80 et 90 et le d´eveloppement grandis-sant des r´eseaux ont permis de voir apparaˆıtre les travaux autour des notions de queue de messages, d’´ev´enements, de syst`eme par abonnement, etc. qui ont pos´e les bases des intergiciels asynchrones actuels.

Depuis lors, les projets autour des intergiciels asynchrones se sont essentiellement centr´es sur la recherche autour des mod`eles de traitement de messages (abonnement, ´ev´enement, etc.) ou des mod`eles de d´elivrance de message (architectures, propri´et´es, etc.) avec souvent le mˆeme but : le

1.3. ETUDE DE CAS 17 passage `a grande ´echelle (ou scalabilit´e). Mais l’impl´ementation des intergiciels asynchrones ac-tuels reste souvent fig´ee et ils n’offrent souvent qu’une API de communication. Les projets ne se pr´eoccupent pas ou peu des probl`emes de configuration et de d´eploiement de l’intergiciel.

Nous pr´esentons dans cette section quatre projets qui montrent les travaux r´ealis´es autour de ces mod`eles.

1.3.1.1 JEDI

L’´ecole polytechnique de Milan a d´evelopp´e une infrastructure orient´ee objet bas´ee sur une com-munication `a ´ev´enements appel´ee JEDI (Java Event-based Distributed Infrastructure) [35]. L’archi-tecture de JEDI utilise la notion d’objet actif (Active Object, AO). Un AO est une entit´e autonome en charge d’une tache applicative sp´ecifique. Les AO communiquent entre eux en consommant et pro-duisant des ´ev´enements. Un ´ev´enement est un type de message sp´ecifique g´en´er´e par un AO et notifi´e aux autres AO selon le mod`ele par abonnement. Les ´ev´enements sont achemin´es d’un producteur `a un consommateur par l’interm´ediaire d’une infrastructure sp´ecifique responsable de la diss´emination appel´ee Event Dispatcher (ED) utilisant une architecture logique en bus (voir figure1.9).

Event Dispatcher

AO AO

AO AO AO

Site1

Site3 Site2

Figure 1.9 – Architecture de JEDI.

Les AO peuvent utiliser deux types d’abonnements : soit l’abonnement bas´e sur le nom d’un ´ev´enement (subjet-based), soit bas´e sur un patron d’´ev´enement (pattern-based). Un pa-tron d’´ev´enement est un ensemble de chaˆınes de caract`ere ordonn´ees repr´esentant une expression r´eguli`ere. Un ´ev´enement ´etant compos´e d’un nom puis de param`etres (= donn´ees), un ´ev´enemente correspond `a un patronpssi les conditions suivantes sont satisfaites :

– Le nom deeest ´equivalent au nom depo`u le nom depest constitu´e d’un pr´efixe puis d’une

´etoile (caract`ere*) eteetpont le mˆeme pr´efixe.

– eetpont le mˆeme nombre de param`etres.

– Chaque param`etre dep qui n’est pas ´egal `a “ ” est le mˆeme que le param`etre correspondant pour l’´ev´enemente.

Il existe deux types d’AO : les objets actifs g´en´eriques et les objets actifs r´eactifs. Les premiers gˆen`erent des ´ev´enements puis se mettent en attente active (bouclent) sur l’arriv´ee d’´ev´enements pro-voquant un coˆut de traitement ´elev´e. Les objets actifs r´eactifs sont bas´es sur le mod`ele ´ev´enement-r´eaction et ne sont«r´eveill´es»par le syst`eme que lors d’arriv´ee d’´ev´enements. Les objets r´eactifs ont la facult´e de se d´eplacer d’un site `a l’autre, l’ED se chargeant de router les messages vers le nouveau site de l’AO.

JEDI est un projet int´eressant car il impl´emente la notion d’´ev´enement par abonnement sur une architecture en bus scalable et permet les deux types d’abonnement bas´es sur le sujet ou sur le patron (≈sur le contenu) de l’´ev´enement. N´eanmoins, il poss`ede sa propre interface de programmation qui

18 CHAPITRE 1. ETUDE DES INTERGICIELS ASYNCHRONES ne permet pas d’interagir avec d’autres intergiciels asynchrones. De plus, les ´ev´enements ´echang´es ne peuvent ˆetre que de type Java simple et il n’est pas possible d’utiliser des types d’´ev´enements complexes comme des graphes d’objets. Cela r´eduit, certes, le coˆut des messages ´echang´es et donc am´eliore la scalabilit´e de l’ensemble mais limite grandement l’interop´erabilit´e et surtout le spectre d’application possible (l’utilisation de chaˆınes de caract`eres structur´ees comme l’XML serait plus adapt´ee `a l’´echange d’information).

L’aspect configuration de l’intergiciel n’est pas trait´e par JEDI. Il n’est pas possible de manipu-ler sa structure interne pour modifier son comportement. Le bus `a ´ev´enement (ED) est fourni avec l’ensemble de ses propri´et´es et de ses fonctionnalit´es sans changement possible. De plus, mˆeme si l’architecture hi´erarchique des sites (formant le bus global) am´eliore la scalabilit´e, elle reste fig´ee et ne peut pas s’adapter `a d’autre besoins.

1.3.1.2 IBM Gryphon

Le projet Gryphon d’IBM Research Center a pour but le d´eveloppement d’un intergiciel asyn-chrone essentiellement centr´e sur un gestionnaire de diffusion par abonnement [12]. Leur syst`eme utilise un algorithme sp´ecifique permettant d’acc´el´erer la distribution des messages. Cette diffusion est bas´ee sur le principe de l’abonnement bas´e sur le contenu (voir section 1.2.1.2). Les clients de Gryphon acc`edent `a l’intergiciel par l’interm´ediaire de l’API JMS.

Les motivations de Gryphon sont ax`es sur trois propri´et´es : la scalabilit´e (le passage `a grande

´echelle), la disponibilit´e et la s´ecurit´e.

– Scalabilit´e : Afin d’am´eliorer le passage `a grande ´echelle, Gryphon utilise simplement la dis-tribution de serveurs de messages interconnect´es. Gryphon a ´et´e l’un des premiers `a utiliser la r´epartition sur des sites distants pour r´epartir la charge dˆue `a l’augmentation du nombre de client. La connectivit´e des serveurs est assur´ee par une architecture snow flake.

– Disponibilit´e : Le syst`eme assure une disponibilit´e du service dans son ensemble en informant automatiquement les clients d’une panne de serveur pour les r´eorienter vers un autre et cela de fac¸on automatique.

– S´ecurit´e : La s´ecurit´e du syst`eme est assur´ee par plusieurs types de connexion possibles des clients. Soit le client utilise un simple mot de passe, soit il utilise une authentification mutuelle s´ecuris´ee soit il se connecte avec du sym´etrique ou asym´etrique SSL. De plus, les messages peuvent ˆetre crypt´es par l’utilisation de m´ethodes standards (`a cl´es, etc.).

Beaucoup de travaux de recherche ont ´et´e mod´elis´es dans cette ´equipe mais peu ont r´eellement

´et´e d´evelopp´es sur l’intergiciel Gryphon. La plupart des articles de ces derni`eres ann´ees ne pr´esentent que des travaux futurs (comme sur l’utilisation de la r´eflexivit´e) mais pas de r´ealisations concr`etes.

Le syst`eme Gryphon a ´et´e utilis´e, avec succ`es, pour des ´ev´enements de grande ampleur⁸, confir-mant son potentiel de passage `a grande ´echelle. N´eanmoins, il ne reste «qu’un »intergiciel asyn-chrone ne proposant que le m´ecanisme d’abonnement et ne permet pas la combinaison de plusieurs mod`eles de traitement de messages. Il se cantonne `a proposer une impl´ementation de JMS un peu plus scalable que les autres grˆace `a son algorithme de diffusion performant. Mais, il ne permet pas de mo-difier son comportement pour l’adapter `a telle ou telle application ou syst`eme. L’aspect d´eploiement n’est pas non plus abord´e dans Gryphon et il est n´ecessaire que les sites soient tous actifs avant de d´emarrer les ´echanges de messages.

8La diffusion des r´esultats sportifs en temps r´eel de l’Open de Tennis US ou pour les jeux olympiques de Sydney 2000.

1.3. ETUDE DE CAS 19