×

You are using an outdated browser that does not fully support the intranda viewer.
As a result, some pages may not be displayed correctly.

We recommend you use one of the following browsers:

Full text

Title
International cooperation and technology transfer
Author
Mussio, Luigi

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.