Conclusion
La phase d'analyse a permis de cerner le contour du
système à travers les différents diagrammes fonctionnels,
dynamiques et statiques afin d'aboutir à la conception. Cette phase
permet de bien canaliser la phase suivante abordée dans le chapitre III
à savoir le déploiement et la mise en oeuvre d'un prototype du
SYGeD1 .
1. SYGeD : Système de Gestion des Domaine
CHAPITRE TROIS
DEpLoiEMENT ET MiSE EN (EuvRE D'uN
pRoToTypE Du SYGED
Introduction
Ce dernier chapitre du mémoire sera consacré
à la mise en oeuvre de la solution retenue. Elle permettra d'aborder de
façon détaillée le déploiement des
différentes composantes du système et l'implémentation de
l'application Web qui lui servira de portail. Les différents tests
permettront d'évaluer les performances du prototype et de
détecter ses limites.
3.1 Déploiement du Système
3.1.1 Architecture physique du système
Les modèles de déploiement et de configuration
matérielle s'expriment tous deux à l'aide d'un diagramme de
déploiement.
Le modèle de configuration matérielle a pour but
d'exprimer les contraintes de mise en oeuvre au niveau physique. On y trouve
les noeuds et les connexions physiques du système, qui sont les
différents types de machines connectées par des moyens divers. Le
modèle de configuration matérielle permet de spécifier, de
documenter et de justifier tous les choix d'organisation physique en fonction
des machines dédiées aux diverses fonctions techniques du
système [10] .
La Figure 3.1 représentant le diagramme de
déploiement de notre système décrit la répartition
physique des fonctions-métiers du système et la localisation des
différents serveurs.
Figure 3.1 - Diagramme de déploiement du SYGeD
Nous proposons une architecture physique dont la communication
est basée sur le protocole TCP/IP.
Au niveau applicatif, l'échange de données entre
le serveur d'application (également serveur Web) et le SGBD se fait
grâce au JDBC (Java DataBase Connectivity) qui est une API Java
très utilisée pour l'accès aux bases de données. De
même, entre le serveur de données et le serveur
géographique, l'API JDBC est utilisé pour les échanges des
données. Par ailleurs, les différents clients demandent des
services au serveur d'application en émettant des requêtes
basées sur le protocole http.
L'internaute (contribuable ou personnel administratif) par le
biais d'un navigateur émet une
requête http qui sera reçue par le serveur Web.
Cette requête peut demander une ressource statique ou une ressource
dynamique. Lorsqu'il s'agit d'une ressource statique, elle est directement
fournie par le serveur Web. Une requête qui demande une ressource
dynamique (image cartographique par exemple) est redirigée par le
serveur Web vers le serveur d'application qui est capable de la traiter. Ce
dernier exécute les morceaux de servlets concernés et interroge
le serveur géographique chargé de la production des cartes. Ceci
peut nécessiter la consultation de la source de données
spatiales. Une fois la carte produite, elle est renvoyée au serveur
d'application qui la présente à son tour au serveur Web sous
forme de page HTML. Ainsi, le serveur Web est capable de l'interpréter
pour enfin présenter la réponse au client sous forme d'une page
statique.
| 
