J’ai essayé d’apprendre ce que sont les beans EJB, ce que cela signifie, leurs instances sont gérées dans un pool, etc… Je n’arrive vraiment pas à les comprendre.
Pouvez-vous m’expliquer en quoi ils consistent réellement (en pratique pour un programmeur Java) ? Que font-ils ? Quels sont leurs objectifs ? Pourquoi les utiliser ? (Pourquoi ne pas s’en tenir à POJO ?) Peut-être un exemple d’application ?
Juste une remarque tirée de mon expérience personnelle …
Je ne doute pas des avantages des EJB, mais ayant déjà pratiqué ces derniers, je considère que les EJB ne conviennent que dans les cas où la sécurité et les transactions sont très importantes (c’est-à-dire les applications financières). Dans 90 % des cas, vous vous débrouillerez très bien sans EJB.
Certains disent dans des discussions comme celle-ci que l’EJB est devenu utile en EJB3 pas avant, et ce n’est pas vrai. c’est vrai qu’il est devenu plus puissant spécialement avec le JPA, mais EJB1.0 et EJB2.1 ont encore fait beaucoup. peut-être qu’ils ne l’ont pas utilisé dans de grandes applications donc ils disent ça.
Par exemple, les POJO ne peuvent pas gérer les transactions, alors que les EJB permettent de spécifier le type de transaction pour une méthode spécifique, qu’elle nécessite une nouvelle transaction ou qu’elle ne provienne pas de la transaction.
Dans notre société, nous avons construit un ERP à partir de zéro et nous utilisons l’EJB dans la logique métier, il datait de 2000 et l’EJB était la version 1.0. Et il ne sépare pas seulement la partie métier des autres parties, mais il sépare également le système les uns des autres, par exemple : le module financier est séparé du module RH. et s’ils veulent ajouter un nouveau module, ils peuvent l’ajouter sans redémarrer le système et il s’intègrera parfaitement au système…
et rappelez-vous ceci dans l’EJB : ce que vous voyez dans le code n’est rien et ce que le conteneur EJB fait pour vous est tout 
.
SI vous avez besoin d’un composant qui accède à la base de données ou à d’autres ressources de connectivité ou d’annuaire, ou qui est accessible à partir de plusieurs clients, ou qui est conçu comme un service SOA, les EJB sont généralement « plus puissants, plus rapides (ou au moins plus évolutifs) et plus simples » que les POJO. Ils sont particulièrement utiles pour servir un grand nombre d’utilisateurs sur le web ou le réseau de l’entreprise et un peu moins utiles pour les petites applications au sein d’un département.
Un EJB est un composant Java, contenant une logique métier, que vous déployez dans un conteneur, et qui bénéficie des services techniques fournis par le conteneur, généralement de manière déclarative, grâce à des annotations :
Gestion des transactions : une transaction peut être démarrée automatiquement avant qu’une méthode de l’EJB ne soit invoquée, et validée ou annulée une fois que cette méthode est retournée. Ce contexte transactionnel est propagé aux appels à d’autres EJBs.
Gestion de la sécurité : il est possible de vérifier que l’appelant dispose des rôles nécessaires pour exécuter la méthode
L’injection de dépendances : d’autres EJB, ou des ressources telles qu’un gestionnaire d’entités JPA, une source de données JDBC, etc. peuvent être injectés dans l’EJB.
Concurrence : le conteneur veille à ce qu’un seul thread à la fois invoque une méthode de votre instance d’EJB.
Distribution : certains EJB peuvent être appelés à distance, à partir d’une autre JVM.
Répartition des charges et défaillance : les clients distants de vos EJB peuvent automatiquement voir leur appel redirigé vers un autre serveur en cas de besoin.
Gestion des ressources : les beans stateful peuvent être automatiquement désactivés sur disque afin de limiter la consommation de mémoire de votre serveur.
… J’ai probablement oublié quelques points.
Les EJB n’existent pas seuls ; ils vivent dans un conteneur EJB, qui vous offre des services très utiles, tels que la sécurité déclarative, les transactions déclaratives et une répartition en clusters relativement facile.
Si vous écrivez dans un EJB:
@Resource DataSource x;
Le conteneur s’assure que lorsque votre bean est prêt à recevoir des appels de méthode, la variable « x » contient une source de données appropriée.