International cooperation and technology transfer

Mussio, Luigi

Bibliographic data

Monograph

Persistent identifier:: 856489328

Author:: Mussio, Luigi

Title:: International cooperation and technology transfer

Sub title:: Parma, Italy, February 15 - 19, 1999, Bandung, Indonesia, April 13 - 14, 1999, Cotonou, Benin, December 6 - 10, 1999 ; proceedings of the workshops

Scope:: XXX, 398 Seiten

Year of publication:: 1999

Place of publication:: London

Publisher of the original:: RICS Books

Identifier (digital):: 856489328

Illustration:: Illustrationen, Diagramme

Language:: English

Usage licence:: Attribution 4.0 International (CC BY 4.0)

Publisher of the digital copy:: Technische Informationsbibliothek Hannover

Place of publication of the digital copy:: Hannover

Year of publication of the original:: 2016

Document type:: Monograph

Collection:: Earth sciences

Chapter

Title:: DES COMPOSANTS LOGICIELS GEOGRAPHIQUES POUR ELARGIR ET DEMOCRATISER L'ACCES A LA TECHNOLOGIE ETA L’INFORMATION GEOGRAPHIQUE. SPATIAL SOFTWARE COMPONENTS FOR WIDENING AND DEMOCRATIZING ACCESS TO GEOGRAPHIC INFORMATION AND TECHNOLOGY. Patrice BOURSIER, Michel EBOUEYA, Arunas STOCKUS, Alain BOUJU, Frédéric BERTRAND.

Write comment:: Überschrift gleichzeitig in französischer und englischer Sprache enthalten.

Document type:: Monograph

Structure type:: Chapter

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.

Access restriction

Copyright

fullscreen: International cooperation and technology transfer

Monograph

Chapter

Table of contents

Cite and reuse

Monograph

Chapter

Image

Image fragment

Citation links

Citation recommendation