Application de commerce électronique Technologies J2EE

Transcription

1 BARBAZAN Jean-René 2A IMA OUAHAB Karim Groupe H RIBEIRO Nicolas TUCITO David Application de commerce électronique Technologies J2EE 1

2 Sommaire Introduction I Gestion du projet 1) Planning ) Répartition des tâches... 5 II Maquette du site 1) La page principale ) La fiche produit ) La page administration... 8 II I- Mise en place technique 1) Le serveur Jboss, les EJB2 et la sécurité ) La base de données MySQL ) Utilisation d'ajax ) Utilisation de subversion ) Utilisation de xdoclet ) Présentation du modèle MVC...14 IV - Développement: niveau EJB 1) Choix d'implantation a) Les entity bean b) Le(s) session bean c) Les interfaces locales d) Les home locales e) Les value objects ) Les relations a) L'exemple de la relation 1-n b) la directionnalité des relations ) les transactions ) les finders EJB-QL ) Les descripteurs XML et la mapping de la base de données a) mappping et configuration de la base de données b) le descripteur ejb-jar.xml et le fichier application.xml...25 c) les descripteurs Jboss-web.xml et Jbosscmp-jdbc.xml

3 V - Développement: niveau Web 1) Utilisateur...26 a) Logo Zone b) Barre d'onglets Zone c) Menu Zone d) Main Zone e) Recherche Zone f) Publicité Zone g) Client Zone h) Caddie Zone ) Administration...31 a) Gestion des produits, magasins, sous-rayons et clients...31 b) Gestion des commandes...32 c) Gestion des mails...32 VI - Mise en service de l'application 1) Packaging et déploiement du serveur ) Validation du service: tests...34 VII Retour sur les technologies utilisées Conclusion

4 Introduction Le but de ce projet est le développement d'une application d'e-commerce utilisant les technologies J2EE. Une relative liberté de conception nous a été laissé afin de pouvoir découvrir nous mêmes de nouveaux outils et technologies en fonction du cahier des charges établit. L'idée de notre application est le développement d'un supermarché en ligne (comme il en existe à Paris par exemple), qui permet à un internaute de faire ses courses conventionnelles depuis chez lui, ainsi la notion de caddie, ou encore de rayon, devient très intuitive lors de la navigation sur le site. Notre application marchande avec des fournisseurs (ou encore «magasins»), qui, à l'image des supermarchés, approvisionnent nos stocks. La gestion des transactions bancaires est également effectuée par l'application (chaque client, chaque magasin, ainsi que le site en lui même, possède un compte bancaire). L'accent a été mis sur la simplicité d'utilisation du site, qui comme nous le verrons fera appel a des technologies particulières, cette volonté passe également par une exploitation maximale des nombreuses possibilités offertes par la J2EE. Spécifications Techniques: J2EE Container: Serveur JBoss GA Edition Base de données: Serveur MySQL 5.0 Authentification sécurisée par certificats SSL Cryptage des mots de passe dans la base de données par l'algorithme SHA-256 Sécurisation des transactions bancaires au niveau EJB Gestion des relations EJB Intégration d'ajax Caractéristiques du site Web: Interface complète d'administration pour ajouter et modifier des rayons/magasins/clients... Bandeau publicitaire avec effets graphiques Possibilité de glisser déposer un produit vers le caddie Possibilité de noter et de commenter chaque produit Gestion d'une Newsletter et d'un service mails Gestion en temps réel des stocks 4

5 I Gestion du projet 1) Planning Le planning est indispensable dans ce type de projet, où le cahier des charges est fourni et le temps limité, nous avons donc dès le début fixé un planning que nous nous sommes efforcé de respecter au cours du développement. Semaine 1 - Mise en place du serveur, du canevas général du site - Documentation sur les différents outils qui pourraient nous intéresser (AJAX, xdoclet, authentification...) - Description des relations et des beans qui vont devoir être développés vis à vis de notre idée. Semaine 2 - Mise en place d'un premier exemple J2EE avec un premier EJB, le but est de faire marcher un exemple simple avec les technologies que nous désirons utiliser. - Poursuite de la documentation. Semaine 3 Développement général des beans d'une part, des servlets et des JSP de l'autre. Des tests unitaires sont faits en parallèle. Semaine 4 Poursuite du travail de la semaine 3 Semaine 5 Derniers débogages, écriture du rapport et préparation de la présentation 2) Répartition des tâches Afin de gagner du temps, la répartition des tâches est cruciale, dès le départ chaque membre de l'équipe doit savoir sur quelles parties du projet il devra travailler mais devra également connaître les objectifs des autres membres de l'équipe, tout en gardant à l'esprit le planning définit. Ainsi nous avons décidé de séparé l'équipe en 2 binômes dont les travaux seraient parallèles à partir de la semaine 2 (la semaine 1 ayant été une phase de réflexion commune): Jean-René et David: Développement des servlets et des JSP (qui inclut notamment l'utilisation de AJAX, de javascript et de CSS). Karim et Nicolas: Mise en place du serveur et de la base de données, développement des beans, des descripteurs de déploiement (utilisant xdoclet), et du packaging. Bien sûr ce travail fut ponctué de réunions où les 2 binômes se réunissaient pour partager leurs avancées sur le projet, que nous synchronisions à chaque nouvelle étape grâce à notre serveur subversion. 5

6 II Maquette du site 1) La page principale Voici un rapide aperçu de la page principale du site web, détaillée dans la partiev 1), on trouve: A gauche: Une zone de recherche (qui peut être étendue en recherche avancée) Une zone pour le parcours des sous rayons d'un rayon, A droite: Une zone client où ce dernier pourra se loguer, modifier ses coordonnées ou encore retrouver un mot de passe perdu. Le caddie contenant les articles avec une image miniature et la quantité sélectionnée. En haut: une barre d'onglets pour sélectionner les rayons du magasin 6

7 2) La fiche produit On y trouve: Le nom du produit La description du produit Le prix du produit La note donnée par les clients (possibilité de notez en cliquant sur les étoiles) Les commentaires laissés par les utilisateurs (possibilité de laisser un commentaire grâce à un cadre déroulant) 7

