117 
• le composant GEOLIB client doit se trouver sur le poste du 
client afin d’être intégré dès le lancement de l’applicatif 
Windows ; 
• toute partie liée à la communication avec le serveur HTTP 
n’est plus présente. 
Les trois architectures couvrent des besoins différents. 
L’architecture mono-poste interagit avec des données qui sont 
sur le même poste, et il n’y a qu’un seul utilisateur accédant à 
ces données. Cette architecture peut être plus performante que 
les deux autres car la couche de communication entre machines 
n’est plus nécessaire. Mais, à cause de la nécessité d’avoir 
toutes les données sur le même poste, cette architecture n’est 
pas adaptée dans les cas suivants : 
• quand les données représentent un volume important ou que 
certaines parties de ces données n'intéressent pas 
l’utilisateur ; 
• quand les mêmes données sont utilisées par plusieurs 
utilisateurs (et donc déployées sur plusieurs postes) ; 
• et quand les données subissent des mises à jours 
fréquentes. 
L’architecture mono-poste est préférable quand le volume des 
données est peu important (jusqu'à quelques méga-octets), pour 
l’utilisation de données confidentielles, pour le développement 
des applicatifs ou pour des démonstrations. 
L'architecture GEOLIB client-serveur a l’avantage de regrouper 
toutes les données nécessaires pour le travail de plusieurs 
utilisateurs dans un seul endroit. Les problèmes de cohérence 
des données dus aux mises à jours et les problèmes liés aux 
données qui ne sont jamais utilisées et qui prennent de la place 
sont résolus. Les utilisateurs peuvent accéder à toutes les 
données dont ils ont besoin. Le problème de confidentialité des 
données n’a pas été traité dans la première version du système 
GEOLIB, mais le système peut être facilement étendu, en 
définissant dans le fichier de configuration du serveur GEOLIB 
(D dans Figure 4), des cartes avec des rectangles englobants qui 
correspondent aux zones (données) accessibles, et en attribuant 
aux utilisateurs des accès sur certaines cartes. Cette architecture 
est idéale pour l’exploitation de données au sein d’une 
organisation avec un réseau interne (Intranet). 
L’architecture GEOLIB Web est destinée à viser un public plus 
large. Grâce au serveur HTTP, toute personne peut télécharger 
le composant GEOLIB Client et consulter des sources de 
données. L’interaction du composant GEOLIB et du navigateur 
peut produire des présentations interactives en exploitant les 
possibilités du langage HTML (texte, images, son) et les 
fonctionnalités du système GEOLIB (navigation géographique, 
requêtes sur les données spatiales et attributaires). 
4. REVIM [SBBB99] 
4.1. Objectif 
Dans le projet REVIM, une architecture pour un système 
embarqué a été définie, permettant d'accéder à des informations 
provenant de sources différentes en utilisant des technologies 
standard. 
Ce système est basé sur des technologies existantes et 
largement utilisées, ce qui doit faciliter son utilisation pratique. 
Nous utilisons ainsi un système de positionnement par satellite 
(GPS : Global Positioning System) pour la localisation 
géographique du véhicule. La liaison avec les serveurs de 
données se fait au niveau physique par l'intermédiaire d'un 
téléphone cellulaire. Au niveau logiciel, une connexion de type 
Internet permet d'établir les communications entre les 
composants du système et les serveurs de données. Un 
navigateur Web et des applets Java autorisent la visualisation et 
le traitement des informations. 
L'architecture du système est de type client-serveur. Elle permet 
de mieux gérer les informations traitées par le système. Les 
quantités d'informations (géographiques ou multimédias) peuvent 
en effet être très importantes, et les informations dynamiques 
(trafic, position des véhicules) nécessitent des mises à jour 
fréquentes. Il est donc préférable d'avoir une source centralisée 
d’informations et d'envoyer toutes les données nécessaires aux 
clients au fur et à mesure, en fonction de leurs besoins. 
Le choix d'utiliser un navigateur Web et une applet Java offre 
plusieurs avantages. Une applet peut charger les données 
nécessaires et les traiter localement, sans se connecter au 
serveur et sans envoyer une requête, ce qui réduit la charge de 
connexions. De plus, le code de l'applet est chargé à partir d’un 
serveur à chaque nouvelle séance de travail, ce qui assure la 
mise à jour facile des applications. Il suffit donc de se connecter 
sur un serveur de données (un serveur HTTP, par exemple), de 
charger le code d'une application (une applet) et de l'exécuter 
sans installer localement d’applications supplémentaires (hormis 
le navigateur web). 
4.2. Intégration des données géographiques 
La principale difficulté vient de la diversité des sources 
d'information devant être traitées dans une unité mobile. En fait, 
l'applet exécutée par un navigateur Web doit accéder aux 
informations provenant d'un (ou de plusieurs) serveur(s) de 
données, ce qui constitue un ensemble de ressources distantes. 
En même temps, l’applet doit recevoir les informations sur le 
positionnement envoyées par un GPS connecté à l'ordinateur, ce 
qui correspond aux ressources locales. Celles-ci faisant partie 
des ressources physiques d'un ordinateur (par exemple, 
connecté à un port série), elles ne peuvent être récupérées et 
traitées que par le code natif d'un système d'exploitation. 
La restriction de sécurité imposée sur une applet exécutée par un 
navigateur pose alors un problème difficile à résoudre. L'applet 
ne peut accéder qu’aux données provenant de la même source 
que lui. Elle ne peut donc pas accéder aux ressources locales 
que sont le système de fichiers ou les périphériques connectés à 
l'ordinateur. Il nous faut donc trouver un moyen de communiquer 
les données d’un GPS à une applet. 
La solution adoptée consiste à utiliser un mini-serveur local, 
installé dans l'ordinateur. Le principe de cette solution est que 
l'applet accède à toutes les données par l'intermédiaire de ce 
serveur. La Figure 6 illustre le principe de fonctionnement. Le 
serveur, quant à lui, redirige une connexion de l'applet sur les 
autres serveurs ou accède aux données locales. Il communique 
ensuite la réponse obtenue par cette connexion à l'applet. Pour 
l'applet, c'est une seule et même source de données, et les 
restrictions de sécurité ne sont pas violées. 
Le principal inconvénient de cette solution est que l'utilisateur doit 
se préoccuper d’installer des logiciels supplémentaires pour le 
bon fonctionnement du système (comme pour la première 
solution), mais elle présente aussi des avantages. 
Les communications entre les deux parties du système sont 
limitées par l'utilisation d'un mécanisme de type "cache" sur le 
serveur distant, et elles ne se font qu’entre eux. Cela nous 
permettra de trouver des méthodes d'optimisation des 
connections tout en gardant le même mode de communications 
vis-à-vis des autres composantes (par exemple, la réponse à une 
requête du navigateur de la part du serveur local est au format 
HTTP). La possibilité d'optimiser les communications présente un 
grand intérêt dans un contexte de type système embarqué, car la 
vitesse de transfert des données y est limitée. 
4.3. Organisation du système 
L'organisation du système est présentée dans la Figure 7. Les 
données disponibles sur un serveur et accessibles par un client 
sont d'abord des pages HTML contenant les références sur le 
code de l'applet et le code de l’applet lui-même. Ces données 
sont demandées par l'intermédiaire d'un navigateur Web, et elles 
correspondent aux requêtes HTTP envoyées par lui.