Approches pour l’interopérabilité

Dans la section 2.3, nous avons défini les questions qui se posent au déve- loppeur d’une application répartie lorsqu’il souhaite intégrer dans celle-ci des composants utilisant des modèles de répartition différents ou des intergiciels incompatibles.

Nous proposons ici deux classes de réponses possibles à ces questions, et nous mettons en évidence la nécessité de retenir une solution permettant la mise en relation dynamique de modèles de répartition hétérogènes.

Approche basée sur les passerelles statiques

La mise en place de passerelles ad hoc entre modèles de répartition a été envisagée comme réponse possible à ces questions. Le travail préparatoire sur CIAO, décrit dans la section 3.3.3, a porté sur la génération automatique de passerelles entre l’annexe des systèmes répartis du langage Ada 95 et les objets répartis CORBA. Nous avons évoqué dans la section 3.3.3 les limitations liées à CIAO en particulier. Cependant, il existe également des problèmes plus généraux, inhérents à l’utilisation de passerelles statiques entre modèles de répartition.

En premier lieu, un nouveau générateur de passerelles doit être développé pour chaque couple de modèles de répartition pour lequel l’interopérabilité est souhaitée. Le coût de cette approche, croît donc en fonction quadratique du nombre d’environnements supportés. Cette explosion combinatoire limite l’in- térêt des passerelles comme solution générique pour l’interaction avec des com- posants hétérogènes.

Par ailleurs, aucune mise en commun de code n’est effectuée entre les inter- giciels correspondant à chaque modèle supporté, ni entre les différentes passe- relles. À l’exécution, l’empreinte d’utilisation de ressources de chaque passerelle

88 Conception d’un intergiciel schizophrène est donc très importante. Un point de passage unique entre modèles de répar- tition est introduit, qui est à la fois un facteur limitant des performances de l’application, et un facteur de vulnérabilité aux défaillances.

L’approche basée sur les passerelles statiques, si elle constitue un premier élément de réponse au problème de l’interopérabilité, n’est donc pas une solution pleinement satisfaisante. Il est nécessaire d’explorer d’autres voies pour obtenir des systèmes répartis interopérables performants, flexibles et sûrs.

Intergiciels à personnalités multiples

Pour lever les problèmes fondamentaux de l’approche précédente, nous pro- posons de mettre en place directement au sein de l’intergiciel les mécanismes nécessaires à l’intégration de multiples modèles de répartition.

Une solution naïve consiste à constituer un intergiciel en agrégeant plu- sieurs intergiciels existants, correspondant chacun à une personnalité. Une telle construction soulève plusieurs difficultés :

– Elle suppose que le code source des divers intergiciels utilisés est dispo- nible, et que les langages, les outils et les bibliothèques qu’ils mettent en jeu sont compatibles.

– Les différences d’architectures et de structures de données limitent les possibilités de mutualisation de code.

– Les intergiciels conçus pour ne proposer qu’une seule personnalité sont peu adaptés à la mise en commun de structures internes, car ils sont conçus sur l’hypothèse que celles-ci ne seront manipulées que par une seule per- sonnalité.

Les intergiciels personnalisables offrent un premier élément de résolution de ces problèmes. Ils identifient des composants génériques, indépendants d’un modèle de répartition. Ceux-ci sont mis en œuvre sous forme d’une « boîte à outils » dont les services sont utilisés par des composants spécifiques d’une personnalité. Ces derniers réalisent un modèle de répartition fixé. Un noyau neutre, constitué par les composants génériques, est ainsi délimité, autour duquel sont configurés les composants de personnalisation.

Cependant, si ces architectures réduisent l’ampleur des problèmes posés par l’agrégation de multiples intergiciels, ceux-ci demeurent présents. Nous avons observé, dans la section 3.1.3, que dans les mises en œuvre existantes d’intergi- ciels personnalisables, le partage de code entre personnalités est limité.

La réalisation d’une nouvelle personnalité demeure un travail considérable, qui se traduit pratiquement par le redéveloppement d’un intergiciel complet. De plus, la question de l’utilisation coordonnée de ressources internes par plusieurs personnalités demeure entière. Un couplage important entre tous les composants spécifiques d’une personnalité est encore observé, ainsi qu’une faible possibilité d’interaction entre personnalités différentes.

Découplage des aspects de personnalité

Le rôle de l’ensemble des intergiciels qui participent à une application ré- partie consiste à mettre en relation les objets qui la constituent. À cet effet, les intergiciels établissent entre eux des échanges de messages représentant les requêtes et les réponses échangées par les objets.

4.1 Intergiciel schizophrène 89 Pour satisfaire d’une manière générale les besoins d’interopérabilité entre modèles de répartition, il est nécessaire de lever les obstacles liés à l’agrégation d’intergiciels ou à l’agrégation d’instances d’un intergiciel personnalisable. En particulier, il est nécessaire de briser le couplage entre les deux aspects d’inter- face de chaque intergiciel :