8 3) La zone d'administration Accessible par mot de passe (crypté dans la base de données), elle permet à l'administrateur une gestion complète de son site, les différentes parties sont interchangeable à souhait (pour plus de détails, voir la partie V 2) ) On y trouve différentes zones: La zone produits La zone magasins La zone rayons La zone clients La zone commandes La zone mails/newsletter Chaque zone permet un contrôle intégrale, par exemple la zone produits permet d'ajouter un produit, de supprimer un produit ou encore de modifier un produit déjà existant, tous les attributs sont accessibles à l'administrateur. Cette fenêtre utilise largement AJAX comme nous le verrons dans la partie V, on peut également diffuser la newsletter aux utilisateurs, ou encore envoyer un mail à un utilisateur en particulier. 8

9 III - Mise en place technique 1) Le serveur Jboss et les EJB2 Lors des séances de Travaux Pratiques, le serveur utilisé pour supporter les composants J2EE était un serveur JONAS dont le container gérait les EJB version 2.0. Lors de nos recherches nous avons découvert un autre serveur, qui semble bien plus utilisé que JONAS, il s'agit de JBOSS, serveur réputé pour sa robustesse, qui présente l'avantage d'être l'un des rares containers supportant la dernière version des EJB (version 3.0). De plus, une quantité impressionnante de plug-in et de documentation existe pour agrémenter l'environnement de développement d'un serveur JBOSS. Nous avons donc choisi de l'utilisé, mais cependant nous avons préférer rester dans les EJB 2.0 car les versions des serveurs et des outils qui gèrent les EJB 3.0 sont encore au stade «Beta» ce qui nous semble gênant pour une application qui se doit avant tout d'être fiable. Cependant le fait d'utiliser JBOSS permettra à notre application d'évoluer assez facilement vers les EJB 3.0 lorsque leur utilisation s'avèrera utile. L'environnement de travail JBOSS: Dans un premier temps, nous avions pensé utiliser Netbean, l'environnement de développement gratuit de Sun. Ce logiciel, très puissant, nous a cependant déçu de part un aspect qui peut surprendre: en effet Netbean automatise un grand nombre de tâches, comme la génération systématique des fichiers.xml ou encore la gestion quasi opaque du serveur, ce qui nous a dérangé car nous préférions maitriser tous les aspects du développement (dont les fichiers.xml sont une clef). Nous nous sommes alors retournés vers Eclipse, pour lequel nous nous sommes déjà familiarisés lors de précédents projets. Une version spéciale de Eclipse, dédiée à JBOSS, est particulièrement efficace et inclut des plugins qui nous le verrons par la suite nous ont été d'un grand secours. (inclus notamment la gestion de xdoclet et du packaging) Cet IDE est disponible à l'adresse suivante: La sécurité: authentification par certificats SSL Soucieux de sécuriser l'accès à notre application, à la fois pour rassurer nos clients, mais aussi pour nous mêmes, nous avons configuré le server tomcat qu'inclut Jboss afin d'effectuer des communications dites tunnelisées grâces au protocole SSL, basé sur des certificats d'authentification. Cet accès se fait donc par https, sur le port standard Nous n'avons bien évidemment pas pu faire valider le certificat du serveur, puisque cela coute autour de 500 euros par an! Cela a simplement pour conséquence d'avertir l'utilisateur que le certificat ne provient pas d'un site de confiance... Nous avons également relevé que SSL est à ce jour la méthode qui propose le meilleur compromis entre haute sécurité et facilité d'utilisation pour l'internaute. D'autres méthodes, comme le httpacces, simples à mettre en œuvre, propose une sécurité d'un niveau beaucoup plus faible. 9

10 2) La base de données MySQL La base de données fait partie du socle d'une application J2EE, elle doit être robuste et fiable. La plupart des containers, comme JONAS ou JBOSS, propose des bases de données intégrées, qui sont simples d'utilisation mais aussi limitées (elles sont surtout utile pout les phases de tests). Nous nous somme alors tourné vers un standard des bases de données: MySQL, dans sa version 5.0, à laquelle notre serveur JBOSS sera connecté. Nous avons utilisé la dernière version du serveur MySQL, la 5.0 disponible ici: Une fois installé, il suffit de créer une base de données via l'invite de commande (avec la commande sql «CREATE DATABASE nom_de_la_db). Pour la suite nous prendrons «J2EE_db» comme nom de notre base. Il nous a fallu ensuite adapter JBOSS, notamment modifier sa configuration, et lui ajouter le driver de MySQL. Le driver est disponible ici: et doit être placé dans \server\default\lib. Ensuite, le fichier \server\default\conf\standardjbosscmp-jdbc.xml doit être modifié ainsi: <defaults> <datasource>java:/avotreserviceds</datasource> <datasource-mapping>mysql</datasource-mapping> Et le fichier \server\default\deploy\mysql-ds.xml doit être modifié ainsi: <!--<local-tx-datasource> <jndi-name>avotreserviceds</jndi-name> <connection-url>jdbc:mysql://gorguda.myftp.org:3306/j2ee_db</connectionurl> <jndi-name> peut être choisi au hasard, du moment que les fichiers xml que nous verrons plus tard prennent en compte le même nom. <connection-url> correspond à l'adresse de la base de donnée que nous avons crée Nous avons procédé à un test qui nous a semblé intéressant de relever: nous avons configurer la base de données en «remote» et l'avons placé sur une machine différente de celle qui héberge le serveur JBOSS, nous avons alors observé une très nette baisse de performances (que nous avions prévu, mais pas à ce point) lors des accès à la base de données, nous avons donc abandonné l'idée de répartir les services sur des machines différentes pour finalement les placer sur une seule machine afin de n'avoir que des accès locaux. 10

