Corba Messaging

Les sp´ecifications de CORBA Messaging ([69]) introduisent quelques caract´eristiques impor-tantes `a CORBA, dont les trois principales sont : l’invocation asynchrone de m´ethode (asynchronous method invocation, AMI), l’invocation ind´ependante du temps (time-independent invocation, TII), et les politiques de QoS sur les messages.

La sp´ecification CORBA AMI d´efinit deux mod`eles, le polling et le callback :

– Dans le Polling Model, lorsqu’un client fait un appel de m´ethode, il r´ecup`ere un objet lo-cal sp´ecifique appel´e poller qui va attendre la r´eponse de l’objet cible. Le client peut donc r´eguli`erement aller chercher la r´eponse sur le poller (ou se mettre en attente du retour sur le poller). Le Polling Model est illustr´e sur la figure 1.13.

Client

1- Operation(args) 1bis - poller

poller

2- réponse 2bis

3- get

Objet Cible

Figure 1.13 – Mod`ele Polling dans Corba AMI.

– Dans le Callback Model, le client invoque l’op´eration sur l’objet et donne une r´ef´erence d’objet local responsable du retour d’invocation (le reply handler) puis reprend la main. Lorsque le serveur retourne, l’ORB client rec¸oit la r´eponse et la transmet au reply handler appropri´e fourni par le client. Le Callback Model est illustr´e sur la figure 1.14.

12«domaine»au sens«domaine r´eseau Microsoft Windows»

24 CHAPITRE 1. ETUDE DES INTERGICIELS ASYNCHRONES

Client

1- Operation(callback,args)

2- réponse 3- upcall

Objet Cible

callback

Figure 1.14 – Mod`ele Callback dans Corba AMI.

Les deux mod`eles AMI ont l’avantage de ne pas n´ecessiter de thread suppl´ementaire chez le client, permettant `a l’application de g´erer plusieurs invocations simultan´ement.

La sp´ecialisation TII de CORBA Messaging permet de supporter la s´emantique du store and forward, autrement dit le message queuing. En utilisant le TII, les requˆetes et r´eponses sont d´elivr´ees lorsque la connexion r´eseau, le routage, etc. le permettent. Pour cela, TII d´efinit un protocole de routage standard (IRP) pouvant ˆetre interfac´e avec les routeurs de diff´erents fournisseurs et mˆeme des MOM.

Malgr´e ces diff´erents modes, Corba Messaging reste avant tout un ORB. Son but reste de faire de l’appel de m´ethode `a distance mais ne propose pas de d´efinition plus pouss´ee de la s´emantique de d´elivrance ou surtout de traitement de messages comme dans un v´eritable intergiciel asynchrone.

Seule la notion de QoS sur certaines caract´eristiques du TII comme la gestion des queues de messages ou la priorit´e de message permet de manipuler un peu la d´elivrance mais ne suffit pas `a fournir les propri´et´es attendues d’un intergiciel asynchrone.

Une impl´ementation existe sur TAO [7] mais reste pour l’instant fig´ee¹³. Il n’est pas possible de configurer les fonctionnalit´es de l’intergiciel et le d´eploiement de l’intergiciel n’est pas pris en charge, chaque site devant ˆetre d´eploy´e«`a la main».

1.3.2.4 JMS (Java Messaging Service)

Sun a choisi vis `a vis des ´editeurs d’intergiciels asynchrones une politique similaire `a celle de JDBC vis-`a-vis des ´editeurs de bases de donn´ees : d´efinir un mod`ele de programmation bas´e sur un ensemble d’interfaces portables quelle que soit l’impl´ementation utilis´ee. Le but est de normaliser l’acc`es aux intergiciels asynchrones ind´ependamment de la structure et de l’architecture interne de l’outil. La sp´ecification de SUN s’appelle JMS pour Java Messaging Service [44], elle traite des modes de communication MessageQueueing et Publish/Subscribe (par abonnement) que nous avons vus pr´ec´edemment. Elle a ´et´e d´evelopp´ee par les principaux acteurs de ce domaine (IBM, Tibco, BEA,...) et poss`ede de nombreuses impl´ementations.

Une br`eve pr´esentation de JORAM, une impl´ementation Open Source de JMS dans le cadre du consortium ObjectWeb, est donn´ee dans la suite.

