1.4 Choix et proposition de solution
Après une étude comparative, nous avons choisi les
outils qui répondent le mieux à nos besoins. Les critères
suivants sont pris en compte :
- l'application doit être développée avec des
outils libres et open sources;
- l'application doit être consultée n'importe
où avec un client léger comme un navigateur : mode
client-serveur;
- pas besoin de plugins supplémentaires pour afficher des
cartes;
Au niveau applicatif, nous optons pour GlassFish vu sa
souplesse, sa double fonctionnalité de serveur Web et serveur
d'application. De plus, GlassFish est disponible sous une licence gratuite et
est incorporé dans NetBeans, l'environnement de développement que
nous avons choisi.
Pour la génération des couches cartographiques,
GeoServer a été choisi comme Serveur géographique
garantissant un meilleur rendu des cartes et une meilleure
sécurité. Implémenté en Java, son choix nous permet
d'avoir une homogénéité au niveau de tout le
système à mettre en place.
Si nous avions à effectuer une classification sur
l'ensemble des fonctionnalités offertes par les SGBDS
étudiés, Oracle Spatial viendrait en tête suivie de
PostgreSQL/PostGIS. Cependant,
nous portons notre choix sur le second du fait qu'il est libre
et gratuit. Il est quasiment aussi performant que Oracle Locator qui est quant
à lui un produit propriétaire et non gratuit. De plus
PostgreSQL/PostGIS est facilement accessible par GeoServer, notre
serveur géographique.
En résumé, nous proposons un système qui
correspond à une architecture quatre tiers composée des
éléments suivants :
- un client léger comme un navigateur Web;
- un serveur d'application : GlassFish;
- un serveur géographique : GeoServer ;
- un serveur de données : PostgreSQL/PostGIS.
L'architecture finale proposée se présente comme
suit :
Figure 1.1 - Architecture technique du système
1. Le client émet une requête (i.e. appelle une
URL) pour demander une ressource au serveur. La réponse à cette
requête peut être une page HTML simple (statique) ou une page
dynamique générée par une application Web.
2. Le serveur Web se charge du traitement de la requête
http. Lorsque la réponse à la requête est une page
statique, elle est directement fournie par le serveur Web.
3. Si le serveur http s'aperçoit que la requête
reçue est destinée au serveur d'applications, il la lui transmet.
Les deux serveurs sont reliés par un canal, nommé connecteur.
4. Le serveur d'applications (exemple : Glassfish )
reçoit la requête à son tour. Il est, lui, en mesure de la
traiter. Il exécute donc le morceau d'application (la Servlet) auquel
est destinée
la requête, en fonction de l'URL. Cette exécution
peut nécessiter des images cartographiques d'où l'interpellation
du serveur géographique (exemple : GeoServer) ou la
consultation des sources de données attributaires comme des bases de
données (exemple : PostgreSQL, 5' sur le schéma).
5. Lorsque le traitement de la requête fait appel
à une image cartographique, le serveur d'application fait recourt au
serveur géographique qui produit l'image correspondant et l'envoie.
6. Pour produire une image cartographique, le serveur
cartographique a besoin des données géographiques qu'il demande
au SGBD (PostgreSQL/PostGIS) via une requête.
7. Une fois sa réponse générée, le
serveur d'applications la renvoie, par le connecteur, au serveur Web. Celui-ci
la récupère comme s'il était lui-même allé
chercher une ressource statique.
8. La réponse est dorénavant du simple code HTML,
compréhensible par un navigateur. Le serveur http peut donc retourner la
réponse au client.
| 
