Bonjour Thomas. Pourrais-tu nous expliquer brièvement ce qu’est un intergiciel, et plus particulièrement un intergiciel schizophrène ?

Un intergiciel, c’est une bibliothèque qui offre aux développeurs d’application un moyen de faire interagir des composants distants sans avoir à prendre en charge certains aspects délicats de la répartition. En particulier, un intergiciel permet la communication entre composants sans que les développeurs aient à utiliser eux-mêmes les fonctionnalités de communication de l’environnement (par exemple les interfaces offertes par les réseaux).

Un intergiciel peut prendre en charge d’autres aspects problématiques de la communication entre calculateurs, tels que l’hétérogénéité. À partir d’une description de haut niveau des données que doivent échanger deux composants, un intergiciel peut proposer une représentation commune de ces données, destinée à être communiquée entre calculateurs, et fournir les fonctions de conversion permettant de passer des représentations natives utilisées par les composants de l’application à la représentation commune utilisée pour les échanges.

Enfin, un intergiciel peut offrir de nombreux services de haut niveau permettant de répondre à certains problèmes introduits spécifiquement par la répartition, tels que des services d’annuaires de composants.

Les intergiciels offrent ces fonctionnalités aux applications par l’intermédiaire d’interfaces de programmation, qui peuvent être définies de diverses façons. Chaque façon de présenter les fonctionnalités des intergiciels aux composants applicatif définit une personnalité, c’est-à-dire une vue de ces fonctionnalités présentée aux composants applicatifs.

De même, diverses conventions (ou protocoles) peuvent être utilisés par les intergiciels lorsqu’ils communiquent à travers un réseau pour s’informer mutuellement des interactions demandées par les composants applicatifs. Chaque protocole susceptible d’être utilisé constitue également une personnalité, c’est-à-dire une vue des fonctionnalités d’intergiciel, présentée cette fois aux autres intergiciels d’une application répartie.

Un intergiciel schizophrène est un intergiciel dans lequel les personnalités applicatives et protocolaires sont découplées, afin d’offrir aux applications la plus grande flexibilité pour intégrer des composants répartis d’origines diverses au sein d’une même application. La séparation entre les personnalités applicatives et les personnalités protocolaires est le trait fondamental de l’architecture schizophrène.

Celle-ci permet également la coexistence de multiples personnalités applicatives et protocolaires au sein d’un même intergiciel. Cette coexistence de multiples personnalités permet à un intergiciel schizophrène de jouer le rôle de passerelle entre des composants tiers incompatibles.

  Par quel chemin es-tu venu à Ada et aux intergiciels ?

Lorsque j’étais élève ingénieur à l’ENST, j’ai eu l’occasion de participer à un projet d’équipe sur les systèmes répartis en Ada 95. Mon premier contact avec Ada 95 m’a forcé à me déshabituer de la concision de C, mais j’ai fini par apprécier les règles du langage qui ont pour objectif d’interdire les constructions « dangereuses » et à rendre explicite l’intention du programmeur. Depuis cette époque (fin 1997), j’ai continué d’utiliser Ada et d’en découvrir l’expressivité.

Jusqu’en 1999, l’annexe des systèmes répartis constituait un espace clos vis-à-vis des normes existantes pour les systèmes répartis telles que CORBA ou SOAP. Je me suis attaché, sous la direction de Laurent Pautet, à la problématique de l’ouverture des systèmes répartis Ada 95 vers le monde extérieur. Cette recherche a d’abord donné lieu à un premier outil orienté sur la compilation et la génération de code, CIAO. J’ai identifié un certain nombre de limitations de cette approches, qui m’ont conduit à poser la nécessité de prendre en compte la nécessité de l’interopérabilité au sein même de l’intergiciel (et non comme une surcouche générée sur un système existant). Cette démarche a abouti à la proposition de l’architecture d’intergiciel schizophrène.

  Combien de personnes au total ont-elles travaillées sur PolyORB ?

PolyORB est le fruit d’un travail d’équipe. Au cours de son développement, chaque année, de nouveaux étudiants de l’ENST ont contribué à l’enrichissement de ses fonctionnalités dans le cadre de projets, de mémoires de fin d’études ENST ou de stages du DEA Systèmes Informatiques Répartis (en cohabilitation entre l’ENST et l’université Pierre-et-Marie-Curie).

Quelques utilisateurs extérieurs nous ont également soumis des modifications, que nous avons intégrées. Au total, la liste des contributeurs compte actuellement trente noms (et j’espère que ce chiffre va rapidement augmenter, notamment grâce à cette entrevue !)

  Le langage choisi a-t-il facilité l’intégration de différents travaux ?

Le mécanisme des paquetages, en Ada, permet au programmeur de définir l’interface exposée par un module de façon clairement isolée par rapport à la mise en oeuvre de ce module. Il favorise les bonnes pratiques de génie logiciel qui consistent à concevoir une interface en fonction d’un besoin, d’un service à rendre à un utilisateur, avant de décider comment ce service doit être réalisé.

