L’intergiciel CORBA

L’INTERGICIEL CORBA

Un intergiciel est un ensemble de services qui ont pour rôle de faciliter le développement d’applications, qui sont ajoutés au-dessus des bibliothèques systèmes, et qui servent d’intermédiaires entre les applications et le système opératoire. Dans nos travaux, nous nous sommes particulièrement intéressés aux intergiciels orientés communication. Ce type d’intergiciels apporte un ensemble de services qui assurent la communication entre des platesformes hétérogènes, facilitant les interactions entre des processus qui s’exécutent sur différentes machines d’un même réseau. En fournissant l’interopérabilité entre différentes plates-formes, les intergiciels ont contribué à la migration des systèmes à architectures centralisées, souvent rigides et contraignantes, vers des systèmes « client/serveur » plus appropriées à la distribution et à la collaboration. Selon la technique qu’ils utilisent, RPC Remote Procedure Call, MOM Message Oriented Middleware et ORB Object Request Broker, les intergiciels présentent des potentiels différents [Youngblood 2004].

Les intergiciels basés sur le concept de l’appel d’une procédure distante (RPC) ont été les premiers logiciels développés, et sont apparus vers le début des années 80 [Birrell 1984]. Ce type d’intergiciels agrège des fonctions spéciales, relatives à l’invocation à distance, au niveau du code de l’application, c’est-à-dire le client et le serveur qui les utilisent. Ainsi, ces intergiciels ne peuvent pas exister seuls et leur portabilité est limitée. Par ailleurs, ces intergiciels ne sont pas appropriés pour le développement des applications orientées objets.

Les intergiciels orientés messages (MOM) qui ont paru vers la fin des années 80 [Steinke 1995], sont adaptés aussi bien aux applications procédurales qu’aux applications à objets. Ils ne sont pas liés à l’application mais se présentent sous la forme d’une couche logicielle indépendante. Toutefois ces intergiciels restent des solutions propriétaires (c’est-à-dire non standard) puisqu’ils ne spécifient pas une architecture commune. Ceci limite l’interopérabilité des applications qui utilisent des intergiciels issus de différents fournisseurs.

Le troisième type d’intergiciels est basé sur la notion de bus à objets (ORB). Apparu au début des années 90 [Wade 1993], le bus à objets sert de support aux applications en masquant une partie de la complexité de la programmation distribuée à objets tout en mettant l’accent sur l’interopérabilité des applications. Ainsi, différentes applications peuvent communiquer entre elles en utilisant un ORB. Plusieurs intergiciels de ce type ont été développés, tels que COM Component Object Model et DCOM Distributed Component Object Model de Microsoft [Williams 1994], RMI Remote méthode Invocation de JAVA [Sun 2004] ou CORBA de l’OMG (Object Management Group). Dans ce mémoire, nous nous intéressons en particulier à la norme CORBA, qui est la plus répandue pour supporter des applications à objets distribuées. L’intergiciel CORBA (Common Object Request Broker Architecture) [OMG 2002a] est une infrastructure spécifiée par l’OMG; ainsi que nous l’avons indiqué, il est basé sur la notion de l’ORB. L’OMG est un consortium essentiellement composé d’acteurs de l’industrie du logiciel créé en 1989 pour promouvoir l’adoption de standards pour le développement d’applications à objets distribués. Plus précisément, l’objectif de l’OMG est de simplifier le développement en fournissant un environnement qui, d’une part, masque les détails de l’utilisation des services offerts par les systèmes opératoires, et d’autre part, qui soit supporté par les différents systèmes opératoires actuels et à venir. D’après ces principes, la programmation distribuée deviendrait standardisée et inter-opérable, au sens où elle serait indépendante des exécutifs, par exemple du système opératoire et de la couche matérielle de la machine hôte, et des langages de programmation .

Le modèle à objet de l’intergiciel CORBA

