Xooctory – Projet GL Aurélie COHE Fabien FAGOAGA Alice GARCIA Matthieu JOUBERT Christelle MAZEREAU Client : Xavier HANIN

Plan Présentation de l’application Architecture adoptée Refactoring et utilisation de Triplesec Réalisation de la persistance en base (Hibernate) Configuration de l’application (Spring) Tests unitaires Management Conclusion

Plan Présentation de l’application Architecture adoptée Refactoring et utilisation de Triplesec Réalisation de la persistance en base (Hibernate) Configuration de l’application (Spring) Tests unitaires Management Conclusion

Présentation du projet

Objectif du projet (1/2) Etat actuel de l’application : Application Persistance LDAP

Objectif du projet (2/2) Etat souhaité de l’application : Application Persistance Persistance LDAP Base de données

Outils utilisés Wicket : Hibernate : Spring : Triplesec : Framework Web permettant de développer des pages HTML dynamiques en Java Utilisée pour les IHM Compréhension nécessaire pour pouvoir l’utiliser Hibernate : Outil de mapping objet-relationnel Spring : Outil utile pour les configurations de l’application Triplesec : Permet la communication avec un serveur LDAP

Organisation du travail Conception Réalisation découpé en 2 sous-équipes : Un binôme sur Wicket et Triplesec Un trinôme sur Spring et Hibernate Tests

Plan Présentation de l’application Architecture adoptée Refactoring et utilisation de Triplesec Réalisation de la persistance en base (Hibernate) Configuration de l’application (Spring) Tests unitaires Management Conclusion

Architecture des paquetages (1/2)

Architecture des paquetages (2/2) Réorganisation des paquetages Séparation des couches vue et persistance

Architecture des classes (1/3) Auparavant : Utilisation de classes Triplesec dans les éléments utilisés par Wicket : Modèles et Panels Utilisation de modèles : adaptateur des données aux composants de Wicket Composants de Wicket : objets permettant de modéliser un élément d’affichage Ex : wicket.markup.html.form.Button représente un bouton

Architecture des classes (2/3) Exemple des rôles dans l'application existante : Conséquences : Modification de ces éléments afin qu’ils ne fassent pas appel à Triplesec (directement ou indirectement) Ajout d’une couche d’abstraction

Architecture des classes (3/3) Exemple des rôles :

Plan Présentation de l’application Architecture adoptée Refactoring et utilisation de Triplesec Réalisation de la persistance en base (Hibernate) Configuration de l’application (Spring) Tests unitaires Management Conclusion

Code spécifique à Triplesec Refactoring (1/3) Paquetage : org.xoocode.xooctory.web Configuration de l’application Panels Mise en place de l’arborescence Code spécifique à Triplesec

Code spécifique à Triplesec Refactoring (2/3) Code spécifique à Triplesec Fonctionnalités : Sauvegarde Suppression Récupération de toutes les instances stockées dans la couche de persistance Objets utilisés : Equivalent aux modèles définies

Refactoring (3/3) Code initial Code spécifique à Triplesec Code équivalent utilisant les fonctions de l’interface Code indépendant

Refactoring – Exemple (1/5)

