Exercice 1 - Implémentation de la partie métier⚓︎

Dans cet exercice, nous allons implémenter la partie "Couche Métier" du schéma suivant :

archi appli — Architecture de notre application

1. Création du projet EJB⚓︎

Nous allons créer le projet qui va permettre d'implémenter la couche métier. Comme indiqué précédemment, pour pouvoir contenir des EJBs Sessions, le projet doit être du type EJB.

Dans le vue Project Explorer, cliquer sur le bouton droit de la souris, puis aller dans :material-mouse:New > Project..., puis dans :material-file-tree:EJB > EJB Project.
Entrer le nom du projet (GestionNotesEJB), puis :
- sélectionner la bonne runtime,
- décocher "Add Project to an EAR" si elle est cochée,
- dans le dernier onglet, cocher la case "Generate ejb-jar.xml ..." (c'est l'équivalent du 📄web.xml)
- puis cliquer sur Finish.
Pour pouvoir utiliser JPA, il faut l'activer dans les "facettes" du projet.

2. Implémentation des différentes couches⚓︎

Ce projet contient trois sous-couches :

La couche "modèle".
La couche DAO.
La couche "Services métiers" (la brique "EJB Session" dans le schéma ci-dessus).

Les modifications décrites ci-dessous le sont par rapport au projet précédent (GestionNotes du TD6).

2.1. Implémentation de la couche "modèle"⚓︎

La couche "modèle" est inchangée. Il faut la recréer à l'identique.

Il ne faut pas oublier de configurer le fichier 📄persistence.xml, comme dans le TD précédent.

2.2. Implémentation de la couche "DAO"⚓︎

La couche DAO est modifiée :

Le constructeur public sans argument, qui permettait d'instancier l'objet EntityManager doit être supprimé.
Cet objet est maintenant instancié via injection, en utilisant l'annotation suivante :
☕ Code Java
```
@PersistenceContext(unitName = "GestionNotesEJB")//(1)!
private EntityManager em;
```
1. Le nom de l'unité de persistance doit être celui indiqué dans le fichier 📄persistence.xml
Dans les méthodes gérant de la persistance (les CUD dans CRUD) (il n'y a normalement que la méthode insertNote), les gestions manuelles de la transaction sont à supprimer : em.getTransaction().begin(); et em.getTransaction().rollback();.
L'appel de la couche DAO (depuis la couche "services métiers") se fera sans état. Il faut donc rajouter l'annotation suivante à la création de la classe :
☕ Code Java
```
@Stateless
public class NotesDAOImplJPA implements NotesDAO {
    ...
}
```
5. L'implémentation DAO JDBC, c'est-à-dire la classe NotesDAOImplJDBC peut être supprimée.

2.3. Implémentation de la couche "Services métiers"⚓︎

La couche "Services métiers" est également modifiée :

Comme indiqué précédemment, un EJB session est une classe implémentant deux interfaces (une pour les appels locaux et une pour les appels distants).
1. Renommer l'interface NotesBusiness en NotesBusinessLocal. Pour indiquer qu'il s'agit de la locale, il faut ajouter l'annotation suivante :
  ☕ Code Java
```
@Local
public interface NotesBusinessLocal {
    ...
}
```
  2. Créer l'interface NotesBusinessRemote. Pour indiquer qu'il s'agit de la distante, il faut ajouter l'annotation suivante :
  ☕ Code Java
```
@Remote
public interface NotesBusinessRemote {
    ...
}
```
  Cette interface contient exactement les mêmes signatures que la locale.
2. Dans la classe NotesBusinessImpl, il faut maintenant indiquer qu'elle implémente les deux interfaces. Il faut également indiquer qu'elle sera appellée "sans état" depuis la Servlet. On ajoute donc l'annotation @Stateless. On obtient donc :
  ☕ Code Java
```
@Stateless
public class NotesBusinessImpl implements NotesBusinessLocal, NotesBusinessRemote {
    ...
}
```
  4. Enfin, le DAO n'est maintenant plus instancié "à la main", mais par injection. Le constructeur public doit donc être supprimé, et remplacé par l'utilisation de l'annotation suivante :
  ☕ Code Java
```
@Inject
private NotesDAO dao;
```

3. Déploiement du projet⚓︎

Déployer le projet GestionNotesEJB sur le serveur WildFly.

Vérifier que l'EJB session est correctement déployé

Vérifier dans les logs que l'EJB session a bien été déployé. Il doit y avoir une ligne ressemblant à cela :

📋 Logs du serveur WildFly

ejb:/GestionNotesEJB/NotesBusinessImpl!fr.univtours.polytech.gestionnotes.business.NotesBusinessRemote

Il s'agit du nom JNDI (c'est annuaire des objets Java disponibles) avec lequel nous allons pouvoir appeler l'EJB session depuis une autre application Java.

Ces noms n'ont pas la même forme selon le serveur d'application utilisé. Pour WildFly, la forme est la suivante :

Détail du nom JNDI

ejb:<Nom du projet d'entreprise>/<Nom du projet EJB>/<Nom de la classe implémentant l'EJB session>!<Package et nom de l'interface remote>

Ici, notre module EJB (le projet que nous venons de créer) n'est pas encore associé à un projet d'entreprise, c'est pour cela qu'il est vide.

java.lang.UnsupportedClassVersionError

Si vous rencontrez l'erreur java.lang.UnsupportedClassVersionError, c'est qu'une classe est exécutée avec une version de Java avec laquelle elle n'a pas été compilée.

Cela vient du fait que la JDK 1.8 n'a pas été indiqué partout.

L'action suivante corrigera certainement ce problème :

Faire un clic droit sur le projet GestionNotesEJB, :material-mouse:Properties, puis dans :material-file-tree:Java Build Path, dans l'onglet Libraries, cliquer sur la JDK ou JRE utilisée, puis sur Edit... et sélectionner une JDK 1.8.
Dans :material-file-tree:Java > Compiler, puis dans le champ Compiler compliance level, indiquer 1.8.
Dans les "facettes" du projet, indiquer que la version de Java utilisée est la 1.8.

Note

Plusieurs projets peuvent être déployés en même temps sur le même serveur (Tomcat, WildFly, ou autre). Il n'est donc pas nécessaire de dépublier (le contraire de déployer) les anciens projets.

Cependant, pour s'y retrouver dans les logs, il est fortement conseillé de ne déployer que les projets nécessaires au développements en cours.

Ça y est, notre service EJB est accessible depuis une autre application. Nous allons tout de suite le tester en créer un client (lourd) Java dans le prochain exercice.