11 L'accès et la gestion de notre base de données: Afin d'accéder et de modifier facilement à notre base de données, nous avons utilisé SQLyog, un logiciel multi-plateformes gratuit largement utilisé par les développeurs, disponible à l'adresse suivante: Il permet notamment la création très rapide de tables et d'entrées dans la base de données, ou encore de le test de requêtes SQL, et nous à été d'un grand secours lors de la phase de test, pour notamment voir si le mapping et les modifications s'effectuaient correctement. 3) Utilisation d'ajax AJAX est un acronyme anglais signifiant Asynchronous JAvascript and XML (Javascript et XML asynchrones). Il s'agit d'employer l'objet XMLHttpRequest() pour communiquer avec le serveur. L'objet permet d'échanger des informations sous différents formats (dont XML, HTML ou texte), mais son principal attrait est sa nature «asynchrone» : tout cela peut se faire sans recharger la page. C'est ce qui permet de mettre à jour certaines parties d'une page sur base d'évènements déclenchés par l'utilisateur. Notre intérêt pour les nouvelles technologies et notre recherche d ergonomie, d originalité, d efficacité et d esthétisme nous ont menés à utiliser AJAX. L intérêt d AJAX est qu il permet de rapprocher une application web d une application classique, l application ne réagissant plus qu à un nombre très limités d événements comme le click de souris mais à des événements plus complexes comme la pression d une touche ou le survol d un élément. Nous avons utilisé les librairies prototype.js et scritaculous.js disponibles sur internet aux adresses suivantes : et La librairie prototype.js présente des fonctions basiques d AJAX tel que la recharge d un unique élément de la page web. Nous avons utilisé cette fonction au maximum afin de n avoir à actualiser que les éléments qui présentaient des modifications. - La fonction Ajax.Updater(conteneur,url,options) permet de mettre à jour uniquement le conteneur sans avoir une actualisation de toute la page, évitant ainsi un désagréable effet «flash» à l utilisateur. - La fonction Ajax.PeridicalUpdater(conteneur,url,options) recharge le conteneur de la même manière que la fonction précédente mais le fait de manière périodique. La librairie scriptaculous.js offre des fonctions beaucoup plus graphiques: - Drag and drop : permet de définir des éléments «glissables» et des conteneurs «déposables» pour y placer les éléments «glissables». Plusieurs options sont disponibles : les conteneurs ne peuvent accepter qu une classe d éléments, peuvent changer de style au survol, les éléments peuvent revenir à leur place - Autocomplétion : permet d afficher une liste d éléments envoyée par le serveur au fur et à mesure de la frappe d une recherche. - Effets visuels : permet d animer un conteneur avec des transitions : clignotement, 11

12 défilement, agrandissement, apparition, disparition. 4) Utilisation de subversion Dans tout projet impliquant une équipe, l'utilisation d'un logiciel de gestion des ressources partagées est indispensable. C'est pourquoi l'une des premières étapes du projet a été de mettre en place un serveur Subversion pour l'équipe. Subversion est un logiciel récent, qui rend aujourd'hui obsolète le célèbre CVS. Sa mise en place a pris du temps puisqu'il s'agissait là pour nous d'une nouvelle technologie. Voici les étapes que nous avons suivies: 1) Mise en place d'un serveur Apache 2) Installation de «svn» (le support de subversion) pour chaque membre 3) Création d'un «repository»: un dépôt central utilisé par toute l'équipe sur le serveur Apache 4) Configuration du serveur Apache (notamment l'ajout des modules permettant la gestion de svn, et la prise en charge du repository commun) 5) Configuration de nos environnements de travail: - Installation du plugin svn pour Eclipse: Subclipse ( ) - Création chez chacun d'un d'entre nous d'un dépôt local Subversion aura été un élément catalyseur du développement puisqu'il a permit à l'ensemble de l'équipe de travailler sur les mêmes sources et ainsi éviter de sans cesse de s'échanger des fichiers inutiles et se perdre dans les versions dont chacun disposait. 5) Utilisation de xdoclet Xdoclet est un logiciel de génération de code, inclut dans la version «Jboss» de l'ide Eclipse, qui va notamment nous servir à générer des fichiers XML grâce à des tags placés dans les fichiers sources (à l'image des tags Javadoc). Xdoclet se configure pour un projet: on ajoute des «tâches» xdoclet, par exemple on peut spécifier une tâche permettant de générer des interfaces correspondant à chaque EJB, qui se réfèrera alors aux tags dédiés. Xdoclet se chargera notamment, grâce aux tags, de générer les fichiers XML de déploiement, ce qui nous libère de la pénible vérification de la conformité des fichiers xml (par exemple xdoclet se charge d'imbriquer les balises sans que l'on ait à spécifier un ordre quelconque: ainsi xdoclet ne se contente pas d'une simple analyse, mais relève également les erreurs dans nos tags et gère seul la bonne imbrication des balises). Site officiel: 12

13 6) Présentation du modèle MVC Une architecture MVC cherche à séparer trois choses : le Modèle, les Vues et les Contrôleurs. Les contrôleurs permettent de répondre aux actions de l'utilisateur. Chaque contrôle est associé à une vue : cette dernière permet de présenter l'information retournée à l'utilisateur. Bien entendu, l'information renvoyée est dépendante des actions d'entrées de l'utilisateur (capturées par les contrôleurs, nous venons de le dire). Les liens (les traitements) sont réalisés par le modèle (la logique métier). Si nous cherchons à mettre en œuvre une architecture MVC via un environnement J2EE, on peut donc faire les rapprochements suivants : Un contrôleur est implémenté sous forme de servlet Java. Le modèle consiste en l'implémentation de la logique métier du site Web. Chaque vue est implémentée via une servlet. Dans la pratique, on peut reprocher une chose au modèle MVC sous environnement J2EE : il est nécessaire de coder un grand nombre de servlets Java pour réceptionner les requêtes clientes. Mais il permet cependant une visibilité et une clarté dont on se passerait difficilement. 13

