Discussion :

[Badshade23]

Bonjour tout le monde,

Utilisant le framework Spring et plus précisément Spring Data j'ai voulu comprendre plus en détaille le fonctionnement de celui-ci.
En est découlé de nombreux mot-clefs tels que : Hibernate, JPA, POJO, EJB, middlewares, EJB, serveur d'application ....
Je me suis donc plongé plus en détail sur les EJB et ce que ça représenté réellement, car ça restait assez abstrait pour moi. Je viens donc solliciter votre aide pour confirmer ou non mes dires à ce sujet.
J'ai compris qu'un EJB(Entreprise Java Bean) est simplement un Bean (d'où le nom) qui est gérer dans un contexte (EJB Container) qui doit être hébergé sur un serveur d'application JAVA EE pour pouvoir "exister".
C'est généralement un jar qui contient une classe qui implémente une interface (toujours ?) offrant différent service à l'utilisateur.
Il existe trois type d'EJB :

• Les EJB session, qui existent en deux variantes : avec état ( stateful ) et sans état ( stateless ). Qui représente un traitement (gestion de compte bancaire, gestion du panier d'achat...)
• Les EJB messages, qui fonctionnent en tandem avec l'API JMS (Java Messaging Service). Qui traite les messages asynchrones. (Pas tout compris encore )
• Les EJB entité qui représente un objet métier (donc un table dans la BDD) et qui permet un stockage persistant (JPA avec les annotation @Entity ... ?)

J'ai trouver un schéma intéressant sur l'architecture de celui-ci :



Trouvé ici https://fr.slideshare.net/HeithemAbb...java-beans-ejb

Si je comprends bien l'application, interroge les EJB présents sur le serveur (en récupérant le Bean via son contexte comme on pourrait dans Spring). On exécute les méthodes désiré et le Bean EJB interroge la BDD (si besoin) via JDBC ou autre et nous retourne le résultat ?

J'ai fait pas mal de supposition dans ce poste, je vous remercie d'avance pour vos éclaircissements .

[OButterlin]

Avec la version 3, la simplification à supprimé la notion d'EJB pour la persistance, maintenant, c'est une simple classe avec des propriétés et des annotations pour faire le lien avec la structure physique de la base de données.
La persistance est confiée à JPA (et JTA pour les transactions, mais on peut changer).
Pour les EJB, ce sont en gros des classes de définition de fonctionnalités qui sont liées à des interfaces, lesquelles sont utilisables à distance ou localement.
Il existe 2 types :
- les EJB session : avec état (stateful) ou sans état (stateless)
- les EJB message driven

Les EJB message driven sont couplés à un système de message JMS (MQ Series, Active MQ, ...), ils sont généralement utilisés de manière asynchrone.

Les EJB session sont les plus couramment utilisés, et particulièrement les stateless dans les applications web (le stateful n'a pas de grand intérêt ici parce qu'on peut conserver un état via la session)
Le principe est le suivant (en très simplifié) :
- le client connaît les interfaces et récupère via JNDI le "lien" (un proxy) avec l'implémentation sur le serveur d'application
- lorsque le client utilise une méthode de ce proxy, il se passe ceci :
-> sérialisation des paramètres
-> transfert vers le serveur
-> le serveur désérialise les paramètres et appelle l'implémentation de la méthode
-> le résultat de la méthode (s'il y en a un) est sérialisé et renvoyé au client
-> le client désérialise le paramètre en retour et continue son traitement

Lorsqu'on utilise les EJB dans une application web, sur le même serveur, on utilise plutôt les interfaces @Local pour des questions de performance, dans ce cas, il n'y a pas de sérialisation/déserialisation, le passage est fait par référence.
Bien sûr, on peut être amené à utiliser les interfaces @Remote dans une application web, par exemple en déployant sur un serveur particulier un service d'accès à la base de données et en déployant les applications web utilisatrices sur d'autres serveurs.
De manière générale, si on est sur la même JVM -> interface @Local ou @Remote, si on est sur des JVM différentes -> interface @Remote.

[Badshade23]

Merci beaucoup pour la réponse.

D'accord pour les entités, donc JPA n'est pas un EJB ?
Du moins leurs annotations sont complètement différentes ?

Ok pour les EJB session, mais sont-ils encore vraiment utilisés ?
Par exemple, j'apprends à faire un site avec Spring en back et angular en front et je n'ai quasiment aucune information persistante pour la session, car j'utilise les JWTs pour stocker mes informations chez le "client" et je communique en REST. Si je ne dis pas de bêtise du coup, mon serveur ne garde en "mémoire" aucune information des personnes actuellement connectées. À moins que les EJB soient entre Spring DATA et mon serveur (conversion des requêtes.....) ?

[OButterlin]

D'accord pour les entités, donc JPA n'est pas un EJB ?
Du moins leurs annotations sont complètement différentes ?

Non, JPA est une api à part entière, elle peut très bien s'utiliser en dehors des EJB.
Après, il ne faut pas perdre de vue que JPA n'est qu'une spécification, l'implémentation peut être confiée à différents tiers (Hibernate par exemple).

Ok pour les EJB session, mais sont-ils encore vraiment utilisés ?
Par exemple, j'apprends à faire un site avec Spring en back et angular en front et je n'ai quasiment aucune information persistante pour la session, car j'utilise les JWTs pour stocker mes informations chez le "client" et je communique en REST. Si je ne dis pas de bêtise du coup, mon serveur ne garde en "mémoire" aucune information des personnes actuellement connectées. À moins que les EJB soient entre Spring DATA et mon serveur (conversion des requêtes.....) ?

Les EJB session Stateless sont très utilisés, les Stateful certainement beaucoup moins.
Pour un service Rest, le stateless est un bon candidat, il ne garde pas d'état, on a accès à un pool d'ejb, il existe des annotations spécifiques pour faire du rest directement dans l'ejb...
Je ne dis pas que Spring ne sait pas faire... d'ailleurs, en gros, les 2 font plus ou moins la même chose...
Un des argument de Spring est de dire qu'on n'a pas besoin d'un serveur d'application mais bon, force est de constater que de nos jours, un serveur wildfly (par exemple) démarre tout aussi vite qu'un Tomcat... par contre, si on a besoin de services de haut niveau, pas besoin de s'arracher les cheveux à combiner des trucs de différentes boites avec les problématiques de compatibilité d'api...

[Badshade23]

Non, JPA est une api à part entière, elle peut très bien s'utiliser en dehors des EJB.
Après, il ne faut pas perdre de vue que JPA n'est qu'une spécification, l'implémentation peut être confiée à différents tiers (Hibernate par exemple).

D'accord, c'est ce que j'avais compris aussi, mais beaucoup de personnes disent (sur le net, après je prends toujours ces infos avec des "pincettes") que JPA est basée sur les EJB « Entity » est cela même pour EJB 3 .
"Pour commencer, nous allons indiquer à notre serveur, plus précisément à notre conteneur, que notre bean Utilisateur va devenir un EJB Entity. Pour cela, nous devons l'annoter avec @Entity :"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
@Entity
public class Utilisateur {
   ...
}

Alors que normalement @Entity est une annotation JPA non ?
Après, je sais que JPA est une API qui définit un ensemble de règles permettant la gestion de la correspondance entre des objets Java et une base de données sur lesquelles beaucoup d'ORM s'appuient.

Les EJB session Stateless sont très utilisés, les Stateful certainement beaucoup moins.
Pour un service Rest, le stateless est un bon candidat, il ne garde pas d'état, on a accès à un pool d'ejb, il existe des annotations spécifiques pour faire du rest directement dans l'ejb...
Je ne dis pas que Spring ne sait pas faire... d'ailleurs, en gros, les 2 font plus ou moins la même chose...
Un des argument de Spring est de dire qu'on n'a pas besoin d'un serveur d'application mais bon, force est de constater que de nos jours, un serveur wildfly (par exemple) démarre tout aussi vite qu'un Tomcat... par contre, si on a besoin de services de haut niveau, pas besoin de s'arracher les cheveux à combiner des trucs de différentes boites avec les problématiques de compatibilité d'api...

Donc quand on utilise Spring dont Spring DATA, on n'utilise pas d'EJB (sachant en plus que l'on n'utilise pas de serveur d'applications donc pas de contexte EJB ...).
Les EJB session font donc la liaison entre notre service et notre BDD . On lui envoie notre requête sous forme jpql ou hql ... et lui fait la conversion et nous donne les informations de la BDD ?
Sachant (à moins que je dise une bêtise) que Spring est l'un ou le Framework le plus utilisé pour faire du Web avec JAVA les EJB on t'ils encore de beaux jours devant eux.

[OButterlin]

Alors que normalement @Entity est une annotation JPA non ?

il suffit de regarder l'import pour s'en convaincre... import javax.persistence.Entity;

Après, je sais que JPA est une API qui définit un ensemble de règles permettant la gestion de la correspondance entre des objets Java et une base de données sur lesquelles beaucoup d'ORM s'appuient.

Donc quand on utilise Spring dont Spring DATA, on n'utilise pas d'EJB (sachant en plus que l'on n'utilise pas de serveur d'applications donc pas de contexte EJB ...).
Les EJB session font donc la liaison entre notre service et notre BDD . On lui envoie notre requête sous forme jpql ou hql ... et lui fait la conversion et nous donne les informations de la BDD ?
Sachant (à moins que je dise une bêtise) que Spring est l'un ou le Framework le plus utilisé pour faire du Web avec JAVA les EJB on t'ils encore de beaux jours devant eux.

Spring est plutôt un produit placé par les sociétés de service, les "grands groupes" utilisent énormément les serveurs d'application, donc JEE plutôt que Spring.

Après, c'est toujours un peu lassant cette guéguerre entre pro-spring, anti-jee et anti-spring, pro-jee...
Pour avoir fait des 2, mon avis est le suivant :
actuellement, je préfère JEE... mais il y a quelques années, je préférais Spring qui était plus complet, plus simple...
Le tournant est lié à la version 3 des EJB, et l'avance (à mon sens) s'est accentuée avec EE8.
Mais les 2 sont de très bon framework (si on peu dire).

Pour ce qui est des applications hors web, on n'a besoin ni de l'un, ni de l'autre... généralement, on utilise un ORM, et pour ma part, c'est toujours Hibernate que je choisis (non pas que les autres ne soient pas bon mais je le connais bien et du coup, je gagne du temps).

Pour les applications web, encore faut-il se poser les bonnes questions. La tendance actuelle est aux applications javascript mais ce n'est pas forcément le plus productif, ni le plus stable. J'ai encore beaucoup de mal à miser sur ce langage dans la mesure où sa normalisation n'est pas complète, on peut encore avoir des différences d'un navigateur à l'autre, même si ça s'améliore beaucoup. L'idée par contre est bonne, laisser le poste client s'occuper de l'IHM et laisser les serveurs "métier" du reste.
Ensuite, chez nous, on fait plutôt des applications de gestion typées client lourd sur le net, et là, j'adore l'approche EE avec JSF/Primefaces pour l'IHM et les EJB pour la couche métier.

[Badshade23]

Ok merci beaucoup pour toutes ces informations / éclaircissement .
Donc si j'ai bien compris EJB et Spring sont des "concourants" par contre Spring et un framework, mais pas EJB si ? EJB fait plutôt partie intégrante de java EE non ? Par contre Spring peut fonctionner avec java EE ?
Après les deux utilisent un contexte et le patron d’architecture IoC, injection de dépendance ... Je ne sais pas, par contre si les EJB offres autant de fonctionnalité que Spring vu ses nombreux outils (Spring Sécurity, Spring Data, ...)
Après personnellement, j'utilise Spring en back pour un site web et aussi dans une application lourde avec Spring Data et mysql qui est vraiment très simple et sympa d'utilisation. Mais comme je n'ai pas d’expérience avec les EJB je ne peux pas vraiment comparer, je te remercie donc pour ton retour d’expérience.
Mon but initial était juste se comprend en "détail" le fonctionnement de Spring Data car il fait énormément de chose automatiquement que le développeur ne voit plus et j'aime savoir le fonctionnement des frameworks que j'utilise ^^.
Et pendant mes recherches à ce sujet je suis tombé sur les EJB que je ne connaissais pas trop^^..

[OButterlin]

Java EE n'est pas vraiment un framework, c'est plus un ensemble de bibliothèques de fonctionnalités... mais ça dépend un peu de quoi on parle : JSF est un framework EE.

Pour ce qui est des fonctionnalités offertes par les 2 protagonistes, j'aurais du mal à dire lequel en a plus... ils en ont en commun et d'autres spécifiques.
Mais clairement se sont des concurrents
Quand on en connait bien un, on a du mal à passer à l'autre, ça prend beaucoup de temps à intégrer/comprendre vu l'étendu des services offerts.

[Badshade23]

Java EE n'est pas vraiment un framework, c'est plus un ensemble de bibliothèques de fonctionnalités... mais ça dépend un peu de quoi on parle : JSF est un framework EE.

D'accord pour JAVA EE ce dont je me doute, mais les EJB ? À moins que ceux-ci fassent partie intégrante de JAVA EE ? Ils ne peuvent pas être dissociés ?

Pour ce qui est des fonctionnalités offertes par les 2 protagonistes, j'aurais du mal à dire lequel en a plus... ils en ont en commun et d'autres spécifiques.
Mais clairement se sont des concurrents
Quand on en connait bien un, on a du mal à passer à l'autre, ça prend beaucoup de temps à intégrer/comprendre vu l'étendu des services offerts.

D'accord donc a part le fait qu'ils soient concurrents et qu'ils sont une structure similaire ils sont donc complètement indépendant l'un de l'autre ? EJB n'utilise pas Spring et vice-versa ?

J'ai lu dans un article que " JPA a réussit même le tour de force de s'extirper de la spécification EJB3 pour pouvoir être exploitée directement sous Java SE et des frameworks léger comme Spring."
Cela veut dire que l'API était avant dédier a EJB et que depuis la version 3 ils en ont fait un API qui peut être utilisée par d'autres Frameworks tel que Spring ?

[OButterlin]

D'accord pour JAVA EE ce dont je me doute, mais les EJB ? À moins que ceux-ci fassent partie intégrante de JAVA EE ? Ils ne peuvent pas être dissociés ?

Oui, EJB fait partie de EE.

D'accord donc a part le fait qu'ils soient concurrents et qu'ils sont une structure similaire ils sont donc complètement indépendant l'un de l'autre ? EJB n'utilise pas Spring et vice-versa ?

Ce qui est certain, c'est qu'EJB n'utilise pas Spring...

J'ai lu dans un article que " JPA a réussit même le tour de force de s'extirper de la spécification EJB3 pour pouvoir être exploitée directement sous Java SE et des frameworks léger comme Spring."
Cela veut dire que l'API était avant dédier a EJB et que depuis la version 3 ils en ont fait un API qui peut être utilisée par d'autres Frameworks tel que Spring ?

JPA n'a rien à voir avec les EJB, ce n'est pas parce qu'on utilise JPA dans des EJB qu'ils sont dépendant.
Un EJB pourrait très bien utiliser JDBC ou Hibernate directement pour faire de la persistence, aucun problème.
On peut même faire un système hybride en récupérant la connexion liée au PersistenceContext et utiliser JDBC derrière.
De toute manière, dans l'utilisation d'une DB, il y a 3 choses :
- la connexion
- la transaction
- les instructions SQL (ou JPQJ ou HQL)

[Badshade23]

Merci pour ta patience j'ai un peut de mal à comprendre la place des EJB à vrai dire ^^.

Oui, EJB fait partie de EE.

D'accord pour ça.

Ce qui est certain, c'est qu'EJB n'utilise pas Spring...

Exacte, j'ai lu un article aujourd'hui disant que Spring pouvais les récupérer dans son contexte pour ensuite les utiliser. Après à voir l'utilité ...
Dans l'exemple, je pourrai dire qu'au final les EJB sont des "services" ou des beans qui garde des informations sur le serveur d'application. Pour moi au final ça serai ça une définition "simpliste" des EJB.

Source : https://www.baeldung.com/spring-ejb

JPA n'a rien à voir avec les EJB, ce n'est pas parce qu'on utilise JPA dans des EJB qu'ils sont dépendant.
Un EJB pourrait très bien utiliser JDBC ou Hibernate directement pour faire de la persistence, aucun problème.
On peut même faire un système hybride en récupérant la connexion liée au PersistenceContext et utiliser JDBC derrière.
De toute manière, dans l'utilisation d'une DB, il y a 3 choses :
- la connexion
- la transaction
- les instructions SQL (ou JPQJ ou HQL)

D'accord, après dans mon cas avec Spring Data, je sais que mes entités utilise les annotations de JPA et quelques une d'Hibernate (notamment pour les annotations "Cascade" que JPA ne doit surement pas avoir).
Après, je passe par des interfaces qui extends de JpaRepository pour créer mes méthodes CRUD.
Donc au final (si je ne dit pas de bêtises), je n'utilise jamais les EJB. Et de base Spring ne les utilises pas non plus. Mais surtout JPA et peut être un peut Hibernate.
Après, je ne sais pas encore si c'est grâce à JPA ou un ORM tel qu'Hibernate qui transforme de simple mot clef (ex : findById) en requête SQL.
Mais vu l'extends, je pense que c'est l'API de JPA qui fait cette conversion ....

[OButterlin]

D'accord, après dans mon cas avec Spring Data, je sais que mes entités utilise les annotations de JPA et quelques une d'Hibernate (notamment pour les annotations "Cascade" que JPA ne doit surement pas avoir).
Après, je passe par des interfaces qui extends de JpaRepository pour créer mes méthodes CRUD.
Donc au final (si je ne dit pas de bêtises), je n'utilise jamais les EJB. Et de base Spring ne les utilises pas non plus. Mais surtout JPA et peut être un peut Hibernate.
Après, je ne sais pas encore si c'est grâce à JPA ou un ORM tel qu'Hibernate qui transforme de simple mot clef (ex : findById) en requête SQL.
Mais vu l'extends, je pense que c'est l'API de JPA qui fait cette conversion ....

JPA utilise également les notions de cascade, pas de souci de ce côté, avec l'attribut orphanRemoval également
Pour ce qui est de la méthode findById, c'est une méthode héritée de CrudRepository, ce n'est pas l'ORM qui fait ça.
Avec JPA, l'équivalent serait

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

entityManager.find(NomDeClasseCible.class, id);

Autant dire que le + de la méthode est limité
Ceci dit, j'ai également codé une classe abstraite que mes façades crud (EJB) étendent pour faire ce genre de choses de manière unifiée, ça limite le code à mettre en œuvre pour 80% des cas.
La limite doit être la même que pour Spring, les fameuses LazyInitializationException (encore qu'avec un conteneur de servlet on peut facilement contourner le problème alors qu'avec le conteneur d'EJB, c'est une autre histoire).
Avec les EJB, j'ai pris la bonne habitude (oui oui ) de passer par des DTO (Data Transfert Object), du coup, toutes les données nécessaires à la vue sont chargées par la façade et renvoyées à l'ihm, du coup, plus d'erreur de ce type.
Autre avantage des DTO, le modèle physique peut s'enrichir sans modification d'anciennes applications utilisatrices... mais bon, c'est une autre histoire

[Badshade23]

JPA utilise également les notions de cascade, pas de souci de ce côté, avec l'attribut orphanRemoval également
Pour ce qui est de la méthode findById, c'est une méthode héritée de CrudRepository, ce n'est pas l'ORM qui fait ça.
Avec JPA, l'équivalent serait

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

entityManager.find(NomDeClasseCible.class, id);

Autant dire que le + de la méthode est limité

D'accord ^^, j'ai encore quelques recherches à faire de ce côté-là, maintenant que je commence à bien visualiser ce qu'est un EJB. Si un jour j'ai un peu de temps, j'essayerai quelques instructions avec les EJB histoire d'aller un peu plus loin. Par contre, Spring offre pas mal de mots clef pour "créer" des requêtes le plus simplement possible que l'on peut retrouver ici : https://docs.spring.io/spring-data/j...-keywords.html. Ce que je trouve relativement simple comme puissant (du moment où l'on maîtrise un minimum ces mots-clefs).

Ceci dit, j'ai également codé une classe abstraite que mes façades crud (EJB) étendent pour faire ce genre de choses de manière unifiée, ça limite le code à mettre en œuvre pour 80% des cas.

Je me doute vu les quelques exemples d'EJB sur le net, la syntaxe de mise en place me parait plus "lourde" que pour Spring. Après je me réfère que sur quelques exemples donc ...

La limite doit être la même que pour Spring, les fameuses LazyInitializationException (encore qu'avec un conteneur de servlet on peut facilement contourner le problème alors qu'avec le conteneur d'EJB, c'est une autre histoire).
Avec les EJB, j'ai pris la bonne habitude (oui oui ) de passer par des DTO (Data Transfert Object), du coup, toutes les données nécessaires à la vue sont chargées par la façade et renvoyées à l'ihm, du coup, plus d'erreur de ce type.
Autre avantage des DTO, le modèle physique peut s'enrichir sans modification d'anciennes applications utilisatrices... mais bon, c'est une autre histoire

J'utilise aussi les DTO, surtout pour mon application "lourde" et ce sont mes services qui s'occupent de la liaison entre mon DAO (instancier dans le contexte spring ....) et mon IHM. J'utilise donc des Mapper comme ModelMapper ou encore Selma pour faire la conversion objet metier -> DTO.
J'ai déjà lu quelque article qui parle des LazyInitializationException comme étant un peut la bête noire de Spring, personnellement je n'ai pas eu encore trop de problème avec cette exception.

En tous cas merci pour cet échange très enrichissant et d'avoir pris le temps de m'expliquer la partie EJB, surtout que cette "notion" représente au final pas mal de fonctionnalité. Je pense que pour appuyer tout ça, il faudra que je me fasse un ou deux exercices avec.

[OButterlin]

J'utilise aussi les DTO, surtout pour mon application "lourde" et ce sont mes services qui s'occupent de la liaison entre mon DAO (instancier dans le contexte spring ....) et mon IHM. J'utilise donc des Mapper comme ModelMapper ou encore Selma pour faire la conversion objet metier -> DTO.
J'ai déjà lu quelque article qui parle des LazyInitializationException comme étant un peut la bête noire de Spring, personnellement je n'ai pas eu encore trop de problème avec cette exception.

Si tu n'as jamais eu cette exception, c'est justement parce que tu passes par les DTO, du coup, tu accèdes à toutes les données (chargées ou non) sur un entity dit "managed".
Dans cet état (managed), tout accès à un sous-entity ou un set d'entity non initialisé provoquerait la(les) requête(s) nécessaire(s) pour le chargement.

Si je peux me permettre, j'ai fait un tutoriel pour exposer une application "type" en EE8, ça pourrait peut-être t'expliquer certains concepts (il y a les sources avec).
Pour y accéder, suivre ce lien.

[Badshade23]

Merci je vais voir ça Je met donc le sujet en résolue. J'ouvrirais un nouveau si j'ai de nouvelle question .