|
Mise en oeuvre d'une solution de gestion centralisée de la fiche signalétique client (FSC)( Télécharger le fichier original )par ABDELKARIM AZIZ Université Abdelmalek Saadi - 2010 |
Annexe 3Hibernate [ Wwwhibernate.com] Hibernate est un Framework open source gérant la persistance des objets en base de données relationnelle. Ce dernier remplace les accès à la base de données par des appels à des méthodes objet de haut niveau. De plus, il permet de tirer partie des concepts de la programmation objet, tels que, l'héritage, le polymorphisme, les relations entre les classes, etc. La figure suivante décrit l'architecture du framework Hibernate :
Figure 28 Architecture du Framework Hibernate SessionFactory : Permet de créer des objets sessions, puis réalise le mapping entre la session créée et la base de données relationnelle. Il est important de souligner que la session ne peut être mappée qu'avec une seule base de données. Session : C'est un objet à courte durée de vie représentant la conversation entre l'application et l'entrepôt de persistance. Ce module permet d'encapsuler une connexion JDBC et de créer des objets de type transaction. Objets persistants : Ce sont des objets à courte durée de vie, contenant l'état de persistance et la fonction métier. Ce sont des objets de type JavaBeans ou
POJOs associés à une seule session. Ils deviennent libres dès la fermeture de la session. Hors connexion, ils peuvent être utilisés par n'importe laquelle des couches de l'application. Objets non persistants : Ce sont des objets non associés à une session (ils peuvent en réalité être des instances de classes persistantes ou métiers, mais en mode déconnecté). Il faut savoir qu'Hibernate utilise : L'API JDBC : permet de gérer la connexion à la base de données relationnelle. L'API JNDI : permet de gérer la connexion aux sources de données L'API JTA : permet de gérer la connexion aux serveurs d'applications
Annexe 4Acegi Security [ Wwwdeveloppez.com]
Acegi Security est un framework Open Source dont l'objectif est de proposer un système complet de gestion de la sécurité. Il peut être utilisé de manière indépendante mais fonctionne de manière optimale avec Spring. Il s'agit d'ailleurs d'une solution très répandue au sein de la communauté Spring. Les avantages fournis par Acegi Security par rapport à une solution J2EE classique.
Le premier avantage d'Acegi Security est sa portabilité. Ne dépendant pas d'un serveur d'applications particulier, son utilisation est identique quel que soit le serveur utilisé. Cette portabilité est particulièrement importante si l'application développée doit pouvoir être vendue à un grand nombre de clients possédant des systèmes hétérogènes. Dans le cadre d'une application développée en interne, il n'en reste pas moins dommage de se trouver bloqué sur un serveur d'applications uniquement à cause d'une problématique de sécurité. Le deuxième avantage d'Acegi Security est qu'il fournit en standard un nombre de fonctionnalités beaucoup plus important qu'un serveur J2EE classique. Parmi les plus simples, et qui manquent cruellement dans la spécification J2EE, citons l'authentification automatique par cookie pour un nombre donné de jours, ainsi que la vérification qu'un utilisateur n'est pas déjà authentifié avec le login demandé. Enfin, Acegi Security propose une excellente intégration
avec les applications Web et
d'utiliser la POA afin de sécuriser la couche métier de manière efficace et transparente. Si nous reprenons les besoins de sécurité rappelés en début de chapitre, Acegi Security apporte les avantages suivants :
Gestion des utilisateurs : solution intégrée, complète et portable. Sécurisation des requêtes HTTP : disponible de manière plus fine que dans la norme J2EE. Sécurisation de la couche de service : API complète, qui s'intègre dans les frameworks courants de POA (AOP Alliance, une API implémentée par Spring AOP, et AspectJ).
Sécurisation de la couche de domaine : listes de contrôle d'accès, qui peuvent être spécifiées au niveau de chaque objet de domaine. Contrôle du code exécuté : non pris en compte par Acegi Security.
Les grands principes d'acegi sécurité : Filtrage des accès :
Le principe mis en place par ACEGI pour sécuriser une ressource est relativement simple, une série de « filtres » sont interposés entre l'appelant et la ressource ellemême. Ces différents filtres ont chacun un rôle précis dans la chaîne de sécurisation. Nous allons voir aussi que l'on peut mettre ou ne pas mettre certains filtres en fonction des options que l'on choisit pour sécuriser la ressource mais aussi en fonction des besoins qui peuvent s'imposer. ACEGI utilise la notion de « filter » définie dans la spécification sur les servlets (fichier web.xml) pour positionner ses propres filtres spécialisés dans la sécurité et les aspects (Spring AOP ou AspectJ), pour sécuriser les appels de méthodes ou les objets.
|
|