14 IV - Développement: niveau EJB 1) Choix d'implantation La technologie J2EE repose sur la notion de Bean, implémenté sous forme de classes Java, ces objets particuliers, gérés par le container et stockés dans la base de données, sont de 2 types: les entity Bean (persistants) et les Session beans (relatifs au contexte de l'utilisateur). Le premier choix d'implémentation consistait à choisir comment la persistance des beans allait être gérée: CMP (Container Managed Persistence) ou BMP (Bean Managed Persistence). Le mode BMP permet le contrôle total des beans, mais se révèle très lourd d'utilisation, nous avons donc opté pour l'utilisation du mode CMP, bien plus facile à utiliser (notamment la gestion de la base de données est entièrement effectué par le container) et ne présentant aucun inconvénient vis à vis de notre application. a) Les entity bean Voici la liste des bean qui constituent la structure du site : En rouge : les primary key accountbean : correspond à un compte bancaire Attributs : Integer id La clé primaire. C'est l'identifiant du compte bancaire String owner Le nom du propriétaire du compte Double balance Le solde du compte Méthodes disponibles (en dehors des getters et setters) void credit(double balance) Drédite le compte void retail(double balance) Débite le compte 14

15 storebean : correspond à un magasin, qui fournira notre site Attributs Integer id La clé primaire. C'est l'identifiant du magasin String name Le nom du magasin String adress L'adresse du magasin String L' du magasin String phone Le numéro de téléphone du magasin clientbean : correspond à un utilisateur enregistré sur le site Attributs String login La clé primaire. C'est le login de l'utilisateur String pwd Le mot de passe de l'utilisateur String name Le nom de l'utilisateur String firstname Le prénom de l'utilisateur String adress L'adresse de l'utilisateur String phone Le numéro de téléphone de l'utilisateur String L' de l'utilisateur Boolean newsletter Indique si l'utilisateur est abonné à la newsletter ou non String title La qualité de l'utilisateur categorybean : correspond à un sous-rayon Attributs Integer id La clé primaire. C'est l'identifiant du sous-rayon String name Le nom du sous-rayon String parentcategory Le nom du rayon auquel il appartient 15

16 productbean : correspond à un produit Attributs Integer id La clé primaire. C'est l'identifiant du produit String name Le nom du produit String picture L'url de la photo du produit String description La description du produit Double price Le prix du produit Integer stockleft Le stock restant disponible pour ce produit Double mark La note du produit, déterminée par les internautes Integer voternumber Le nombre d'internautes ayant voté pour ce produit adminbean : correspond à un administrateur du site Attributs Integer id La clé primaire. Correspond à l'identifiant de l'administrateur String pwd Le mot de passe de l'administrateur Méthodes disponibles (en dehors des getters et setters) void computeallproducts() Crée un vecteur de tous les produits disponibles en base de données productlocal getrandomproduct() Revoie un produit au hasard parmi le vecteur des produits Vector<categoryLocal> getcategoriesbyparent(string parentcategory) Renvoie la liste des sous-rayon du rayon dont le nom est passé en paramètre 16

17 orderbean : correspond à une liste de courses Attributs Integer number La clé primaire. C'est le numéro de la commande Date date Date de la commande String state L'état de la commande Pour chaque clé primaire, en dehors de celle de l'ejb clientbean, on assigne une propriété d'autoincrémentation, ce qui nous permet de ne pas la gérer, spécialement quand un crée un EJB. b) Le(s) session bean Nous avons utilisé un session bean, caddiebean, pour représenter le caddie. Ce session bean est en stateful, c'est-à-dire qu'il peut avoir plusieurs états possibles. Attributs HashMap productlist Représente la liste des produits du caddie, accompagné de la quantité choisie Double total Prix total du caddie Méthodes disponibles (en dehors des getters et setters) void addproduct(productlocal p, Integer quantity) Ajoute un produit et la quantité choisie au caddie void removeproduct(productlocal p, Integer quantity) Retire la quantité passée de produits passés en paramètre du caddie, si il en dispose de la quantité supérieure au paramètre void clearcaddie() Efface le contenu du caddie c) Les interfaces locales Les interfaces locales, générées par xdoclet, représentent les EJB dans le code de la servlet. Ce sont les objets JAVA qu'on récupère grâce aux home locales. Chaque méthode métier décrit dans les EJB possédant le view-type="local" sont disponibles par cette interface. 17

18 d) Les home locales Les home locales, générées elles aussi par xdoclet, représentent la table de la base de données associée à un EJB. La méthode create y est présente, qui représente la méthode ejbcreate et ejbpostcreate des EJB. On y retrouve également tous les finders : celui défini automatiquement, qui renvoie un EJB grâce à sa clé primaire, ainsi que ceux définis par xdoclet grâce au signature="" query="" dans les entêtes des classes des EJB. e) Les value objects Le value object (ou encore 'javabean') occupe une place importante dans le respect du modèle MVC et de l'architecture J2EE: Puisque nous n'avons pas de référence directe à un objet persistent (un EJB), comment allons-nous lire le contenu de cet objet? Cette limitation à une solution très simple, et qui ajoute même de nombreuses possibilités d'amélioration: Le Value Object, qui n'est autre qu'un objet qui offre une vue figée de notre entité à un moment donné. Ainsi tous nos entity beans possède un valueobject (généré par xdoclet grâce au tag de name = "category" match = "*" Un Value Object possède un constructeur reprenant la méthode ejbcreate du Bean correspondant, ce qui permet dans une servlet de construire un valueobject à partir d'un bean local récupéré par la home. Les valueobject possèdent l'avantage considérable de pouvoir être passé directement en paramètre d'une page JSP: ainsi les pages JSP utilisent le tag 'usebean' pour récupérer ces ValueObjects 18

19 2) Les relations Les relations constituent une élément clef des EJB, elles permettent de définir au sein de la base de données des relations entre les beans qui y sont enregistrés. Ces relations ont été définies dès la conception du projet et font partie intégrante de la structure de la base de données. Les relations sont de 3 grands types: 1-n, n-m et 1-1, et chacune de divise en 2 sous-types: unidirectionelles et bidirectionelle. Voici un schéma symbolisant les différentes relations entre EJB 19