JMS `a travers JORAM JORAM est une impl´ementation Open source des sp´ecification JMS de SUN. JORAM est d´evelopp´e par la soci´et´e Scalagent (start-up de l’ancienne ´equipe A3 pr´esent´ee dans la section 1.3.1.4) dans le cadre du consortium ObjectWeb. JORAM fournit un intergiciel asynchrone

`a base de messages construit sur la plate-forme distribu´ee A3.

JORAM fournit un support complet des sp´ecifications de JMS dans lesquelles il existe deux styles de gestion de messages : le mod`ele de message point `a point (Point-to-point) ou le mod`ele par

abon-13L’utilisation de l’ORB reflexif DynamicTAO (voir section 2.2.2.2) avec cette impl´ementation pourrait n´eanmoins ˆetre int´eressante pour la configuration de l’intergiciel.

1.4. CONCLUSION 25

Figure 1.15 – JORAM.

nement (Publish/Subscribe). Rien n’empˆeche une application d’utiliser les deux modes `a la fois, cependant JMS se focalise sur les applications qui utilisent l’un ou l’autre. JMS introduit deux termes pour d´efinir les applications clientes de l’API JMS. Il y a les consommateurs qui repr´esentent tous les clients qui rec¸oivent un message que ce soit en mode synchrone (r´eception en attente de message) ou asynchrone (r´eception sans attente). Les clients qui envoient des messages sont appel´es produc-teurs. JORAM utilise JNDI (Java Naming and Directory Interface) comme syst`eme de nommage pour trouver des clients destinataires, des sujets d’abonnement, etc.

JORAM poss`ede une architecture distribu´ee de ces serveurs JMS bas´ee sur l’utilisation des ser-veurs A3. Cette architecture permet, par exemple, de g´erer des sujets d’abonnement (topic) distribu´es.

Ceci a l’avantage d’all´eger la charge sur les serveurs responsables de topic tr`es demand´es.

Certaines fonctionnalit´es ne sont pas incluses dans les sp´ecifications de JMS : la tol´erance aux fautes, la notification d’erreurs, l’administration, la s´ecurit´e et un standard de persistance de mes-sages. De plus, la notion d’´ev´enement/r´eaction n’est pas pr´esente dans les sp´ecifications. N´eanmoins l’engouement de l’industrie pour JMS montre bien l’int´erˆet port´e aux intergiciels asynchrones et sur-tout le besoin d’un standard commun permettant l’interop´erabilit´e entre les diff´erents intergiciels.

1.4 Conclusion

Un des crit`eres que l’on peut appliquer lors d’une analyse ou d’une d´efinition d’une architecture est le degr´e de libert´e (ou de couplage possible) entre plusieurs applications. L’appel de proc´edure

`a distance est typiquement une technologie imposant un couplage fort entre les applications parce qu’elle impose aux clients et aux serveurs d’ˆetre actifs en mˆeme temps et qu’elle ne save pas g´erer l’´evolution des composants. A l’oppos´e, les intergiciels asynchrones favorisent le d´ecouplage car ils proposent des modes de communication tr`es souples ; les applications ne communiquent plus direc-tement entre elles mais s’´echangent des messages par l’interm´ediaire d’un m´ediateur. L’intergiciel asynchrone devient donc un outil indispensable pour l’int´egration de syst`eme ou d’application mo-derne mettant en jeu des syst`emes de plus en plus h´et´erog`enes, mobiles, et `a grande ´echelle.

Nous pensons qu’il se d´egage clairement deux parties bien distinctes dans l’impl´ementation des intergiciels asynchrones : une partie responsable de la d´elivrance des messages et une partie en charge du traitement des messages. La partie responsable de la d´elivrance, ou mod`ele de d´elivrance, d´efinit les principes fondamentaux du transfert des messages entre les diff´erents sites (l’architecture des sites, le routage des messages, etc.). La partie en charge du traitement des messages d´efinit la mani`ere dont

26 CHAPITRE 1. ETUDE DES INTERGICIELS ASYNCHRONES les messages vont ˆetre manipul´es avant (ou apr`es) avoir ´et´e transf´er´es (mod`ele de communication, propri´et´es sur les messages, etc.). Ce mod`ele de traitement des messages d´efinit la s´emantique de l’application, il sp´ecifie le mod`ele de d´elivrance en fonction des applications. Nous nous baserons sur cette constatation pour notre proposition d’un mod`ele d’intergiciel asynchrone bas´e sur le d´ecoupage en un mod`ele de d´elivrance et un mod`ele de traitement des messages.

Insuffisance des solutions actuelles Les intergiciels asynchrones actuels n’abordent pas de fac¸on suffisante les probl`emes de configuration et de d´eploiement de l’intergiciel. Les diff´erents projets pr´esent´es, repr´esentatifs de l’ensemble des intergiciels asynchrones, ne permettent pas le change-ment de la structure des impl´echange-mentations pour les adapter `a des besoins sp´ecifiques (enlever certaines propri´et´es coˆuteuses, changer l’architecture de communication des sites, etc.). Nous pr´esentons ci-dessous une grille r´ecapitulative des diff´erents projets et produits¹⁴en fonction de leur configurabilit´e, de leur capacit´e de d´eploiement et de leur habilit´e au passage `a grande ´echelle (scalabilit´e).

