Extension de ScalAgent

Description

Introduction. ScalAgent est un intergiciel orient´e messages (MOM : Message-Oriented Middleware). [Quema and Bellissard, 2002] pr´esente une extension de ce syst`eme permettant d’optimiser la configuration du middleware en fonction des besoins non-fonctionnels exprim´es par les applications.

ScalAgent. Le middleware ScalAgent fournit un mod`ele de communication asynchrone inspir´e des ac- teurs [Agha, 1985]. Il est constitu´e d’ un canal de communication (« channel »), qui assure le transport des messages, et d’un « moteur » (engine) qui s’occupe de router les messages re¸cus vers les composants ap- propri´es. Le middleware lui-mˆeme est construit `a base de composants et des propri´et´es non-fonctionnelles peuvent y ˆetre ajout´ees, soit dans le moteur (cas de la persistance par exemple), soit dans le canal de communication (par exemple pour assurer le s´ecurit´e des communications). Chaque composant non- fonctionnel peut ajouter des attributs aux composants applicatifs pour r´ealiser sa fonction ; par exemple, le composant qui impl´emente le service de persistance utilise un attribut "location" associ´e `a chaque composant applicatif persistant pour savoir o`u le sauvegarder. Dans ce syst`eme, la construction d’un application se fait en trois phases :

1. Description de l’architecture de l’application grˆace `a un adl [Medvidovic and Taylor, 2000] bas´e sur Olan [Balter et al., 1998] mais utilisant un syntaxe xml6_.

2. Instanciation de cette architecture, en sp´ecifiant quels composants doivent ˆetre d´eploy´es sur quels sites.

3. D´eploiement des composants sur les diff´erents sites, sur chacun desquels doit se trouver un middle- ware ScalAgent compatible avec les besoins non-fonctionnels des composants.

ADL ´etendu. Bien que ScalAgent soit modulaire et configurable, dans la version standard du syst`eme, l’infrastructure est homog`ene : tous les sites disposent d’une configuration identique du middleware. Ceci peut poser de gros probl`emes si certains des hˆotes ont des capacit´es restreintes, car ils doivent quand mˆeme supporter l’ensemble des fonctionnalit´es utilis´ees par tous les composants de l’application. La premi`ere extension de ScalAgent propos´ee dans [Quema and Bellissard, 2002] concerne l’adl utilis´e pour d´ecrire les composants applicatifs et l’architecture de l’application. ´Etant bas´e sur xml, cet adl est facilement extensible. La version ´etendue de ce langage permet la sp´ecification des propri´et´es non-fonctionnelles directement dans le langage en indiquant les valeurs des attributs g´erant ces propri´et´es. Par exemple, la description xml d’un composant qui doit ˆetre persistant contiendra un ´el´ement suppl´ementaire indiquant comment et o`u il doit ˆetre sauvegard´e. Pour chaque composant applicatif, il est aussi possible de sp´ecifier

6

l’ensemble des sites sur lesquels il peut ˆetre d´eploy´e ; si rien n’est sp´ecifi´e, il pourra a priori ˆetre d´eploy´e sur n’importe lequel.

D´eploiement. L’algorithme de configuration et de d´eploiement est ´etendu pour prendre en compte les nouvelles informations ajout´ees `a l’adl. Il utilise une analyse de coˆuts pour d´eterminer pour chaque site la configuration optimale du middleware (en levant la contrainte d’homog´en´eit´e) et les composants applicatifs `a y d´eployer. Ainsi, seuls les services r´eellement utiles aux composants pr´esents sur un site y sont configur´es. Pour ´evaluer les coˆuts, l’algorithme interroge chacun des composants fournissant les services non-fonctionnels en lui indiquant les caract´eristiques mat´erielles du site, le nombre total de composants `

a y d´eployer, et le nombre de ces composants que le service doit prendre en charge. Le composant renvoie un entier correspondant `a son ´evaluation du coˆut de la gestion de la propri´et´e non-fonctionnelle dans ces circonstances. Cette analyse de coˆut, qui prend en compte, entre autre, les caract´eristiques mat´erielles de l’hˆote, est `a rapprocher de nos notions de fonction d’ad´equation et de contexte d’ex´ecution. Ainsi, la nouvelle version de ScalAgent propos´ee est capable d’adapter la r´epartition des composants fonctionnels et des services non-fonctionnels en fonction de leur contexte, ici limit´e aux caract´eristiques mat´erielles des hˆotes disponibles.

´

Evaluation

Ce syst`eme ne supporte que deux types d’op´erations de d´eploiement : l’instanciation de certains services sur les noeuds du r´eseau, et la r´epartition des composants applicatifs sur ces mˆemes noeuds. On peut difficilement parler de reconfiguration dans ce cas puisque ces deux choix sont fait statiquement, une fois pour toute, et le syst`eme ne semble pas supporter de modifications dynamiques (pour cette raison, parler de performances n’a pas vraiment de sens ici). Un des avantages de cette approche est que le syst`eme offre la garantie que chaque composant sera d´eploy´e sur un noeud qui fournit tous les services dont il a besoin. En revanche, la modularit´e est assez limit´ee, puisque les services sont sp´ecifi´es noeud par noeud (cette limite est inh´erente `a l’approche traditionnelle du middleware) : si deux composants se trouvent sur un mˆeme noeud, ils doivent partager la mˆeme impl´ementation des services qu’ils ont en commun. Le syst`eme semble assez ouvert, puisqu’il est possible d’ajouter de nouveaux services `a la plate-forme et d’en faire b´en´eficier les composants applicatifs en ne modifiant que leur description dans l’adl.

Au niveau de la connaissance du contexte d’ex´ecution, les seuls ´el´ements de « contexte » semblent ˆetre les diff´erents services disponibles ou non sur les diff´erents noeuds, et des caract´eristiques non pr´ecis´ees des- dits noeuds. Bien que cela n’ait pas trop de sens ici, on peut dire que d’une certaine fa¸con, la pr´ecision des informations est parfaite, puisque l’on sait exactement quels services et quels composants sont pr´esents sur chaque noeud. En terme de richesse, le syst`eme va plus loin que la seule pr´esence ou absence d’un service grˆace `a l’analyse des coˆuts que doivent impl´ementer les services.

Concernant les strat´egies d’adaptation, le syst`eme est ferm´e puisqu’il n’en supporte en fait qu’une seule, fixe, bas´ee sur une ´evaluation des coˆuts au moment du d´eploiement (mˆeme si celle-ci est ˆetre influenc´ee par les diff´erents services). La solution propos´ee en donc plus proche de l’optimisation de d´eploiement que de l’adaptation, puisque les choix statiques ne sont jamais remis en cause. Malgr´e ce caract`ere statique, la possibilit´e d’ajouter de nouveaux services, qui influencent le choix de l’algorithme de d´eploiement, rend le syst`eme relativement g´en´erique. L’avantage d’une strat´egie fixe, est qu’elle est a priori facilement analysable ; on pourrait mˆeme imaginer prouver l’optimalit´e de ses choix de d´eploiement ´etant donn´ees les coˆuts indiqu´es par les services (mais les auteurs ne mentionnent pas cette possibilit´e).

Globalement, la solution propos´ee ne nous semble pas assez dynamique et trop limit´ee au niveau des possibilit´es de configuration ; elle ne peut convenir qu’`a des applications statiques s’ex´ecutant sur des r´eseaux qui ne changent jamais.