Cette possibilité d’abstraction a facilité le développement de PolyORB de plusieurs manières. Tout d’abord, elle a permis la réutilisation de nombreuses bibliothèques existantes, telles que XmlAda ou GNAT.Sockets, ainsi que l’intégration de certaines fonctionnalités issues du projet AdaBroker. Comme le langage encourage un style de programmation modulaire et offre les constructions nécessaires à l’expression de ce style, il facilite le développement d’applications par assemblage de briques préexistantes.

La modularité et les constructions orientées objets (introduites par Ada 95) ont également permis l’intégration dans PolyORB de nombreuses contributions réalisées par des développeurs travaillant chacun de façon autonome sur un aspect de l’intergiciel. Ainsi, plusieurs étudiants de l’ENST ont pu travailler de front, seuls ou en équipe, sur différents aspects de PolyORB, en pouvant compter sur le fait que l’interface de chaque module demeurait relativement stable, même lorsque sa mise en oeuvre évoluait rapidement.

  As-tu été amené à modifier le compilateur GNAT pour l’interfacer avec PolyORB ?

L’un des objectifs de PolyORB est de pouvoir être utilisé comme moteur de communication pour mettre en oeuvre l’annexe des systèmes répartis d’Ada 95 (annexe E).

Cette annexe offre aux utilisateurs les moyens de spécifier que certaines unités composant une application Ada doivent être exécutées par des calculateurs différents, à charge pour le compilateur et l’environnement d’exécution de rendre leur localisation aussi transparente que possible.

Ainsi, les appels de sous-programmes situés sur un autre calculateur sont transformés en appels à distance, et transportés par une couche de communication. De même, les appels de méthodes portant sur des objets instanciés sur un autre calculateur doivent faire l’objet d’une transmission.

La fourniture de cette annexe suppose la réalisation d’une bibliothèque de communication, mais aussi une spécialisation du compilateur : tous les appels de sous-programmes ou de méthodes distants doivent être remplacés par des appels à la bibliothèque de communication.

Une mise en oeuvre de l’annexe des systèmes répartis pour GNAT existait déjà : GLADE. Elle était basée sur une bibliothèque de communication ad hoc, Garlic, qui utilisait un protocole dédié. J’ai pu réutiliser une partie des travaux effectués sur GLADE en modifiant la phase d’expansion de GNAT pour adapter le code généré à l’interface offerte par la couche neutre de PolyORB, très différente des fonctionnalités exposées par Garlic.

Cette expérience m’a permis de modifier le compilateur pour pouvoir produire des souches et des squelettes dont la structure soit adaptée à PolyORB au cours de mon travail de thèse. Rien de tout cela n’aurait été possible sans la possibilité d’accéder aux sources de GNAT, de les comprendre et de travailler sur des versions modifiées. La disponibilité des composants de base sous forme de logiciel libre a donc en l’occurrence été un atout majeur pour la recherche en systèmes. C’est entre autres pour cela que PolyORB est également, et demeurera, un logiciel libre.

  PolyORB est-il seulement un projet de recherche universitaire ou a-t-il de l’avenir en tant que produit industrialisé ?

PolyORB est maintenant un produit industriel supporté par ACT Europe. Plusieurs clients ont déjà fait état de leur intérêt pour le produit, et un premier contrat de support est d’ores et déjà en vigueur. Ce contrat a permis la correction d’un certain nombre de problèmes existant dans les versions antérieures de PolyORB, ainsi que le développement d’améliorations à l’exécutif de répartition, notamment pour ce qui concerne les performances.

Cependant, PolyORB demeure également une plateforme de recherche et d’enseignement : une thèse de doctorat et plusieurs projets d’étudiants à l’ENST et au LIP6 sont en cours autour de PolyORB.

  Maintenant que tu as obtenu ta thèse de doctorat, continues-tu à travailler en Ada ?

Bien sûr ! Tout d’abord, je continue à travailler au développement et à la maintenance de PolyORB et de GNAT, qui sont majoritairement écrits en Ada. J’ai également tendance à pencher pour Ada lorsque je dois choisir un langage pour un nouveau projet, chaque fois qu’il est nécessaire d’écrire du code sûr et pérenne. Enfin, même lorsque je suis amené à programmer en utilisant d’autres langages, tels que C, j’essaie de mettre en application autant que possible les bonnes pratiques issues d’Ada, telles que la séparation stricte entre spécification et mise en oeuvre d’une unité. Avec gcc, en activant l’ensemble des avertissements et en les considérant tous comme des erreurs, on peut se rapprocher des vérifications de typage offertes par tout compilateur Ada. Même quand j’écris du C, je pense en Ada ! Cela m’a déjà économisé d’innombrables heures de débogage.

Thomas, merci, et bonne continuation !

Merci à toi !

Liens :
  PolyORB
  ACT Europe
  Page personnelle de Thomas Quinot
  Thèse de Thomas Quinot