20 a) L'exemple de la relation 1-n La relation 1-n ( One to Many ), est la plus fréquente, nous allons ici présenter la facon dont elle a été implémentée, grâce aux tags xdoclet. Prenons l'exemple de la relation entre les produits et le magasin qui les propose: il s'agit de la relation [produit 1 n store] : Un magasin connait n produits qui chacun connaissent leur magasin. Cette relation, dite CMR (Container-Managed Relationships), va être définie par un getter et un setter, à l'instar d'un CMP field (Container-Managed Persistence) classique. Dans l'ejb productbean.on trouve: /** * Getter for CMR Relationship * view-type="local" name = "product-to-store" * role-name = "product-has-one-store" * target-multiple = "yes" * target-ejb = "store" * target-role-name = "store-has-many-product" fk-column = "storeid" related-pk-field = "id" */ public abstract avotreservice.interfaces.storelocal getstore(); C'est ici le qui nous intéresse: On donne un nom à la relation On nomme le rôle de la relation, qui servira dans l'autre bean concerné par la relationship On déclare que se beans est un coté many de la relation ( target-mutliple=yes ) On définit l'autre EJB de la relationship On déclare le nom du rôle de la relation dans l'autre bean Enfin le permet de définir la colonne qui servira à référencer du coté des produits ( many ) la colonne des ID des magasins et le CMP field qui sert à remplir cette colonne. Le container JBOSS se contente de ces informations pour gérer la relation. 20

21 Dans l'ejb storebean.on trouve: /** * Getter for CMR Relationship * view-type="local" name = "product-to-store" * role-name = "store-has-many-products" * target-multiple = "no" * target-ejb = "product" * target-role-name = "product-has-one-store" */ public abstract Collection getproducts(); On comprend grâce à ce second coté de la relation comment celle-ci est interprétée: On retrouve productbean comme EJB cible On retrouve product-has-one-store comme rôle cible dans l'ejb productbean.java Ici, la propriété target-multiple est bien à no puisque l'on est du coté 1 de la relation. <?xml version="1.0" encoding="utf-8"?> <!-- $Id: mysql-ds.xml,v /12/01 11:36:28 schrouf Exp $ --> <!-- Datasource config for MySQL using available from: --> <datasources> <local-tx-datasource> <jndi-name>avotreserviceds</jndi-name> <connection-url>jdbc:mysql://gorguda.myftp.org:3306/j2ee_db</connection-url> <driver-class>com.mysql.jdbc.driver</driver-class> <user-name>root</user-name> <password>root</password> <exception-sorter-classname>org.jboss.resource.adapter.jdbc.vendor.mysqlexceptionsorter</exception-sorter-classname> </local-tx-datasource> </datasources> 21

22 b) la directionnalité des relations Une transaction se définit également par sa directionnalité, qui définit si la relation est visible des deux ou de un seul de ses cotés. Ainsi une relation bidirectionnelle permettra aux 2 cotés d'être liés, tandis qu'une relation unidirectionnelle n'assurera le maintien et la visibilité de la relation que d'un seul coté. Dans l'exemple précédent, la relation était bidirectionnelle, pour cela, il suffit d'utiliser des deux cotés de la relation le le container interprète alors la relation comme bidirectionnelle. Prenons un autre cas, la relation [admin n 1 category], elle est unidirectionnelle: l'admin doit connaître la liste des rayons, mais les rayons n'ont pas à connaître l'admin. Nous avons alors utilisé le uniquement dans le bean categorybean. 3) les transactions Les transactions sont un élément de sécurité (cohérence) essentiel pour une base de données. Dès l'instant où l'on doit gérer la persistance dans un contexte J2EE, dans un conteneur EJB, il faut se pencher sur les paramétrages ou sur le code de gestion des transactions. Le conteneur de JBOSS est responsable de la démarcation transactionnelle. La façon dont le conteneur gère la transaction pour une méthode de l'ejb est paramétrée dans les " attributs de transaction ". Laisser le conteneur gérer les transactions permet de spécifier le comportement transactionnel d'un bean entreprise sans réécrire de code, mais aussi de changer le comportement d'une application en adaptant finement le comportement des beans entreprise. Le conteneur gère automatiquement la démarcation transactionnelle à l'exécution d'une méthode selon ces attributs transactionnels. Ici nous avons définit des transactions pour les opérations critiques, c'est-à-dire celles dont la réversibilité est nécessaire, en particulier la phase d'achat. Xdoclet propose des tags permettant la définition des transactions. Prenons l'exemple de la méthode credit dans l'ejb accountbean: /** view-type="local" * Credite le compte view-type="local" type = "Required" balance somme à créditer */ public void credit(java.lang.double balance) { setbalance(getbalance() + balance); } 22

23 Le tag qui nous intéresse ici = Required : Il indique que l EJB adhère à la transaction de l appelant et que si aucune transaction n existe, il crée la sienne. D'autre valeurs existent, notamment RequiresNew qui indique que l EJB crée systèmatiquement sa propre transaction. Ce tag indique le comportement de la méthode, mais pas la façon dont le Bean va traiter les transactions, ainsi en tête de la classe on place le tag suivant: name= transaction-type="container" Ce tag indique que c'est le container JBOSS qui se charge de la gestion des transactions. En effet une transaction n'a que deux issues possibles: un 'commit' (réussite) ou un rollback (échec), en fonction de cette issue, le container se chargera de valider ou d'annuler la transaction, ceci soulage évidemment considérablement notre travail 4) les finders EJB-QL Les finders constituent une brique de la plateforme J2EE, il s'agit de méthodes java permettant un accès directe à la base de données grâce à une requête EJB-QL (Entreprise Java Beans Query Language), un langage dérivé de la norme SQL. Par défaut, chaque bean possède un finder sur la clef ( primary key ) qui permet donc de récupérer directement un bean local si l'on connait sa clef, ce finder, très utile, n'est cependant pas suffisant. Nous avons du développer nos propres finders afin de réaliser certaines fonctions. Prenons l'exemple de la recherche avancée, qui permet de rechercher des produits sur la base de données en fonction de paramètres fournit par l'utilisateur. Xdoclet va là encore nous être d'une grande aide, puisque grâce à des tags de classes, il se chargera de générer le finder dans la home locale qui correspond au bean. Voici le tag de classe correspondant à ce finder que l'on trouve dans productbean: *@ejb.finder signature="java.util.collection findproducts(java.lang.string name, java.lang.string trademark, java.lang.string parentcategory, java.lang.double price1, java.lang.double price2)" * query="select Object(p) from product p WHERE p.name LIKE?1 AND p.trademark LIKE?2 AND p.price BETWEEN?4 AND?5 AND p.category.parentcategory LIKE?3" On indique la signature du finder, qui en l'occurrence renvoie une collection de Beans (les produits correspondant à la recherche avancée) et prend en paramètre les différents critères de la recherche avancée. On indique ensuite la requête EJB-QL en elle même, le langage étant très proche de celui utilisé par MySQL, la requête n'a pas été très difficile à écrire. 23

