Conception d’un intergiciel schizophrène 

Rôle de l’intergiciel

Pour le développeur d’une application utilisant un modèle de répartition de haut niveau (appel de sous-programmes à distance, objets répartis ou mémoire partagée, par exemple), la répartition est introduite de façon « transparente », au sens où elle lui est dissimulée. Les opérations de communication sous-jacentes sont réalisées de façon implicite ; le développeur utilise les mêmes procédés de découpage d’une application en composants indépendants que dans le cas non réparti. Il définit les limites des sous-programmes, les interfaces et les relations des objets de la même façon. La répartition consiste alors à projeter les entités ainsi délimitées sur les différents calculateurs participant à l’application répartie.
Les échanges de messages sous-tendus par le modèle de répartition sont effectués par l’intergiciel. Celui-ci réalise ainsi les abstractions du modèle de répartition. De plus, il réduit la dépendance des composants vis-à-vis de l’environnement d’exécution, en masquant les aspects d’interfaçage de bas niveau avec les primitives de communication.
L’organisation générale d’une application répartie utilisant un intergiciel : les composants de l’application utilisent les fonctions de l’intergiciel pour communiquer entre eux de façon transparente ; c’est l’intergiciel qui utilise les services de base du système d’exploitation et l’environnement matériel sous-jacents pour fournir ces fonctions de communication de haut niveau.
Chaque nœud possède donc une instance de l’intergiciel. Ces instances communiquent entre elles au moyen de primitives de bas niveau, et jouent le rôle d’intermédiaires entre les composants de l’application qui résident sur le même nœud et ceux qui résident sur d’autres nœuds. Les interactions avec ces derniers sont réalisées par échange de messages entre les instances d’intergiciel locale et distante.
Adressage :L’intergiciel doit avant tout définir un moyen de nommer les diverses entités qui participent à une application répartie : il leur attribue des identifiants susceptibles d’être échangés et compris par chacun des nœuds de l’application. Ces identifiants permettent à un composant d’en désigner un autre, et ainsi d’interagir avec lui. L’intergiciel remplit une fonction d’adressage des composants de l’application. Cette fonction est rendue accessible aux composants applicatifs à travers des constructions de programmation qui permettent d’associer certains objets concrets du programme utilisateur à des abstractions d’un modèle de répartition. Le choix d’un modèle particulier conditionne donc la forme de ces objets de l’application.
Transport :À partir des identifiants d’objets, une instance d’intergiciel établit des canaux de communication avec d’autres. Ces canaux sont utilisés pour échanger les messages représentant les interactions entre composants applicatifs. À cet égard, l’intergiciel assure le transport de messages entre les nœuds, en utilisant le réseau de communication sous-jacent.

Limites introduites par l’intergiciel

L’utilisation d’un intergiciel dans une application répartie, par opposition à l’utilisation directe des primitives de communication fournies par le système d’exploitation, permet l’utilisation d’un modèle de répartition sophistiqué. Ce gain en abstraction facilite également la mise en place d’applications hétérogènes. Toutefois, les apports des intergiciels s’accompagnent de plusieurs contreparties. Coûts relatifs des différents modèles de répartition :À chaque modèle de répartition correspond un coût de mise en œuvre. Plus les fonctionnalités offertes sont importantes, plus l’intergiciel est volumineux, et plus les ressources nécessaires sont considérables. Un intergiciel offrant le modèle « passage de messages » peut n’introduire qu’un surcoût minime par rapport à l’utilisation directe des primitives de communication du système d’exploitation sous-jacent. En effet, il rend un service
d’un faible niveau d’abstraction, dont la réalisation transparente ne nécessite pas d’opérations complexes.
Lorsqu’un modèle plus évolué (l’appel de sous-programmes à distance ou les objets répartis) est mis en œuvre, en revanche, l’intergiciel effectue des traitements complexes. Il occupe donc plus d’espace en mémoire. Les fonctions avancées sont également susceptibles d’introduire des délais de traitement supplémentaires pour tous les messages échangés, et d’augmenter le volume de données à transmettre entre les nœuds.
Adaptation aux besoins des applications :D’une application à une autre, les besoins peuvent être très divers. Une application de télévision, par exemple, nécessite la transmission de flux multimédia en temps réel vers des terminaux embarqués. Elle nécessite donc une transmission de messages avec une faible variance de délai. En revanche, elle peut souffrir la non-remise de quelques messages, par exemple au prix d’une baisse transitoire de qualité d’image. Une application réalisant des transactions bancaires, au contraire, pourra supporter des délais plus importants. En revanche, elle imposera une fiabilité importante dans la remise des messages.
Par ailleurs, au sein d’une même application, les fonctionnalités requises et les ressources disponibles (puissance de calcul, mémoire, capacité des liaisons de communication) peuvent varier d’un nœud à l’autre dans des proportions importantes. Un nœud pourra être une station de travail puissante, alors qu’un autre sera un système embarqué, un robot mobile autonome, ou une carte à
microcircuit.
Les besoins globaux de l’application, ainsi que les caractéristiques particulières de chaque nœud, nécessitent un intergiciel adapté à chaque cas. Or, les intergiciels traditionnels sont développés en tant que produits d’usage général, afin d’être utilisés dans un grand nombre d’applications. Ils sont destinés à éviter le redéveloppement de modules de communication pour chaque projet. L’utilisation du même intergiciel sur tous les nœuds d’une application représente donc un compromis, et ne peut satisfaire idéalement l’ensemble des contraintes de tous les composants répartis.