– l’interface applicative présentée aux objets qu’il héberge localement et rend accessibles à distance ;

– l’interface protocolaire qu’il présente aux intergiciels distants.

La figure 4.1 illustre la différence entre les architectures qui agrègent des intergiciels et les architectures qui en découplent les composants. Dans l’ap- proche par agrégation (4.1(a)), les composants de chaque intergiciel agrégé sont fortement couplés entre eux. L’interaction entre personnalités est limitée par l’architecture des intergiciels agrégés.

Dans l’approche par composants découplés (4.1(b)), au contraire, les com- posants de personnalisation des deux aspects d’interface sont découplés :

– Les composants réalisant l’interface entre les objets d’application et l’inter- giciel n’utilisent que des services génériques de l’intergiciel. Ils n’effectuent aucun traitement, ne manipulent aucune représentation, qui soit spécifique d’un protocole particulier.

– De même, les composants réalisant un protocole ne font aucune hypothèse particulière sur le choix d’une interface entre objets de l’application et intergiciel. ✁✁✁✁✁✁✁ ✁✁✁✁✁✁✁ ✁✁✁✁✁✁✁ ✂✁✂✁✂✁✂✁✂✁✂✁✂✁✂ ✂✁✂✁✂✁✂✁✂✁✂✁✂✁✂ ✂✁✂✁✂✁✂✁✂✁✂✁✂✁✂ ✄✁✄✁✄✁✄✁✄✁✄✁✄✁✄ ✄✁✄✁✄✁✄✁✄✁✄✁✄✁✄ ✄✁✄✁✄✁✄✁✄✁✄✁✄✁✄ ☎✁☎✁☎✁☎✁☎✁☎✁☎✁☎ ☎✁☎✁☎✁☎✁☎✁☎✁☎✁☎ ☎✁☎✁☎✁☎✁☎✁☎✁☎✁☎ ✆✁✆✁✆✁✆✁✆✁✆✁✆✁✆ ✆✁✆✁✆✁✆✁✆✁✆✁✆✁✆ ✆✁✆✁✆✁✆✁✆✁✆✁✆✁✆ ✝✁✝✁✝✁✝✁✝✁✝✁✝✁✝ ✝✁✝✁✝✁✝✁✝✁✝✁✝✁✝ ✝✁✝✁✝✁✝✁✝✁✝✁✝✁✝ ✞✁✞✁✞✁✞✁✞✁✞✁✞✁✞ ✞✁✞✁✞✁✞✁✞✁✞✁✞✁✞ ✞✁✞✁✞✁✞✁✞✁✞✁✞✁✞ ✟✁✟✁✟✁✟✁✟✁✟✁✟✁✟ ✟✁✟✁✟✁✟✁✟✁✟✁✟✁✟ ✟✁✟✁✟✁✟✁✟✁✟✁✟✁✟ Personnalité B Interface protocolaire Personnalité A Intergiciel Interface applicative Personnalité A Interface applicative Personnalité B Interface protocolaire

(a) Couplage fort

✁✁✁✁✁✁✁ ✁✁✁✁✁✁✁ ✁✁✁✁✁✁✁ ✂✁✂✁✂✁✂✁✂✁✂✁✂✁✂ ✂✁✂✁✂✁✂✁✂✁✂✁✂✁✂ ✂✁✂✁✂✁✂✁✂✁✂✁✂✁✂ ✄✁✄✁✄✁✄✁✄✁✄✁✄✁✄ ✄✁✄✁✄✁✄✁✄✁✄✁✄✁✄ ✄✁✄✁✄✁✄✁✄✁✄✁✄✁✄ ☎✁☎✁☎✁☎✁☎✁☎✁☎✁☎ ☎✁☎✁☎✁☎✁☎✁☎✁☎✁☎ ☎✁☎✁☎✁☎✁☎✁☎✁☎✁☎ ✆✁✆✁✆✁✆✁✆✁✆✁✆✁✆ ✆✁✆✁✆✁✆✁✆✁✆✁✆✁✆ ✆✁✆✁✆✁✆✁✆✁✆✁✆✁✆ ✝✁✝✁✝✁✝✁✝✁✝✁✝✁✝ ✝✁✝✁✝✁✝✁✝✁✝✁✝✁✝ ✝✁✝✁✝✁✝✁✝✁✝✁✝✁✝ ✞✁✞✁✞✁✞✁✞✁✞✁✞✁✞ ✞✁✞✁✞✁✞✁✞✁✞✁✞✁✞ ✞✁✞✁✞✁✞✁✞✁✞✁✞✁✞ ✟✁✟✁✟✁✟✁✟✁✟✁✟✁✟ ✟✁✟✁✟✁✟✁✟✁✟✁✟✁✟ ✟✁✟✁✟✁✟✁✟✁✟✁✟✁✟ Personnalité protocolaire Y protocolaire X Personnalité applicative A applicative B Personnalité Personnalité Intergiciel neutre (b) Couplage faible

Fig. 4.1 – Intergiciels à personnalités multiples