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.