V.3.4. Paquetage « dao »
Le paquetage « dao » représente la couche
d'accès aux données persistantes via l'intermédiaire
d'Entity Bean. Il joue le rôle de « Proxy » entre la couche
service et la base de données persistante (ou plus
précisément avec JPA).
V.4. Mise en oeuvre de l'architecture en couche du
système
1
Figure 5-3 : Architecture en couche du
système
87
1
88
Figure 5-4 : Suite architecture en couche du
système.
V.4.1. Description de la couche présentation
Permet à l'utilisateur de piloter l'application et d'en
recevoir des informations (voir figure 5-5).
PACKAGE WEB
COUCHE PRESENTATION
Administration
Utilisateur Profil
Nouveau Lister
Edit
Template
Envoyer
Session
Nouveau
Liste
Nouveau
Liste
LOGIN
Nouveau
Rechercher
Lister
SetReponsePage
Success
Echec
Evaluer
Modèle
Nouveau
Modifier
Nouveau
Liste
Template
SecureTemplate
HOME
Dossier
Dossier
Etablissement
Candidat
« Extend »
Service
Template.properties
Wizardstep
Nouveau
Liste
Position
Nouveau
Liste
Diplome
Pieces
Lettre
Impression
Fauxdiplome Lettre
Arrêtés
Lettre
Nouveau Rechercher
Lister
Etablissement
Nouveau
Liste
Figure 5-5 : Architecture couche
présentation.
89
90
V.4.2. Description de la couche métier
La couche métier est la couche qui
applique les règles dites métier, c.à.d. la logique
spécifique de l'application, sans se préoccuper de savoir
d'où viennent les données qu'on lui donne, ni où vont les
résultats qu'elle produit (voir figure 56).
PACKAGE METIER
RESOURCES
persistance
META-INF
|
ENTITIES
|
|
|
DOSSIER
|
SERVICE
|
CANDIDAT
|
PIECES
|
|
|
ETABLISSEMENT
|
ENVOYER
|
DIPLOME
|
LETTRE
|
|
|
MODELE
|
STATUT
|
UTILISATEUR
|
TYPES
|
|
Figure 5-6 : Architecture couche
métier
V.4.3. Description de la couche service
Elle implémente les algorithmes " métier " de
l'application. Elle est indépendante de toute forme d'interface avec
l'utilisateur, utilisable aussi bien avec une interface console, web, client
riche (voir figure 5-7).
91
PACKAGE SERVICE
ServiceFactory
IUtilisateurService
IDossierService
CONFIG
Spring-bean
IMPLEMENTATION
UtilisateurServiceImpl
DossierServiceImpl
RESOURCES
Figure 5-7 : Architecture couche service
V.4.4. Description de la couche DAO
La couche DAO est la couche qui fournit
à la couche métier des données
préenregistrées (fichiers, bases de données, ...) et qui
enregistre certains des résultats fournis par la couche
métier.
La spécification JPA (Java Persistence
API) est utilisée pour standardiser la couche ORM. Hibernate est un
outil qui fait le pont entre le monde relationnel des bases de données
et celui des objets manipulés par Java.
Nous utiliserons le Framework Spring pour
lier la couche DAO et JPA/Hibernate. Le grand intérêt de Spring
est qu'il permet de lier les couches par configuration et non dans le code.
Avec Spring, les couches seront implémentées avec des
POJOs permettant la réutilisation de ceux-ci dans un
autre contexte. Ceux-ci auront accès aux services de Spring (pool de
connexions, gestionnaire de transaction) par injection de dépendances
dans ces POJOs : lors de la construction de ceux-ci, Spring leur injecte des
références sur les services dont ils vont avoir besoin.
PACKAGE DAO
COUCHE DAO
IUtilisateurDao
IServiceDao
ILettreDao
CONFIG
IEtablissementDao
ISessionDao
IEnvoyerDao
IDossierDao
ICandidatDao
IDao
DataAccessException
Spring-bean
RESOURCES
META-INF
IMPL
DAO
Persistence
IUtilisateurDaoImpl
IServiceDaoImpl
ILettreDaoImpl
IEtablissementDaoImpl
ISessionDaoImpl
IEnvoyerDaoImpl
IDossierDaoImpl
ICandidatDaoImpl
IDaoImpl
DataAccessExceptionImpl
LOG4J.Properties
Figure 5-8 : Architecture couche DAO.
92
V.5. Sécurité
Le système est application web qui devra fonctionner
dans un réseau informatique (Internet ou Intranet), dés lors
celui pourra être susceptible à une attaque provenant soit d'un
pirate informatique ou d'autres utilisateurs connectés sur le
réseau. Il est donc nécessaire de programmer une politique de
sécurité afin de prévenir tout risque qui pourra nuire au
bon fonctionnement de l'application.
V.5.1. Accès à l'application
La sécurité au niveau de l'accès de
l'application consiste à mettre en place une structure
sécurisée d'accès et de suivi de toutes les
opérations jugées critiques. Il nous parait anormal de mettre en
place une application multiutilisateur fonctionnant en mode client-serveur sans
pouvoir contrôler l'accès de chaque utilisateur. Une politique
d'identification par login et mot de passe ont été définie
pour chaque compte utilisateur.
Login et password
IDENTIFICATION
HOME
Figure 5-9 : Accès application.
93
V.5.2. Chiffrage du mot de passe
En plus du fait d'avoir definir une politique d'accès
à l'application sécurisé par login et mot de passe, il est
important de définir une politique de chiffrement du mot de passe. Ainsi
si un pirate snife l'echange entre le client et le serveur il ne pourra avoir
accès seulement au mot de passe codé. Le codage du mot de passe
s'est éffectué avec l'algorithme du SHA 256 (Secure Hash
Algorithm). Lorsque l'utilisateur saisit son mot de passe, il est codé
et la vérification s'effectué avec les deux versions
codées : celle de la base de données et celle saisie (voir figure
5-10).
Password chiffré
Serveur
Client
Figure 5-10 : Chiffrage du mot de passe.
V.5.3. La session
Notre application web est basée sur le protocole HTTP,
qui est un protocole dit "sans état" : cela signifie que le serveur, une
fois qu'il a envoyé une réponse à la requête d'un
client, ne conserve pas les données le concernant. C'est pour pallier
cette lacune que le concept de session a été créé :
il permet au serveur de mémoriser des informations relatives au client,
d'une requête à l'autre. La session représente un espace
mémoire alloué pour chaque utilisateur, permettant de sauvegarder
des informations tout le long de leur visite ;
le contenu d'une session est conservé jusqu'à ce
que l'utilisateur ferme son navigateur, reste inactif trop longtemps, ou encore
lorsqu'il se déconnecte du site ; La figure 5-11 ci-dessous illustre la
création d'une session.
IDENTIFICATION
getSession ()
Création d'un objet HttpSession, avec identifiant
unique
94
HOME
|
Figure 5-11 : Création session.
|
| 
