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

Acquisitioris et raphic Services services biôliiraphiques

The author has p t e d a non- exclusive 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 communi-

cation 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 iii

Table des mati&res iv

Liste des tableau vii

Liste des figures 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 A R 0 0 : 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 L E 0 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'im-

porte 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 vir-

tuelle à 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 Microsys-

tems 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 par-

faitement 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 com-

munication (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 com-

posants 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 compo-

sant 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 modi-

fier 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 graphi-

quement 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 mo-

dè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 l'exécution

FIG. 1 - L 'anatomie d'un Java Bmn

Utilisés a la > conception

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 plu-

part 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 permet-

tront 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 produc-

teur 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. Évi-

demment, 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 a u 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 ban-

caire). 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 uti-

lisé 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 compila-

teur 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 in-

former 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 CO-

nernant 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 inter-

giciel (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 plu-

sieurs 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 proces-

sus 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

W C , 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 In-

terface 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 mul-

titude de langages de programmation. Cette approche permet la réutilisation d'an-

ciens 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

implante. Pour ce faire, le stub utilise l'ORB pour localiser l'implantation du service

désiré. Ensuite, il lui fait parvenir la demande et récupère le résultat produit. Le sque-

lette est quant à lui chargé de recevoir les demandes s'adressant à l'objet CORBA qu'il

représente. Il reformule les demandes conformément à l'implantation du service, interroge

l'objet CORBA et retransmet le résultat s'il y a lieu.

1.2.5 L'Object Management Architecture

1 Objets 1 Facilités Norxdisks

(Coumon Facilities - COF)

1 Courtier d'objets (Object Request Broker - ORB) 1

1 SeMces Normalisés (Common Objet Servcies - COS) 1

FIG. 2 - Object Management Architecture

CORBA est basé sur l'architecture nommée Object Management Architecture (OMA)

illustrée a la figure 2. C'est à l'automne de l'année 1990 que la première version de cette

architecture a été publiée. Elle a ensuite été revue et modifiée en 1992 et 1995. Voici la

description des quatre composants de l'architecture OMA :

1. L'ORB est le composant qui est responsable de la communication entre les pro-

grammes clients et serveurs. Il établit les relations client-serveur entre les parti-

cipants. Le stub et le squelette utilisent les services offerts par l'ORB de façon à

rendre transparentes les interactions entre des objets CORBA.

2. Outre la communication entre les participants, CORBA offre un ensemble de ser-

vices qui peuvent être utilisés par les objets CORBA. Ces services sont com-

munément appelés les services normalisés CORBA (Common Object SeMces -

COS). Ils peuvent par exemple servir à créer des objets, leur affecter des noms,

gérer la sécurité et le temps. Les COS sont des services qui sont traditionnellement

offerts par les systèmes d'exploitation répartis pour faciliter la création de systèmes

répartis.

3. CORBA offre aussi un ensemble de services appelés facilités CORBA (Common Ob-

ject Facilities - COF) qui peuvent être utilisés à un niveau hiérarchique supérieur à

celui des COS. Les COF sont généralement utilisés par des objets d'application pour

effectuer des tâches plus spécialisées comme l'utilisation d'une interface graphique

ou la mobilité des objets CORBA.

4. Les objets d'application sont ceux qui composent les applications et qui utilisent

des objets CORBA à travers un ORB.

1.2.6 L'anatomie d'un ORB

1 Implantation des objcts

v w w

Dii Stub Inter. Squelette DSI Enîrepôt

I I

FIG. 3 - L 'anatomie d'un ORB

I I Interfàce & c o ~ c a t i o n ORB

Comme il a déjà été question, l'ORB sert essentiellement à établir les relations client-

serveur entre les clients et les objets CORBA. Il peut établir des relations statiques ou

dynamiques selon les besoins du client. L'ORB offre des senrices qui sont soit utilisés

par les clients (par exemple, l'appel de méthodes), par les objets CORBA (par exemple,

l'activation d'objets) ou par les deux (par exemple, la sérialisation de référence sur des

objects CORBA). La figure 3 illustre l'anatomie d'un ORB et sa relation avec les pro-

grammes clients ainsi qu'avec les objects implantés. La suite de cette section contient la

description des services offerts par chacun des composants du ORB.

Les composants utilisés par le client

- Le stub permet l'utilisation statique des services. Il est généré dans le même lan-

gage que le client qui l'utilise. La génération du code est effectuée par le compilateur

de spécifications IDL. Lorsque la spécification est compilée, chaque service spécifié

engendre la création d'un objet stub. Le stub possède un ensemble de méthodes

qui représentent les services offerts. Pour utiliser les services d'un objet CORBA, le

programme client doit d'abord obtenir une référence à l'objet désiré. La référence

obtenue est en réalité une instance de l'objet stub correspondant. Le client doit

ensuite utiliser la méthode du stub qui représente le service voulu. Chacune de ces

méthodes commence d'abord par générer une requête à l'aide des paramètres reçus.

Ensuite, la requête est transmise et la réponse (si réponse il y a) est récupérée.

Contrairement à SunRPC, le langage d'implantation du stub n'est pas nécessaire-

ment le même que celui du squelette. Cette particularité permet à un programme

client d'utiliser un service à partir du langage d'implantation de son choix (figure 4).

- Le Dynamic Invocation Interface (DII) est le mécanisme dont se sert le client

pour l'utilisation dynamique des services. Ce mécanisme permet à un client de

bénéficier d'un service sans en posséder le stub. L'utilisation de ce mécanisme force

r"""""""'

Implantation i dessetYices I

FIG. 4 - Utilisation interiangages d'un service

néanmoins le programme client à effectuer explicitement les tâches du stub, ce qui

élimine toute transparence. En d'autres termes, le client doit localiser le service

désiré, lui transmettre un message de requête et obtenir le message de réponse.

DI1 oâre une façon de découvrir les services offerts au moment de l'exécution du

client. Lorsqu'un client découvre un service, DI1 lui donne une requête qui décrit sa

signature. Le client utilise ensuite cette requête pour fournir les paramètres d'entrée

et demande à DI1 de la transmettre et de récupérer la réponse produite. La réponse

est fournie par DI1 sous une forme de message que le client doit manipuler pour

en extraire les informations. Il est à noter que puisque le client effectue les mêmes

tâches qu'un stub, le serveur est incapable de distinguer un appel de méthode

dynamique d'un appel statique.

- L'entrepôt des spécifications de seMces est en quelque sorte une base de

données distribuées qui contient la spécification de tous les services enregistrés à

un moment donné. L'entrepôt offre la possibilité d'ajouter, d'obtenir et de modifier

les spécifications qu'il contient. Les spécifications sont contenues sous une forme

binaire pour faciliter leur utilisation par des programmes. C'est le compilateur de

spécification qui est responsable de fournir cette forme binaire. Tous les services qui

sont enregistrés dans un ORB sont tenus de fournir cette forme de spécification à

l'entrepôt. Le mécanisme d'utilisation dynamique des services utilise cet entrepôt

pour permettre aux clients de découvrir dynamiquement les services offerts.

Les composants utilisés par le serveur

- Les squelettes sont des classes qui représentent l'équivalent des stubs pour le ser-

veur. Ils sont aussi générés par le compilateur de spécifications IDL et permettent

l'utilisation statique des services. Pour implanter la spécification d'un serveur, le

programmeur doit créer un objet qui hérite du squelette approprié et ajouter l'im-

plantation des services. Lorsque le ORB du serveur reçoit une demande de ser-

vice (une requête), il la transfère à l'objet concerné. Cet objet utilise d'abord les

méthodes du squelette pour décoder les paramètres. Ensuite, il appelle la méthode

qui implante le service et récupère la réponse. Finalement, il utilise les méthodes

du squelette pour encoder la réponse et la transmettre au client.

- Le Dynamic Skeleton Interface (DSI) est le mécanisme dont se sert le serveur

pour l'utilisation dynamique des services. Ce mécanisme permet à un ORB d'uti-

liser un service sans en posséder le squelette. Ce mécanisme est équivalent à celui

qui permet au client d'utiliser dynamiquement (sans stub) un service. En général,

I'ORB reçoit des demandes de services pour lesquelles il possède un squelette (cas

statique). Lorsque ce n'est pas le cas, l'ORB est forcé d'effectuer le travail du sque-

lette lui-même. Pour ce faire, il emploie le mécanisme d'utilisation dynamique des

services. Ce mécanisme lui permet d9encoder/décoder les paramètres, d'appeler la

méthode appropriée et de retourner la réponse au client. Le type d'utilisation (sta-

tique ou dynamique) employé par I'ORB est complètement transparent en ce qui

concerne le programme client et l'implantation du service.

- Le r4partiteur (Object Adapter) est le composant du ORB qui reçoit toutes

les demandes de services. Le répartiteur est toujours en marche et en attente de re-

cevoir une demande de service. Il utilise l'interface de communication du ORB pour

la réception des requêtes. Les objets CORBA enregistrent leurs services auprès du

répartiteur de telle sorte qu'il peut leur acheminer les requêtes qu'il reçoit. Lors de

l'enregistrement d'un service, le répartiteur ajoute les informations nécessaires dans

l'entrepôt des implantations. Pour des raisons de performance, tous les services en-

registrés dans un ORB ne sont pas actifs (chargés en mémoire et en exécution) en

même temps. Typiquement, certains services sont toujours actifs et d'autres sont

seulement démarrés lorsque nécessaire. Néanmoins, afin de minimiser le travail du

côté du client, l'ORB serveur offre l'illusion que tous ses services sont actifs. C'est

le répartiteur qui est responsable de créer cette illusion. Lorsqu'il reçoit une de-

mande de requête pour un objet CORBA qui n'est pas actif, il l'active et lui fait

parvenir la demande de service. Le répartiteur offre plusieurs schéma d'activation

d'un service. Par exemple, il est possible de faire en sorte que le répartiteur démarre

et arrête une nouvelle copie du service pour chaque demande. Il est aussi possible

qu'il utilise toujours la même copie du service demandé. Selon CORBA 2.0 [58],

chaque ORB doit fournir un répartiteur de base (Basic Object Adapter - BOA)

qui offre quatre schémas d'activation. Néanmoins, CORBA 2.0 ne spécifie pas de

quelle façon le BOA est accessible ni comment les schémas d'activation doivent

6tre fournis. Cette situation a engendré beaucoup d'incompatibilité entre les BOAS

des différents fournisseurs de ORB. Pour remédier à cette situation, I'OMG a in-