Dans cette partie, nous présentons les définitions des entités qui sont utilisées par le modèle à objet CORBA :
• Un client est une entité qui, conceptuellement, peut ne pas être un objet. Un client requiert un service auprès d’autres objets.
• Un objet est une entité identifiable, qui fournit un ou plusieurs services pour d’éventuels clients. Un objet est caractérisé par un état, un comportement et une identité. L’état d’un objet renferme la description de toutes ses fonctionnalités et les valeurs courantes de ses attributs. Le comportement précise la manière avec laquelle un objet agit et réagit en fonction du changement de son état et des messages reçus qui déclenchent des opérations internes. L’identité est la propriété qui permet de distinguer deux objets, qu’ils aient ou non le même type. Le processus de création d’un objet s’appelle instanciation.
• Une interface renferme l’ensemble des opérations qu’un client peut invoquer auprès d’un objet. Toute interface est décrite dans un langage de description d’interfaces, appelé Interface Definition Language (IDL). Un objet n’est capable de satisfaire la définition d’une interface que s’il implémente toutes les méthodes spécifiées et déclarées dans celle-ci.
• Une opération représente un service offert par un serveur à travers son interface. Elle est décrite dans le langage IDL qui permet de spécifier sa signature, c’est-à-dire le type de chacun de ses paramètres. Les opérations d’un serveur, dans le concept à objet CORBA, correspondent aux méthodes publiques de l’objet qui implémente l’interface de ce serveur, dans les langages orientés-objets.
• Une requête est un message issu d’un client pour effectuer une demande de service auprès d’un objet offrant un rôle de serveur. L’intergiciel interprète ce message pour décider du serveur qu’il va appeler et du service que ce dernier va effectuer. Cette interprétation consiste à extraire de la requête l’identificateur du serveur cible et le nom de l’opération à invoquer. Le premier sert à identifier d’une manière unique un serveur parmi ceux qui sont présents dans le réseau et le second permet de repérer une opération parmi l’ensemble de celles qui sont définies au niveau de l’interface du serveur. Par ailleurs, la requête renferme les paramètres de l’opération qui véhiculent les données d’entrée du service.
• Un attribut est déclaré au niveau de l’interface d’un serveur. Bien qu’il corresponde à la notion d’attribut d’une classe dans le concept orienté-objet standard, il ne peut être que public. Pour qu’un client distant puisse récupérer ou changer la valeur d’un attribut, l’intergiciel lui associe une paire d’opération appelée accesseurs.

L’architecture de l’intergiciel CORBA

Cette architecture est organisée autour de la notion d’ORB (Object Request Brocker) qui correspond à un bus à objets responsable de la connexion et de l’interaction entre objets. Cette architecture requiert également les services suivants :
• Le répertoire d’interfaces (Interface Repository) est un référentiel qui stocke la description des interfaces sous la forme d’objets accessibles par le client et l’ORB (Object Request Brocker). L’objectif est d’accéder lors de l’exécution à une représentation objet des interfaces des objets présents sur le bus.
• L’interface d’invocation statique (Static Invocation Interface, SII) appelée aussi «souche », est le résultat de la pré-compilation d’une interface IDL dans un langage donné selon une projection donnée, c’est-à-dire dans un langage de programmation donné. Du point de vue du client, l’utilisation des souches s’apparente à des appels locaux puisqu’elles jouent le rôle de médiateurs (proxies) locaux d’objets-serveurs qui résident dans les sites distants.
• L’interface d’invocation dynamique (Dynamic Invocation Interface, DII), est une interface unique et indépendante de celle du serveur cible. Elle offre aux clients la possibilité d’interagir avec des serveurs dont l’interface est inconnue lors de leur génération. Cette API (Application Programming Interface) normalisée par CORBA permet de lire l’interface d’un serveur, de générer des paramètres, de créer des requêtes, de les invoquer dynamiquement et de récupérer les résultats.
• L’interface de l’ORB est celle qui donne accès aux primitives de base de l’ORB (par exemple, la conversion de référence objet/chaîne de caractères, l’initialisation de l’ORB, …). Elle est commune aux applications clients et serveurs.
• L’interface statique du squelette (Static Skeleton Interface, SSI) fournit des interfaces pour les invocations statiques des objets serveurs ; une SII est nécessaire par objet. Elle décode les requêtes pour invoquer le code des méthodes appropriées. Comme pour les souches, les squelettes sont le résultat de la pré-compilation de l’interface IDL du serveur.
• L’interface dynamique du squelette (Dynamic Skeleton Interface, DSI) fournit des mécanismes de lien dynamique à l’exécution pour les objets qui veulent prendre en compte les requêtes adressées à des interfaces non connues lors de leur génération. Ces mécanismes analysent les paramètres de la requête pour déterminer l’objet cible et la méthode à appeler. Ainsi, la DSI côté serveur est équivalente à la DII côté client.
• L’adaptateur d’objet portable (Portable Object Adapter, POA) permet aux développeurs d’avoir une implémentation d’objet qui est portable entre les différents ORB. Selon la politique de création choisie, le POA peut générer un ou plusieurs identificateurs d’objet lors de la création d’un serveur. Ces identificateurs sont utilisés par le POA pour faire parvenir de manière transparente une requête au serveur cible. Le POA peut également masquer le redémarrage d’un serveur par rapport à un client en fournissant des identités persistantes aux objets.
• Le répertoire d’implémentation (Implementation Repository) est un référentiel d’implémentation qui stocke les détails spécifiques à l’ORB concernant l’implémentation des serveurs, leurs politiques d’invocation ainsi que leurs identités.