Architectures génériques d’intergiciel

Un unique intergiciel traditionnel, au comportement et aux fonctionnalités :fixés une fois pour toutes, ne peut répondre à la diversité des besoins des applications, et à la diversité des ressources disponibles sur les différents nœuds.
Cependant, il est possible de définir des intergiciels capables d’adapter leur comportement et leurs fonctionnalités à des besoins spécifiques.
Intergiciels flexibles :L’adaptation de l’intergiciel aux besoins peut être réalisée selon deux axes. En premier lieu, elle peut être paramétrable : le dimensionnement de ses structures internes, par exemple, peut alors être ajusté en fonction de la taille de l’application, et des capacités de chaque nœud.
D’autre part, une conception modulaire et configurable permet de n’instancier sur un nœud que celles de ses fonctionnalités qui y sont nécessaires. Les fonctionnalités offertes (et donc le coût de la répartition) sont ainsi adaptés en fonction des ressources disponibles sur chaque nœud et des exigences de l’application. Cette idée d’assembler les systèmes logiciels comme les ordinateurs, à partir de composants préexistants et réutilisables, date des origines du génie logiciel . Son application au domaine des intergiciels a fait l’objet de plusieurs études. En particulier, les auteurs de Quarterware la systématisent, et proposent une analogie entre des intergiciels hautement modulaires et les architectures matérielles RISC, où les instructions machine offertes par le matériel sont des unités de fonctionnalité minimales, que l’utilisateur agence au plus juste pour répondre à ses besoins.
Dans le cas des intergiciels, une telle flexibilité rend possible la réutilisation d’un même intergiciel dans des contextes variés. La configuration permet la prise en compte des contraintes spécifiques de l’application, et de n’intégrer que les modules essentiels. Dans les cas où les ressources disponibles sont réduites, seules les fonctionnalités de base seront instanciées, à l’exclusion d’autres plus avancées. De tels profils de fonctionnalité réduits permettent la mise en place d’application réparties intégrant des systèmes embarqués.

Configuration par politiques d’adaptation d’objets : le POA de CORBA

La spécification CORBA définit une architecture d’adaptateur d’objets, le POA (Portable Object Adapter ). L’adaptateur d’objets est le composant d’un intergiciel CORBA qui contrôle l’association entre les références d’objets et les structures concrètes qui mettent en œuvre ces objets : les servants.
Un servant est une structure concrète (souvent une instance d’objet d’un langage de programmation) qui met en œuvre un (ou plusieurs) objet d’une application à objets répartis. Le POA est mis en œuvre par de nombreux intergiciels tels que TAO ou AdaBroker, un intergiciel CORBA complet développé au sein de notre équipe à l’ENST, et distribué sous forme de logiciel libre.
Contrairement aux interfaces d’adaptateur d’objets qui existaient dans les premières versions de CORBA, le POA propose un espace d’attribution de références arborescent. L’utilisateur peut définir librement une hiérarchie entre différents espaces d’adressage. Il peut également configurer certains aspects du comportement de l’adaptateur d’objets, en contrôlant indépendamment chaque
nœud de l’arborescence.
Ce paramétrage est réalisé en associant à chacun de ces nœuds des politiques, une politique étant une instance particulière d’un comportement configurable. Les axes de paramétrage ainsi exposés par la spécification CORBA peuvent être considérés comme des instances du patron Strategy.
Ils permettent d’agir sur de nombreuses facettes de l’intergiciel. En effet, dans le modèle de répartition de CORBA, l’adaptateur d’objets est un acteur central du traitement des requêtes reçues. En tant que composant responsable de l’affectation d’une requête à un objet concret, il contrôle le déroulement des fonctions d’activation et d’exécution. Il intervient également dans la fonction d’adressage, car il contrôle l’espace local des identificateurs d’objets d’un nœud.
Ainsi, trois politiques d’activation sont normalisées, régissant l’association entre références d’objets et servants :
Les servants peuvent s’enregistrer auprès de l’intergiciel et incarner chacun un objet. Dans ce cas, une référence d’objet correspond exactement à un servant, et l’intergiciel maintient une table associant chaque référence attribuée à l’objet de mise en œuvre correspondant ;
Toutes les références correspondant à un même nœud de l’arborescence du POA peuvent également être associée à un même servant, qui est alors le servant par défaut de ce nœud. Ce servant par défaut traite alors les requêtes pour toutes les références créées à ce point de l’arborescence.
Une usine de servants peut être utilisée pour créer ou retrouver dynamiquement le servant qui doit traiter une requête donnée.
Les politiques du POA de CORBA permettent d’exprimer une grande variété de comportements de l’intergiciel côté serveur. En revanche, elles ne permettent pas de paramétrer le fonctionnement du rôle client.

