Objectif

Java Enterprise Edition, ou Java EE, est une spécification pour la technique Java d'Oracle plus particulièrement destinée aux applications d'entreprise. Ces applications sont considérées dans une approche multi-niveaux. Dans ce but, toute implémentation de cette spécification contient un ensemble d'extensions au framework Java standard (JSE, Java Standard Edition) afin de faciliter notamment la création d'applications réparties.

Les EJB (Entreprise Java Bean) sont un des éléments très importants de la plateforme Java EE pour le développement d'applications distribuées. La plateforme Java EE propose de mettre en œuvre les couches métiers et persistance avec les EJB. Une des principales caractéristiques des EJB est de permettre aux développeurs de se concentrer sur les traitements orientés métiers car les EJB et l'environnement dans lesquels ils s'exécutent prennent en charge un certain nombre de traitements tels que la gestion des transactions, la persistance des données, la sécurité, ...

L'objectif principal des TPs d'EJB est donc de construire un projet mettant en œuvre chacune des notions évoquées précédemment et ainsi comprendre le fonctionnement, l'interaction et le développement de chaque composant constituant une application JEE.

Pour faire le lien avec les TPs dédiés à la partie Web Profile vu avec Mr Piedeloup, le sujet du projet d'EJB sera le même, à savoir, construire une application bancaire. Les EJB étant dédiés à la partie métier d'une application, l'idée est donc de transformer vos « Beans » métiers de votre projet Web en un projet EJB.

La partie suivante présente le cahier des charges de l'application tel qu'un client pourrait vous le formuler avec son lot de contraintes qu'il faudra impérativement respecter pour que l'application fonctionne dans son système d'information.

Cahier des charges

I. Contexte

Un de vos clients a fait appel à deux prestataires pour opérer la transformation digitale de sa banque et ainsi proposer une plateforme de gestion entièrement numérique. L'autre prestataire est en charge de la partie front tandis que vous opérez sur la partie back destinée à la fois aux collaborateurs des différentes agences ainsi qu'aux clients pour la gestion de leurs comptes bancaires. Il a été convenu que les deux plateformes communiqueront par Webservice Rest Json et vous êtes donc en charge de la mise à disposition des différentes API à l'autre prestataire.

II. Fonctionnalités

Consultation

L'espace de consultation sera utilisé par les clients et les collaborateurs de la banque pour consulter l'ensemble des comptes bancaires d'un client. Une première page devra donc afficher l'ensemble des comptes avec les noms et soldes actuels de chaque compte. En tant que conseiller vous avez accès à une page supplémentaire (Comptes externes) qui vous liste l'ensemble des comptes qui vous sont rattachés. L'affichage des comptes se matérialisera donc par un tableau contenant :