Pour envoyer une requête, le client peut utiliser l’interface des invocations dynamiques ou la souche, selon que l’interface du serveur cible est connue ou non lors de son développement. Par ailleurs, le client peut utiliser l’interface de l’ORB pour réaliser certaines fonctions, comme l’initialisation de l’ORB ou la récupération de la référence d’un objet distant.

Table des matières

INTRODUCTION GENERALE
CHAPITRE I INTERGICIEL, TOLERANCE AUX FAUTES ET REFLEXIVITE
I.1. L’intergiciel CORBA
I.1.1. Le modèle à objet de l’intergiciel CORBA
I.1.2. L’architecture de l’intergiciel CORBA
I.1.3. Dynamique de l’intergiciel CORBA
I.2. La tolérance aux fautes
I.2.1. Définitions
I.2.2. Modèles
I.2.3. Mise en œuvre de la tolérance aux fautes
I.3. La réflexivité
I.3.1. Introduction
I.3.2. Terminologie
I.3.3. Le déploiement de la réflexivité
I.4. Problématique et approche retenue
II. CHAPITRE II SYSTEMES TOLERANT LES FAUTES A BASE D’INTERGICIELS
II.1. Les approches classiques
II.1.1. Définition d’une classification
II.1.2. Approches implicites
II.1.3. Approches explicites
II.1.4. Analyse des approches
II.2. Les approches réflexives
II.2.1. FRIENDS
II.2.2. OpenORB
II.2.3. Dynamic TAO
II.2.4. Classification et analyse des approches réflexives
II.3. La norme FT-CORBA
II.3.1. Vue générale de la norme FT-CORBA
II.3.2. Aspect explicite et implicite dans la norme FT-CORBA
II.3.3. Aspect réflexif de la norme FT-CORBA
II.4. Conclusion
III. CHAPITRE III MECANISMES REFLEXIFS DANS CORBA ET APPLICATION A LA TOLERANCE AUX FAUTES
III.1. Mécanismes réflexifs dans CORBA
III.1.1. Mécanismes réflexifs spécifiques
III.1.2. Mécanismes réflexifs standards
III.2. Architecture de Daisy
III.2.1. Spécifications
III.2.2. Définitions (principes)
III.2.3. Composants de tolérance aux fautes
III.2.4. Composants utilitaires
III.3. Différentes variantes de DAISY
III.3.1. Approche à base de composants externes
III.3.2. Approche à méta-objets intégrés
III.3.3. Comparaison et choix entre les deux variantes
III.3.4. Impact de l’utilisation de DAISY sur la conception des applications
III.4. Limites conceptuelles des intercepteurs CORBA
III.4.1. Protocole à méta-objets à base d’intercepteurs CORBA
III.4.2. Méta-objet de tolérance aux fautes à base d’intercepteurs CORBA
III.5. Conclusion et préconisation de nouvelles solutions
IV. CHAPITRE IV MISE EN OEUVRE DES MECANISMES REFLEXIFS STANDARDS ET ANALYSE
IV.1. Mise en œuvre de la réplication passive
IV.1.1. Initialisation de la plate-forme
IV.1.2. Intercepteur client
IV.1.3. Intercepteur primaire
IV.1.4. Intercepteur réplique
IV.2. Mise en œuvre de la réplication active
IV.2.1. Initialisation du mode actif
IV.2.2. Intercepteur Principal
IV.2.3. Intercepteur Subsidiaire
IV.3. Gestion de la plate-forme DAISY
IV.3.1. Usine à objets
IV.3.2. Gestionnaire de réplication
IV.4. Évaluation des intercepteurs CORBA et proposition de solutions d’un point de vue du développement
IV.4.1. Association intercepteur/serveur non identifiable
IV.4.2. Absence d’une politique d’ordonnancement
IV.4.3. Source de blocage et de boucles infinies
IV.4.4. Obligation d’invoquer chaque requête interceptée
IV.4.5. Absence de brins propres d’exécution
IV.4.6. Incapacité de générer une réponse
IV.4.7. Incapacité d’utiliser la DII
IV.4.8. Incapacité de rediriger une requête à plusieurs serveurs
IV.4.9. Incapacité de modifier les paramètres de retour
IV.5. Mesure de performance de la réplication passive
IV.5.1. Initialisation des objets
IV.5.2. Coût des opérations
IV.5.3. Coût des différents mécanismes
IV.6. Conclusion
CONCLUSION GENERALE
BIBLIOGRAPHIE

Lire le rapport complet