24 Xdoclet génère alors automatiquement le finder dans AccountLocalHome: public java.util.collection findproducts(java.lang.string name, java.lang.string trademark, java.lang.string parentcategory, java.lang.double price1, java.lang.double price2) Qui s'utilisera simplement sur la home récupéré dans une servlet. Cependant nous retiendrons la pauvreté du langage EJB-QL, qui de plus ne respecte pas toujours la norme SQL: Fonctions majeures manquantes (UPPER et LOWER par exemple) Respect de la casse pour la fonction LIKE, contrairement à SQL (entre autres) Impossible de retourner plusieurs colonnes avec un Select Cependant EJB-QL a été largement modifié dans la nouvelle version d'ejb (la 3.0), une version 2.x comportant ces modifications aurait été la bienvenue, puisque de nombreux développeurs ne sont pas encore près à passer aux EJB3, qui implique de vastes mises à jour et un support pas encore fiable à 100%. 5) Les descripteurs XML et le mapping de la base de données Les liens entre les différentes entités du projet se font grâce au fichiers XML. Voici les différentes fonctions nécessaires pour bien paramétrer le projet : a) mappping et configuration de la base de données Le serveur JBoss doit connaitre la base de données afin d'y accéder. Pour cela, on passe par l'intermédiaire de 2 fichiers : mysql-ds.xml : Ce fichier doit être présent dans le répertoire deploy du serveur. Il contient les informations nécessaires afin de reconnaitre la base de données utilisée, comme l'url de la base, ainsi que l'user et le pass pour s'y connecter. Voici le contenu de ce fichier : standardjbosscmp-jdbc.xml : Ce fichier doit être présent dans le répertoire conf du serveur. Il effectue le mapping de la base grâce au nom jndi, défini dans le fichier précédent, ici avotreserviceds. Voici l'extrait du fichier correspondant : <jbosscmp-jdbc> <defaults> <!--<datasource>java:/gorgudads</datasource>--> <datasource>java:/avotreserviceds</datasource> <datasource-mapping>mysql</datasource-mapping> 24

25 b) les descripteurs ejb-jar.xml, web.xml et application.xml Le projet se divise en 2 modules : ejb et web. Le module EJB, comme son nom l'indique, pour les EJB, et le module web, pour les servlets et les pages web. Chaque module dispose d'un descripteur. A ceux-ci s'ajoute un dernier descripteur qui regroupe ces fichiers. Ces descripteurs sont indépendants du serveur utilisés. Le fichier ejb-jar.xml décrit tout ce qui concerne les EJB : leur nom jndi, leur interface locale, leur home, leur relations... C'est ce fichier qui va être utilisé pour le déploiement des EJB, et qui va servir d'aiguillage lors de leur utilisation. Le fichier web.xml décrit tout ce qui concerne les Servlet : leur propriétés (nom JNDI, description...) et leur mapping (url-pattern). C'est ce fichier qui va être utilisé pour le déploiement des Servlet, et qui va servir d'aiguillage lors de leur utilisation. Le fichier application.xml décrit les différents modules utilisés dans le projet, ici modules ejb et web. On y retrouve le nom des archives correspondant aux modules, ainsi que la racine du contexte, par laquelle on passe pour accéder au site. c) les descripteurs jboss.xml, jboss-web.xml et jbosscmp-jdbc.xml Ce sont les fichiers utilisés pour raccorder les descripteurs au serveur : jboss.xml pour le module ejb, jboss-web.xml pour le module web. Le fichier jbosscmp-jdbc.xml assure la liaison avec la base de données, notamment avec les informations datasource et datasource-mapping, qui correspondent à ceux du fichier standardjbosscmp-jdbc.xml. 25

26 V - Développement: niveau Web 1) Utilisateur Notre site est découpé en 8 zones : a) Logo Zone 1 Le logo du site est cliquable, il ramène à la page d accueil. b) Barre d'onglets Zone 2 Les onglets ont été dessinés à l aide du logiciel ImageReady d Adobe. Les onglets prennent la couleur du rayon lorsqu ils sont survolés ou cliqués. Nous avons utilisé un système de fenêtre coulissante afin de ne pas avoir de temps de chargement lors de changement de couleur. L image de l onglet contient les deux couleurs, elle donc chargée qu une seule fois et est recadrée au moyen de classe CSS : 26

27 TabDroguerie.gif li#droguerie,.headdroguerieoff{ background: url(./images/tabdroguerie.gif) no-repeat left; } li#droguerie a:hover, li#droguerie a:active, li#droguerie a:focus,.headdroguerie{ background: url(./images/tabdroguerie.gif) no-repeat right; border: none; } La sélection d un onglet recharge les zone 3, 4, 5, 6 avec les couleurs du rayon sélectionné grâce à du javascript. c) Menu Zone 3 Dans la page d accueil, le menu contient la liste des liens vers les rayons, puis la liste des liens vers les sous-rayons lorsqu on est dans un rayon. Lors de la sélection d un rayon, comme pour la barre d onglets, les zones 3, 4, 5 et 6 sont actualisées. d) Main Zone 4 Page principale : Une vidéo en Flash de démonstration de l utilisation du site a été créée. Le choix du format Flash s imposait de lui-même pour éviter des problèmes de compatibilité avec les différents navigateurs. Liste de produits : En fonction du sous-rayon courant, un appel à la servlet MainServlet passe en paramètre à la page main.jsp une liste de produits à afficher. L image est «glissable», elle peut être déposée dans le caddie pour effectuer un achat. La partie textuelle est cliquable, elle mène à la fiche du produit. 27