troduit un nouveau répartiteur dans CORBA 3.0 (551. Ce nouveau répartiteur est

complètement normalisé (incluant les schémas d'activation) et se nomme Portable

Object Adapter (POA).

- L'entrepôt des implantations est une base de données qui contient des infor-

mations utilisées par le répartiteur durant son exécution. Cet entrepôt contient la

liste des services enregistrés et de ceux qui sont actifs à un instant donné. L'en-

trepôt peut aussi être utilisé pour y sauvegarder des informations non standard

telles qu'un journal des transactions et des informations relatives à la sécurité.

Les composants utilisés par le serveur et le client

- L'interface du ORB contient un ensemble de seMces qui peuvent être utilisés

localement. Cette interface fournit par exemple un moyen de convertir une référence

à un objet CORBA en une chaîne de caractères (et vice versa). Ce service peut être

utilisé par des applications pour sauvegarder ou échanger de telles références.

- L'interface de communication est l'épine dorsale du ORB puisqu'elle est le com-

posant responsable de la communication réseau. Cette interface fournit un service

de communication à travers lequel tous les objets interagissent. Pour permettre l'in-

teraction entre des ORBs de compagnies différentes, I'OMG a spécifié le protocole

de communication General Inter-ORB Protocol (GIOP). Ce protocole définit un en-

semble de formats de messages et un format de représentation interne de données

(Common Data Representation - CDR). Ces deux formats servent à l'échange d'in-

formations entre deux ORBs. GIOP représente en quelque sorte la grammaire à

utiliser pour communiquer avec d'autres ORB. Il est destiné à être utilisé avec

n'importe quelle interface de communication orientée connexion. L'Internet Inter-

ORB Protocol (IIOP) [63] est le protocole normalisé de 1'OMG qui spécifie comment

les messages GIOPs doivent être échangés en utilisant le protocole TCP/IP. Par

conséquent, les ORBs CORBA pour 1'Internet doivent tous fournir une interface

de communication qui implante le protocole IIOP.

1.2.7 Les Common Object Services (COS)

Si l'ORB (ou son interface de communication) représente la grammaire de CORBA,

les COS [62, 651 représentent le vocabulaire de base. Ce vocabulaire sert à fournir un

ensemble de services qui sont susceptibles d'être utilisés par la majorité des systèmes

distribués. Ces services sont en quelque sorte la matière première essentielle à la création

de systèmes répartis. Tkaditionnellement , cette matière première est produite par les

programmeurs pour être ensuite utilisée à la conception de leurs applications. Dans le

but de faciliter, normaliser et accélérer le processus de conception, I'OMG a spécifié 15

services qui représentent la matière première. Les fabriquants de ORB ne sont toutefois

pas tenus de fournir ces 15 services puisqu'ils sont optionnels. Voici une brève description

de chacun de ces services :

1. Le sewice de cycle de vie: utilisé pour créer, copier, déplacer et détruire des

objets.

2. Le service de persistance: utilisé pour sauvegarder des objets en utilisant par

exemple de simples fichiers, des bases de données orienté objet ou des bases de

données relationnelles.

3. Le service de noms : utilisé pour localiser des objets par leurs noms. Il est habilité

à utiliser des serveurs de noms déjà existants tels que X.500, DCE, NB+, NDS et

LDAP.

4. Le service d'événements : permet à des objets de pouvoir être informés de l'occu-

rence des événements qui les intéressent. Ce service permet aussi aux objets de pro-

duire des événements qui seront distribués à tous les ORBs d'une même fédération.

5. Le service de contrôle de concurrence : fournit un contrôleur qui s'occupe de

gérer la concurrence des accès aux ressources.

6. Le service de transactions : procure les propriétés ACID [Il] aux interactions

entre les participants. Il offre un mécanisme d'engagement à deux phases et la

possibilité d'utiliser des transactions imbriquées ou à un seul niveau.

7. Le service de relations: offre une façon d'établir des liens entre des objets.

Ce service peut être utilisé pour regrouper des objets et définir des contraintes

d'intégrité référentielle.

8. Le service d9ext6riorisation: fournit un moyen d'échanger l'état d'un objet à

l'aide d'une séquence d'octets (streaming) . La séquence peut être entreposée dans

une base de données ou dans un simple fichier. Ce service permet aussi l'échange

de paramètres par copie ce qui est autrement impossible avec CORBA.

9. Le service de requêtes : fournit un langage de recherche d'objets qui est basé sur

le futur standard SQL3.

10. Le service de licences: offre une façon de mesurer et de contrôler l'accès aux

objets. Il permet aux concepteurs d'objets de s'assurer que les clients qui utilisent

leurs objets se sont procurés une licence à cet effet.

11. Le service de propriétés : offre la possibilité d'attribuer dynamiquement des pro-

priétés à des objets. Ces attributs peuvent s e ~ r à décrire, catégoriser et rechercher

des objets.

12. Le service de gestion du temps: offre la possibilité de synchroniser le temps

dans un environnement distribué. Il peut aussi servir à planifier l'occurrence d'évé-

nements futurs.

13. Le service de sécurité : offre tout le nécessaire (liste de contrôle d'accès - ACL,

authentification, confidentialité) pour la sécurité dans un environnement distribué.

14. Le service de négociation : est un service de recherche de type pages jaunes qui

permet aux objets de publier les services qu'ils offrent et de répondre à des appels

d'offre de services.

15. Le service de collection : offre un moyen de créer et manipuler dynamiquement

la majorité des structures de données (liste chaînée, schéma de découpage, etc.).

1.2.8 Les Common Object Facilities (COF)

Si l'ORB et les COS représentent la grammaire et le vocabulaire de base, alors les

COFs [61,65] représentent des formes de rédaction. Ils sont en quelque sorte l'équivalent

des modèles de documents offerts par la majorité des logiciels de traitement de textes.

Les COFs se situent hiérarchiquement à un niveau supérieur de celui des COS. Ce sont

des services gui sont directement utilisés par la couche application (objets d'applica-

tion). Les tâches qu'ils accomplissent n'ont rien à voir avec un middleware et tout à voir

avec le domaine d'application. Il existe deux grandes catégories de COFs : horizontale et

verticale.

Les COFs horizontaux sont susceptibles d'être utilisés par la majorité des objets

d'application. Ils regroupent les COFs qui offrent des services moins spécialisés. Il existe

quatre groupes de COFs horizontaux : interfaces utilisateurs, gestion d'information, ges

tion de systèmes et gestion de tâches.

Les COFs verticaux sont des services plus spécialisés qui ne sont pas nécessairement

utiles pour tous les types d'applications. Ils offrent des services qui se rapportent à des

segments verticaux de marché tels que Les domaines de la santé, manufacturiers et finan-

ciers.

1.3 Autres modèles de composants répartis

Évidemment, CORBA n'est pas la seule approche qui permet la création de com-

posants répartis. Microsoft fournit sa propre approche qui se nomme Distributed Corn-

ponent Object Mode1 (DCOM) 1421. Un composant DCOM est un composant binaire

qui peut être utilisé de la même façon peu importe sa localisation physique. Les compo-

sants DCOM peuvent être créés à partir de plusieurs langages de programmation (C++,

Java, Visual Basic) et sont accessibles via plusieurs protocoles (TCP-UDP, IPX-SPX et

HTTP). La principale différence entre DCOM et CORBA est que les composants DCOM

ne sont pas décrit a l'aide d'un IDL comme avec CORBA. Par conséquent, les compo-

sants DCOM ne peuvent pas être automatiquement générées dans le but d'encapsuler des

systèmes existants. Par ailleurs, DCOM est principalement disponible pour les systèmes

d'exploitation de Microsoft .

Sun Microsystems fournit aussi sa propre approche qui se nomme Remote Method In-

vocation (RMI) [46]. Les composants RMI doivent absolument être développés et utilisés

à travers le langage de programmation Java. Cette approche est complètement différente

puisqu'elle repose sur la portabilité des programmes Java pour offrir l'homogénéité au

niveau des ordinateurs utilisés. La création de composants RMI impose aussi l'utilisation

d'un IDL pour offrir la transparence au niveau de la localisation des composants uti-

lisés. Par conséquent, RMI peut être utilisé pour encapsuler des programmes Java déjB

existants.

Le centre de recherche Xerox PARC fournit pour sa part une approche qui se nomme

Inter-Language Unification (ILU) [g]. Les composants répartis ILU peuvent être dévelop

pés avec plusieurs langages de programmation (C++, ANS1 C, Python, Java, Common

Lisp, Modula-3, Guile Scheme et Perl 5) en utilisant la majorité des systèmes d'exploi-

tation . Les composants peuvent être décrits avec le langage IDL de CORBA ou avec

celui fourni par ILU ILU's Interface Specàfication Language (ISL). Les composants sont

utilisés à travers des stubs et des squelettes pour permettre la transparence au niveau

de la localisation des composants. Lorsque deux composants sont distants, les stubs uti-

lisent un mécanisme de RPC pour communiquer. Par contre, lorsque les composants sont

dans le même espace mémoire, ILU utilise des appels traditionnels de fonctions ce qui

augmente considérablement la performance des appels.

1.4 Le modèle de composants agents mobiles

1.4.1 Introduction

Comme nous l'avons déjà vu, les modèles client-serveur et composants répartis sépa-

rent les programmes en deux catégories: des clients et des serveurs. De façon générale,

ces modèles fonctionnent assez bien pour la plupart des types d'applications. Par contre,

l'expérience nous a appris qu'il ne sont pas très bien adapté à la création de systèmes

hautement répartis, de systèmes qui utilisent un réseau peu fiable ou de systèmes qui sont

fréquemment modifiés. Depuis le début des années 1980, plusieurs modèles alternatifs ont

été proposés pour la création de ces types de système réparti. L'un de ces modèles est

basé sur le concept de message actif. Ce type de message contient des données et du

code exécutable. Les systèmes R2D2 [76] et Chorus [68] sont des systèmes qui utilisent ce

concept. Ils implantent un modèle selon lequel le code des message actif est exécuté par

tous les noeuds du réseau parcourus par les messages. Un autre modèle alternatif appelé

Remote Evaluation (REV) a été proposé en 1986 [TOI. Ce modèle est issu d'un croisement

entre le modèle client/serveur et le concept de messages actifs. Au lieu de transmettre

des requêtes, le client transmet du code qui est exécuté par un serveur qui retourne la

réponse produite par un message de réponse. Le langage de programmation Emerald

[31] introduit en 1988 constitue un autre modèle qui utilise le concept de transmission

de code. Ce langage est orienté objet et permet la transmission d'objets (méthodes et

attributs). Les objets peuvent être transmis à n'importe quel noeud d'un système réparti

qui utilise Emerald. Ce modèle constitue en quelque sorte le pius proche ancêtre du tout

dernier-né des modèles : le modèle agents mobiles.

Le modèle agent mobile est une évolution des modèles précédents. La figure 5 illustre

les différences entre ce modèle et les autres. Avec le modèle RPC, le client transmet des

données à un serveur qui lui retourne un message de réponse qui contient des données.

Avec REV, le client transmet du code au serveur qui lui retourne aussi des données.

PamIdtres (do&)

-- Procédure (code)

état d'exécution) Ageob

(code, données et M o b b

RPC Client 4

Agent Commettant I (code, données et )I

Résultats (données) ;

Smeur

REV Client 1

d'agents Serveur

FIG. 5 - Modèles alternatifs

Rtsultats (données)

smeur

Agent (code, damées et

Contrairement à RPC et à REV, la notion de client et de serveur d'application n'existe

Serveur d'agents

pas avec le modèle agents mobiles. Les systèmes répartis sont composés d'agents mobiles

qui peuvent se déplacer pour utiliser les différents ordinateurs d'un système. Ces agents

état d'exécution)

sont autonomes et ils ne transmettent pas nécessairement une réponse après avoir été

transférés.

Un système à base d'agents mobiles est généralement constitué d'agents stationnaires

et d'agents mobiles qui collaborent pour accomplir des tâches. Comme l'indique son nom,

l'agent stationnaire est immobile. Il est responsable d'offrir des services qui donnent accès

aux ressources qu'il représente. Ce type d'agent ne fournit pas de services spécialisés

comme le fait l'entité serveur du modèle client-serveur. Il offre seulement des services de

base que les agents mobiles peuvent utiliser pour implanter leurs propres services d'ap

plication. L'agent mobile est chargé de représenter son commettant (agent ou humain)

dans l'accomplissement d'une tâche. 11 implante des semices d'application en utilisant

des services de bases et/ou des services offerts par d'autres agents mobiles. Il est à la fois

un serveur et un client puisqu'il offre ses services à un commettant tout en utilisant des

services offerts par d'autres agents. Durant l'accomplissement de sa tâche, il peut être

appelé à migrer vers d'autres ordinateurs pour bénéficier de la performance des interac-

tions locales. Le résultat produit par un agent mobile peut être transmis ou transporté

avec lui s'il retourne à son lieu d'origine.

1.4.2 Qu'est-ce qu'un agent ?

Il est très difficile de donner une seule définition au terme agent puisqu'il est utilisé

dans plusieurs domaines de l'informatique. Pour les gens du domaine de l'intelligence

artificielle, un agent est un programme intelligent et autonome. Pour les gens qui oeuvrent

dans le domaine de la gestion de réseaux, un agent est un programme autonome qui réagit

à des stimulis externes en fonction de règles préétablies. Le concept d'agent est aussi

très semblable au concept d'acteur utilisé dans le domaine des systèmes temps réel [32].

Finalement, dans le domaine des systèmes répartis, un agent est un programme mobile.

Comme vous pouvez le constater, le terme agent possède plusieurs définitions. Tenter

d'en imposer une seule qui fasse l'unanimité est très difficile. Par conséquent, plusieurs

systèmes de classification (taxonomies) ont été proposés pour pouvoir reconnaitre les

agents à partir de leurs caractéristiques [7, 26, 51. A notre avis, la plus simple et la plus

complète des taxonomies est celle qui a été proposée par [26]. Selon cette taxonomie, tous

les agents peuvent être décris en utilisant un espace tridimensionnel qui possède les axes

suivants (figure 6) : l'autonomie, l'intelligence et la mobilité.

Autonomie

Mobilité

FIG. 6 - Tuonornie en trois axes

- L'autonomie est la caractéristique qui décrit à quel point un agent est capable

d'agir sans intervention de son commettant. Un agent autonome est un programme

qui représente son commettant en prenant des décisions en son nom. L'autonomie

est la caractéristique qui nous à fait passer de simples programmes réactifs à des

programmes actifs (321.

- L'intelligence décrit la capacité d'un agent à acquérir et utiliser des informations

(raisonner) dans le but de solutionner des problèmes. Les agents intelligents peuvent

êtres implantés à l'aide d'un agencement logique de code pour simuler une certaine

forme d'intelligence (391. Ils peuvent aussi être implantés à l'aide de techniques

avancées d'intelligence artificielle telles que l'inférence et l'apprentissage [5].

- La mobilité décrit la capacité d'un agent à se déplacer d'un système à un autre.

La mobilité des agents est souvent limitée par des contraintes de sécurité. Certains

types d'agent permettent seulement un déplacemment dans un environnement ho-

mogène. D'autres permettent seulement le fonctionnement avec un réseau local. Un

agent complètement mobile est un agent qui peut se déplacer sur n'importe quel

type de réseau dans un environnement hétérogène.

Cette taxonomie peut être utilisée pour catégoriser les agents de tous les domaines

de l'informatique. Les agents du domaine de l'intelligence artificielle peuvent être

décrits en utilisant les axes de l'autonomie et de l'intelligence. Ceux des domaines

de la gestion de réseaux et des systèmes répartis peuvent être décrits selon les axes

de l'autonomie et de la mobilité.

1.4.3 Bénéfices

Même si la notion de client et de serveur d'application n'existe pas dans le mo(

agents mobiles, il est possible de simuler le modèle client-serveur. Pour ce faire, il suffit

d'utiliser des agents stationnaires qui interagissent par le biais d'échanges de messages

(requête-réponse). Le modèle composants répartis peut quant à lui être simulé en utilisant

des agents stationnaires qui interagissent de façon indirecte. Par conséquent, le modèle

agents mobiles est un modèle plus général que les modèles client-serveur et composants

répartis. Il offre les mêmes bénéfices que les deux modèles précédents et même davantages

[35] grâce au concept de mobilité des agents. Voici la liste des principaux bénéfices reliés

à l'utilisation des agents mobiles.

- Réduction de l'utilisation du réseau : Avec un système réparti client-serveur,

chaque interaction engendre la transmission de deux messages (requête et réponse).

Comme l'accomplissement d'une tâche nécessite généralement plusieurs interac-

tions, nous pouvons conclure que le modèle client-serveur génère beaucoup de trafic.

En fait, ce modèle génère 2 * N(T) messages où N ( T ) indique le nombre d'inter-

actions à effectuer pour accomplir une tâche T. Conséquemment, la performance

d'un système réparti client-serveur est étroitement reliée à la performance du réseau

utilisé [41]. C'est d'ailleurs pour cette raison que ce modèle n'est pas adapté à la

création de systèmes hautement répartis ou à l'utilisation d'un réseau a faible débit

ou non fiable.

Avec le modèle agents mobiles, l'accomplissement d'une tâche peut toujours s'ef-

fectuer avec l'échange de deux messages : la transmission et la réception d'un agent.

En effet, lorsqu'un agent doit effectuer plusieurs interactions avec une ressource, il

se transporte vers celle-ci, l'utilise localement et retourne à son lieu d'origine. Ainsi,

en plus de minimiser le nombre de messages transmis, cette approche permet à un

agent mobile de bénéficier de la performance des interactions locales. Évidemment,

deux messages qui contiennent un agent sont généralement plus voluminew que de

simples messages de requête. Par contre, les réseaux à haute vitesse d'aujourd'hui

souffre davantage d'un grand délai de latence que d'un faible débit. Par conséquent,

le transfert d'un grand message n'est pas toujours plus long que le transfert d'un

petit [36].

En résumé, la performance des systèmes distribués qui effectuent beaucoup d'in-

teractions peut être grandement améliorée avec les agents mobiles (figure 7). Ils

peuvent aussi être utilisés pour réduire les frais de communication pour les appli-

cations qui communiquent par un réseau sans fil (par exemple, les personnal digital

assistankr - PDA) [22, 251. Finalement, les agents mobiles peuvent aussi servir à

masquer les mauvaises performances d'un réseau.

- Optimisation de l'utilisation des ressources : La durée d'utilisation des res-

sources est aussi un facteur qui influence la performance d'un système réparti. Plus

les ressources sont utilisées pendant de longues périodes de temps, moins elles sont

disponibles pour les autres participants. L'utilisation d'une ressource nécessite géné-

ralement plusieurs interactions. Avec le modèle client-serveur, la durée de l'utilisa-

tion d'une ressource s'étend de la réception de la première requête à la production

de la dernière réponse (figure 7).

La performance du réseau influence beaucoup moins la durée d'utilisation des res-

sources avec l'approche agents mobiles (figure 7). Le modèle agents mobiles mi-

nimise le temps d'utilisation des ressources puisque les agents peuvent migrer et

interagir localement. La grande majorité des systèmes distri bu& peut bénéficier

de cette optimisation. Par exemple, grâce aux agents mobiles, il est maintenant

possible d'utiliser un réseau qui impose une grande latence pour développer des

systèmes temps réel [36].

- Augmentation de l'asynchronisrne : Avec les agents mobiles, l'exécution d'un

service ne nécessite pas que les ordinateurs utilises par deux agents mobiles soient en

marche en même temps tout au long des interactions. La synchronisation des deux

ordinateurs est seulement necessaire lors de la migration d'un agent. Une fois migré,

un agent mobiie est capable d'accomplir ses tâches de façon autonome. L'ordinateur

utilisé par le commettant (lieu d'origine d'un agent) peut même être éteint durant

l'exécution du service. Évidemment, pour retourner à son lieu de départ, un agent

mobile doit attendre que l'ordinateur du commettant soit en marche.

Le modèle agents mobiles est particulièrement bien adapté à la création d'applica-

tions pour les ordinateurs (ordinateur portable, PDA) qui utilisent un accès réseau

intermittent.

- Augmentation de l'extensibilité : L'ajout de nouveaux services d'application à

un système réparti est inévitable dans un monde où tout évolue si rapidement. Par

conséquent, les systèmes répartis doivent être facilement extensibles. Avec l 'ap

proche client-serveur, l'ajout de nouveaux services nécessite la modification du

programme serveur. Une fois modifié, compilé et vérifié, le nouveau programme

serveur est utilisé pour remplacer l'ancien. Le processus de remplacement entraîne

évidemment l'interruption momentanée des services ce qui n'est pas toujours sou-

haitable (par exemple, la téléphonie et l'électricité). Pour éviter cet inconvénient,

il est possible de ne pas remplacer l'ancien serveur et d'offrir les nouveau services

ailleurs. Toutefois, les programmes clients qui ont besoin des nouveaux services

doivent être informés (modifiés, compilés et vérifiés) de la localisation du nouveau

serveur. Cette approche n'est guère mieux puisqu'elle entraîne la modification de

tous les clients plutôt que celle d'un seul programme serveur. Elle offre néanmoins

l'avantage de ne pas avoir à interrompre les services offerts et de pouvoir modifier

les programmes clients graduellement.

Avec le modèle agents mobiles, les services d'application sont implantés par les

agents mobiles qui les utilisent. La création d'un nouveau service entraîne donc la

modification d'un seul programme : l'agent. Par ailleurs, cet te approche n'entraîne

pas l'interruption des services de base. En d'autres termes, l'ajout d'un nouveau

service d'application n'affecte que l'agent qui va l'utiliser ce qui est un avantage ma-

jeur [8]. Cet avantage peut par exemple être utilisé pour permettre à un système

réparti d'utiliser dynamiquement de nouveaux protocoles, ce qui intéresse parti-

culièrement les gens du domaine de la télématique.

- Augmentation de la robustesse: Les applications client-serveur utilisent un

protocole pour pouvoir interagir via un réseau. Pour utiliser un protocole, les pro-

grammes client et serveur doivent maintenir un état qui leur indique la prochaine

tâche à effectuer. Le maintient de la cohérence de ces états est absolument essentielle

à la coordination des activités des programmes. Comme cette cohérence est assurée

par l'échange de messages, la perte d'un seul message peut suffire à désynchroniser

les participants et à entraîner la panne d'un système. Les concepteurs doivent donc

s'efforcer de créer des protocoles qui tiennent compte d'éventuelles pertes de mes-

sages, ce qui est relativement difficile. Ils doivent aussi doter les programmes de

mécanismes qui leur permettent de récupérer après une panne. Tout ceci ajoute

à la complexité de la conception, de l'implantation et du maintient des systèmes

répartis client-serveur.

L'utilisation d'agents mobiles ne nécessite pas l'échange de messages sur un réseau

puisqu'ils peuvent migrer pour interagir localement. Par conséquent, les systèmes

répartis à base d'agents mobiles sont robustes et simples à créer. Par ailleurs, cer-

tains serveurs [28, 73, 51, 18, 271 d'agents offrent un service de sauvegarde perio-

dique de l'état d'un agent durant sont exécution, ce qui procure une très grande

robustesse lors de pannes imprévues.

- Augmentation du parallélisme : Il existe plusieurs façons d'accélérer l'exécution

des taches dans un environnement client-serveur. La plus facile d'entre elles est sans

aucun doute l'utilisation d'un ordinateur multi-processeurs. Néanmoins, cette a p

proche peut s'avérer très dispendieuse. Le parallélisme peut aussi être implanté en

utilisant des threads, mais cet te approche est assez complexe. Par ailleurs, l'uti-

lisation de threads mène à la création d'applications qui sont très difficiles à va-

lider et maintenir. Finalement, il est possible d'utiliser un langage de program-

mation spécialisé ou un système d'exploitation qui facilite le parallélisme ce qui

nécessite une main-d'oeuvre qualifiée. Bref, l'implantation du parallélisme auprès

d'un système client-serveur nécessi te l'utilisation d un artifice quelconque.

Avec l'approche agents mobiles, le réseau est considéré comme un seul gigantesque

ordinateur multi-processeur [39]. Chacun des ordinateurs du réseau représente en

quelque sorte un processeur du gigantesque ordinateur. Pour pouvoir bénéficier du

parallélisme, il suffit de faire migrer plusieurs agents mobiles vers différents proces-

seurs. La création d'un agent mobile est effectué en utilisant un ensemble d'outils

qui visent ii rendre la migration transparente. Par conséquent, le développeur peut

créer des programmes qui sont indépendant de leur localisation. Domel et al. [15]

décrivent différentes techniques de communication inter-agent qui offre la transpa-

rence face a la localisation.

Comme les agents mobiles peuvent naturellement migrer vers d'autres ordinateurs,

aucun mécanisme spécialié n'a besoin d'être utilisé pour l'implantation du pa-

rallélisme.

- Augmentation de l'autonomie : Les agents mobiles peuvent s'adapter de façon

autonome à différents changements dans leur environnement d'exécution. Ils peu-

vent par exemple détecter que l'ordinateur utilisé est surchargé et migrer vers un

autre ordinateur [l]. Ils peuvent aussi se rendre compte que de nouveaux services

sont offerts et que d'autres ne le sont plus. En résumé, les agents mobiles peuvent

prendre des décisions sans consulter leur commettant, ce que les programmes client-

serveur ne font généralement pas.

1.4.4 L'anatomie d'un serveur d'agents mobiles

La figure 8 illustre l'anatomie d'un serveur d'agents mobiles. Tous les ordinateurs d'un

système réparti qui utilisent (reçoivent/créent) des agents mobiles doivent posséder un

serveur d'agents. Ce serveur est responsable de créer, vérifier, transporter et exécuter tous

les agents mobiles qu'il contient. Voici la description des composants d'un tel serveur.

- Environnement d'exécution : L'environnement d'exécution est le composant qui

contient et exécute les agents mobiles et stationnaires. Ce composant est représenté

par une machine virtuelle ou un interpréteur. Le système d'exploitation peut aussi

jouer le rôle de l'environnement d'exécution lorsque les agents mobiles sont t rans

férés dans une forme binaire et dépendante d'une architecture. Certains serveurs

d'agents [66' 20, 371 utilisent plusieurs environnements d'exécution pour permettre

l'hétérogénéité au niveau des langages d'implantation des agents mobiles. D'autres

[30, 25, 291 utilisent un seul environnement d'exécution capable d'exécuter des

agents mobiles qui sont portables.

L'environnement d'exécution est aussi responsable de fournir un mécanisme de

contrôle d'accès aux ressources et aux agents tel que les access control lzsts (ACL)

[21] et [71]. Ce mécanisme est généralement utilisé par les agents stationnaires pour

restreindre l'accès aux ressources.

Enfin, l'environnement d'exécution est aussi responsable de fournir un mécanisme

d'interaction que les agents utilisent pour communiquer (voir section 1.4.6).

- Place: Une place est un contenant qui héberge des agents mobiles. En réalité,

lorsque les agents mobiles migrent, ils se transportent de place en place. Par ana-

logie, les places sont à l'environnement d'exécution ce que les boutiques sont à un

centre d'achat. Elles sont généralement utilisées pour regrouper des agents qui ont

les mêmes intérêts et qui sont susceptibles d'interagir ensemble.

- Agent : Comme il a déjà été question, il existe deux types d'agent : les agents m+

biles et les agents stationnaires. Les agents stationnaires sont typiquement chargés

dans l'environnement d'exécution au démarrage du serveur d'agents. Ils sont res-

ponsables d'offrir des services qui donnent accès aux ressources de l'ordinateur

qui héberge le serveur d'agents. Les agents mobiles sont créés par l'environnement

d'exécution et ils peuvent migrer vers n'importe quel serveur d'agents. Un agent

représente le composant de base utilisé pour la création d'applications.

- Contrôleur : La responsabilité du Contrôleur est de s'assurer que les agents mo-

biles qui proviennent de l'extérieur ne sont pas malicieux. Il existe plusieurs façons

d'effectuer ce travail de vérification (33, 161. Lorsque les agents sont interprétés, le

Contrôleur analyse leurs instructions avant de les admettre dans l'environnement

d'exécution. Quand il détecte des instructions potentiellement dangereuses pour la

sécurité du serveur d'agents, il peut soit détruire l'agent ou le modifier [2] de façon

à le rendre inoffensif. Lorsque les agents ne sont pas interprétés, le Contrôleur doit

absolument modifier les agents inoffensifs sinon la sécurité repose entièrement sur

l'environnement d'exécution (c'est-à-dre le système d'exploitation).

- Transporteur: Le Transporteur est le composant qui est responsable de trans-

mettre et recevoir les agents mobiles. Généralement, il est aussi responsable de

l'authentification et llencodage/décodage des agents mobiles. L'authentification des

agents est essentielle pour que les agents stationnaires puissent contrôler l'accès aux

ressources en fonction de l'identité des agents. Le lkansporteur est celui qui im-

plante le protocole de transfert des agents mobiles. Certains systèmes utilisent leur

propre protocole [72, 341. D'autres Tkansporteurs utilisent les protocoles HTTP

[37, 341 ou IIOP [40].

1.4.5 La migration

La migration est le processus par lequel les agents mobiles se transportent vers d'autres

ordinateurs pour y continuer leur exécution [24]. Pour migrer, un agent mobile utilise

une instruction spéciale qui indique à son environnement d'exécution qu'il désire être

transporté vers un autre ordinateur. L'agent peut utiliser cette instruction à n'importe

quel moment de son exécution. Lorsqu'il le fait, son exécution est interrompue et son

état sauvegardé pour ensuite être transporté vers un autre ordinateur. Lorsqu'un serveur

d'agent reçoit un agent, il recrée l'agent localement et lui redonne son état sauvegardé.

Ensuite, le serveur redémarre l'agent nouvellement créé ce qui complète le processus de

migration.

Il existe deux types de migration [12, 331 : la forte et la faible. La migration forte

permet à l'agent migré de recommencer son exécution à l'instruction qui suit celle qui a

été utilisée pour migrer. Pour ce faire, l'environnement d'exécution doit être capable de

sauvegarder l'état d'exécution (données, pile et compteur d'instructions) d'un agent. Cet

état prend une forme différente dans la majorité des systèmes d'exploitation, ce qui rend

la sauvegarde très difficile dans un environnement hétérogène. Néanmoins, l'utilisation

de machines virtuelles et d'interpréteurs facilite la solution du problème. Telescript et

d'Agents (191 sont des exemples d'environnements qui permettent ce type de migration.

La migation faible permet seulement à un agent d'être redémarré au début d'une

méthode (ou fonction) prédéterminée. Ce type de migration ne sauvegarde pas complète-

ment l'état d'exécution de l'agent mobile. Seules les données sont sauvegardées et trans-

mises wec l'agent. La migration faible est beaucoup plus simple à implanter et peut être

utilisée avec la majorité des machines virtuelles et interpréteurs qui ne donnent pas accès

à leur état d'exécution (par exemple, Java). Contrairement à la migration forte, la migra-

tion faible n'est pas tout à fait transparente aux yeux des concepteurs. Les agents mobiles

doivent être développés en tenant compte que l'exécution des agents sera toujours reprise

au début d'une méthode (ou d'une fonction) après une migation.

En résumé, il est beaucoup plus facile d'utiliser la migration forte puisqu'elle est

transparente en ce qui concerne le programmeur. Par contre, elle est très difficile à im-

planter et ne permet pas l'utilisation d'environnements qui ne donnent pas accès à leur

état d'exécution.

1.4.6 Types d'interaction

L'interaction entre les agents peut s'effectuer de deux façons différentes [15] : directe ou

indirecte. L'interaction directe permet à un agent d'utiliser les méthodes (ou procédures)

publiques d'un autre agent. Cette approche entraîne la création d'agents qui dépendent

les uns des autres puisqu'ils doivent connaître la signature des services qu'ils utilisent.

Pour diminuer cette dépendance, il est possible d'utiliser un mécanisme de découverte

dynamique de service comme celui de CORBA. Toutefois, l'interaction indirecte supprime

complètement cette dépendance en utilisant le concept de babillard de communication.

Avec cette approche, les agents interagissent en échangeant des messages qui sont affichés

sur un babillard publiquement accessible. Ils sont donc très indépendants les uns des

autres puisqu'ils n'ont pas besoin de se connaître pour interagir. Par ailleurs, cette forme

d'interaction facilite grandement la communication entre des agents qui utilisent des

langages d'implantation différents. Grâce à ces deux caractéristiques, il est possible de

créer des agents mobiles qui sont des composants semblables aux Java Beans (concernant

l'indépendance) et aux composants réparties de CORBA (concernant l'accès réseau et

l'hétérogénéité).

1.4.7 Implantations

Plusieurs serveurs d'agents ont été développés depuis la fin des années 1980. L'annexe

D contient une liste de serveurs d'agents mobiles présentement disponibles. Le premier

serveur d'agents a été Telescript introduit par la compagnie General Magic à la fin des

années 1980. Ce serveur d'agents est encore aujourd'hui le plus complet à avoir été créé

mais son langage de programmation propriétaire a fini par causer sa perte. L'engouement

pour le langage Java et ses applets n'est pas étranger au destin qu'a connu Telescript.

Depuis l'avènement de Java, la très grande majorité des serveurs d'agents sont développés

avec ce langage. Java offre beaucoup d'outils qui peuvent être utilisés pour développer des

serveurs d'agents. Il offre par exemple une machine virtuelle qui exécute du code portable.

Il offre aussi un mécanisme de base qui permet la transmission de code (les applets)

et d'innombrables outils de communication. Mais avant tout, Java est publiquement

accessible et gratuit.

L'OMG est actuellement en voie de spécifier une facilité [64] qui permettra l'utilisation

d'agents mobiles avec un ORB CORBA. Cette faeilité porte le nom de Mobile Agent

System Interoperability Facility (MASIF).

1 A.8 Conclusion

Le modèle agent mobile est le plus général des modèles pour la création de systèmes

répartis. Il permet de simuler les modèles RPC et CORBA alors que l'inverse n'est pas

possible. 11 possède des caractéristiques qui permettent d'optimiser la performance des

systèmes répartis traditionnels. Néanmoins, ce modèle soulève beaucoup d'inquiétudes

concernant la sécurité des ordinateurs qui hébergent des agents mobiles. Beaucoup de

recherche sont actuellement en cours [16, 74, 50, 10, 331 pour évaluer différents systèmes

de sécutié pour les agents mobiles. Certains croient que le modèle d'agents mobiles rem-

placera un jour tous les autres modèles grâce à sa performance. D'autres croient que

pour des raisons de sécurité, il sera seulement utilisé pour créer des applications très

spécialisées. Mais tous s'entendent pour dire que ce modèle est ici pour rester [33].

Modèle client-serveur

Int. 1

Int. 2

Int. 3

Modèle agents mobiks

-1

2 messages

I

3 Int. 1 3 Int. 2 3 Int. 3

FIG. 7 - Compamison de la performance entre les modèles client/serveur et agents mo- biles pour effectuer trois interactions

Environnement d'exécution

Place I I

I contrôleur I I Transporteur

I Réseau I Fic. 8 - Anatomie d'un serveur d'agents mobiles

Chapitre 2

Préliminaires sur la poursuite de

satellites

2.1 Introduction

Il existe essentiellement deux grandes classes de satellites : les Geostatàonnory Earth

Orbit (GEO) et les Low Earth Orbit (LEO). La principale différence entre ces satellites

se situe au niveau de leur position relative à la Terre. Contrairement à un LEO, un GE0

occupe une position fixe par rapport à la Terre. En d'autres termes, la région de la Terre

couverte par un GE0 est fixe alors que celle d'un L E 0 varie constamment.

De par son type de couverture, le GE0 est principalement utilisé par les télédiffuseurs

pour retransmettre leurs signaux sur de grandes régions. Ce type de satellite se situe à

environ 36 000 rn d'altitude et couvre près du tiers de la planète. La figure 9 illustre le

satellite GE0 MSat et la région qu'il couvre (cercle noire l'entourant). Pour entrer en

communication avec un GEO, il faut utiliser une antenne orientée vers le satellite ainsi

qu'un équipement de transmission/réception.

Contrairement à un GEO, un LE0 est toujours en mouvement par rapport à la surface

de la Terre. Il évolue à basse altitude d'où son nom de Low Earth Orbàt. La figure 9 montre

FIG. 9 - Couverture d'un LE0 et d'un G E 0

le satellite LE0 Huble Space Telescope (HST) et la taille de sa zone d'acquisition ainsi que

le chemin parcourue (tracé jaune). Comme ce type de satellite est toujours en mouvement,

les utilisateurs d'un L E 0 obtiennent seulement un service intermittent. De plus, à cause

de son altitude, la zone d'acquisition région couverte par un LE0 à un instant donné est

beaucoup plus petite que celle d'un GEO. Ces deux dernières caractéristiques font en sorte

qu'un LE0 n'est pas adéquat pour la télédiffusion. Par contre, sa mobilité et sa proximité

à la surface de la Terre en font un outil de choix pour la cartographie, l'étude de la planète

et la recherche d'objets (bateau en perdition, objectif militaire). Un LE0 est aussi utilisé

par les radioamateurs pour effectuer des expériences en télécommunication car, pour des

raisons techniques (autonomie, robustesse, taille, carburant), il coûte beaucoup moins

cher à produire et à lancer qu'un GEO. Pour entrer en communication avec un LEO, il

faut utiliser une antenne dont l'orientation peut être dynamiquement ajustée pendant un

passage du satellite (communément appelé la passe du satellite). La région couverte par

un LE0 à un instant donné est appelée zone d'acquisition et l'union de toutes ces zones

constituent la zone de couverture (figure 10).

FIG. 10 - Zone de couverture d'un LE0

Tout comme celle d'un GEO, l'orbite d'un L E 0 peut être circulaire. Toutefois, contrai-

rement à un GEO, la vitesse relative d'un LE0 supérieure à zéro. L'orbite d'un LE0 peut

aussi être elliptique. Par conséquent, la taille de la zone de couverture d'un LE0 ellip

tique se situe entre celle d'un GE0 et celle d'un LE0 circulaire. Ce type d'orbite peut

seulement être utilisé par les LE0 car elle entraîne une altitude et une vitesse relative

qui varient périodiquement.

A titre d'exemple, le G E 0 Direct-TV2 est un satellite américain qui rediffuse 150

canaux de télévision à travers toute l'Amérique du Nord. Son orbite est circulaire et il

évolue à une vitesse relative nulle pour maintenir sa position à O degré de latitude (plan

équatorial), -100 degrés de longitude et 35 777 km d'altitude. La station spatiale MIR

évolue aussi selon une orbite circulaire mais à basse altitude (approximativement 350

km d'altitude) et à une vitesse relative approximative de 7'7 km par seconde. Enfin, le

satellite Phase-3D de l'organisme AMSAT évoluera sur une orbite elliptique à une altitude

qui oscillera entre 4000 km et 64 470 km. La figure 11 montre la grandeur proportionnelle

des orbites utilisées par chacun de ces trois satellites.

T e r r e - S t a t i o n S tiale Mir - . 0 irec ci-d!! -. _ _ _/

- a - . - - /--

P h i ~ - 3 0

FIG . 1 1 - Trors types d 'orbites

2.2 La poursuite de satellite

L'expression poursuite de satellites réfere au processus par lequel on entre en com-

munication avec un LE0 puisqu'il faut diriger l'antenne vers le satellite en mouvement.

La duré d'une poursuite est limitée par la durée d'une passe. Une passe commence au

moment où un LE0 apparaît à l'horizon et se termine quelques secondes ou minutes plus

tard lorsqu'il disparaît. La durée de la poursuite peut être plus courte que celle d'une

passe lorsqu'un obstacle (immeuble, montagne) s'interpose entre l'antenne et le satellite.

L'antenne utilisée pour entrer en communication avec un L E 0 doit être munie d'un

dispositif qui permet l'ajustement dynamique de son orientation. L'orientation d'une

antenne se décrit par deux angles : l'azimut sur 360 degrés et l'élévation sur 180 degrés.

Tout au long de la poursuite, l'orientation de l'antenne est ajustée à intervalles réguliers.

La passe d'un LE0 est généralement décrite par une liste contenant des orientations à

des heures spécifiques. Le tableau 1 décrit une passe du LE0 HST au-dessus de la ville

de Sherbrooke (Québec, Canada) qui est située à 45,24 degrés de latitude, -71,46 degrés

de longitude et 225 mètres d'altitude.

TAB. 1 - Tableau de prédiction

L'orientation de l'antenne est une condition essentielle mais non suffisante à l'établis-

ue 10 11 12 13 4 5 6 7 8

sement d'une communication de qualité avec un LEO. En effet, il faut aussi tenir compte

de l'effet Doppler, un phénomène physique qui d e c t e les signaux de communication

Azimut -231'1" -223'6" -214'7" -204,5" -193,4" -182'0" -171,2" -161'5" -153,2"

lorsqu'un participant est en mouvement. Par exemple, du point de vue d'un individu

EUvation 0'6" 2,8" 4'7" 6'2" 6'9" 6,7" 5'6" 3'9" 1'8"

immobile, le son émis par la sirène d'un véhicule en mouvement change durant son

trajet. Lorsque l'individu est en aval, le son est plus aigu alors que le son est plus grave

dans le cas contraire. Le son émis est exactement le même que celui entendu seulement

lorsque le véhicule passe directement devant l'individu immobile. Cet exemple peut être

transposé à la poursuite de satellite en substituant l'individu par une station terrestre et

le véhicule par un LEO.

Concrètement, l'effet Doppler est représenté par une équation mathématique qui four-

nit le décalage qu'il faut appliquer à la fréquence utilisée par un LEO. Tout comme

l'orientation de l'antenne, le décalage est directement relié à la position d'un LE0 et doit

être évaluée périodiquement. Le tableau 2 illustre la même passe que celle du tableau 1

mais il contient aussi le décalage de fréquence.

Il existe plusieurs façons d'obtenir un tableau de prédiction de passe. Notamment, la

NASA offre gratuitement ses prédictions via le WEB [48] et le courrier électronique [49].

Il est aussi possible d'utiliser un ordinateur personnel muni d'un logiciel de prédiction de

passe. L'organisme AMSAT fournit d'ailleurs une liste partielle de logiciels à cet effet [3].

TAB. 2 - Tubleou de prédiction avec décalage de fréquence

1 Date 1 1 3eure 1 Azimut Él4vation Décalage de fi&uence (Hz) l3:OO 1-231.1" 10.6" +31161

Le tableau de prédiction produit par ce genre de logiciel est le résultat d'une extra-

polation basée sur la dernière position connue d'un satellite. L'extrapolation consiste à

résoudre ur. ensemble d'équations mathématiques qui modélisent le mouvement d'un sa-

tellite autour de la Terre. II existe plusieurs modèles à cet effet ([13, 231) et ils produisent

des résultats de précisions différentes. La complexité d'un modèle n'est pas étrangère à

son niveau de précision. La dernière position connue de chacun des satellites est décrite

par un ensemble d'éléments d'information. Ces informations nécessaires à l'extrapolation

sont disponibles à travers 1'Internet sous deux formats [4] : NASA et AMSAT. Elles sont

mises à jour régulièrement ce qui est utile puisque la majorité des modèles ne peuvent

fournir une bonne précision que pour trois à quatre jours d'extrapolation.

2.3 L'équipement nécessaire

Le tableau 2 contient toutes les informations qui auraient été nécessaires pour entrer

en communication avec HST le 23 octobre 1999 entre 3h00 et 3h08 a partir de Sherbrooke.

Néarimoins, ce tableau est inutile sans le matériel de communication nécessaire (voir la

Radio

FM. 12 - Équipement de communication de notre station terrestre

figure 12). Ce matériel comprend un radio émetteur/récepteur qui couvre les fréquences

employées et une antenne munie de moteurs pour l'orienter. Le radio est reliée a l'antenne

avec un câble. Aussi, le moteur de l'antenne est généralement relié à un périphérique

de contrôle qui permet de modifier l'orientation à distance. Avec tout cet équipement,

l'utilisateur peut manuellement ajuster la fréquence du radio et l'orientation de l'antenne

tel qu'indiqué dans un tableau de prédiction.

11 est aussi possible d'utiliser un ordinateur personnel pour effectuer des poursuites

automatisées. Dans ce cas, c'est I'ordinateur qui, par le biais d'un logiciel de poursuite de

satellites et d'équipements spécialisés, utilise le tableau de prédiction pour orienter I'an-

tenne et ajuster la fréquence du radio. L'ordinateur doit donc être relié au radio ainsi qu'à

l'antenne pour les contrôler. La façon la plus courante de relier l'ordinateur au contrôleur

d'orientation est par le biais d'une interface d'extension insérée dans l'ordinateur. Pour

sa part, le radio est généralement relié à I'ordinateur via un périphérique externe branché

à un port série (RS232).

II existe actuellement plusieurs logiciels qui offrent la poursuite automatisée. LogSat

Professionnel [38] est un exemple parmi tant d'autres. Ce logiciel effectue des poursuites

à partir d'un tableau de prédictions qu'il produit lui-même en temps réel. En d'autres

termes, LogSat intègre la prédiction de passe et la poursuite dans un seul logiciel. 11 offie

une interface graphique affichant la position d'un satellite selon différentes projections de

la Terre.

Chapitre 3

Une station terrestre virtuelle

La plupart des logiciels de poursuite disponibles jusqu'à présent offrent une interface

utilisateur très conviviale à l'aide de laquelle une poursuite peut être démarrée par un

simple clic de la souris. L'utilisation de l'ordinateur et de logiciels spécialisés a grandement

simplifié la poursuite de satellites. Malgré tout ce progrès, il est encore nécessaire de

se procurer l'équipement requis et d'en effectuer l'installation. Or, cet équipement est

dispendieux et son installation représente un défi de taille même pour les mieux aguerris.

De toute évidence, le coût réduit l'accessibilité à la communication par satellites.

Nous nous sommes penchés sur ce problème d'accessibilité et nous proposons le

concept de station terrestre virtuelle. Ce nouveau type de station terrestre représente

ses équipements de façon virtuelle et les rend accessibles à travers l'hternet. Cette a p

proche permet donc à un utilisateur de se servir d'équipements achetés et installés par

d'autres gens ce qui devrait contribuer à augmenter l'accessibilité a la communication par

satellites. De plus, l'utilisation d'une station virtuelle offre un certain nombre d'avantages

supplémentaires comparativement à une station traditionnelle. Par exemple, l'utilisateur

n'est pas forcé d'attendre qu'un satellite survole sa région pour engager une poursuite.

Il lui suffit d'utiliser une station qui peut communiquer avec le satellite à poursuivre.

Ainsi, un utilisateur du Québec peut poursuivre un satellite qui survole le Japon via une

station virtuelle située à Tokyo.

l 2. Services de poursuite I

F I G . 13 - Modèle à trois couches de notre architecture logicielle

Comme un serveur WEB, la station virtuelle offre un certain nombre de services qui

sont publiquement accessibles à travers 1' Internet. Certains de ces services concernent la

manipulation de l'équipement alors que d'autres portent sur la prédiction de la passe

d'un satellite ou l'identification de la station virtuelle. Au niveau conceptuel, ces services

peuvent être regroupés en deux couches superposées qui correspondent aux couches 1

et 2 de la figure 13. Les services de la couche de niveau 1 sont ceux qui concernent la

manipulation des équipements de communication : le radio et l'antenne. Les services de

la couche 2 sont ceux qui ont trait à la poursuite de satellite : calcul de la position d'un

satellite, prédiction de passe, démarrage de poursuite, etc. Enfin, la couche 3 est celle qui

contient les applications qui utilisent des services offerts par les couches 1 et 2.

Comme les logiciels de poursuites actuellement disponibles ne peuvent tirer profit

du concept de station virtuelle, nous avons créé un nouveau logiciel qui se nomme Accès

Réseau Auz Objets en Orbites (AROO). A l'image des récents logiciels de ce type, A R 0 0

intègre les services de poursuite et de prédiction de passes de satellites. Avec AROO, la

sélection de la station virtuelle à utiliser s'effectue tout simplement à l'aide d'un panneau

de configuration. En fait, il est même possible d'effectuer plusieurs poursuites à la fois

en utilisant l'équipement de différentes stations virtuelles, ce qu'aucun autre logiciel de

poursuite n'offre en ce moment. Au niveau conceptuel, AR00 se situe dans la couche 3

(figure 13).

Le fait qu'il existe différents niveaux d'abstraction parmi les services à offrir est

l'une des raisons principales pour laquelle nous avons choisi une architecture logicielle

en couches. Une autre raison est que cette architecture o&e un certain nombre d'avan-

tages très utiles. D'abord, elle entraîne une décomposition fonctionnelle du problème ce

qui simplifie l'analyse et la conception. Ensuite, elle augmente le degré de modularité et

favorise la réutilisation tout en réduisant l'impact des modifications. Elle minimise aussi

l'interdépendance des services en imposant la création d'interfaces publiques pour tous

les services. Cet avantage s'avère très intéressant puisque que toutes les stations virtuelles

n'utilisent pas le même équipement pour offrir les mêmes services. Enfin, la forme en es-

calier de notre architecture logicielle donne aux couches de niveaux supérieurs un accès

direct à toutes les couches de niveaux inférieurs. Cette particularité fournit davantage

de flexibilité que l'architecture en couche traditionnelle selon laquelle une couche peut

seulement accéder à la couche sous-jacente.

Dans le but de simplifier le processus de développement d'une station virtuelle, nous

avons créé un cadre d'application. Un cadre d'application est une implantation complète

d'un système qui peut être adaptée à des besoins spécifiques. L'utilisation d'un cadre

d'application nous permet d'assurer l'homogénéité et la compatibilité entre différentes

implantations d'une station. Notre cadre d'application fournit une implantation de la

station virtuelle et tout le nécessaire pour y intégrer différents équipements de communi-

cation. Essentiellement, le cadre contient l'implantation des services de poursuite (couche

2) et définit comment les services relatifs à l'équipement (couche 1) doivent être implantés

afin d'être utilisés par la station virtuelle.

Le reste de cette section décrit la structure d'une station virtuelle à travers trois

étapes d'un processus de développement : l'analyse, la conception et l'implantation. La

section analyse contient une description générale des services offerts par les couches 1

et 2. La spécification des classes principales ainsi que la plate-forme physique utilisée y

sont aussi présentées. La section conception introduit la spécification détaillée des classes

principales et des classes utilitaires. Enfin, la section implantation décrit la réalisation de

notre station virtuelle.

3.1 Analyse

3.1.1 Concept ualisation

Orienter l'antenne

Configurer la radio

Frc. 14 - Cas d'utilisation reliés à la première couche

La figure 14 illustre un diagramme qui contient des cas d'utilisation implantés par les

services de la couche numéro 1 alors que la figure 15 montre ceux implantés par la couche

numéro 2. Voici une brève description de chacun des services.

- Le service d'orientation de l'antenne: Utilisé pour changer l'orientation de

l'antenne à partir de deux angles: l'azimut et l'élévation. L'azimut varie de -180

à 180 degrés et l'élévation varie entre O et 180 degrés. Ce service offre la possibilité

d'obtenir ou de modifier la position de l'antenne en fonction de ces deux angles.

- Le service d'acchs au radio émetteur/récepteur : Utilisé pour entrer en corn-

munication avec le satellite. Ce service permet la sélection des fréquences de corn-

munication et d'un type de modulation.

Calculer la position

f d'unaaMIL y7 O O '1 Poursuivre un

satellite

--------%

Station virtuelle Prédimlapositjon

d'un satellite

identifier une station virtuelle

FIG. 15 - Cas d'utilisation reliés a la de&ème couche

- Le service de calcul de position d'un satellite : Utilisé pour obtenir la position

d'un satellite à un moment précis dans le temps. La position d'un satellite est

généralement définie comme un triplet qui contient une longitude, une latitude et

une altitude. Ce triplet est communément appelé sub-satellite point (SSP) puisqu'il

indique la position du satellite par rapport à la Terre.

- Le service de poursuite: Utilisé pour démarrer et arrêter des poursuites de

satellites en fonction d'un nom de satellite, de fréquences et d'un mode de com-

munication. Tout au long d'une poursuite, ce service utilise d'autres services pour

déterminer la position d'un satellite, ajuster la fréquence du radio et l'orientation

de l'antenne.

- Le service de pddiction : Utilisé pour obtenir un tableau de prédiction de passe

pour un satellite particulier en fonction de la position d'une station terrestre et

d'un intervalle de temps. Ce service sert essentiellement à faire varier le temps et

il utilise le service de calcul de position pour déterminer à quel moment le satellite

est au-dessus de la station terrestre spécifiée.

- Le service d'identification d'une station: Utilisé pour obtenir le nom et la

position physique (longitude, latitude et altitude) de la station terrestre. Il est aussi

responsable de la description de l'environnement d'une station à travers l'angle

minimal d'élévation. Cet angle représente le seuil à partir duquel l'antenne de la

station terrestre peut entrer en communication avec un satellite. Par exemple, la

station virtuelle de l'université de Sherbrooke possède un angle minimal de trois

degrés puisqu'il y a une montagne qui obstrue le champ de vision des cinq premiers

degrés d'élévation.

Tous ces services sont offerts par la station virtuelle et disponible à travers l9Internet.

Comme il en a déjà été question, A R 0 0 est un exemple d'application qui utilise ces

services. La relation entre A R 0 0 et une station virtuelle en est une de type client-serveur

comme le montre la figure 16.

1- Radio

FIG. 16 - Modèle client-senteur de A R 0 0

3.1.2 Spécification des classes

Les services dont il vient tout juste d'être question sont essentiellement offerts par

quatre classes : AntennaRotor, Thnscetver, Satellite Racker et GmundStation. Comme

FIG. 17 - Relations entre les classes qui composent une station virtuelle

l'indique son nom, la classe AntennaRotor est celle qui représente l'antenne de cornmuni-

cation. Cette classe offre Ie service d'orientation de l'antenne. Le service d'accès au radio

émetteur/récepteur est quant à lui offert par la classe Transceiver. La classe Satellite-

Tracker offre pour sa part le service de calcul de position d'un satellite. Enfin, la classe

GroundStation représente le concept de station virtuelle et offre les services d'identifica-

tion, de prédiction et de poursuite de satellites. Comme l'illustre le diagramme de classe

de haut niveau (figure l7), les classes AntennaRotor, Transceiver et Satellite Tracker a p

partiennent à une seule station virtuelle (GroundStation) et inversement. L'accés à ces

trois classes est contrôlé par la station virtuelle à travers l'encapsulation au sens orienté

objet.

1 AntennaRotor 1 %et€levation () : int %etkirnuth () : int %et~levatbn (elevaüon : int = default) : void %etkirnuth (azirnuth : int = default) : void

FIG. 18 - Spécification de h classe AntennaRotor

La figure 18 montre la signature complète des méthodes de la classe AntennaRotor.

Les méthodes getElevation() et getAtimuth() bumissent la valeur des angles qui décrivent

l'orientation de l'antenne à un moment donné. Pour changer ces angles, il suffit d'utiliser

les méthodes setElevation() et setAzzmuth().

*setMode (mode : Wng = default) : void *get~ode () : String %etFrequency (frequency : Süing = default) : void %et~requency () : Sbing

FIG. 19 - Spéczficution de la classe Transceiver

La classe Transcezuer (figure 19) offre quant à elle les méthodes getMode() et getFre-

quency() pour déterminer le mode (modulation de fréquence, modulation de fréquence

en bande étroite) et la fréquence du radio. Les méthodes setMode() et setFrequency0

servent à changer ces paramètres.

. %etsatellite (sabILNarne : String) ~etsatei i 'b () : Sbing

. %etSSPAt (tirne : Calendar) : Posioon

1

Position

. %etlatitude () : double

. %etiongitude () : double + *get~ltitude () : double . %&longitude (longitude : double = default) : vol + %etlatitude (latitude : double = default) : void . %et~ltitude (altitude : double = default) : void

FIG. 20 - Spécification de la classe SatelliteTracker

Pour obtenir la position d'un satellite avec la classe SatellitelBocker (figure 20), i l faut

57

d'abord spécifier le nom du satellite avec la méthode setsatellite(). Ce nom de satellite

peut par la suite être obtenu avec la méthode getSatellite(). La position du satellite

spécifié est calculée à l'aide de la méthode getSSPAt() en fonction d'une datelheure.

Cette méthode retourne la position du satellite par le biais d'une classe de type Position

qui contient la latitude, la longitude et l'altitude du SSP.

GroundStation

%tart~racking (satelliteName, inputMode, inputirequency, outputMode, outputfreguency) : void %top~racking () : mid btPosition (pos : Position) : voici %etPosition () : Position *get~rediction (steitTime, endTime : Wng, minElemtion : int)

Position A F I G . 21 - Spécification de la classe GroundStation

La classe GroundStation (figure 21) est celle qui utilise les classes précédentes pour

offrir ses propres services (couche 2). La méthode setPosztion() défini la position géogra-

phique de la station terrestre. La méthode getPosition() sert à obtenir la position. Les

méthodes start Dack+ng() et stopTracking() démarre et arrête une poursuite de satellite.

Les paramètres requis pour démarrer une poursuite sont le mode et la fréquence de

communication.

Le diagramme d'état de la figure 22 décrit la logique de fonctionnement des méthodes

startTracking() et stop Tracking(). L'état de départ est l'état Attente de démarrage. L'ap

pel de la commande start7!rucking() mène à l'état Attente délai via la transition 1. L'objet

demeure dans cet état jusqu'à ce que l'élévation de l'antenne dépasse le seuil minimal de

la station terrestre. Durant ce temps, la position du satellite et l'orientation de l'antenne

sont recalculées périodiquement (transition 2). Lorsque le seuil minimal est dépassé, les

moteurs de rotation de l'antenne sont démarrés pour ajuster l'orientation de l'antenne

6.1 déid échu ] 1

FIG. 22 - Automate décrivant la logique d'une poursuite de satellite

(transition 3) et l'état Attente fin ajustement orientation est atteint. L'objet demeure

dans cet état tant que l'ajustement de l'orientation n'est pas terminé ce qui peut prendre

quelques secondes. Le processus d'ajustement des fréquences de communication est en-

suite démarré (transition 4) et I'objet arrive à l'état Attente fin ajustement fréquence

où il demeure jusqu'à la fin du processus. L'état Attente délai est atteint (transition 5)

de nouveau lorsque les fréquences sont ajustées. Tout au long de la poursuite, I'objet

emprunte séquentiellement les transitions 7, 4, 5 et 6. Une poursuite se termine lorsque

l'orientation de l'antenne redevient sous le seuil minimal ou lorsque la commande stop-

fiacking() est appelée. Lorsque c'est le cas, la transition 8 est utilisée pour retourner

dans l'état initial Attente de démarrage.

Enfin, la méthode getPredzction() est utilisée pour obtenir un tableau de chaînes de

caractères décrivant une prédiction

indiquent un intervalle de temps à

de passe. Son utilisation nécessite des paramètres qui

l'intérieur duquel il faut rechercher des passes ayant

une élévation supérieure à un certain seuil. La réponse retournée a la forme illustrée par

le tableau 3.

TAB. 3 - Format d'un tableau de prédiction

Date et heure 1 Position du satellite 1 Orientation de l'antenne 1

3.1.3 Plate-forme physique

a..

Date et heure

Le logiciel qui constitue la station virtuelle de poursuite doit pouvoir fonctionner

avec une majorité d'ordinateurs et de systèmes d'exploitation. La première version de

notre logiciel est fonctionnelle avec un ordinateur personnel compatible IBM muni de

Windows NT (Microsoft) ou de Linux. Par ailleurs, la station virtuelle offre ses services

par l'intermédiaire d'un Objet Request Broker (ORB) compatible à la norme établie par

l'organisme Object Management Group (OMG) . Pour accomplir ses tâches, la station virtuelle fait usage des équipements de poursuite

qui sont reliés a l'ordinateur de la station. La figure 12 montre comment les différents

équipements sont reliés.

Tout d'abord, le poste radio émetteur/récepteur utilisé est le modèle FT736R fabriqué

par Yaesu. Il est branché à l'ordinateur par le biais de l'interface série (RS232C). Pour

le contrôler (ouvrir/fermer, ajuster la fréquence), il faut utiliser le protocole fourni à

l'annexe B.

Ensuite, il y a le contrôleur d'orientation qui actionne les moteurs de l'antenne pour

ajuster les deux angles d'orientation (azimut et élévation). Ce contrôleur est relié aux

moteurs de l'antenne et à l'ordinateur par le biais d'une interface spécialisée. Cette inter-

face est insérée dans l'ordinateur et est fabriquée par la compagnie Kansus City h c k e r

(KCT). Ainsi, pour changer l'orientation de l'antenne, un programme doit s'adresser à

. S .

Position du satellite ... Orientation de l'antenne

l'interface KCT qui s'adresse à son tour au contrôleur d'orientation. La communication

avec l'interface KCT s'effectue par le biais d'une zone mémoire commune avec l'ordina-

teur. Le protocole de communication à utiliser est fourni à l'annexe C.

3.2 Conception

3.2.1 Spécification détaillée des classes

Dans la section concernant l'analyse, la description des classes est minimale. Le but

de la section courante est de fournir une description détaillée des classes qui font partie

des couches 1 et 2. Pour des raisons reliées à l'efficacité et la qualité de la conception,

la majorité des classes déjà présentées sont modifiées. Un certain nombre de nouvelles

classes sont créées pour les même raisons.

La suite de cette section décrit la version finale de chacune des classes qui composent

le cadre d'application. Cette présentation est effectuée par groupes de classes relatives à

une activité commune.

Classes relides au calcul de la position d'un satellite

La classe SatelliteTracker est utilisée par la station virtuelle pour calculer la position

d'un satellite en fonction du temps. Comme il existe plusieurs façon de calculer la position

d'un satellite, cette classe est définie de façon abstraite afin d'être générique. Ainsi, la

station virtuelle peut utiliser n'importe quelle classe qui hérite de SatelliteThcker à

travers le concept de polymorphisme. La méthode getSSPAt() n'est pas implantée par

la classe SatellàteTkacker. Cette méthode est celle qui effectue le calcul de la position du

satellite. Elle doit être implantée par une classe spécialisée. Les autres méthodes de la

classe SatellàteTbacker ne sont pas abstraites et servent à choisir/obtenir le satellite dont

la position sera calculée par la méthode getSSPAt().

Satellite

. %mame () : Slnng . %etsatellite (sat : Sabllibe) : -id %tNumûer () : int ~tsadsii i te () : Sabiiies +BSt€p~ch~une () : dau~e *lssp():~oaiiion %t~ean~nomaly () : double

~tSS?~t(time:Ca~endrr):Poribion w*tMeanMotW):dwble \. %Undination () : doubk + %~ccenbicity () : dauble . ~WgOfPsrigee () : double . %~RAAN () : dauble . ~tRavolubn~urnber () : int . %t~ecaylRab () : double %eWarne (name : String) : -id

Posiîhn . h ~ u r n b e r (number : int) : void - %tEpochTime (epochlime : double) : void ~ ~ n ~ n o m a l y (rnean~nomaly : double) : void

~tLatitudelnDegrw () : double . %t~eanMotion (rneanbîbn : double) : void ~ t l o n g i W e l n ~ q r e e () : double . %etlnclination (indination : double) : void

. *getlatitudeh~ad'in () : double ~tkamûic i ty (eccentricity : double) : wid ~ ( ~ o r t g ~ h ~ a d l s n () : doubla . %t~rgOfPsrigss (argOfPerigea : double) : miâ hetlatiWehDegme (bibido : double) : void . RAAN AN (riaan : dwble) : voici %ellongitudeln~qne (longaide : double) : void . %etRevduaOnNumber (mvoIutionNumbew : double) : w %etlatitudeInRadian (Iataido : doubie) : void . %t~ecayRets (deca.yR*s : double) : ma %8ILong~lnRadian (longitude : double) : void

FIG. 23 - Spécification détaillée de la classe SatelliteTracker

Le calcul de position d'un satellite est effectué à l'aide d'une extrapolation basée sur la

dernière position connue du satellite en question. Cette position peut être décrite en terme

d'éléments de Kepler. Les informations qui décrivent la dernière position d'un satellite

sont contenues dans la classe Satellite. Par conséquent, les méthodes setSatellite() et

getsatellate () de la classe Satellite Tracker() sont modifiées afin qu'elles utilisent un objet

Satellite comme illustré par la figure 23.

L'ensemble des méthodes get YYY() et set YYY() de la classe Satellite servent à ob-

tenir et spécifier les paramètres qui décrivent la dernière position et le nom du satellite.

Les paramètres de Kepler sont obtenus par la lecture d'un fichier qui est produit par la

N.4S.4. Ce fichier contient dix paramètres répartis sur deux lignes de texte d'où le nom

de Two Line Element File (TLE File). Le fichier est régulièrement mis à jour par la

NASA et il est publiquement accessible par le biais de I'Internet. Il existe a u moins deux

formats populaires du fichier TLE : NASA et AMSAT. Ces deux formats difirent dans

la disposition des paramètres mais contiennent les mêmes informations.

La classe TLEInJo Provider est responsable de l'extraction des informations conte-

nues dans un fichier TLE peu importe son format. Cette classe est abstraite et doit être

spécialisée pour utiliser un format spécifique de fichier. EIle est employée par la classe

SatelliteFactory qui sert essentiellement à faciliter I'instantiation d'objets Satellite. En

d'autres termes, il suffit de faire appel à la méthode createSatellite() de la classe Satelli-

teFactoy pour obtenir une instance de la classe Satellite contenant tous les paramètres

relatifs à sa dernière position. La figure 24 montre les relations entre les classes Satelli-

teFactoy, TLEIn foProvider et Satellite.

%tSatellits~arne~ist () : Enurneration . %t€pochTime () : double ~et~atel l i te~umber () : int 4get~ecayftab () : double % e t ~ e ~ a y ~ a t e ~ ~ t : double

- %tBStar () : double *getlndinatbn () : double

O %RAAN () : double . *get€ccenbicity () : double . *t~igofperigee (1 : double . %t~eanAnornaly () : double %tMean~otion () : double ~ t ~ e w l u t i o n ~ u r n b e r () : int ~ t ~ a t e ~ l i t e ~ a r n e () : String k ~ n p u t n l e ~ a m e (name : String) : void *set~atellite~ame (name : Sbing) : void

*set~~€lnfo~rovider (IlelnfoPmvider : TLElnfoPmvider) : *create~atellib (satelliteName : String) : Satellite

Classe reliée au radio

FIG. 25 - Spécification détaillée de la classe Transceiver

La classe Transceiver est essentiellement identique à ce qui a été décrit dans l'analyse

à l'exception d'attributs qui ont été ajoutés pour simplifier l'utilisation des méthodes

setMode() et getMode(). La méthode setMode() prend une constante en paramètre (LSB,

USB, CW, CWN, FM, FMN) qui correspond à une valeur reconnue. En ce qui concerne

la fréquence de communication, elle doit être spécifiée à l'aide d'une chaine de caractères

(String) passée en paramètre à la méthode setFrequency0. La forme de cette chaîne de

caractères est la suivante: zzzz.yyyyy en MHz. II est à noter que la classe Trunsceiver

est abstraite puisqu'il existe plusieurs types de radio différents pouvant être utilisés par

la station virtuelle à travers le polymorphisme.

Classes reliees à l'orientation de l'antenne

La classe AntennaRotor possède six méthodes additionnelles comparativement à la

version présentée dans l'analyse. Quatre de ces méthodes servent à ajuster la précision

désirée en ce qui concerne l'orientation de l'antenne. En effet, grâce à l'ouverture d'une

antenne, il n'est pas nécessaire de changer son orientation lorsque le satellite bouge de

. ~t~lewtion~recision () : int ~t~zirnuth~racisbn () : int

. %t~imctian () : Direction ~tE1emtion () : int *geWimuth () : int

. *eet€levation~mcision (degree : int) : void *set~~nuth~recision (degiea : int) : mid *set~irection (direction : Direction) : voici %et~evation (elevation : nt) : void

. %etkirnuth (azimuth : int) : void

I

I Direction

*get~timuthlnûqree () : double ~8tElevathh~egree () : double %etAzimuthln~adian () : double %etElevationlnF?adian () : double kt~zirnuthlnûegree (ammuth : double) : voici *set€levationln~egree (elavalion : double) : *set~~muthln~adian (atimuth : double) : void %et€levationln~adian (elevatkn : double) :

FIG. 26 - Spécification détaillée de la classe AntennaRotor

seulement quelques degrés. Les méthodes setElevationPrecision() et setAzimuthPreci-

szon() servent à spécifier la précision (en degrés) que nécessite l'antenne en fonction de

son ouverture. Les méthodes getEleuationPrecision( ) et getAzzmuthElevation() servent

à obtenir l'information relative à la précision de l'antenne. La classe AntennaRotor est

maintenant abstraite afin de permettre à la station virtuelle d'utiliser différents types de

contrôleurs d'orientation.

Enfin, les méthodes setDirection() et getDirection() ont aussi é té ajoutées à la classe

AntennaRotor. Elles utilisent une nouvelle classe appelée Direction qui sert à la repré-

sentation et la manipulation des deux angles décrivant l'orientation. La classe Direction

encapsule l'élévation et l'azimut. Cette nouvelle classe offre des services qui permettent

d'obtenir les angles en degrés et en radians.

Classes reliées à la station virtuelle de poursuite

W a m e () : String %etposition () : Position

. %et~inimum~levation () : int *getinfo () : string *ge t~~~ ln fo~mv ider () : MoPmvider %etsatellite~adory () : Satdl WFadory ~etSatellite~racker () : SatelliteTracker *get~ransceiver () : Transceiver %et~nbnnaRotor () : AntennaRotor %etName () : voiâ %etPosifion (pos : Position) : void %et~inirnum~levation (elevabn : int) : void %etlnfo (info : String = ddault) : voiâ %et~~Elnfo~mvider (tlelnfoPiovider : TLElnfoProvider) : vokl %etSatellitefactory (satellitaFadory : SatelliteFactory) : void ketsatellite~racker (satelliteTracker : SatelliteTracker) : voiâ

. %etTranstxiver (transceiwr : Transeber) : wid h t ~ n t e n n a ~ o t o r (antennaRotor : AntennaRotor) : void htart~racking (saMame, inMode. inFieq. outMode, outfreg : Çbing) : voiâ *stopTracking () : void %etPrediction (startTime, endTime : Stiing, minElevation : int) : Sûingu

1 TLElnfoProvider 1 [ 1 1 Satellitefracker ] 1 TransceNer ( ( AntennaRotor 1 L III-

Frc. 27 - Spécification détaillée de la classe GmundStation

La classe GroundStation représente le noyau du cadre d'application. Elle est composée

des classes AntennaRotor, Transceiver, TLEInfoProuider et SatelliteTracker qui lui sont

toutes essentielles pour offrir ses services. Pour indiquer quels objets d'implantation la

classe CmundStation doit utiliser, il faut faire appels aux méthodes set TLEInfo Pmvi-

der(), setSatellàteFacto y(), setSatellàte~cker(), setThnsceiver() et setAntennaRotor().

Pour des raisons de sécurité, ces méthodes sont seulement accessibles par l'administrateur

de la station virtuelle. Il en est de même pour les méthodes setPosataon(), setMinimu-

rnElevation(), setInfo() et setName(). Ces méthodes servent respectivement à indiquer la

position de la station de poursuite, l'élévation minimale d'une passe pour pouvoir entrer

en contact avec un satellite, certaines informations descriptives (adresse, coordonnées de

l'administrateur) et le nom de la station virtuelle.

L'ensemble des méthodes set YYY() est essentiel au fonctionnement du cadre d'appli-

cation. Elles facilitent le remplacement des objets d'implantation utilisés par la station

virtuelle de telle sorte qu'il soit possible de supporter différents équipements, algorithmes

de calcul de position de satellites et formats de fichiers TLE. En d'autres termes, un admi-

nistrateur de station de poursuite peut utiliser notre architecture pour créer une station

virtuelle. Pour ce faire, il lui suffit d'écrire des classes d'implantation spécifiques à son

équipement (en héritant des classes appropriées) et de les fournir à l'objet GmundStation

sans avoir a modifier aucune autre classe du cadre d'application.

Spécification des interfaces IDL

Comme il en a déjà été question, l'ensemble des services offerts par une station vir-

tuelle de poursuite sont disponibles à travers lTInternet. De façon plus précise, certaines

méthodes de la classe GroundStation sont accessibles a travers un ORB CORBA. La

figure 28 montre la définition de l'interface (IDL) de la station virtuelle. Cette définition

utilise (#inchde) la définition d'autres IDL non présentés ici.

L'instruction interface permet de spécifier le nom et la signature des méthodes qui

sont offerts par un objet CORBA. Dans le cas actuel, l'objet est appelé GroundStation.

L'utilisation de l'instruction module permet de regrouper les interfaces. Ainsi, l'objet

GroundStatzon fait partie du sous-groupe CU. usherb.dmi.satellite%cIn'ng. Lorsque I'IDL

FIG. 28 - Fichier de défiition de l'interface (IDL)

#include "Position.id1" #inchde loSatelliteFactory. idl" #include SatelliteTracker . idl" Winclude "Transceiver.idlM #include VntennaRotor.idlu Winclude Wxceptions.idlu

module ca < module usherb C module dmi { module satelliteTracking < interface GroundStation <

void startTracking (in string satellitelame) taises (ca::usherb::dmi:exceptions::IOE.ception); void

string string

Position long

Transceiver AntennaRotor

SatelliteTracker String[]

stopTracking0 ; getName0 ; getInfo0 ; getPosition0 ; getMinimumElevation() ; getTransceiver 0 ; getAntennaRotor O ; getSatelliteTracker 0 ; getPrediction(in string startlime ,

in string endTime. long minElevat ion) ;

est transformé en Java par le compilateur d'interfaces, les mots clés interface et module

deviennent respect ivement package et clus.

3.3 Implantation

La section implantation illustre l'utilisation du cadre d'application pour représenter

une station de poursuite conventionnelle comme une station virtuelle. Les détails relatifs

à la plate-forme (ou environnement d'exécution) sont aussi présentés dans cette section.

3.3.1 Pilotes de périphériques

La première étape du processus de représentation consiste à développer des classes

d'implantations spécifiques (communément appelées pilotes) à I'équipement utilisé. En ef-

fet, selon le cadre d'application, l'objet GroundStation utilise des pilotes pour contrôler les

périphériques de communications. Les pilotes utilisés par la station virtuelle sont abstraits

(au sens orienté objet) et doivent par conséquent être spécialisés pour les périphériques

utilisés.

Comme il en a déjà été question, le radio émetteur-récepteur utilisé dans le cadre

de notre projet est le modèle FT-736R fabriqué par Yaesu. II est branché à l'ordinateur

par le biais de l'interface série et pour le contrôler, il faut utiliser le protocole fourni en

Annexe B. La figure 29 montre la classe YaesuFT736R qui constitue l'implantation du

pilote abstrait Z+ansceiuer.

L'implantation de ce pilote nécessite l'accès a l'interface série et, pour ce faire nous uti-

lisons l'extension JavaComm [41]. JavaComm est disponible pour plusieurs plate-formes

dont les deux que nous utilisons : PC/Linux et PCIWinNT.

Pour contrôler l'orientation de l'antenne, nous utilisons une interface d'extension

insérée dans l'ordinateur de la station virtuelle. Cette interface est fabriquée par la com-

pagnie Kansas City Tracker (KCT) et elle est reliée aux moteurs d'orientation. Pour

F I G . 29 - SpéciJicotion de la classe d'implantation YaesuFT736R

orienter l'antenne, il faut envoyer des commandes à cette interface suivant le proto-

cole présenté à l'Annexe C. L'envoi des commandes s'effectue en écrivant à une adresse

mémoire spécifique. Une adresse différente est utilisée pour la lecture d'informations en

provenance de l'interface.

L'implantation de ce pilote nécessite l'utilisation de l'extension Java Native Interface

(JNI) [45] puisqu'il faut obtenir un accès direct à la mémoire ce que ne permet pas

Java. JNI est disponible pour les mêmes plateformes que Java et offre la possibilité à

un programme Java d'utiliser des fonctions externes à Java. Ces fonctions dites natives

doivent être entreposées dans des librairies de type dynamique (lzb*.so sous Unix et *.dl1

sous Windows) .

Ainsi, pour permettre à notre pilote d'entrer en communication avec l'interface KCT

nous avons développé une classe Java appelée MernoyCell. Cette classe utilise deux

fonctions natives à travers JNI qui lui permettent d'écrire ou de lire à des adresses

mémoire spécifiques. La figure 30 montre l'interface publique de la classe MemoryCell.

Le constructeur de cette classe prend un paramètre qui indique l'adresse mémoire où il

faut écrireIlire un octet. Notre pilote YaesuFT736R utilise cette classe utilitaire pour

entrer en communication avec l'interface KCT.

L'implantation Java de la classe MemoyCell reste la même peu importe la plate-

forme utilisée. Seule l'implantation de la librairie native utilisée par MemoryCell est

différente d'une plate-forme à une autre. Dans notre cas, nous avons une librairie native

~ m o r y C e l l (address : in . %ad () : int . *mile (value : int) : void

FIG. 30 - Spécification de la classe MemoryCell

pour Windows NT4 (memorycell.dll) et une autre pour Linux (libmemoryCell.so).

Pour la version Linux de notre logiciel, nous avons tout simplement implanté la li-

brairie native (en langage C) avec les fonctions systèmes ioperm(), in60 et outb(). La

fonction iopenn() sert à réserver l'exclusivité de l'accès mémoire à l'adresse spécifiée en

paramètre. Les fonction in60 et out60 servent respectivement à lire et écrire un octet

à l'adresse spécifiée en paramètre. Puisque Linux est un système d'exploitation qui uti-

lise le concept de mémoire protégée, seul l'utilisateur maître (root) peut démarrer un

programme qui se sert de cette librairie native.

L'implantation de cette même librairie pour WinNT4 est un peu plus laborieuse. En

effet, la librairie native doit être un véritable pilote de WinNT4 pour pouvoir utiliser

l'équivalent des instructions znb() et outb(). Pour ce faire, nous avons développé (en

langage C) un pilote en utilisant le Driver Development Kit ( D D K ) [43, 751 de Microsoft.

3.3.2 Calcul de la position d'un satellite

La deuxième étape du processus de représentation consiste à développer un en-

semble de classes relatif au calcul de position d'un satellite. Comme pour les pilotes

de périphériques, la station virtuelle utilise des classes abstraites à cet effet. Ainsi, il

faut fournir des implantations des classes SatellzteTracker et TLEInfoProuider pour que

l'objet GroundStation puisse offrir ses services.

Notre implantation de la classe Satellite Tmcker se nomme Two BodySatellite nacker

comme l'illustre la figure 31. Cette implantation est basée sur un modèle de prédiction

FIG. 31 - Spécification de la classe d'implantation TwoBodySatelliteltncker

particulier que l'on nomme le modèle à deux corps [13]. Ce modèle offre une précision

acceptable pour engager des poursuites de LE0 seulement. D'autres modèles existent

pour différents types de satellite et pour différents niveaux de précision [23]. Cette classe

est implantée en Java.

F IG . 32 - Spécification de la classe d 'implantation NASA In fo Provider

L'autre classe qu'il faut implanter est celle qui extrait du fichier TLE les informations

représentant la position de référence d'un satellite. Comme il en a déjà été question, ce

fichier est disponible sous au moins deux formats différents : NASA et AMSAT. Dans le

cadre de notre projet, nous utilisons le format NASA e t la classe d'implantation corres-

pondante se nomme NASAInfoProvzder. Cette classe est implantée en Java et hérite de

la classe abstraite TLEInjoProvider comme le montre la figure 32.

3.3.3 Fichier de configuration

F I G . 33 - Fichier de configuration

groundStation.name = Sherbrooke1 goundStation.position.1atitude = 45.24 grou.ndStation.position.longitude = -71.46 goundStation.position.altitude = 0.225 groundstat ion. minimumElevat ion = 3 goundstation. info = \ Universite de Sherbrooke, \n \

2500 Boulevard Universite, \n \ Sherbrooke, Quebec (Canada) . \n \ Contact: michel.barbeauQdmi.usherb.ca

antemaRotor . className = ca.usherb.dmi.~atelliteTracking.ante~aRotor.KansasCityTracker antemaRotor.instantiation.parameters = 03e0

transceiver.className = ca.usherb.dni.satelliteTracking.transceiver.YaesuFn36R transceiver.instantiation.parameters = COMZ

Outre le polymorphisme, la station virtuelle utilise aussi le concept d'instantiation

dynamique offert par Java. Grâce à ce concept, l'objet GmundStation peut instancier

différentes classes d'implantation sans avoir à être modifié. Par exemple, pour changer

la classe d'implantation relative au calcul de position d'un satellite, il suffit de modifier

l'attribut satelliteTbacker.classname du fichier de configuration illustré à la figure 33.

L'objet GroundStation est implanté de façon à lire ce fichier pour déterminer quelles

classes d'implantation il faut instancier. Évidemment, ces classes doivent hériter des

classes abstraites appropriées pour être acceptées par la station virtuelle.

L'instantiation dynamique de Java représente un net avantage comparativement à

l'utilisation de langages tel que C et C++ avec lesquels il faut modifier et recompiler un

programme pour utiliser de nouvelles classes. Dans le cadre de notre projet, la station

virtuelle utilise un fichier de configuration pour connaître les classes à instancier.

La troisième étape du processus de représentation consiste donc à créer un tel fi-

chier. Chacun des paramètres contenus dans le fichier de configuration est spécifié sous

la forme : nomDuPammètre=valeur La figure 33 présente le fichier de configuration que

nous utilisons dans le cadre de notre projet.

Tous les paramètres illustrés concernant la station virtuelle sont essentiels au bon

fonctionnement de l'objet GroundStation Ces paramètres indiquent le nom de la station

virtuelle (Sherbrookel), sa position (45.24, - 71.46, 0.225)' l'élévation minimale (trois

degrés) et certaines informations supplémentaires (adresse et personne responsable).

En ce qui concerne les paramètres relatifs au contrôleur d'orientation de l'antenne,

seul le nom de la classe d'implantation est nécessaire (antennaRotor.clussName). Le

second paramètre (antennaRotor.instantiation.pammeters) est utilisé pour configurer la

classe d'implantation. Ce paramètre indique l'adresse mémoire partagée (Ox03eO) entre

l'interface KCT et l'ordinateur utilisé. La classe KansasCityDacker utilise (à travers

Memo yCell) cette adresse pour entrer en communication avec l'interface KCT.

Le paramètre tmncezver.className sert à sélectionner la classe d'implantation pour

le radio émetteur-récepteur. Celui appelé tmnceiver.instantiation.parameters indique a

quel port de communication série (COM2) la radio est branchée. Ce paramètre sert à

initialiser le pilote YaesuFT736R.

Les deux paramètres suivants du fichier de configuration sont utilisés pour indiquer le

nom du fichier TLE et la classe d'implantation utilisée pour la manipulation de ce fichier.

Enfin, le dernier paramètre sert à sélectionner la classe d'implantation pour le calcul de

la position d'un satellite.

3.4 Évaluation de la station virtuelle

Cette section contient une discussion concernant la station virtuelle et le logiciel de

poursuite AR00 que nous avons créés dans ce projet. Cette discussion présente une brève

évaluation de chacun de ces deux logiciels ainsi qu'une liste d'améliorations potentielles.

En ce qui concerne le cadre d'application, nous avons constaté qu'il est simple à uti-

liser. Pour intégrer un nouveau type d'équipement, il suffit de développer un pilote (ou

classe d'implantation) et de modifier un fichier de configuration pour le faire connaître

à la station virtuelle. La création d'un pilote s'effixtue par le développement d'une nou-

velle classe qui doit hériter d'une classe abstraite spécifique afin de respecter une interface

publique. La création de notre station virtuelle de poursuite n'a entraîné aucune modifi-

cation du cadre d'application ce qui témoigne de la flexibilité de l'architecture logicielle.

L'utilisation du langage de programmation Java et du concept d'instantiation dynamique

ont eu une grande importance à cet égard.

3.4.1 Améliorations

1. L'utilisation d'une station virtuelle de poursuite à travers notre logiciel AR00 a

démontré que ce concept procure de nombreux avantages au niveau de l'acces-

sibilité. Une station virtuelle est accessible à tous les utilisateurs de l'lnternet . Néanmoins, une telle accessibilité entraîne des problèmes en ce qui concerne la ges-

tion des accès, de la sécurité et de la concurrence. Ces trois sujets n'ont pas été

traités dans le cadre de notre projet mais des solutions à ces problèmes sont ab-

solument essentielles à une utilisation généralisée du concept de station virtuelle.

A cet égard, I'OMG propose quelques services normalisés qu'il serait intéressant

d'évaluer (571.

2. Afin de fournir la transparence de localisation les stations virtuelles pourraient être

sélectionnées à partir d'un menu. Ceci pourrait être rendu possible en reliant tous

les ORB des stations virtuelles pour créer une confédération CORBA [67]. Une

fois les ORB reliés, AR00 pourrait utiliser le service de requêtes pour découvrir

l'existence des stations terrestres disponibles.

3. La liste des stations virtuelles pourrait aussi être utilisée pour implanter un service

qui déterminerait automatiquement la prochaine station virtuelle à utiliser lors-

qu'une poursuite se termine. Le logiciel AR00 utiliserait ce nouveau service pour

eff'tuer automatiquement la sélect ion des stations virtuelles à utiliser durant une

poursuite. On peut imaginer qu'avec un nombre suffisant de stations virtuelles, la

poursuite d'un LE0 pourrait s'effectuer de façon quasi-continue.

4. L'acheminent des informations (voix ou données) en provenance d'un satellite pour-

rait être rendu possible à travers la station virtuelle. Pour ce faire, il serait inté-

ressant d'utiliser un modem à travers un pilote contrôlé par la station virtuelle. La

diffusion du son serait effectuée par la station et AR00 offrirait tout le nécessaire

pour la réception.

5. L'ordinateur utilisé par la station virtuelle pourrait héberger un serveur d'agents

mobiles. Cette approche offrirait aux agents un accès local aux services offerts par

la station virtuelle. Des poursuites étendues pourraient être effectuées par les agents

en se déplaçant de station en station. L'utilisateur d'un tel système ne serait pas

tenu de garder son ordinateur en marche tout au long d'une poursuite étendue. De

plus, en se basant sur certains travaux de recherche (61, il serait possible de faire

collaborer les agents mobiles pour échanger de l'information telle que des données

transmises par des satellites.

6. La classe Satellite pourrait être modifiée de telle sorte qu'elle puisse contenir la

forme vectorielle de description de la dernière position d'un satellite. Cette modifi-

cation permettrait le développement de différents algorithmes de calcul de position

d'un satellite.

3.5 A R 0 0 : un nouveau type de logiciel de poursuite

Cette section présente le logiciel que nous avons développé afin de montrer l'utilité

du concept de station virtuelle de poursuite. Le nom de ce logiciel est un acronyme qui

se définit comme suit : Accès Planétaire aux Objets en Orbite (AROO). C'est un logiciel

qui intègre la prédiction de passe et la poursuite de satellite.

FIG. 34 - Projection équidistante de la Terre

La figure 34 présente l'interface utilisateur de AR00 avec une fenêtre illustrant une

poursuite du satellite télescope Hubble (Hubble Space Telescope - HST) . La poursuite

de satellite s'effectue toujours par le biais d'une fenêtre de poursuite qui affiche la po-

sition des satellites selon différentes projections de la Terre. Le menu Poursuite offre

actuellement (figure 35) deux choix de projection : équidistante et Winkel-Thpel. II suf-

fit de sélectionner l'un de ces deux choix pour ouvrir une fenêtre de poursuite. La fi-

gure 34 illustre la projection équidistante alors que la figure 36 illustre la projection

Winkel-Tripel. A R 0 0 n'impose aucune limite sur la quantité de fenêtres de poursuite

qui peuvent être ouvertes en même temps. C'est la performance de l'ordinateur utilisé

qui détermine cette limite.

Frc. 35 - Menu Poursuite de l'application AR00

Pour obtenir la position d'un satellite, il faut d'abord l'ajouter à une fenêtre de

poursuite en inscrivant son nom dans le champ à cet effet (figure 37). Chacune des fenêtres

de poursuite peut contenir plusieurs satellites puisque ici aussi la limite est imposée par

l'ordinateur utilisé. Une fenêtre de poursuite de satellites peut aussi contenir une infinité

de stations terrestres. La figure 37 en montre une qui contient la station terrestre de

Sherbrooke.

Un satellite ajouté affiche son cercle d'acquisition du signal (figure 38), son tracé

orbital, son nom et sa position. Comme il en a déjà été question, le cercle d'acquisition

représente la zone dans laquelle une station terrestre doit se trouver pour entrer en

communication avec le satellite. Le tracé orbital représente quant à lui une partie du

chemin parcouru par le satellite. Enfin, la position du satellite est spécifiée en degrés Est

de longitude et en degrés Nord de latitude. L'affichage des informations relatives a un

satellite peut être configuré via le menu contextuel (figure 39) du satellite.

Pour démarrer une simulation, il faut utiliser les boutons de contrôle de l'écoulement

du temps. La figure 40 indique la position des boutons démarrage, arrêt et pause ainsi

FIG. 36 - Projection WinkebTripel de la Terre

que celle de l'affichage du temps. AR00 offre la possibilité de simuler le déplacement

d'un satellite dans le temps passé, présent et fiitur. Pour ce faire, il faut utiliser la jauge

qui détermine dans quelle direction et à quelle vitesse le temps doit s'écouler. Lorsque

I'ascenseur est au centre de la jauge, le temps s'écoule à la vitesse réelle. Si l'ascenseur

se trouve à droite du centre de la jauge, le temps s'écoule vers le futur. Plus l'ascenseur

s'approche de la droite plus le temps s'écoule rapidement. L'effet contraire se produit

lorsque l'ascenseur est dans la partie gauche de la jauge.

Pour démarrer une poursuite de satellite, il faut d'abord sélectionner le satellite a

FIG . 37 - Représentation graphique d 'une station terrestre

poursuivre et la station terrestre à utiliser. Comme le démontre la figure 41, la barre de

statut de la fenêtre de poursuite affiche les informations relatives au satellite en poursuite

et à l'orientation de l'antenne.

Après avoir sélectionné un satellite et une station terrestre, l'utilisateur doit spécifier

l'adresse TCP/IP du ORB C O M A de la station sélectionnée. Pour ce faire, il faut

appuyer sur le bouton Connexion ORB situé dans la partie supérieure gauche de la

fenêtre de poursuite tel qu'indiqué par la figure 42. Après avoir appuyé sur ce bouton,

une fenêtre de configuration apparaît (figure 43) pour permettre à l'utilisateur d'entrer

l'adresse d'un ORB.

Une poursuite est démarrée chaque fois que la station terrestre sélectionnée se retrouve

à l'intérieur du cercle d'acquisition du satellite sélectionné et se termine dans le cas

contraire. Il est important de noter qu'aucune poursuite de satellite n'est démarrée si le

temps n'est pas le temps réel. Dans le même ordre d'idées, si une poursuite est en cours

et que l'utilisateur avance ou recule le temps, la poursuite est immédiatement annulée.

Le démarrage d'une poursuite de satellite s'effectue par la transmission d'une requête à

la station virtuelle et se termine de la même façon.

FIG. 38 - Représentation graphique des informations relatives à une poursuite

Enfin, soulignons que A R 0 0 possède son propre service de prédiction et de calcul de

position. En conséquence, les informations affichées à l'écran proviennent de ses propres

prédictions et non pas de la station virtuelle. Les services utilisés par A R 0 0 proviennent

d'instances locales des mêmes classes qu'utilise la station virtuelle. Il est donc possible

d'utiliser A R 0 0 sans accès réseau pour effectuer des prédictions par exemple.

3.6 Évaluation de A R 0 0

Le logiciel AR00 a été créé dans le but d'évaluer le concept de station virtuelle.

La création de cette application a démontré à quel point il était simple d'utiliser les

services d'une station virtuelle à travers un ORB. L'utilisation de AR00 nous a conduit

à découvrir qu'il est possible d'étendre la durée d'accessibilité d'une poursuite. Nous avons

constaté que l'interface graphique de A R 0 0 est simple et intuitive. Plusieurs personnes

non impliquées dans notre projet en ont fait usage et ont réussi à engager des poursuites

de satellites avec un minimum de formation.

FIG. 39 - Menu contextuel relz'é à un satellite

3.6.1 Améliorations

1. Pour ajouter un satellite à une fenêtre de poursuite, il faut actuellement inscrire

dans le champ approprié le nom de code qui le désigne. Ce nom de code est souvent

différent du nom réel du satellite. Par exemple, le satellite Hubble Space Telescope

porte le nom de code HST alors que le nom de code UO-11 représente le satellite

UoSA T- OSCARI l. Un menu contenant tous les noms de satellites pourrait être

ajouté à A R 0 0 pour remplacer l'utilisation actuelle du champ texte.

2. Le menu contextuel associé à chacun des satellites pourrait offrir davantage de

possibilités. Il pourrait être intéressant de choisir les couleurs d'un satellite et de

son tracé orbital pour distinguer les tracés des satellites les uns des autres. Il serait

aussi possible de spécifier l'icône qui serait utilisé pour sa représentation graphique.

Les fréquences de communication à utiliser et les paramètres décrivant sa dernière

position pourraient aussi être spécifiés via ce menu.

3. L'ajout dynamique de stations virtuelles de poursuite à une fenêtre de poursuite

FIG. 40 - Boutons reliés à la manipulation du temps

FIG. 41 - Barre de statut reliée à une jenêtre de poursuzte

est implanté mais non disponible à travers l'interface graphique de AROO. Il serait

donc facile d'ajouter une fenêtre de dialogue permettant l'ajout de stations.

4. Le menu contextuel associé à chacune des stations virtuelles pourrait permettre la

sélection des couleurs et d'une icône. La couleur pourrait par exemple être utilisée

pour refléter l'état de la station. Il serait aussi possible d'obtenir les informations

relatives à une station (nom, administrateurs, positions) via ce même menu.

5. La fréquence à laquelle la position des satellites est recalculée par AR00 dépend

d'un intervalle du temps qui ne peut être modifié pour le moment. Il serait inté-

ressant de permettre l'ajustement de cette valeur en fonction de la performance de

l'ordinateur utilisé.

FIG. 42 - Emplacement du bouton concernant la connexion ci un ORB

6. 11 serait intéressant de pouvoir sauvegarder une fenêtre de poursuite comme on sau-

vegarde un fichier dans un éditeur de textes. La sélection des satellites, des stations

terrestres et de leur configuration respective serait entreposée dans un fichier qu'il

serait possible d'ouvrir ultérieurement. L'utilisateur pourrait ainsi catégoriser les

types de poursuite qu'il effectue (satellites radioamateur, satellites météos)

7. Plutôt que d'utiliser une projection de la Terre pour effectuer une poursuite, une

fenêtre de poursuite textuelle pourrait être ajoutée. Cette fenêtre afficherait des pa-

ramètres de poursuites supplémentaires et pourrait être utilisée pour complémenter

la poursuite graphique.

8. Enfin, il faudrait pourvoir sélectionner la source du fichier TLE. La version ac-

tuelle exige que ce fichier se nomme TLE.new et qu'il soit dans le répertoire où

l'application AR00 est démarrée.

FIG. 43 - Fenêtre pour lu sélection d'un ORB

Conclusion

Le nombre de satellite de type LE0 ne cesse de grandir à chaque année. Ces satellites

de plus en plus performants et spécialisés, sont entre autres utilisés par les scientifiques

pour l'étude de notre planète. Les radioamateurs utilisent aussi ces satellites pour ef-

fectuer toute sorte d'expériences. Par exemple, certains de leurs satellites sont munis

de logiciels capables de recevoir et de retransmettre des messages électroniques. Ces sa-

tellites sont en quelque sorte des boîtes postales qui se déplacent à travers le monde.

L'utilisation des services offerts par les LE0 s'effectue à l'aide de stations de poursuite

qui sont dispendieuses et difficiles à manipuler, ce qui limite leur utilisation.

La contribution apportée par la recherche présentée dans ce mémoire est un prototype

de station virtuelle de poursuite. Ce nouveau type de station offre ses services à travers

1'Internet ce qui la rend facilement accessible. Les services offerts sont simples à utiliser

puisque les détails relatifs à chacun des périphériques sont implantés à même des pilotes

invisibles à l'utilisateur. L'application AR00 que nous avons développée utilise notre

station virtuelle à travers un ORB et démontre bien les avantages énoncés.

Grâce à l'expérience acquise au cours de projets précédents ([52], [14], (531)' le déve-

loppement de AR00 s'est effectué rapidement et I'utilisation des services de notre station

terrestre se limite à quelques appels de méthodes. En fait, la presque totalité du temps de

développement a été investie au niveau de l'interface graphique. L'utilisation de AR00

nous a mené à découvrir un autre avantage de I'utilisation d'une station terrestre : la pos-

sibilité d'effectuer une pour~uite étendue de LEO. En effet, il est possible de se brancher

à plusieurs stations virtuelles à tour de rôle pour effectuer la poursuite d'un satellite.

En d'autres termes, il est possible d'établir plusieurs communications durant une seule

révolution d'un LEO, ce qui est actuellement impossible pour un radioamateur.

Enfin, nous croyons que le concept de station virtuelle de poursuite peut fortement

contribuer à promouvoir l'utilisation de satellites LEO. La popularité récente des LE0

pourrait être accrue en augmentant leur flexibilité et en améliorant leur facilité d'utilisa-

tion. Nos travaux représentent un premier pas dans cette direction. Des prolongements de

nos travaux pourraient être effectués en ce qui concerne le concept de poursuite étendue

automatique et la diffusion du signal radio par la station virtuelle.

Annexe A

Acronymes

-- -. . .

1 AMSAT 1 AMateur SATellite --

1 A R 0 0 1 Accès Planétaire aux Objets en Orbites

1 B0,4 1 Basic Object Adapter

1 COF 1 Cornmon Object Facilites

1 COS 1 Cornrnon Object Services

1 CORBA 1 Cornrnon Object Request Broker Architecture

1 DCOM 1 Distributed Cornponent Object Mode1

1 DI1 1 Dynarnic Interface Invocation - - - - -- - - -

1 DDK 1 Driver Development Kit

1 DSI 1 Dynamic Skeleton Invocation

1 G E 0 1 Geoûynchronous Earth Orbit

1 GIOP 1 General Inter-ORB Protocol

1 HAL 1 Hardware Abstraction Layer

1 HST ( Huble Space Telescope

1 IDL 1 Interface Definition Language

1 IIOP 1 Internet Inter-ORB Protocol

1 ILU 1 Inter-Language Unification I 1 IP 1 Intemet Protocol 1

/ JAR 1 Java ARchive 1

ISL

JNI

1 KCT 1 Kansas City Tracker 1

Interface Specification Language

Java Native Interface

1 LE0 1 Low Earth Orbit 1

1 NASA 1 National Aeronautics and Space Agency 1 MASIF Mobile Agent System Interoperability Facility

1 OMG 1 Object Management Group 1 OMA

1 ORB 1 Object Request Broker

Object Management Architecture

1 RMI 1 Rernote Method Invocation 1

POA

REV

-

1 RPC 1 Rernote Procedure Cal1

Portable Object Adapter 4

Remote EValutation

1 SDK 1 Software Developrnent Kit 1 1 SSP ( Sub Satellite Point I 1 TCP 1 Transmission Control Protocol 1 1 TLE 1 Two Line Element

Annexe B

Protocole de communication du

radio Yaesu FT736R

TAB. 4 - Résumé du protocole

O2h=CW, 82h=CWN1 08h=FM, 88h=Receive xx : n'importe quelle valeur

La communication avec le radio émeteur-récepteur s'effectue par le biais de l'interface

série (RS-232C). Le format des messages interprétés par le radio est défini par le protocole

Fonction Démarrer Fermer Initialiser fréquence Initialiser mode

illustré par le tableau 4. En résumé, les messages sont composés de cinq octets qui selon

p4 xx xx

leur valeur engendrent différents comportements. Les quatre premiers contiennent les

p l xx xx

pl p l

paramètres relatifs à la fonction spécifiée par le cinquième octet (l'octet instruction).

Inst. OOh 80h

Lors de la transmission d'un message, chacun des cinq octets doit être transmis et ce

Description xx: n'importe quelle valeur xx: n'importequelle valeur

p2 xx xx

p2 xx

dans l'ordre suivant: pl , p2, p3, p4 et inst.

pLp4: fréquence en format BCD p l : OOh=LSB, Olh=USB,

p3 xx xx

p3 xx

p4 xx

Olh 07h

Annexe C

Protocole de communication de

l'interface KCT

L'interface KCT est utilisée pour modifier et obtenir l'orientation de l'antenne. Elle

est reliée à un contrôleur d'orientation qui représente les deux angles de l'orientation

d'une antenne (l'azimut et l'élévation) en niveaux de voltage qui varient de O à 5v.

L'interface KCT convertit ces niveaux de voltage en un nombre entier entre O et 255.

Deux nombres entiers sont donc nécessaires pour décrire les deux angles. Le tableau 5

décrit la correspondance entre les niveaux de voltage, les angles en degrés et les nombres

entiers.

TAB. 5 - Correspondance des dtffémntes unités de mesure

Pour entrer en communication avec l'interface KCTy il faut utiliser deux ports spéc

fiques localisés dans l'espace mémoire de l'ordinateur. Ces deux ports sont situés à des

91

Entier O

Voltage O

C

Elévation O

r

Azimut -180

adresses consécutives et ont une taille d'un octet chacun. Les ports sont communément

appelés port0 et portl. Dans le cadre de notre projet, le port0 occupe l'adresse Ox03e0 et

le portl l'adresse OxO3el. Le port0 est utilisé en lecture et en écriture tandis que le portl

est utilisé en lecture seulement. Le tableau 6 résume la fonction de chacun des ports.

TAB. 6 - Fonctions de chacun des ports

1 Port 1 Mode 1 Rôle 1 1 1 I I

1 O 1 Lecture 1 indique l'état de la conversion de voltage à entier 1 l O

-

criture 1 modification de l'angle d'orientation soécifié 1 1 1 U .

1 1 Lecture 1 fournit un entier [O - 2551 qui décrit l'angle spécifié (

PortO en Rcriture PortO en lecture

3 Gauche 4 Démarrage 5 Bascule 6 Sélection 7 Non ublise

FIG. 44 - Boutons reliés à la manipulation du temps

La figure 44 indique le nom de chacun des bits du Port O en fonction du mode

d'utilisation. Ce qui suit décrit les algorithmes à suivre pour modifier et obtenir l'azimut

et l'élévation.

C.l Obtenir l'azimut

1. Écrire la valeur 0x40 sur le port0 (indique que l'azimut est requis).

2. Attendre quelques millièmes de seconde (lecture du port0 par l'interface KCT).

3. Écrire la valeur 0x20 sur le port0 (initialise le bit Bascule gui assure l'accès exclusif

à l'interface).

4. Attendre quelques millièmes de seconde (lecture du port0 par l'interface KCT).

5. Écrire la valeur 0x10 sur le port0 (démarre la conversion du voltage vers un nombre

entier entre O et 255).

6. Attendre quelques millièmes de seconde (lecture du port0 par l'interface KCT).

7. Tant que le bit Statut du port O n'est pas égal à 1, la conversion est en cours et il

faut attendre.

8. Lorsque la conversion est terminée, la réponse est entreposée dans le portl.

C .2 Obtenir l'élévation

1. Écrire la valeur 0x00 sur le port0 (indique l'élévation est requise).

2. Suivre les étapes 2 à 8 de Obtenir l'azimut.

C.3 Modifier l'azimut

Pour modifier l'azimut, il faut soit démarrer le moteur qui oriente l'antenne vers la

droite ou celui qui l'oriente vers la gauche. Ensuite, il faut constamment vérifier l'azimut

pour déterminer quand éteindre le moteur lorsque l'angle désiré est atteint.

1. Écrire la valeur 0x04 (bit Droite) ou la valeur 0x08 (bit Gauche) sur le port0 pour

démarrer la rotation de l'antenne.

2. Obtenir l'azimut tant que l'angle désiré n'est pas atteint.

3. Arrêter le moteur activé en réinitialisant le bit modifié en 1 à la valeur O.

C .4 Modifier l'élévation

La modification de l'élévation fonctionne de façon similaire à la modification de l'azi-

mut.

1. Écrire la valeur 0x01 (bit Haut) ou la valeur 0x02 (bit Bas) sur le port0 pour

démarrer la rotation de l'antenne.

2. Obtenir l'élévation tant que l'angle désiré n'est pas atteint.

3. Arrêter le moteur activé en réinitialisant le bit modifié en 1 à la valeur O .

Annexe D

Liste des serveurs d'agents mobiles

Aglets 1 http ://www.trl.ibm.co.jp/aglets/index.html - - -

1 AGNI 1 ht tp ://www.antd.nist .gov/antd-staff/mranga/mranga. html

1 Ajanta 1 http ://www.cs.umn.edu/Ajanta/

1 AMETAS 1 http://www.vsb.cs.uni-frankhrt.de/ametas/inde~~en~html 1 Ara ( http : / /www.uni -k l .de /AG-Nehrner /Projekte /Ahrnl

1 Concordia 1 http ://www.rneitca.com/HSL/Projects/Concordia/

D'Agents

Discovery

http ://www.cs.dartmouth.edu/ agent/

ht tp ://discovery.mctr.umbc.edu/

Dreme

Emerald

Extendend Facile

Facile

Grasshopper 1 http ://www.ikv.de/products/grasshopper/index.html

. - -

http ://www.cs.nyu.edu/phd~students/fuchs/index. html

ht tp : //www .diku .dk/research-groups/dist lab/Research/

Internal/DistOOS/

Emerald/index. html

http ://www.cs.virginia.edu/ knabe/perforrnance97.ps.g~

ht tp ://www .ecrc.de/research/projects/facile/facile~ome. html

ffMAIN - -

http ://www. tm.informatik.uni-frankfurt.de/agents/ffmain.html

1 Gypsy 1 http ://www.infosys. tuwien.ac.at/Staff/lux/Gyp/

Jumping Beans http ://www.jumpingbeans.com/

Kali Scheme http ://www.neci.nj.nec.com/PLS/kali.html

1 Knowbot 1 http ://www.cnri.reston.va.us/home/koe/

1 MAP 1 http ://sunl95.iit.unict.it/MAP/map.html

1 Messenger 1 http ://cuiwww .unige.ch/tios/rnsgr/

1 MESSENGERS 1 http ://www.ics.uci.edu/ bic/rnessengers/

1 ML3000 1 http ://cuiwww.unige.ch/ ecoopws/ws96/7.ps.gz

Mole http ://www.informatik.uni-stuttgart.de/ipvr/vs/projekte/

mole.htm1

MSA http ://www.ecrc.de/research/dc/msa/

Obliq http ://gatekeeper.dec.com/pub/DEC/SRC/research-reports/

1 Odyssey 1 ht tp ://www.genmagic.com/technology/ody~~ey. hm1

Omniware http ://www.cs.cmu.edu/afs/cs.cmu.edu/user/ali/www/

Perpetum http ://www.sce.carleton.ca/netmanage/rnctoolkit/

1 Plangent 1 http://www2.toshiba.co.jp/plangent/index.htm --

REV ftp ://cst r-ftp.lcs.mit .edu/pub/cstr-ftp/publicat ions/

LCS-TR/O300-0399/LCS-TR-354

Rover http ://www. pdos.lcs.mit .edu/papers/rover-sosp95.ps.g~

Safe-Tc1 http ://www.sun.com/96090l/feature3/safe-tcl-html

Sumatra http ://www.cs.umd.edu/ acha/papers/lncs974. html

TACOMA http ://www. tacoma.cs.uit.no/

( TIAS 1 http : / /www.cs .dartmouth.edu/reports /abstr~~258/

Telescript ht tp ://www .genmagic.com/

'Iùbe

Tycoon

Voyager

WAVE

http ://www.cl.cam.ac.uk/users/dah28/tube/

http ://www.sts.tu-harburg.de/projects/Tycoon2/ent~.html

http ://www.objectspace.com/voyager/prodVoyager.asp

http ://www.ira.uka.de/I32/wave/wave.html

[l] A. Acharya, M. Ranganathan, and J. Saltz. Mobile Object Systems : Towankr the

Progrummable Internet, pages 1 11-130. Springer-Verlag, 1997.

[2] A. Adl-Tabatabai, G. Langdale, S. Lucco, and R. Wahbe. Efficient and language-

indepedant mobile programs. In Conference on Programmzng Language Design and

Implementution (PLDI), Proceedings of the ACM SIGPLAN '96, pages 127-136.

ACM, 1996.

[3] AMSAT. http ://WEB.amsat .org/amsat/ftpsoft .html.

[4] AMSAT. http ://www.amsat .org/amsat/keps/formats. html.

[5] J. P. Bigus and J. Bigus. Conîtructing Intelligent Agents with Java : A Programmer's

Guide to Smarter Applications. John Wiley & Sons, 1997.

[6] J. M. Bradshaw, editor. Sojlware Agents, pages 291-316. AAAI Press, 1997.

[7] R. Brooks. A robust layered control system for a mobile robot. IEEE Journal of

Robotics and Automation, 2(1) :14-23, 1986.

[8] A. Carzaniga, G. P. Picco, and G. Vigna. Designing distributed applications with

a mobile code paradigm. In Proceedings of the 19th International Conference on

Software Engineeràng, 1997.

[9] Xerox's Pa10 Alto Research Center. ftp ://ftp.parc.xerox.com/pub/ilu/ilu.html.

[IO] D. Chess, C. Harrison, and A. Kershenbaum. Mobile agents: Are they a good idea?

IBM Technical Report RC19887(88465), IBM T. J. Watson Research Center, 1995.

[Il] G. Coulouris, J. Dollimore, and T. Kindberg. Dktributed Systems, Concept and

Design. Addison- Wesley, second edit ion, 1995.

[12] G. Cugola, C. Ghezzi, G. P. Picco, and G. Vigna. A characterization of mobility and

state distribution in mobile code languages. In 2nd ECOOP Workshop on Mobile

Objezt Systems, pages 10-19, 1996.

[13] M. Davidoff. The Satellite Ezperimenters handbook. The American Radio Relay

Ligue, second edition, 1994.

[14] J.-M. Desbiens. Développement de composants d un logiciel client-serveur pour la

poursuite de satellites. Master's thesis, Université de Sherbrooke, 1998.

[15] P. Domel, A. Lingnau, and 0. Drobnik. Mobile agent interaction in heterogeneous

environnements. In Proceedings of the First International Workshop MA '97, 1997.

[16] W. M. Farmer, J. D. Guttman, and V. Swarup. Security for mobile agents : Authen-

tication and state appraisal. In Proceedings of the Fourth European Symposium on

Research in Computer Security, Rome, Italy, pages 118-130. Springer-Verlag, 1996.

(171 D. Flanagan. Java in a Nutshell, pages 4-5. O'Reilly & Associates, 1996.

[18] Germany GMD Fokus. Grasshopper - the agent development platform.

http ://www.ikv.de/products/grasshopper/index.html.

[19] R. S. Gray. Agent tcl: A transportable agent system. In CIKM '95 Worhhop on

Intelligent Agents, 1995.

[20] R. S. Gray, D. Kotz, G. Cybenko, and D. Rus. D'agents: Security in a multiple-

language, mobile-agent system. In Giobanni Vigna, editor, MAAS97 - Mobile Agents

and Security volume 1419, 1998.

[21] R Grimm and B. N. Bershad. Access control in extensible systems. Technical Report

UW-CSE98-02-02, University of Washington, Department of Computer Science,

1997.

[22] K. E. Harker. Tias : A transportable intelligent agent system. Technical Report

PCSTR95-258, Department of Computer Science, Dartmouth College, Hanover,

N.H., 1995.

[23] F. R. Hoots and R. L. Roehrich. Models for propagation of norad element sets.

http ://www.amsat.org/amsat/ftp/docs/spacetrk.pdf, 1998.

[241 L. Hughes. Process migration and its influence on interproces communication.

Computer Communications, 21 (9), 1998.

[25] J. Hylton, K. Manheimer, F. L. Drake, Jr. B. Warsaw, R. Masse., and G. van Rossum.

Knowbot prograrnming : System support for mobile agents. In Proceedings of the

Fifth International Workshop on Object Orientation in ûpemting Systems, pages

8-13, 1996.

[26] IBM. Intelligent agents resource manager, 1996.

[27] Ad Astra Engineering Inc. Jumping beans. http ://www.jumpingbeans.com/.

[28] Mitsubishi Electric ITA and Horizon Systems Labotary. Concordia.

http ://www.meitca.com/HSL/Projects/Concordia/.

[29] Mitsubishi Elect ronic ITA. Mobile agent computing, 1998.

[30] A. D. Joseph, A. F. delespinasse, J. A. Tauber, D. K. Gifford, and M. F. Kaa-

shoek. Rover : A toolkit for mobile information access. In Proceedings of the 15th

A CM Symposium on Operuting Systems Principles, pages 156-1 71. Copper Moun-

tain Company, 1995.

[31] E. Jul. Fine-grained mobility in the emerald system. ACM tmnsactions on Computer

Systems, 6(1) :103-109, 1988.

[32] D. Kafura and J.-P. Briot. Actors and agents. IEEE Concumncy, Pamllel, DLPtri-

buted and Mobile Computing, 1998.

[33] N. M. Karnik and A. R. 'Itipathi. Design issues in mobile-agent programming sys-

tems. IEEE Concumncy, Pamllel, Distributad and Mobile Computing, 1998.

[34] D. B. Lange and M. Oshima. Progmmming and Deploying Java Mobile Agents With

Aglets. Addison- Wesley, 1998.

[35] D. B. Lange and M. Oshima. Seven good reasons for mobile agents. Cornmunicotions

of the ACM, 43(3), 1999.

[36] W. Li and D. G. Messerchmitt. Mobile agent-based network signaling for resource

negotiations. In Workshop on Resource Allocation Problems in Multimedia Systems.

IEEE Real-Time Systems Symposium, 1996.

[37] A. Lingnau and 0. Drobnik. An infrastructure for mobile agents : Rquirements and

architecture. In 13th DIS Worhhop, 1995.

[38] LogSat. http://www.logsat.com/.

[39] P. Maes. Pattie maes on software agents : Humanizing the global computer. IEEE

Intemet Computing, pages 10-19, 1997.

[40] General Magic. Mobile agents. White paper, General Magic, 1998.

[41] D. E. McDysan and D. L. Spohn. ATM: Theory and Applications. McGraw-Hill,

1995.

[42] Microsoft . http ://www.rnicrosoft .com/corn/tech/DCOM .asp.

[43] Microsoft . ht tp ://m. microsoft .corn/ddk/.

[44] Sun Microsystems. http ://java.sun.com/products/javacomm.

[45] Sun Microsystems. http ://java.sun.com/products/jdk/l.2/docs/guide/jni.

[46] Sun Microsystems. Java remote method invocation - distributed computing for java.

http ://java.sun.com/marketing/collateral/javarmi.html.

[47] Sun Microsystems. Rpc: Remote procedure cal1 protocol specification version 2.

http ://www.faqs.org/rfcs/rfcl83l.html, 1995. RFC1831.

[48] NASA. http ://liftoff.msfc.nasa.gov/ReaiTime/JPass/20.

[49] NASA. http ://liftoff.msfc.nasa.gov/RealTime/JPass/PassGenerator.

1501 G. C. Necula and P. Lee. Safe, untmsted agents using proof-carrying code. Submitted

for an LNCS Special Volume on Mobile Agent Security, 1997.

[51] USA New-York University. Dreme. www.cs.nyu.edu/phdstudents/fuchs/index.html.

[52] M. Normandeau. Le modèle room : Formalisation de sa sémantique statique et son

application au développement d'un logiciel de poursuite de satellites. Master's thesis,

Université de Sherbrooke, 1997.

1531 M. Normandeau, S. Bernier, J.-M. Desbiens, and M. Barbeau. Watoo : An internet

access software to a satellite tracking station. In Pmceedings of the AMSAT-NA

15th Space Symposium, pages 24-28. AMSAT, The American Radio Relay Ligue,

1997.

[54] OMG. http://www.omg.org/.

[55] OMG. http ://www.omg.org/news/pr98/compnent.html.

[56] OMG. http ://www.omg.org/library/clangindx.html.

[57] OMG. http ://www.omg.org/corba/sectranl. html.pdf.

[58] OMG. The common object request broker : Architecture and specification.

ftp ://ftp.omg.org/pub/docs/ptc/96-03-04.pdf.

[59] OMG. A discussion of the object management group architecture. Technical report,

Object Management Group, 1997.

[60] OMC. The common objet request broker : Architecture and specification. Technical

report, Object Management Group, 1998.

[61] OMG. Corba facilities architecture. Technical report, Object Management Group,

1998.

[62] OMG. Corba services book. Technical report, Object Management Group, 1998.

[63] OMG. Corba/iiop 2.2 specification. Technical report, Object Management Group,

1998.

[64] OMG. Masif-rtf results. Technical report, Object Management Group, 1998.

[65] R. Orfdi, D. Harvey, and J. Edwards. Instant CORBA. Wiley, 1997.

(661 H. Peine and T. Stolpmann. The architecture of the ara platform for mobile agents.

In Proceedings of the First International Workshop on Mobile Agents, Berlin, Ger-

many, 1997.

[67] A. Pope. The CORBA Reference Guide, pages 45-47. Addison Wesley, first edition,

1998.

[68] P. Ravasio, G. Hopkins, and N. N d a h . The chorus distributed operating system :

Design and implementation. In Proceedings of the IFIP TC 6 International In-Depth

Symposium, pages 207-223, 1982.

[69] J. Siegel. Omg overview : Corba and the orna in enterprise computing. Cornmuni-

cations of the ACM, 41(10), 1998.

[70] J. W. Stamos. Remote Evaluation, Cambridge, Mass. PhD thesis, Institute of

Technology, 1986.

[71] J. Tardo and L. Valenta. Mobile agent security and telescript. In Proceedings of

IEEE COMPCON'96. IEEE, 1996.

[72] A. Tkipathi, N. Karnik, M. Vora, and T. Ahmed. Ajanta - a mobile agent program-

rning system. Technical Report TR98-016, University of Minnesota, Department of

Computer Science, 1998.

[73] Germany University of Kaiserslautern. The ara platform for mobile agents.

http ://www.uni-kl.de/AG-Nehmer/Projekte/Ara/index-e.htm~.

[74] G. Vigna. Protecting mobile agents through tracing. In 3rd ECOOP Workshop on

Mobile Object Systems. IEEE, 1997.

[75] P. Viscarola and W. A. Mason. Windows NT DeMce Dràver Deuelopment. Macmillan

Technical Publishing, first edition, 1998.

[76] Vital. Active message processing : Messages as meççengers. Computer Message

Systern, 1981.