CONCEPTION ET IMPLANTATION BASÉES SUR DES COMPOSANTS RÉPARTIS D'UNE STATION TERRESTRE VIRTUELLE DE COMMUNICATION SATELLITE Steve Bernier mémoire présenté au Département de mathématiques et d'informatique en vue de l'obtention du grade de maitre ès sciences (M.Sc.) Sherbrooke, Québec, Canada, septembre 2000
raphic Services Acquisitioris et services biôliiraphiques The author has pted a nonexclusive licence aliowing the National LI* of Canada to reproduce, loan, distribide or seli copies of this thesis in microform, papa or electronic foxmats. The author retains ownership of the copyright in this thesis. Neither the thesis nor substantial extracts fiom it may be printed or otherwise reproduced without the author's permission. L'auteur a accordé une licence non exclusive permettant à la Bibliothèque nationale du Cana& de reproduire, prêter, distribuer ou vendre des copies de cette thèse sous la forme de microfiche/film, de reproduction sur papier ou sur format électronique. L'auteur conserve la propriété du droit d'auteur qui protège cette thèse. Ni la thése ni des extraits substantiels de celle-ci ne doivent être imprimés ou autrement reproduits sans son autorisation.
Sommaire Ce mémoire traite des problèmes reliés à l'accessibilité aux services offerts par les satellites évoluant à basse altitude (Low Earth Orbit - LEO). La communication avec de tels satellites nécessite un équipement dispendieux, difficile à installer et complexe à utiliser. L'investissement et le niveau de connaissance requis font obstacles à l'accessibilité des LEO. La recherche présentée dans ce mémoire vise à faciliter l'accès à la communication par satellite. Notre solution à cet égard consiste à rendre les stations terrestres de communication par satellite accessibles sur 1'Internet à travers le concept de station virtuelle. Ces stations virtuelles deviennent accessibles à partir de n'importe quel ordinateur branché à I'Internet indépendamment de sa position géographique. Les services offerts par une station virtuelle sont implémentés par des composants répartis CORBA. Ce mémoire présente en détail un cadre d'application qui facilite la création de stations virtuelles, ainsi que l'utilisation que nous en avons fait pour créer notre propre station. Enfin, un exemple d'application qui utilise les services de notre station virtuelle est présenté. Cette application de poursuite de satellites sert a illustrer la simplicité et la flexibilité du concept de station virtuelle.
Remerciements En premier lieu, je veux remercier mon directeur de recherche, le professeur Michel Barbeau, pour m'avoir offert un projet aussi intéressant. Je tiens à le remercier pour son implication et pour l'ouverture d'esprit dont il a fait preuve tout au long du projet. Enfin, je le remercie de m'avoir soutenu financièrement. Beaucoup de gens ont participé de près ou de loin à ce projet et je les en remercie tous. Je remercie plus particulièrement Denis Thibault pour son implantation de l'algorithme de calcul de position du satellite. Sans son aide, ce projet aurait sûrement duré quelques mois de plus. Je remercie aussi François Lévesque pour son aide au niveau du design et de l'architecture de notre logiciel. Par ailleurs, je veux remercier Denis et François pour les bons moments de détente que nous avons passés ensemble à discuter et à réinventer le monde. Je garde de bons souvenirs de ces discussions philosophiques. En terminant, je m'en voudrais de passer sous silence le support de ma conjointe, de mes parents et de tous mes proches. Merci à vous tous! iii
Table des matières Sommaire Remerciements Table des mati&res Liste des tableau Liste des figures iii iv vii viii Introduction 1 Problème..................................... 1 Description de notre solution........................... 2 Organisation du mémoire............................. 2 1 Revue de la littérature 4 1.1 Le modèle de composants Java Bean.................... 4 1.1.1 Introduction.............................. 4 1.1.2 Description.............................. 5 1.1.3 Bénéfices......,......................... 5 1.1.4 L'anatomie d'un Java Bean..................... 6 1.1.5 L'introspection............................ 10
1.1.6 Conclusion.... 10 1.2 Le modèle de composants répartis CORBA.... 11 1.2.1 Introduction.... 11 1.2.2 Description... 12 1.2.3 Bénéfices.... 12 1.2.4 Spécification de services... 14 1.2.5 L'Object Management Architecture... 15 1.2.6 L'anatomie d'un ORB... 16 1.2.7 Les Common Object Services (COS)... 22 1.2.8 Les Common Object Facilities (COF).... 24 1.3 Autres modèles de composants répartis... 24 1.4 Le modèle de composants agents mobiles... 26 1.4.1 Introduction.... 26 1.4.2 Qu'est-ce qu'un agent?... 28 1.4.3 Bénéfices.... 30 1.4.4 L'anatomie d'un serveur d'agents mobiles.... 35 1.4.5 La migration... 37 1 A.6 Types d'interaction... 38 1.4.7 Implantations... 38 1.4.8 Conchsion.... 39 Préliminaires sur la poursuite de satellites 42 2.1 Introduction... 42 2.2 La poursuite de satellite... 45 2.3 L'équipement nécessaire... 47 Une station terrestre virtuelle 50 3.1 Analyse... 53
3.1.1 Conceptualisation... 53 3.1.2 Spécification des classes... 55 3.1.3 Plate-formephysique... 60 3.2 Conception... 61 3.2.1 Spécification détaillée des classes... 61 3.3 Implantation... 69 3.3.1 Pilotes de périphériques... 69 3.3.2 Calcul de la position d'un satellite... 71 3.3.3 Fichier de configuration... 73 3.4 Évaluation de la station virtuelle... 75 3.4.1 Améliorations... 75 3.5 AR00 : un nouveau type de logiciel de poursuite... 77 3.6 Évaluation de AR00... 81 3.6.1 Améliorations... 82 Conclusion 86 A Acronymes B Protocole de communication du radio Yaesu FT736R C Protocole de communication de l'interface KCT 91... C.l Obtenir l'azimut 92... C.2 Obtenir l'élévation 93 C.3 Modifier l'azimut... 93... C.4 Modifierl'élévation 94 D Liste des serveurs d'agents mobiles 95 Bibliographie 98
Liste des tableaux 1 Tableau de prédiction... 46 2 Tableau de prédiction avec décalage de fréquence... 47 3 Format d'un tableau de prédiction... 60 4 Résumé du protocole... 90... 5 Correspondance des différentes unités de mesure 91... 6 Fonctions de chacun des ports 92 vii
Liste des figures L'anatomie d'un Java Bean... 6 Object Management Architecture... 15 L'anatomie d'un ORB.... 16 Utilisation interlangages d'un service... 18 Modèles alternatifs... 27 Taxonomie en trois axes... 29 Comparaison de la performance entre les modèles client/serveur et agents mobiles pour effectuer trois interactions.... 40 Anatomie d'un serveur d'agents mobiles... 41 Couverture d'un LE0 et d'un GE0.... 43 Zone de couverture d'un LE0... 44 Trois types d'orbites... 45 Équipernent de communication de notre station terrestre... 48 Modèle à trois couches de notre architecture logicielle... 51 Cas d'utilisation reliés à la première couche.... 53 Cas d'utilisation reliés à la deuxième couche... 54 Modèle client-semeur de AR00... 55 Relations entre les classes qui composent une station virtuelle... 56 Spécification de la classe AntennaRotor... 56 Spécification de la classe Transceiver... 57... Vlll
Spécification de la classe Satelliteï'racker... 57 Spécification de la classe GmundStation... 58 Automate décrivant la logique d'une poursuite de satellite... 59 Spécification détaillée de la classe Satellite'ïracker... 62 Spécification de la classe TLEInfoProvider... 63 Spécification détaillée de la classe Transceiver... 64 Spécification détaillée de la classe AntennaRotor... 65 Spécification détaillée de la classe GroundStation... 66 Fichier de définition de l'interface (IDL)... 68 Spécification de la classe d'implantation YaesuFT736R... 70 Spécification de la classe MemoryCell... 71 Spécification de la classe d'implantation TwoBodySatelliteTracker... 72 Spécification de la classe d'implantation NASAInfoProvider.... 72 Fichier de configuration... 73 Projection équidistante de la Terre... 77 Menu Poursuite de l'application AR00... 78 Projection Winkel-Tripel de la Terre... 79 Représentation graphique d'une station terrestre... 80 Représentation graphique des informations relatives à une poursuite... 81 Menu contextuel relié à un satellite... 82 Boutons reliés à la manipulation du temps... 83 Barre de statut reliée à une fenêtre de poursuite... 83 Emplacement du bouton concernant la connexion à un ORB.... 84 Fenêtre pour la sélection d'un ORB... 85 Boutons reliés à la manipulation du temps... 92
Introduction Depuis la mise en orbite du tout premier satellite, Sputnik, (URSS), le 3 octobre 1957, la communication par satellite a fait des progrès considérables. Les 30 dernières années nous ont fait passer de la communication d'un simple timbre sonore au multimédia. Les satellites sont maintenant utilisés dans divers domaines comme la téléphonie, I'Internet, la télévision, la cartographie et la météorologie. Plusieurs types de satellites sont en fonction, et dans le cadre de ce mémoire, nous nous sommes exclusivement intéressé à la communication par satellites a basse altitude. La communication avec ce type de satellites nécessite un équipement de communication spécialisé que nous nous proposons de rendre plus accessible. Problème L'endroit où est installé cet équipement est appelé station terrestre. La construction d'une station terrestre de communication est complexe et dispendieuse. Ces deux raisons font en sorte qu'il existe peu de ce genre de station. Par ailleurs, l'utilisation d'un satellite à basse altitude engendre aussi un certain nombre d'inconvénients en ce qui concerne la disponibilité des services. En effet, la position d'un tel satellite varie constamment, ce qui le rend accessible seulement à certains moments de la journée. En d'autres termes, pour utiliser un satellite particulier, il faut attendre qu'il survole l'endroit où se trouve la station terrestre employée.
En résumé, l'accessibilité à la communication par satellite est limitée par la disponi- bilité des stations terrestres. De plus, l'utilité d'un satellite à basse altitude est diminuée par le caractère intermittent des services qu'il offre. Description de notre solution Les travaux dont fait état ce mémoire visent à augmenter l'accessibilité aux services offerts par les satellites évoluant a basse altitude. Notre solution à cet égard consiste à créer une station terrestre de communication par satellite qui soit accessible sur l'hternet, à travers le concept de station virtuelle. Ce type de station peut être utilisé par n'importe quel ordinateur branché à I'Internet, ce qui augmente son accessibilité. La station virtuelle représente aussi une solution en ce qui concerne la disponibilité d'un satellite puisqu'il suffit d'utiliser une station virtuelle survolée par le satellite désiré pour établir une communication. Dans le cadre de ce projet, nous avons créé une station virtuelle dont l'architecture est à base de composants répartis CORBA. La création de la station virtuelle a été effectuée à l'aide d'un cadre d'application que nous avons mis au point dans le but de minimiser la quantité de programmation nécessaire. Enfin, dans le but de vérifier le bon fonctionnement de notre station virtuelle, nous avons conçu une application de poursuite de satellite. Organisation du mémoire Le premier chapitre de ce mémoire présente une revue de la littérature concernant trois différents modèles de conception de systèmes répartis : client-serveur, composants répartis et agents mobiles. De plus, le concept de composant logiciel est exploré à travers les Java Beans.
Le deuxième chapitre introduit quelques notions de base concernant la communication par satellite. 11 est notamment question des différents types de satellites, du processus de poursuite de satellite, ainsi que de l'équipement de communication nécessaire. Le troisième chapitre présente nos travaux concernant la réalisation d'une station virtuelle à travers trois étapes d'un processus de développement : l'analyse, la conception et l'implantation. Est aussi présentée dans ce chapitre l'interface graphique de l'application de poursuite de satellite que nous avons développée pour vérifier ia conception de notre station virtuelle. Enfin, ce chapitre se termine par une évaluation de notre projet et une conclusion.
Chapitre 1 Revue de la littérature 1.1 Le modèle de composants Java Bean 1.11 Introduction Le langage de programmation Java a été introduit par la compagnie Sun Microsystems en 1993 [17]. Java est un langage orienté objet révolutionnaire à plusieurs égards. D'abord, ce langage est exécuté par une machine virtuelle disponible sur la plupart des machines/systèmes d'exploitation. Par conséquent, les programmes Java sont parfaitement portables sous leur forme compilée. De plus, ce langage a spécifiquement été développé pour faciliter la création d'applications répartis. Il offre une interface de communication (socket) qui est complètement intégrée avec le langage ainsi qu'une façon simple d'utiliser des threads. Au fil des années, ce langage a connu un essor fulgurant qui a suivi l'émergence du WWW. Il a beaucoup évolué depuis son introduction de telle sorte qu'il offre aujourd'hui une grande quantité de librairies et d'outils.
1.1.2 Descript ion Actuellement, l'environnement Java offre notamment la possibilité de créer des composants très réutilisables qu'il est convenu d'appeler des Beans. Les Beans sont en réalité des objets qui sont créés en respectant un modèle (le modèle Java Bean) qui les rend beaucoup plus réutilisables que de simples objets. Le modèle Bean spécifie comment les objets doivent interagir avec leurs conteneurs et comment ils doivent publier la description de leurs services. Un conteneur est un objet qui peu contenir des objets (par conséquent des Beans aussi) et qui fournit un contexte dans lequel les composants peuvent interagir. Puisque les Beans sont des objets, ils peuvent être utilisés par n'importe quel programme Java. Le modèle Java Bean est en fait un standard de programmation qui définit plusieurs règles que les programmeurs doivent respecter. La plupart des objets fournis avec Java adhèrent déjà à ce standard et ils peuvent donc être considérés comme des Java Beans. Lorsque toutes les règles du modèle sont respectées, les Java Beans sont complètement indépendants les uns des autres, ce qui les rend extrêmement réutilisables. 1.1.3 Bénéfices - L'approche boîte noire: Aux yeux d'un programmeur, un Bean est un composant qui n'a pas d'implantation. C'est un composant qui offre une interface publique d'utilisation (méthodes, propriétés et événements) à l'aide d'un objet de description appelé un BeanInfo. Grâce à un mécanisme d'introspection, cet objet peut être créé dynamiquement. Par conséquent, les programmeurs peuvent utiliser un Bean sans en posséder les programmes sources. - Manipulation visuelle : Plusieurs environnements de développement permettent aux concepteurs d'applications de manipuler les Beans graphiquement pour modifier leurs comportements et leurs propriétés. De plus, le modèle Java Bean offre la
possibilité aux programmeurs de fournir explicitement des éditeurs de propriétés et un assistant de personnalisation avec chaque Bean créé. Les programmeurs peuvent, de cette façon, fournir des outils graphiques qui facilitent le travail des concepteurs d'applications en ce qui concerne la personnalisation des propriétés d'un Bean. Les environnements de développement fournissent aussi un moyen de définir graphiquement les interactions entre des Beans, qu'ils soient visuels ou non. Un Bean est dit visuel s'il possède une interface graphique qui est présentée à l'utilisateur d'une application qui contient le Bean. Même si un Bean est non visuel, il possède quand même une interface graphique lorsqu'il est utilisé dans un outil de développement. Cette interface graphique est utilisée par les concepteurs d'applications. - Indépendance : Les Beans sont généralement implantés en respectant un modèle d'événement qui facilite les interactions tout en favorisant l'indépendance. Ce modèle permet à un Bean de produire des événements que d'autres Beans peuvent utiliser pour réagir. 1.1.4 L'anatomie d'un Java Bean services fivénements Propriétés Persistance (- pib~~quer) Actives 1 Passives Utilisés a la > conception Utilisés a l'exécution FIG. 1 - L 'anatomie d'un Java Bmn Il est assez difficile de déterminer si un objet est un Bean ou pas. Le modèle Bean
est décrit par un ensemble de règles optionnelles. Par exemple, si un composant ne res pecte pas le standard de nomenclature Java Bean, il peut fournir explicitement un objet BeanInfo qui contient les informations normalement trouvées par introspection. La plupart des objets fournis avec Java peuvent d'ailleurs être considérés des Beans puisqu'ils respectent au moins le standard de nomenclature Java Bean. Néanmoins, pour créer des composants très réutilisables, il est préférable de respecter toutes les règles du modèle Bean. La figure 1 illustre l'anatomie d'un Bean qui respecte toutes ces règles. Voici la description de cette figure. - Services : Les services sont offerts par des méthodes publiques que les concepteurs peuvent utiliser librement. Il est à noter que les utilisateurs de services n'ont pas besoin d'une spécification de services pour les découvrir. Ils utilisent le mécanisme d'introspection. - Évhements: Les événements sont très utiles pour permettre à un composant d'interagir avec d'autres qu'il ne connaît pas préalablement. Le modèle à base d'événements fourni par Java est particulièrement bien adapté à cet effet. Il offre un mécanisme standard qui permet à n'importe quel composant consommateur d'événements de s'enregistrer auprès de n'importe quel composant producteur. Cette approche permet de créer des composants indépendants les uns des autres. Selon le modèle Bean, il existe deux types d'événements: les événements unicast et broadcast. Les composants qui produisent des événements unicast ne permettront qu'à un seul composant de s'enregistrer pour les recevoir. Les composants qui produisent des événements broadcast ne limitent pas le nombre de composants consommateurs. - ProprMtés: Une propriété est un attribut qui peut être utilisé en lecture ou en écriture pour modifier l'état d'un Bean. Comme un Bean est aussi un objet, ses attributs sont protégés par I'encapsulation. Le modèle Bean spécifie que chaque propriété doit être accédée à travers une méthode de modification (setter) ou une
méthode de lecture (get ter). Le modèle Bean offre aussi un mécanisme très intéressant qui permet à un compe sant d'informer d'autres composants lorsqu'une de ses propriétés est modifiée. Ce mécanisme fonctionne un peu de la même façon que le modèle d'événements. Des composants consommateurs peuvent s'enregistrer auprès d'un composant producteur qui les informera au moment opportun. Le composant producteur peut offrir deux types de senices pour informer les autres d'un changement : un service passif ou actif. Le service actif permet à des composants consommateurs de s'opposer (droit de veto) à une modification de propriété. Lorsque c'est le cas, tous les composants consommateurs sont informés que le changement n'a finalement pas eu lieu. Évidemment, le composant producteur a toujours le pouvoir de refuser de respecter le droit de veto d'un autre composant. Le service passif n'attribue aucun droit de veto au composants consommateurs. - Persistance: Un Bean peut devoir être sauvegardé par une applications pour conserver des informations (par exemple, Un Bean qui représente un compte bancaire). Il peut aussi être sauvegardé par un concepteur d'application pour conserver un nouveau comportement. Le service de persistance utilisé par les Beans est celui qui est fourni par Java pour sauvegarder de simples objets. Ce service peut être utilisé de fqon complètement transparente. Finalement, les Beans sont généralement contenus dans des fichiers de type Java ARchive (JAR). La manipulation de ce type de fichier est complètement intégrée à Java. - BeanInfo : L'objet BeanInfo contient toutes les informations normalement définies par un langage de spécification de services tel que ceux utilisés par RPC et CORBA. Il contient donc la signature des méthodes, la liste des propriétés, le nom des événements générés, la liste des exceptions générées et la liste des propriétés dont la modification peut être observée de façon active ou passive. Il peut aussi contenir
des icônes servant à représenter un Bean daas un environnement de développement. L'objet BeanInfo peut être fourni explicitement par le concepteur de Beans ou il peut être généré par un outil d'introspection (Introspector). Le langage Java offre un service d'introspection complet qui permet de découvrir la structure interne d'un objet sous sa forme binaire. Pour que l'objet Beadnfo puisse être généré a partir de l'introspection, les concepteurs de Beans doivent respecter un standard de nomenclature spécifique pour la création des Beans. - Éditeur de propriétes: Pour faciliter la manipulation des propriétés d'un Bean lors de son utilisation par le concepteur d'applications, des éditeurs de propriétés peuvent être utilisés. Ces éditeurs doivent être fournis par le concepteur du Bean et chaque propriété peut avoir son propre éditeur. Les environnements de dévelop pement utiliseront ces éditeurs explicitement fournis au lieu d'utiliser une interface standard permettant de modifier la valeur des attributs. Supposons qu'un Bean possède une propriété de type entière qui représente le jour de la semaine. Si aucun éditeur n'est fourni, le concepteur utilisera l'interface graphique standard fourni par l'environnement de développement pour modifier cette valeur. Dans ce cas, le concepteur peut utiliser n'importe qu'elle valeur entière pour modifier la propriété, ce qui n'est pas souhaitable. Par contre, si un éditeur est fourni, le concepteur est contraint d'utiliser un menu affichant les jours de la semaine en texte, ce qui assure la cohérence de la valeur de la propriété. - Assistant de personnalisation : L'assistant de personnalisation est l'équivalent des assistants personnels de plus en plus utilisés pour aider les utilisateurs de logiciel (par exemple, Word). II doit être fourni par le concepteur du Bean et il est utilisé pour personnaliser les propriétés à travers des questions. Il représente en quelque sorte plusieurs éditeurs de propriétés intégrés dans un seul outil graphique.
1.1.5 L'introspection L'outil d'introspection est utilisé pour découvrir dynamiquement les services offerts par un Bean. Contrairement à RPC et CORBA, les Beans ne doivent pas être expli- citement décrits à l'aide d'un langage de spécification de services. L'avantage de cette approche est qu'il n'est pas nécessaire de manipuler des fichiers IDL et un compilateur d'interface. Pour implanter un outil d'introspection, il faut utiliser un langage de programmation qui offre des services de réflection. Comme il n'existe aucun standard concernant l'utilisation de ces services, l'outil d'inspection doit être développé pour un langage spécifique. En d'autres termes, l'outil d'introspection utilisé par les Beans ne fonctionne que pour des composants développés avec Java. Cette particularité constitue le principal désavantage de cette approche; les Beans ne peuvent pas être développés avec d'autres langages de programmation que Java. L'outil d'introspection est utilisé par les environnements de développement pour informer le développeur des services qui sont offerts par les Beans. Il peut aussi être utilisé par un programme quelconque pour découvrir dynamiquement les services qui lui sont offerts par un Bean. 1.1.6 Conclusion Les Beans représentent sans aucun doute un modèle de composants très flexible qui facilite grandement le développement. Néanmoins, ils ne sont d'aucune utilité dans des environnements répartis. Les Beans ne sont pas des composants répartis comme c'est le cas avec CORBA. Par contre, ils offrent un meilleur support en ce qui concerne les concepteurs d'applications. De plus, les mécanismes d'événement et d'avertissement COnernant les modifications d'attributs permettent la création de composants totalement indépendants qui peuvent facilement interagir.
1.2 Le modèle de composants répartis CORBA 1.2.1 Introduction Le modèle composants répartis est en quelque sorte un croisement entre les modèles orienté objet et client-serveur. Comme un objet, un composant est une entité logique qui contient des données et qui est capable d'exécuter des opérations (méthodes) sur ces dernières. Les méthodes peuvent être utilisées localement ou à distance comme c'est le cas avec les modèles client-serveur à base d'appel de procédure distante tels que le Remote Procedure Cal1 de Sun (SunRPC [47]) et le Remote Method Invocation de JavaSoft (JavaRMI [46]). Néanmoins, contrairement à un objet, un composant ne dépend pas d'un langage de programmation, d'un système d'exploitation ou d'une architecture d'ordinateur. Les services offerts par un composant peuvent être utilisés par un programme client écrit avec un langage quelconque, hébergé par un ordinateur d'architecture différente et un système d'exploitation distinct. Cette forme d'indépendance ajoute une nouvelle dimension au concept de réutilisation puisque le composant peut être utilisé par un plus grand nombre de clients qu'un simple objet, ce qui lui procure un meilleur potentiel de réutilisation. L'indépendance des composants concernant l'environnement est fourni par un intergiciel (middleware). Ce type de logiciel est responsable de créer l'illusion que tous les composants sont hébergés dans un même ordinateur et évoluent dans un envrionnement homogène. De facon plus précise, I'intergiciel joue le rôle de l'intermédiaire entre les clients et les composants en transformant les appels de méthodes en transmissions de messages (requêtes et réponses) de façon complètement transparente. II existe actuellement plusieurs intergicieis permet tant la conception de composants répartis dont CORBA. Cette section présente CORBA alors que la section suivante traite d'autres approches.
1.2.2 Description Common Object Request Broker Architecture (CORBA) [59, 69, 671 est un intergiciel permettant la création de systèmes à base de composants répartis. La création de CORBA a été entreprise en 1989 par 1'Object Management Group (OMG)[54], un consortium qui regroupe plus de 800 compagnies de tous les domaines de l'informatique. Le but ultime de 1'OMG est de donner naissance à un intergiciel normalisé qui soit utilisé par toute la communauté des développeurs de systèmes répartis. Son travail se limite à la création de spécifications qui peuvent ensuite être utilisées par différents fabriquants pour implanter des intergiciels qui soient compatibles. La version 1.1 de la spécification CORBA a été introduite en 1991 et elle normalise seulement l'interface d'utilisation. La normalisation des interactions entre deux implantations différentes de CORBA a été introduite avec la version 2.0 en 1995. Enfin, la version 3.0 [55] normalise principalement le mécanisme de démarrage des services. Avec CORBA, les interactions entres les composants répartis (généralement appelés objets CORBA) sont pris en charge par le Object Request Broker (ORB) [60] via un mécanisme d'appel de methodes distantes. Par ailleurs, dans le but d'accélérer le processus de développement, 1'OMG a normalisé un ensemble de services et de facilités dont il est respectivement question aux sections 1.2.7 et 1.2.8. 1.2.3 Bénéfices L'utilisation de CORBA offre de nombreux bénéfices. Certains d'entre eux sont aussi offerts par d'autres intergiciels mais ceux-ci n'ont pas l'avantage d'être normalisés par un organisme d'importance tel que 1'OMG. Voici une courte liste des bénéfices de l'utilisation de CORBA : - Utilisation statique et dynamique de services: Comme c'est le cas avec WC, un programme CORBA peut bénéficier d'un service en utilisant une méthode
générée par le compilateur de spécification de services. Toutefois, avec CORBA le programme peut aussi utiliser un service pour lequel aucune méthode n'a été générée par le compilateur de spécifications. Ce type d'utilisation est dit dynamique puisque le service utilisé est préalablement inconnu du programme utilisateur et découvert au moment de son exécution. - Interaction via des langages de haut niveau diffhrents: Un objet CORBA peut être utilisé par un programme client implanté avec un langage de haut niveau différent. Cette particularité nécessite néanmoins l'utilisation d'un langage de spécification de services dont il est question dans la section 1.2.4. - Systéme de description des services: CORBA fournit un entrepôt (interface repository) contenant des informations qui décrivent en détails les services offerts par les objets CORBA. Ces informations peuvent être utilisées par des outils de développement pour effectuer de l'introspection ou de la génération de code. Enfin, cet entrepôt est utilisé par l'orb pour implanter le mécanisme d'appel dynamique de méthodes. - Indépendance face à la localisation des services: L'ORB peut être utilisé dans le cadre d'une confédération où tous les ORBs sont interconnectés pour donner l'impression qu'ils constituent un seul ORB gigantesque. Typiquement, les ORBs d'une confédération sont hébergés par différents ordinateurs et communiquent via un protocole normalisé par l'organisme OMG. Ce protocole est appelé General Inter-ORB Protocol (GIOP). - Gestion de la s6curité et des transactions: Chacun des messages échangés entre deux ORBs contient des informations de contexte utilisées pour permettre
une communication sécuritaire et fiable. - Polymorphisme: L'utilisation de l'orienté objet fait en sorte que l'appel d'une même méthode sur deux objets distincts peut engendrer un résultat différent. Selon la terminologie du paradigme orienté objet, cette situation est décrite comme étant du polymorphisme. La plupart des autres intergiciels n'offrent pas cette possibilité. - Coexistame avec les syst&mes existants : CORBA sépare l'implantation des services de leur spécification en utilisant un langage de haut niveau appele le Interface Definition Language (IDL). L'IDL est utilisé pour spécifier l'interface des services disponibles aux clients. Ces services peuvent être implantés dans une multitude de langages de programmation. Cette approche permet la réutilisation d'anciens systèmes puisqu'il suffit de les décrire avec I'IDL. 1.2.4 Spécification de services Comme pour RPC, le langage de spécification de services sert à décrire les services offerts. Le langage utilisé est un sous-ensemble de C++ adapté à la création de systèmes répartis. Avec I'IDL de OMG, les services offerts sont décrits en termes de méthodes et d'objets. Les spécifications de services CORBA peuvent être traduites dans six langages d'implantation : C, C++, Smalltalk, Ada, COBOL et Java [56]. Pour chaque objet spécifié, le compilateur de spécifications de CORBA engendre un objet local pour le client (un stub) et un autre pour le serveur (un squelette). Lorsqu'un client veut bénéficier d'un service, il utilise une méthode du stub qui représente le service désiré. Le stub crée l'illusion que les services qu'il représente sont situés sur le même ordinateur site que celui du client. Il achemine la demande de service à l'objet qui les