Refactoring – Exemple (2/5) Exemple avec le panel gérant les permissions public PermissionPanel(String id, IModel model, Tree tree) { […] PermissionModel permissionModel = new PermissionModel(getPermission()); getForm().setModel(new CompoundPropertyModel(permissionModel)); [...] } private Permission getPermission() { return (Permission) ((DefaultMutableTreeNode) getModelObject()).getUserObject(); getForm().setModel(new CompoundPropertyModel(getPermission())); private PermissionModel getPermission() { return (PermissionModel) ((DefaultMutableTreeNode) getModelObject()).getUserObject();

Refactoring – Exemple (3/5) protected void onDelete() { [Code Triplesec pour la suppression] } protected AdministeredEntity onSave() { [Code Triplesec pour la sauvegarde] Locator.getSecurityManagementService().deletePermission(getPermission()); protected AdministeredEntityModel onSave() { return Locator.getSecurityManagementService().savePermission( getPermission(), (PermissionModel) getForm().getModelObject());

Refactoring – Exemple (4/5)

Refactoring – Exemple (5/5) private TriplesecPermissionDAO permissionDAO = new TriplesecPermissionDAO(); [...] public AdministeredEntityModel savePermission(PermissionModel oldPermission, PermissionModel newPermission) { return permissionDAO.save(oldPermission, newPermission); } public void deletePermission(PermissionModel permission) { permissionDAO.delete(permission); TriplesecSecurityManagementService [...] public void delete(PermissionModel permission) { [Code Triplesec pour la suppression] } public AdministeredEntityModel save(PermissionModel oldPermission, PermissionModel newPermission) { [Code Triplesec pour la sauvegarde] TriplesecPermissionDAO

Plan Présentation de l’application Architecture adoptée Refactoring et utilisation de Triplesec Réalisation de la persistance en base (Hibernate) Configuration de l’application (Spring) Tests unitaires Management Conclusion

Persistance en base de données Utilisation d’Hibernate Informations stockées dans la même base que celle déjà existante Mapping des modèles réalisées dans les classes *Model

Les classes à mapper (1/2)

Les classes à mapper (2/2) Choix techniques : Mapping des classes AdministeredEntityModel et LocalUserModel

Choix techniques retenus (1/4) La classe AdministeredEntityModel : Mapping en représentant une table par classe concrète Pas de table AdministeredEntity Toutes les tables mappant des classes héritant de AdministeredEntityModel contiennent les données de la classe mère

Choix techniques retenus (2/4) La classe LocalUserModel : Hiérarchie dû au framework Triplesec 3 types d’utilisateurs : LocalUser, ExternalUser et HauskeysUser Mapping représentant une table par hiérarchie : une seule table User Uniquement des utilisateurs LocalUser

Choix techniques retenus (3/4) Tables principales : Ajout des classes faisant l’objet d’un mapping dans le fichier de configuration spring-config-hb.xml : <property name="annotatedClasses"> <list> ... <value>org.xoocode.xooctory.web.directory.security.model.AdministeredEntityModel</value> <value>org.xoocode.xooctory.web.directory.security.model.ApplicationModel</value> <value>org.xoocode.xooctory.web.directory.security.model.GroupModel</value> <value>org.xoocode.xooctory.web.directory.security.model.LocalUserModel</value> <value>org.xoocode.xooctory.web.directory.security.model.PermissionModel</value> <value>org.xoocode.xooctory.web.directory.security.model.ProfileModel</value> <value>org.xoocode.xooctory.web.directory.security.model.RoleModel</value> <value>org.xoocode.xooctory.web.directory.security.model.UserModel</value> </list> </property>

Choix techniques retenus (4/4) D’autres tables pour stocker les associations : Table Profile_Grants pour les ensembles de privilèges associés aux profils Table Profile_Roles pour les ensembles de rôles associés aux profils

Problème rencontré (1/2) Tous les modèles héritent de AdministeredEntityModel et mapping représentant une table par classe concrète @Entity @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS) public abstract class AdministeredEntityModel implements Serializable { private String creatorsName; private String modifiersName; private Date createTimestamp; private Date modifyTimestamp; … } Exception au démarrage de l’application : org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.transaction.interceptor.TransactionAttributeSourceAdvisor': ... nested exception is org.hibernate.AnnotationException: No identifier specified for entity: org.xoocode.xooctory.web.directory.security.model.AdministeredEntityModel

Problème rencontré (2/2) Causes : Pas d’identifiant précisé au modèle avec l’annotation @Id La classe mère n’a pas d’identifiant, ils sont dans les sous-classes Correction : Utilisation de l’annotation @MappedSuperClass @MappedSuperclass public abstract class AdministeredEntityModel implements Serializable { private String creatorsName; private String modifiersName; private Date createTimestamp; private Date modifyTimestamp; … }

Implémentation des DAO Hibernate (1/3)

Implémentation des DAO Hibernate (2/3) Accès à la base de données Hibernate en utilisant un ensemble de DAO Chaque DAO hérite de la classe HibernateDaoSupport du framework Spring : Accès à Hibernate par les méthodes de cette classe public class HbGroupDAO extends HibernateDaoSupport { @Transactional(readOnly = false) public AdministeredEntityModel add(GroupModel group) { String id = (String) getHibernateTemplate().save(group); group.setId(id); return group; } …

Implémentation des DAO Hibernate (3/3) Instanciation d’une SessionFactory obligatoire : Création d’un bean pour chaque DAO dans spring-config.xml <bean id="permissionDAO" class="org.xoocode.xooctory.web.directory.security.manager. hibernate.HbPermissionDAO"> <property name="sessionFactory"> <ref bean="sessionFactory"/> </property> </bean> Chaque bean possède une propriété SessionFactory récupérée à l’aide du bean sessionFactory présent dans spring-config-hb.xml

Plan Présentation de l’application Architecture adoptée Refactoring et utilisation de Triplesec Réalisation de la persistance en base (Hibernate) Configuration de l’application (Spring) Tests unitaires Management Conclusion

Choix de l’implémentation (1/3) Objectifs : Facilité pour changer d’implémentation de la sécurité Pas de modification de code source Solution : utilisation de Spring pour faire la configuration

Choix de l’implémentation (2/3) Utilisation du fichier spring-config-security.xml Création de 2 beans Mise en commentaire du bean non choisi

Choix de l’implémentation (3/3) Création d’un locator :

Les DAO Hibernate (1/3) Homogénéité avec les DAO existants

Les DAO Hibernate (2/3) Ajout d’un bean pour chaque DAO dans le fichier spring-config.xml

Les DAO Hibernate (3/3) Dans spring-config-hb.xml :

Les problèmes rencontrés Dans spring-config.xml Dans spring-config-hb.xml

java.lang.ClassNotFoundException: ${jdbc.driver.class} Solution provisoire Erreur : java.lang.ClassNotFoundException: ${jdbc.driver.class}

Plan Présentation de l’application Architecture adoptée Refactoring et utilisation de Triplesec Réalisation de la persistance en base (Hibernate) Configuration de l’application (Spring) Tests unitaires Management Conclusion

Tests existants Avant Après

Nouveaux tests Une classe de tests par DAO Ajout Mise à jour web Une classe de tests par DAO Ajout Mise à jour Consultation Suppression

Scénarios des nouveaux tests Ajout d’un élément Vérification que l’élément ait bien été créé Modification de l’élément Vérification que les modifications aient été prises en compte Suppression de l’élément Vérification que l’élément n’existe plus

Plan Présentation de l’application Architecture adoptée Refactoring et utilisation de Triplesec Réalisation de la persistance en base (Hibernate) Configuration de l’application (Spring) Tests unitaires Management Conclusion

Management – Diagramme de Gantt (1/2)

Management – Diagramme de Gantt (2/2)

Plan Présentation de l’application Architecture adoptée Refactoring et utilisation de Triplesec Réalisation de la persistance en base (Hibernate) Configuration de l’application (Spring) Tests unitaires Management Conclusion

Conclusion Projet très intéressant Découverte de nouveaux outils Refactoring de code Utilisation d’Hibernate (approfondissement du cours) Merci à Xavier Hanin pour son aide