Projet/Produit Configurabilit´e D´eploiement Scalabilit´e

JEDI

- -

GRYPHON

- -

SIENA

- -

A3

-

MQSeries +

-

MSMQ +

- -

Corba Messaging

- -

-Comme on peut le voir, les projets de recherche travaillent essentiellement au niveau de la scalabi-lit´e. Certain en optimisant leur algorithme de diffusion (Gryphon, SIENA), d’autres en hi´erarchisant leur architecture (A3, JEDI). Et seul A3 propose un d´ebut de solution de d´eploiement de l’intergiciel avec un service¹⁵d’instanciation de serveurs `a distance. Les produits industriels (MQSeries, MSMQ) essayent quant `a eux de fournir quelques supports de configuration pour le traitement des messages

`a l’aide d’outils d’administration des files de messages. Mais globalement, peu se pr´eoccupent des probl`emes de configurabilit´e et de d´eploiement distribu´e de l’intergiciel.

Presque toutes les impl´ementations restent donc fig´ees quels que soient les sites d’ex´ecution et l’application (ou les applications) l’utilisant. L’ensemble des propri´et´es non fonctionelles offertes par l’intergiciel sont donc fournies sur chaque nœud du syst`eme. Or cette rigidit´e dans la composition de l’intergiciel, si elle peut ˆetre supportable dans le cadre d’une application l´eg`ere de petite taille, devient carr´ement ing´erable lors de l’utilisation `a grande ´echelle. Nous verrons dans le chapitre4 comment la propri´et´e de causalit´e p`ese sur la scalabilit´e de l’intergiciel et les difficult´es `a configurer l’intergiciel pour all´eger ce coˆut. Les intergiciels asynchrones ne proposent pas de possibilit´es de configuration et gardent un aspect tr`es monolithique. Ils manquent de m´ecanismes permettant de contrˆoler aussi bien leur comportement que leur architecture.

De plus, les intergiciels asynchrones n’offrent souvent qu’une API de communication et ne pro-pose pas la possibilit´e d’utiliser plusieurs s´emantiques en mˆeme temps. Chaque projet supporte seule-ment un ou deux types de s´emantique (abonneseule-ment, Push/Pull, etc.) limitant consid´erableseule-ment le comportement applicatif. L’utilisation de plusieurs s´emantiques sur un mˆeme intergiciel, au lieu de plusieurs intergiciels avec une seule s´emantique applicative, permettrait d’all´eger la charge sur les sites d’ex´ecution. Depuis l’apparition de la sp´ecification JMS, les intergiciels asynchrones peuvent

14Nous n’avons volontairement pas inclus JMS car ses propri´et´es d´ependent de l’impl´ementation sous-jacente (A3 pour Joram, MQSeries pour WebSphere, etc.).

15Cette solution a ´et´e r´ealis´ee dans le produit de Scalagent, la start-up issue du projet A3.

1.4. CONCLUSION 27 enfin s’appuyer sur un standard d’interop´erabilit´e, mais de tr`es nombreux projets n’ont pas encore d’impl´ementation de JMS notamment `a cause de la limitation des possibilit´es s´emantiques offertes.

La plupart des intergiciels asynchrones restent donc des«usines `a gaz»monolithiques statiques qui ne sont pas configurables et donc non configur´es pour satisfaire aux exigences de l’informatique omnipr´esente.

Tous les probl`emes cit´es ci-dessus sont trait´es depuis de nombreuses ann´ees dans le cadre des intergiciels synchrones. Le chapitre suivant ´etudie les diff´erentes m´ethodes de configuration dans les intergiciels synchrones et aborde la notion du d´eploiement des intergiciels.

28 CHAPITRE 1. ETUDE DES INTERGICIELS ASYNCHRONES

Chapitre 2

Configuration et d´eploiement