28 Produits : Lorsqu on passe à MainServlet un identifiant de produit, elle va chercher l EJB du produit correspondant et passe le JavaBean correspondant à la page JSP. L image est ici également «glissable» pour être déposé dans le caddie. Sous l image, l utilisateur peut voir l avis des consommateurs et ajouté le sien si il le désire (note et commentaires). Les cinq étoiles permettent de noter le produit. L activation et la validation des étoiles sont gérées par javascript. La zone de commentaire permet de voir les commentaires des autres consommateurs et de laisser son propre avis. Elle est visible qu après un clique sur le lien «Voir les commentaires», elle est affichée grâce à un effet «slide down» issu de la librairie scripaculous. e) Rechercher Zone 5 Le conteneur Rechercher possède un champ pour la recherche et un lien vers la recherche avancée. Le champ de recherche est autocomplété grâce à la fonction autocomplete de scripaculous qui affiche la liste de produits fournie par la servlet AutocompleteServlet, elle est recalculé à chaque nouvelle frappe et ce à partir de la 2e lettre entrée. Si l utilisateur renseigne le champ recherche avec le nom exact du produit, la fiche produit est directement accessible dans le conteneur «main» tandis que si aucun produit ne correspond au nom 28

29 renseigné une recherche est effectue dans nom, marque et description du produit. Si tout fois l utilisateur veut faire une recherche plus poussée, il en a la possibilité avec le lien vers «Recherche avancée». La rechercher avancée est faite à l aide d un «finder» défini dans l EJB productbean.java. Une vérification sur la validité des prix minimum est maximum est faite ; un indicateur «Prix non valide» s affiche le cas échéant. f) Publicité Zone 6 Afin d attiser le client, une bannière a été ajouté. Les produits de cette bannière sont choisis au hasard parmi la liste des produits. Un effet de la bibliothèque des effets visuels de scriptaculous est choisi également au hasard. L effet visuel permet d attirer l attention de l utilisateur. De plus, cette bannière est rafraîchie toutes les 10 secondes par la fonction PeriodicalUpdater fourni par la librairie prototype.js. g) Client Zone 7 Cette fenêtre permet au client de s identifier, ce qui est nécessaire pour faire une commande ou poster des commentaires. Lorsque le client s identifie, seule cette zone est rechargée. S il n est pas encore identifié sur notre site, il peut le faire en cliquant sur le lien Nouveau client qui affiche un formulaire d inscription dans la zone 3. Un contrôle sur le login est opéré afin d assurer l unicité du login. De plus, on vérifie que tous les champs ont été remplis. Le mot de passe est crypté avant d être stocké dans la base de données grâce à la méthode de hachage SHA-256. Si l utilisateur a perdu son mot de passe, un lien Mot de passe oublié lui permet de remplir son login et son adresse mail. Un mail lui est alors envoyé avec un mot de passe généré. Une fois identifié, l utilisateur peut modifier ses coordonnées ou se delogger. 29

30 h) Caddie Zone 8 Le caddie est zone «déposable» au sens de la librairie scriptaculous, on peut y déposer les images des produits provenant de la zone 3. Les images des produits sont affichées en miniature, les noms des produits sont tronqués et la quantité est affichée entre parenthèses. Les images sont «glissables» afin de pouvoir les supprimer, en les déposant dans les rayons, c est-à-dire la zone 3. Le bouton Valider permet d afficher un récapitulatif du caddie dans le main : Les boutons -, + et x permettent respectivement de réduire la quantité d une unité, d augmenter la quantité d une unité et de supprimer complètement le produit du caddie. Un indicateur renseigne le client sur la disponibilité du produit. Le clique sur l un de ces boutons n entraîne le chargement que de cette zone et du caddie. Le bouton Valider confirme la commande. Si le client ne possède pas les fonds nécessaire à l achat du caddie, la transaction est annulée et un message lui est adressé. Si la commande est effective, le client reçoit un mail de récapitulatif de sa commande. 30

31 2) Administration La page d administration contient 6 zones «glissables» et «déposables», ce qui permet à l administrateur d organiser sa page comme il le souhaite : a) Gestion des produits, magasins, sous-rayons et clients L administrateur a la possibilité d ajouter, de modifier ou de supprimer un produit, un magasin, un sous-rayon ou un client. Chacun des champs de recherche est autocomplété à l aide de la fonction Autocomplete de la librairie scriptaculous et de la servlet AutocompleteServlet. Si le nom recherché existe déjà dans la base de données, alors on modifie cet EJB, sinon on en créer un nouveau. 31

32 b) Gestion des commandes L administrateur peut accéder à l historique des commandes effectuées par chaque client afin de remédier d éventuels litiges ou réclamations. Les commandes sont classées par client puis par date. c) Gestion des mails L administrateur peut par l intermédiaire de l interface envoyer un mail à un utilisateur précis ou à l ensemble des utilisateurs inscrits à la newsletter pour leur faire part des nouveautés ou des promotions du site. 32

33 VI - Mise en service de l'application 1) Packaging et déploiement du serveur La version JBOSS de l'ide Eclipse inclue un excellent gestionnaire de packaging qui permet de générer le xml de déploiement à partir d'une interface graphique, et de l'exécuter d'un simple clic. Voici à quoi ressemble notre configuration de déploiement: On décrit le contenu de chaque package de déploiement, avec leurs descripteurs et fichiers respectifs. Il nous suffit alors (sous Eclipse ou manuellement), de déployer le fichier avotreserviceapp.ear pour que JBOSS effectue automatiquement le déploiement du contenu du package. 33