Définition de la notion d’intergiciel schizophrène

Les conditions que doit remplir l’architecture d’un intergiciel pour permettre la coopération aisée et dynamique entre modèles de répartition :
le découplage des aspects applicatifs et protocolaires des éléments de personnalité ; la cohabitation de personnalités différentes au sein de l’architecture ; le partage des services et des données dans un noyau indépendant de toute personnalité.
Le découplage des aspects applicatifs et protocolaires des intergiciels permet d’introduire deux notions complémentaires : Une personnalité applicative est la spécification d’une interface entre des objets applicatifs et un intergiciel en vue d’en utiliser les services pour interagir avec d’autres objets applicatifs.
Une personnalité protocolaire est la spécification d’une interface entre deux intergiciels destinée à l’échange de messages représentant les interactions entre les objets hébergés par ces intergiciels. Nous synthétisons ces conditions (découplage des personnalités applicatives et protocolaires, cohabitation de personnalités différentes, mutualisation de fonctionnalités) dans cette définition: Nous qualifions de schizophrène un intergiciel capable de disposer, simultanément, de plusieurs personnalités applicatives et protocolaires et de les faire interagir efficacement.

Table des matières

1 Introduction générale 
1.1 Paradoxe de l’intergiciel 
1.2 L’interopérabilité, pourquoi ?
1.3 L’interopérabilité, comment ? 
1.3.1 Passerelles entre intergiciels
1.3.2 Intergiciels interopérables
1.4 Objectifs 
1.5 Plan du mémoire
I Étude et conception 
2 Problématique — axes d’investigation 
2.1 Systèmes répartis
2.1.1 Définition
2.1.2 Terminologie
2.2 Modèles de répartition et classification
2.2.1 Passage explicite de messages
2.2.2 Appels de sous-programmes à distance
2.2.3 Objets répartis
2.2.4 Mémoire partagée répartie
2.2.5 Discussion
2.2.6 Extensions aux modèles de répartition
2.3 Interopérabilité des systèmes répartis 
2.3.1 Définition
2.3.2 Incompatibilités entre modèles de répartition
2.3.3 Incompatibilités entre mises en œuvre d’un modèle
2.3.4 Synthèse
2.4 Intergiciels de répartition 
2.4.1 Rôle de l’intergiciel
2.4.2 Limites introduites par l’intergiciel
2.4.3 Architectures génériques d’intergiciel
2.4.4 Synthèse
2.5 Intergiciels pour les objets répartis
2.5.1 Fonctions spécifiques aux objets répartis
2.5.2 Relations avec les autres modèles de répartition
2.5.3 Synthèse
2.6 Synthèse et axes de travail 
3 État de l’art des intergiciels pour objets répartis 
3.1 Intergiciels génériques 
3.1.1 Généricité par liaisons flexibles : Jonathan
3.1.2 Généricité par décomposition : Quarterware
3.1.3 Discussion
3.2 Intergiciels configurables
3.2.1 Configuration des propriétés globales de l’application : GLADE
3.2.2 Configuration par patrons de conception : TAO
3.2.3 Configuration par politiques d’adaptation d’objets : le POA de CORBA
3.2.4 Discussion
3.3 Intergiciels interopérables
3.3.1 Interopérabilité par partage de protocoles : LSA, SoapRMI
3.3.2 Interopérabilité par protocoles adaptables : TAO
3.3.3 Interopérabilité par génération de passerelles : CIAO
3.3.4 Trois perspectives sur l’interopérabilité
3.3.5 Discussion
3.4 Synthèse
3.4.1 Généricité
4 Conception d’un intergiciel schizophrène 
4.1 Intergiciel schizophrène
4.1.1 Motivation
4.1.2 Approches pour l’interopérabilité
4.1.3 Définition de la notion d’intergiciel schizophrène
4.2 Application témoin
4.2.1 Configuration homogène
4.2.2 Configuration d’interopérabilité avec protocole unique
4.2.3 Configuration d’interopérabilité avec protocoles multiples
4.2.4 Configuration d’interopérabilité indirecte
4.3 Traits architecturaux d’un intergiciel schizophrène 
4.3.1 Découplage entre les aspects protocolaires et applicatifs
4.3.2 Introduction d’une couche neutre
4.3.3 Architecture générale
4.4 Une architecture d’intergiciel schizophrène
4.4.1 Vue d’ensemble
4.4.2 Composants de support
4.4.3 Couche neutre
4.4.4 Personnalités applicatives
4.4.5 Personnalités protocolaire
4.5 Projection des fonctions sur l’architecture
4.5.1 Adressage
4.5.2 Transport
4.5.3 Liaison
4.5.4 Représentation
4.5.5 Protocole
4.5.6 Activation
4.5.7 Exécution
4.6 Processus de personnalisation
4.7 Patrons de conception 
4.7.1 Patrons comportementaux
4.7.2 Patrons de parallélisme
4.7.3 Patrons de polymorphisme
4.7.4 Synthèse
4.8 Synthèse 
II Réalisation 
5 Réalisation des services de base 
5.1 Initialisation 
5.1.1 Élaboration d’un programme Ada 95
5.1.2 Gestionnaire d’initialisation
5.2 Parallélisme et synchronisation 
5.2.1 Configurabilité du parallélisme
5.2.2 Interface des objets primitifs
5.2.3 Profils de parallélisme
5.2.4 Objets de synchronisation composés
5.3 Structures de données de haut niveau 
5.3.1 Pointeurs à comptage de références
5.3.2 Dictionnaires
5.4 Patrons de conception
5.4.1 Composants
5.4.2 Annotations
5.5 Synthèse
6 Réalisation d’une couche neutre de répartition
6.1 Noyau générique 
6.1.1 Modèle de répartition
6.1.2 Cycle de vie d’une requête
6.1.3 Références d’objets
6.1.4 Ordonnanceur-orienteur
6.1.5 Lieur
6.2 Composants applicatifs de la couche neutre 
6.2.1 Interface abstraite des adaptateurs d’objets
6.2.2 Adaptateurs d’objets concrets
6.3 Composants protocolaires de la couche neutre 
6.3.1 Tampons de communication
6.3.2 Mécanismes de transport
6.3.3 Objets de liaison
6.4 Synthèse 
7 Réalisation de personnalités applicatives
7.1 Anatomie d’une personnalité applicative 
7.1.1 Interface pour les clients
7.1.2 Interface pour les serveurs
7.1.3 Génération de code
7.1.4 Descripteurs d’interface
7.2 CORBA
7.2.1 Compilateur IDL
7.2.2 Bibliothèque
7.2.3 Services
7.3 DSA 
7.3.1 Génération de code
7.3.2 Exécutif
7.3.3 Services
7.4 MOMA
7.4.1 Intergiciels fondés sur le passage de messages
7.4.2 Bibliothèque
7.5 Synthèse — perspectives
8 Réalisation de personnalités protocolaires 
8.1 Anatomie d’une personnalité protocolaire 
8.1.1 Interface basse des sessions
8.1.2 Interface haute des sessions
8.1.3 Fonctions de représentation
8.1.4 Usines d’objets de liaison
8.1.5 Usines de profils
8.2 CORBA 
8.2.1 Mise en œuvre de GIOP (fonction protocole)
8.2.2 Mise en œuvre de CDR (fonction représentation)
8.2.3 Usines de liaisons et de profils IIOP
8.3 SOAP 
8.3.1 SOAP RPC (fonction protocole)
8.3.2 Représentation SOAP
8.3.3 Usine de profils SOAP
8.4 Synthèse — perspectives 
9 Validation et mesures 
9.1 Fonctionnalités d’intergiciel 
9.1.1 CORBA
9.1.2 DSA
9.1.3 MOMA
9.2 Contribution à l’interopérabilité 
9.2.1 Interopérabilité entre mises en œuvre des objets répartis
9.2.2 Interopérabilité avec un intergiciel existant
9.2.3 Interopérabilité entre modèles de répartition
9.3 Évaluation des performances 
9.3.1 Temps d’exécution
9.3.2 Empreinte mémoire
9.3.3 Leçons tirées des observations
9.4 Génie logiciel et coût de personnalisation 
9.4.1 Répartition du code
9.4.2 Analyse sur des configurations complètes
9.5 Synthèse 
10 Conclusion générale et perspectives 
10.1 Interopérabilité : le paradoxe de l’intergiciel 
10.2 Architecture schizophrène 
10.3 Réalisations 
10.4 Perspectives
Bibliographie

Télécharger le rapport complet