• Le numéro du compte
• Le type de compte (chèque, épargne)
• Le nom du titulaire (s'il diffère de la personne connectée)
• Le solde du compte

Un compte chèque est un compte où le taux d'intérêt est à 0 tandis qu'un compte épargne possède un taux > 0.

La sélection d'un compte permet d'afficher par la suite le détail des transactions réalisées sur ce dernier ainsi que le montant des intérêts cumulés de l'année courante. Un tableau récapitulant les transactions sera construit sous cette forme :

• Numéro de la transaction
• La date
• Compte source et destination (avec le nom da personne s'il diffère de la personne connectée)
• Le montant
• Auteur de l'opération
• Le libellé de l'opération

Chaque client est rattaché à un conseiller, les comptes sont par conséquent suivis par un seul conseiller. Chaque conseiller de l'entreprise sera donc en mesure d'accéder à l'ensemble des comptes de ses clients (via la page Comptes externes). Un client quant à lui ne pourra voir que ses propres comptes.

Transactions

Un client sera en mesure de réaliser des transactions entre ses propres comptes tandis que le conseiller pourra réaliser des transactions entre des comptes de plusieurs clients qui lui sont rattachés.

Chaque transaction devra être autorisée en mentionnant le compte source et destinataire avec le montant ainsi que la personne ayant réalisé l'action. Un commentaire optionnel pourra être saisi par l'auteur. Un client ne peut pas effectuer un virement supérieur à 1 000€ sans autorisation de son conseiller. Le virement est donc mis en attente de validation jusqu'à ce que le conseiller du client valide ou non ce dernier. Le client quant à lui voit sa transaction dans l'historique avec le statut en attente de validation.

Chaque compte dispose (en fonction de son type) d'un seuil de découvert. Il est donc primordial que les fonds restants après application de la transaction sur chaque compte (émetteur et récepteur) respectent le montant suffisant pour être appliqué. Dans le cas contraire, la transaction est annulée.

Chaque transaction finalisée devra être historisée dans une table prévue à cet effet. Cette historisation sera visible dans l'espace de consultation du compte. Elle sera par ailleurs utilisée pour calculer les taux d'intérêts de chaque compte. Ayant le solde actuel, les transactions avec les dates, vous êtes en mesure de connaître le solde d'un compte à un instant T.

Taux

Lors de la consultation d'un compte, il sera possible d'accéder au calcul des intérêts. Le calcul des intérêts seront calculés sur la base du solde à cet instant et par rapport au taux du compte. Il n'est pas utile de sauvegarder les taux à chaque date puisque vous êtes en mesure de les recalculer grâce à l'historique des transactions.

Une fois par an, au 1er Janvier de chaque année, les taux seront appliqués à chaque compte. Cette action sera représentée sous la forme d'une transaction provenant d'un compte spécifique d' « id=1 » correspondant au compte de la banque. Il vous suffira de parcourir tous les comptes épargne et de récupérer les intérêts de l'année précédente puis de réaliser un virement entre le compte spécifique de la banque et celui du compte en cours de traitement.

III. Matrice des rôles

Au vu des fonctionnalités et des types de personnes utilisant l'application, le client a recensé deux types de profils :

• Clients :
  • Jean Dupont (administré par Lucas Perrin)
  • Sophie Petit (administré par Lucas Perrin)
  • Christophe Moreau (administré par Vincent Fournier)
• Conseillers :
  • Lucas Perrin
  • Vincent Fournier

Chaque profil sera en mesure ou non de réaliser les actions suivantes :

Pour des raisons de simplicité, la sécurisation par authentification n'est pas demandée, néanmoins chaque Web service transmet l'ID de la personne réalisant l'action et il sera donc à votre charge dans l'application d'autoriser une action en fonction des droits que possède un profil. Attention à bien faire correspondre les contraintes de votre de vue et celle de vos EJBs.

IV. Base de données

Vous allez devoir réaliser votre projet avec la base de données déjà existante du client dont voici le schéma :

La table « user » représente les informations d'un utilisateur, elles sont créées lors de l'ajout d'un utilisateur et seule l'adresse « email » peut être actualisée.

Deux tables « customer » et « advisor » permettent de dissocier nos utilisateurs en étant respectivement « client » et « conseiller » et permet en outre de rattacher un client à son conseiller.

La table « account_type » est une table référençant l'ensemble des comptes proposés par la banque (une sorte de catalogue). Cette table référencera le taux du compte et les capacités de découvert.

La table « account» représentera donc un compte pour un client et rattaché à son type. Il contiendra le solde du compte à l'instant présent.

La table « transaction» regroupe l'ensemble des transactions réalisées. Pour toutes les transactions, il est primordial qu'elle provienne d'un compte et à destination d'un compte existant. On permet néanmoins que l'auteur puisse être à « null » dans le cas où c'est le système qui réalise le transfert (commission, application des taux en début d'année, etc…). En dehors d'un cas particulier, l'auteur doit systématiquement être remplit.

La base de données sera disponible au format SQL dans le Starter (cf. « Travail à réaliser - Starter »). Les données par défaut seront à conserver et serviront de base de test (comptes avec les taux et seuil de découvert, utilisateurs, etc…). La structure de la base ne peut en aucun cas être modifiée, vous êtes néanmoins libre de rajouter vos propres données pour tester tous les cas particuliers du projet.

Travail à réaliser

I. Enterprise Java Bean

La partie EJB correspond donc à l'aspect métier de notre application bancaire. L'ensemble des classes et méthodes permettant le fonctionnement de l'application devront être implémentées dans cette partie (EJB). Elle sera entre autre constituée de :

• Session Beans (classe & interfaces)
• EJB Entities
• Java Messaging Service
• Persistance Manager

La manipulation du front étant déjà réalisée par une équipe externe, vous devrez implémenter des Web services dans la partie Web afin de faire le lien entre le contrôleur et le rendu visuel à savoir l'appel de vos « Sessions Beans » (EJB) et du formatage des données pour la construction des pages HTML.

Déroulement étape par étape

1. Construire vos « Sessions Beans » permettant de réaliser l'aspect métier de l'application. Pour ce faire, pour chaque classe, il faudra définir le périmètre des actions de cette dernière sur les données en base (contrôle des données, interfaces accessibles, cycle de vie, attributs, etc…). Les données en base ne seront pas encore accessibles, il faudra donc simuler ces données avec des objets virtuels (MOCK) pour attester du bon fonctionnement de vos méthodes.

2. Elaboration et création de vos objets virtuels permettant de faire le lien entre vos données en base et le rendu visuel (et inversement). Ces classes devront être construites en fonction de vos besoins, de la manière dont vous souhaitez organiser votre vue et surtout, de protéger vos EJB Entités. Nous verrons par la suite que ces objets qui font le pont entre nos données et notre vue apporteront une certaine souplesse dans le code.

3. Reliez vos « Sessions Beans » à votre vue. Utilisez vos objets virtuels pour organiser et afficher vos vues avec les informations souhaitées.

4. Construction des EJB Entités. Représentation de la base de données en Java (ORM = Object-Role Modeling), vous aurez pour tâche de réaliser les constructeurs, attributs, accesseurs, contraintes d'attributs, relations entre entités et enfin redéfinir les méthodes « toString ».

5. Reliez le « Persistance Manager » aux « Sessions Beans » et remplacez les données virtuelles par les vraies données de la base.

6. Réalisez les transactions en prenant en compte la gestion des exceptions ainsi que les rollbacks éventuels.

7. Modifiez votre « vue » pour prendre en compte ces levées d'exception et ainsi informer et orienter l'utilisateur en cas d'anomalie (découvert, erreur interne, etc…).

II. Front API

Afin de faciliter vos tests (également pour la correction), une console en ligne représantant le front finalisé vous a été mis à disposition.

• Documentation
• Tests

Déroulement étape par étape

1. Pour chaque demande du cahier des charges, construire l'ensemble des prototypes d'API en réfléchissant bien à la cohérence de vos requêtes.
2. Créez l'ensemble des payloads (input/output) vous permettant d'appeler l'ensemble des requêtes avec toutes les informations nécessaires.
3. Vos EJB étants maintenant disponible, vous n'avez qu'à les relier à vos web-services.
4. Vérifier que toutes les fonctionnalités du front fonctionnent.

Console en ligne

Afin de faciliter vos tests (également pour la correction), une console en ligne représantant le front finalisé vous a été mis à disposition. Il vous suffit donc de vous connecter à la console et de tester l'ensemble de vos méthodes. L'équipe ayant réalisé le front n'avait pas encore accès à vos webservices, ils ont donc réalisé un MOCK pour chaque appel et vous ont mis à disposition dans la rubrique "Aide", l'ensemble des requêtes, méthodes et payloads à fournir pour pouvoir lier votre back au front.

Important : Il est possible que lors de votre premier appel, la console n'arrive pas à accéder à votre serveur. Pour des raisons de sécurité la console en ligne est sécurisée en HTTPS, les navigateurs ne permettant pas le mixed content (un site en HTTPS ne peut pas appeler un site en HTTP), vos webservices locaux sont donc en HTTPS. Localhost oblige, vous avez un certificat auto-signé qu'il faudra donc valider manuellement un première fois en vous rendant à l'adresse suivante : https://localhost:8001

Liste des Webservices à implémenter

Pour tester votre application, vous n'aurez qu'à implémenter les WS demandés sur chaque page de la console. Ci-dessous, l'ensemble des WS à implémenter pour couvrir toutes les pages/demandes :

{
  "result": false
}

III. Starter

Pour vous épauler dans la réalisation de ce projet, une architecture de démarrage vous est fournie directement via un dépôt Git publique. Ce starter contient une architecture prête et fonctionnelle du projet vous permettant de vous concentrer sur l'implémentation back-end du projet. Elle vous affranchit en autre de la construction du projet de base : build, installation de la base de données, configuration du serveur d'application, ...

Modalités du rendu

I. Consigne

Le projet est à faire par binôme. Les personnes souhaitant réaliser le projet seuls sont autorisées à le faire dans la mesure où cela ne porte pas préjudice à un autre étudiant ne voulant pas être dans cette situation. Notez que dans les deux cas, le barème de notation restera inchangé (il faut assumer).

Chacun de vos projets devront être hébergés sur un environnement de versionning en ligne (github, gitlab, etc). Le lien de votre dépôt vous sera demandé par binome et vous n'aurez donc plus qu'à vous assurer que votre projet est correctement synchronisé pour la date de rendu. Vous pouvez utiliser autant de branches, commit, tags que nécessaires, pour le rendu, seul le dernier commit (avant la dead-line) sur la branche « master» sera testé et fera office de rendu. Pensez donc à bien « Push » vos modifications locales et à merger vos branches sur la master. Aucun build n'est demandé, vous devez uniquement versionner le code source.

Pour ceux qui ne souhaiteraient pas que leur dépôt soit public, voici comment sécuriser votre dépôt et me partager son accès :

II. Notation

Le barème sera réalisé lors de la correction des projets afin de valoriser les parties en fonction de l'avancement du groupe. Certains points du cahier des charges ont volontairement été laissés en suspens afin de voir votre faculté à appréhender votre vision du projet et la manière d'organiser votre code. Les points suivants seront en outre passés en revue :

• Organisation des classes (packages)
• Périmètre & rôle de chaque classe
• Propreté du code (nom des méthodes, documentation, commentaires)
• Bonne utilisation des états « Stateless » & « Stateful »
• Gestion des exceptions (et donc roll back éventuels)
• Modularité du code
• Construction des entités (contraintes des attributs et relation des tables)
• Contrôle des données (la vue n'est pas à l'abri de données erronées)
• Gestion des transactions
• Réalisation de toutes les fonctionnalités
• Gestion des webservices
• Construction des payloads
• Analyse des branches & commits afin de voir l'évolution de votre projet au cours de la période donnée

III. Planning

Nous disposerons de 3 séances de 4 heures. Chacune des séances portera sur un point en particulier sous forme de TP/cours afin d'approfondir chaque notion des connaissances requises pour réaliser l'ensemble des fonctionnalités de ce projet. Vous êtes néanmoins libre d'avancer à votre guise au cours des séances pour réaliser votre projet.

Séance 1 :

• Présentation
• Lancement du projet
• [BREAK]
• Java Sessions Beans
• Entity Manager x EJB Entities

Séance 2 :

• Entity Manager - Queries
• EJB Entities - Mapping
• [BREAK]
• EJB Entities - Relations

Séance 3 :

• EJB Entities - Héritage
• [BREAK]
• Transaction
• Web Services

Rendu :

Le projet final sera à rendre au plus tard le Dimanche 5 Janvier 2025 à 14h00.

Avant chaque séance, pour ceux qui le souhaitent, vous avez la possibilité de me solliciter par mail (mickael.boudignot@icloud.com) ou via le Discord ESIPE-INFO afin que j'inspecte votre avancement (via le dépôt en ligne) et vous faire un retour sur votre travail à la séance suivante. L'application à réaliser n'est pas compliquée mais beaucoup de notions sont à voir, il est donc primordial que le planning de chaque séance soit respecté. Il est donc fortement conseillé d'avancer entre chaque séance pour arriver au cours suivant avec les notions vues précédemment acquises ou en attente de clarification.

Good luck…

Documentation

I. Pré-requis

Vous êtes libre d'utiliser l'environnement qui vous convient le mieux

• JDK
• Maven
• Docker
• Docker-compose

II. Installations

sudo apt-get update

sudo apt-get install git maven docker-ce docker-compose

export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64

III. Récupération du projet Git

Pour importer le projet, il vous suffit de partir de l'URI suivante du dépôt :

git clone https://github.com/Mackile/ejbank.git

Le projet EJBank est un projet Maven qui package trois sous projets :

• EJBank-ear : pour packager notre EJB et WEB au sein d'un même bundle
• EJBank-ejb : la partie bean métier à développer
• EJBank-web : la partie web qu'il faudra agrémenter de webservices

Une fois que vous aurez récupéré le starter, il faudra le lier à votre propre dépôt pour ne pas perdre votre avancement et surtout pour le rendu du projet (ne pas oublier de me communiquer le lien de votre dépôt) :

git remote set-url origin https://github.com/VOTRE_COMPTE/NOM_DE_VOTRE_PROJET.git

IV. Démarrer le projet

Pour compiler vos sources avec maven, placez-vous à la racine votre projet (celui qui contient les docker-compose) :

mvn clean install

Pour lancer le projet, vous allez devoir démarrer l'architecture contenant le serveur d'application qui va exécuter votre application à l'aide de docker :

• Linux & Mac (une seule fois) :

  sudo docker-compose up

• Windows (à chaque build) :

  docker-compose -f docker-compose.windows.yml up --build

Votre build va générer une archive EAR qui sera envoyée au serveur d'application présent DANS le docker et ainsi déployer votre application. A chaque fois que vous fairez une modification de projet, pour redéployer vos modifications, relancez uniquement la commande maven (sauf pour Windows où vous devrez également relancer la commande docker-compose).

Note : Au premier lancement de votre projet, la base de données sera déployée dans le container MySQL. Tant que vous ne supprimez pas vos containers, la base de données restera inchangée.

Le starter est livré avec un petit webservice et un EJB pour tester que toutes les interconnexions fonctionnent, vous pouvez tester avec la commande suivante :

curl --insecure https://localhost:8001/test/ejb

Pour accéder à un conteneur docker (dans le cas où vous souhaiteriez accéder à la console et exécuter des commandes à l'intérieur de ce dernier) :

sudo docker exec -ti NOM_DU_CONTENEUR bash

Conteneurs :

• ejbank_app_1 : conteneur de votre application (port 8001 pour l'application & 8002 pour le serveur d'application)
• ejbank_db_1 : conteneur de base de données
• ejbank_phpmyadmin_1 : un conteneur vous permettant de manipuler votre base via phpMyAdmin (port 8003)
  • Accès à phpMyAdmin : http://localhost:8003
  • Identifiant : root
  • Mot de passe : root

V. Importer le projet dans l'IDE

wget -O eclipse.tar.gz http://mirror.ibcp.fr/pub/eclipse//technology/epp/downloads/release/2023-09/R/eclipse-jee-2023-09-R-linux-gtk-x86_64.tar.gz
tar -xvf eclipse.tar.gz
./eclipse/eclipse

Annexes

I. Schémas

• 1
• 2
• 3
• 4

II. Versions