34 2) Validation du service: tests Les tests constituent une tâche longue et indispensable pour tout projet qui se veut fiable et solide. Tout au long du développement, de nombreux tests ont été effectués afin de valider les différents étapes. Certains de ces tests nous ont semblé particulièrement importants, dans la mesure où nous nous devions de les refaire régulièrement au fur et à mesure de l'avancement, c'est pourquoi nous avons crée un ensemble de servlets/jsp uniquement dédiés aux tests, dans celles ci on trouve notamment des tests pour: La création d'entrées dans la base de données, et leur récupération La validité des relations CMR La validité des transactions L'envoi d' s Les finders EJB-QL Ce n'est qu'une fois tous ces tests majeurs validés que l'on peut passer à une phase plus précise du débogage qui consiste à utiliser l'application dans un maximum de cas envisageables et de vérifier que les résultats sont ceux attendus (que ce soit dans le navigateur ou dans la base de données). Ces tests nous permettent aussi de démontrer au client que nous utilisons des technologies fonctionnelles sur lesquelles il pourra compter. 34

35 VII Retour sur les technologies utilisées Voici notre bilan sur les technologies nous avons été confrontées et décrites dans ce rapport: Niveau Développement: Technologie Les + Les - Problèmes rencontrés Eclipse Solide, facile à utiliser, flexible - - Subversion Efficace, s'adapte à tous les environnements Utilisation parfois déroutante Un certain temps pour s'adapter au service Niveau EJB Technologie Les + Les - Problèmes rencontrés Jboss Solide, bien documenté, compatible EJB Difficile à mettre en place, ce qui venait probablement du fait que nous n'étions pas familiarisés avec JBoss MySQL Fiable, très bien documentée, aucun problème rencontré. - La connexion avec Jboss n'était pas des plus faciles, mais une fois effectuée et comprise, nous avons pu la refaire facilement. Xdoclet (Générateur de code) Excellent logiciel, gain Il est parfois difficile de temps énorme sur la de trouver le tag qui génération des XML, correspond à ce que documentation très l'on souhaite tellement fournie: les possibilités il en existe sont impressionnantes. Bien souvent, on rencontre des problèmes qui sont indirectement liés à xdoclet, comme la bonne configuration des tags pour les transactions. Packaging Configurator Très pratique, clair et maniable. - - EJB-relations Une fois la démarche comprises, les relations sont faciles à mettre en place. - Difficiles à mettre en œuvre: il faut à la fois configurer Jboss et la base de données. 35

36 EJB-transactions Possibilités de laisser le container gérer les relations définies - Difficile à tester EJB-finders Très pratiques. Faciles à définir Ne respecte pas complètement SQL. Certaines fonctions importantes manquantes Difficultés liés au problèmes cités précédemment (on supposait que EJB QL respectait SQL...) SQLyog (Gestionnaire de base de données SQL) Excellent logiciel, très pratique, intuitif et léger à la fois Possibilité de sauvegarder les tables et de tester des requêtes L'interface n'est pas toujours très claire - Niveau Web Technologie Les + Les - Ajax Rapprochement vers une application classique. Librairie disponible en ligne fournissant un grand nombre de possibilités. CSS Mise en forme avancée Laborieux et fastidieux - Javascript Modification facile du contenu web d'une page Debbogage ardu - Flash Compatibilité avec tous les navigateurs. Taille et qualité Problèmes rencontrés Impossibilité d'utiliser Problèmes inhérents au le bouton page javascript. précédente. Le javascript doit être activé.

37 Conclusion Ce projet est de loin celui qui nous aura demandé le plus de temps et d'investissement, mais cela est lié au fait qu'il s'agissait ici d'un sujet réellement passionnant, puisque nous nous retrouvions dans la situation d'une équipe d'ingénieurs, avec un cahier des charges, une dead-line, et un planning. Le fait de développer une application fonctionnelle, basée sur des technologies web récentes est quelque chose de vraiment motivant, il nous a fallu améliorer nos techniques de documentation, prendre le temps pour les décisions importantes et bien sur tout faire pour favoriser le travail d'équipe et donc notre efficacité. La découverte de nouveaux outils et de nouvelles technologies au delà des limites du cours fut une épreuve que nous avons passée avec plaisir. Par exemple l'utilisation et la découverte d'ajax et de xdoclet nous a enthousiasmé au point que nous ne cessions d'améliorer l'utilisation de ces nouvelles technologies. Seuls quelques éléments nous ont troublé voir déçu (on citera par exemple EJB-QL, qui dans sa version 2.0 est de notre point de vue calamiteux, ou encore le langage CSS, pénible, dont nous nous serions bien passé si une alternative efficace existait). Ce projet est en fait la synthèse de nombreux domaines dans lesquels un ingénieur doit évoluer: le développement, l'autonomie (recherche d'informations par exemple), le travail en équipe, la performance. Nous sommes conscients que les technologies J2EE représentent un large espace de travail, et il est rassurant pour nous d'avoir développé un projet complet s'appuyant sur cette plateforme dont l'avenir est certain. Nous sommes également conscients qu'il nous reste encore beaucoup à apprendre, même si nous sommes désormais plus confiant vis à vis de nos connaissances. Le cahier des charges est finalement atteint, mêmes si certaines fonctionnalités gadgets n'ont pas pu être implémentées sur le site, faute de temps (par exemple les EJB incluent la gestion de listes de courses que le client pourrait repasser automatiquement sans repasser dans les rayons, il ne reste plus qu'à implémenter cela dans les servlets et JSP concernées, ce qui est tout à fait faisable dans ce genre d'application, à la fois évolutive et facilement modulable). Enfin, nous avons éprouvé du plaisir de travailler ensemble, chacun s'étant impliqué dans ce projet. Le travail en équipe, lorsqu il est efficace, permet de pousser un groupe vers le haut, et au final, chacun retrouve dans l'application une partie de son travail, ce qui constitue la satisfaction du travail accompli. 37