Soutenance mémoire
En général l’informatique répartie présente un défi majeur de l’informatique actuelle et à venir. Pour faire face au défi on a besoin de développer les applications reparties de manière simple tout en limitant les coûts. Dans le monde CORBA, l’invocation standard d’une méthode consiste en une exécution synchrone d’une opération fournie par un objet. Cependant la plupart des applications reparties nécessitent un modèle de communication fortement découplé entre les objets communiquant. Ce besoin de découplage entre les objets a conduit L’OMG (l’Object Management Group) à définir un nouveau type d’interfaces qui assure la communication asynchrone entre objets, ces interfaces sont intitulées les services d’évènements qui constituent un des principaux dispositifs d’interaction asynchrone dans les systèmes répartis. Un service d’évènement comprend des producteurs d’évènements, des consommateurs d’évènements, et des canaux d’évènement.
Le principe de fonctionnement du service d’évènements est fondé sur un canal d’évènements dans lequel des producteurs d’évènement émettent des données tandis que des consommateurs reçoivent ces données. Le modèle de communication se base sur l’architecture Client /Serveur, Le serveur va jouer le rôle du producteur tandis que le client va jouer le rôle de consommateur. Les producteurs peuvent générer des évènements sans avoir connaître les identités des consommateurs. De même, les consommateurs peuvent recevoir des évènements sans avoir connaître les identités des producteurs. Pour initier la communication d’évènements il y a deux approches push et pull Dans le modèle push le producteur prend l’initiative de transférer des données évènements vers le consommateur, dans l’autre modèle le consommateur prend l’initiative de solliciter des données évènements du producteur. Cependant, les spécifications actuelles de ces services ne permettent pas d’exprimer des contraintes temporelles et des contraintes de fiabilité dans l’envoi des évènements, Considérant ces lacunes nous proposons dans ce mémoire une approche pour la prise en compte de tels contraintes dans l’envoie des évènements.
Présentation de CORBA
L’Object Management Group (OMG) est un consortium international créé en 1989 et regroupant actuellement plus de 850 acteurs du monde informatique : des constructeurs, des producteurs de logiciel des utilisateurs et des institutionnels et universités. L’objectif de ce groupe est de faire émerger des standards pour l’intégration d’applications distribuées hétérogènes à partir des technologies orientées objet. Ainsi les concepts-clés visé sont la l’interopérabilité, réutilisabilité, et la portabilité de composants logiciels, programmés dans différents langages. Le cœur de la vision de l’OMG est CORBA (Common Object Request Broker Architecture) : qui est un middleware orienté objet et repose sur le protocole TCP / IP. L’idée consiste à créer des objets qui seront accessibles par le client et le serveur. CORBA propose un support d’exécution masquant les couches techniques d’un système réparti et il prend en charge les communications entre les composants logiciels formant les applications réparties et hétérogènes.
Modèle client/serveur de CORBA
Architecture client/serveur traditionnelle
L’application cliente est située sur le poste client. Le lien entre le serveur et le client est direct. L’application cliente accède aux données de la base via des requêtes SQL. Peu de traitements sont localisés au niveau du serveur.
Architecture client/serveur à trois tiers
Le client n’accède pas directement au serveur. Il émet des requêtes au serveur d’application qui exécute les traitements et à son tour faire transmettre les requêtes au serveur de données. Cette architecture ne repose pas sur le concept d’objet.
Architecture distribuée
Dans cette architecture l’ensemble des dialogues entre machines est pris en charge par le middleware (dans notre cas c’est CORBA). Il prend en charge tous les problèmes de communication liés à l’intégration des différentes plates-formes utilisées (langages distincts, machines distantes, environnements hétérogènes) CORBA propose donc un modèle client/serveur de coopération entre des objets répartis, chaque application peut exporter certains services sous forme d’objet CORBA, cette notion de client serveur intervient uniquement lors de l’utilisation de l’objet. Les interactions entre applications sont faites à travers les invocations de procédures distantes. L’application utilisant un objet est un client, et celle en attente des requêtes est le Serveur tandis que la partie du serveur implantant l’objet est appelée le servant.
La coopération client-serveur se déroule de la manière suivante :
➤ Le client détient une référence sur un objet CORBA qui permet de le localiser sur le bus CORBA.
➤ Le client dispose de l’interface de l’objet CORBA qui définit ses opérations et ses attributs exprimés dans le langage IDL (voir ci-dessous).
➤ Le client invoque une requête sur l’objet CORBA.
➤ Le bus CORBA achemine cette requête vers l’objet CORBA tout en masquant les problèmes d’hétérogénéité liés aux systèmes d’exploitation, langages, machines, réseaux.
➤ L’objet CORBA est associé à un objet d’implantation
➤ Le serveur détient l’objet d’implantation qui code l’objet CORBA et gère son état temporaire.
L’architecture globale de CORBA
L’OMG a défini une architecture globale pour classifier les différents objets qui participent dans la construction d’applications réparties. Cette architecture comprend un bus d’objets répartis : l’ORB (voir ci-dessous) qui est l’intermédiaire à travers lequel les objets vont pouvoir dialoguer. Des services de base (CorbaServices) qui fournissent les fonctions nécessaires à la plupart des applications réparties. Ces services sont spécifiés grâce au langage OMG-IDL (voir ci-dessous). Des utilitaires communs (Common Facilities) qui répondent plus particulièrement aux besoins des utilisateurs. Des interfaces d’objets applicatifs (Application Interfaces) qui définissent les objets créés par les utilisateurs. Des interfaces de domaines (Domain Interfaces) qui définissent des interfaces spécialisées répondant aux besoins spécifiques de tel ou tel marché comme la finance ou la santé.
L’ORB (Object Request Broker)
L’ORB (Object Request Broker) est une entité (en réalité en ensemble des interfaces) qui fournit des mécanismes d’interrogations permettant de récupérer des objets, des procédures qui constituent une application répartie. Donc c’est l’intermédiaire/négociateur à travers lequel les objets vont pouvoir dialoguer et ce de manière transparent. Le noyau de communication (ORB Core) transporte les requêtes du client vers l’implantation de l’objet cible, selon diverses techniques dépendantes de la localisation. Si les objets sont situés sur des machines différentes, L’ORB Core utilise le protocole IIOP (Internet Inter-ORB Protocol) et si les objets sont sur le même site il utilise des outils de communication interprocessus. Ainsi l’ORB est responsable de trouver l’implantation de l’objet, de l’activer, de délivrer la requête à l’objet et de retourner la réponse à l’appelant. Ce noyau n’est pas directement accessible par les programmeurs.
L’IDL (Interface Definition Language)
IDL est un langage de définition d’interface orienté objet. Il a été créé pour fournir l’interopérabilité entre plusieurs applications répartir, flexibles écrites dans différents langage de programmation, Il cherche à masquer l’hétérogénéité de ces applications et il définit les types des objets en spécifiant leurs interfaces. Cette spécification des applications répartie flexibles sur des plateformes hétérogènes nécessite une séparation stricte entre l’interface de l’objet et de son implémentation. D’où l’idée de créer un langage objet : OMG-IDL qui ne décrit que les interfaces des objets, et ceci de manière indépendante du langage d’implantation. L’interface d’un objet contient les éléments suivent :
➤ Les opérations,
➤ Les paramètres,
➤ Les noms des méthodes,
➤ Le type de retour,
➤ Les attributs,
➤ Les types et les exceptions.
|
Table des matières
INTRODUCTION GENERALE
PARTIE I : ÉTAT DE L’ART
CHAPITRE I : PRESENTATION DE CORBA
I.Introduction
II.Modèle client/serveur de CORBA
1.Architecture client/serveur traditionnelle
2.Architecture client/serveur à trois tiers
3.Architecture distribuée
III.L’architecture globale de CORBA
1.L’ORB (Object Request Broker)
2.L’IDL (Interface Definition Language)
a.Les fonctionnalités
b.Les caractéristiques de l’IDL
c.Les limites actuelles
d.La projection vers un langage de programmation
IV.Les composantes de CORBA
V.Les protocoles réseaux
VI.Les services objet communs
1.La recherche d’objets
2.La vie des objets
3.La sûreté de fonctionnement
4.Les communications asynchrones
VII.Les interfaces de domaine
VIII.Les limites de CORBA
CHAPITRE II : SERVICE D’EVENEMENT
I.Introduction
II.La communication par événement
III.Principes de conception d’un service d’événement (Design
Principles)
IV.Qualité de service
1.Modules et interfaces
a.CosEventComm
b.CosEventChannelAdminmodule
2.Le canal d’événement
3.Le modéle de communication push avec un chanel d’événement
4.Le modèle de communication pull avec un chanel d’événement
5.Communication mixte avec un canal d’événement
V.Modèle de la plateforme indépendante (PIM)
1.Le Package CosLightweightEventComm
2.Le Package CosLightweightEventChannel
PARTIE II : CONCEPTION
CHAPITRE III : CONCEPTION D’UN SERVICE D’EVENEMENT FIABLE ET TEMPORISE
I.Introduction
II.Les limitations des services d’évènement CORBA
1.Contrainte de temps de livraison
2.Contrainte de Fiabilité
III.Protocoles de diffusion fiable (multicast)
1.Définition et Principes de base
2.Problème de fiabilité
IV.Conclusion
PARTIE III : REALISATION
CHAPITRE IV : PARTIE PRATIQUE
I.Introduction
II.Architecture TAO
III.Prise en main de l’environnement de développement
1.Installation de TAO pour l’application Serveur
a.Modification de la variable PATH
b.Création du fichier config.h
c.Compilation de TAO
2.Installation de JacORB pour l’application Cliente
a.Installation de Ant
b.Modification de la variable PATH
c.Installation de JacORB
d.Génération du script de lancement des applications Java avec JacORB
3.Génération du compilateur IDL
IV.Les différentes étapes pour la mise en place de notre prototype
V.Conclusion
CONCLUSION & PERSPECTIVES
BIBLIOGRAPHIE & NETOGRAPHIE
