[Debutant] Quelles raisons contre l'utilisation des EJBs ?

"Vincent Cantin" <pere.noel@lutin.fr> a écrit dans le message de
news:e0cumn$v8o$1@shakotay.alphanet.ch...

Bonjour,

Il y a quelques posts, quelqu'un avait parle d'un livre ecrit par l'auteur
de SpringFramework ou il explique comment faire des trucs super bien
*sans*

EJB.

Dans d'autres posts, je vois d'autres personnes qui disent que dans
beaucoup

des cas, l'utilisation d'EJB n'est pas justifiee.

Moi, je debute a peine dans le JEE et je n'ai toujours pas une idee bien
claire de ce que sont les SpringFramework, Tomcat, EJB, Struts, etc ..
(pour

ne pas dire que je nage encore dans l'ignorance la plus totale). Il y a 2
jours j'ai achete un livre sur les EJB, et bien sur le livre ne dit pas
pour

quelle raison il ne faut pas utiliser les EJBs. Quand je vois les posts
dans

cette newgroup, j'ai l'inquietude de faire fausse route en allant passer 2
semaines a lire mon bouquin.

Alors ma question est :
Quel est le probleme avec les EJB ? Pourquoi les gens parlent de l'eviter
quand c'est possible ?

--
Un programmeur inquiet.


C'est vrai que Rod Johnson ( Spring / J2EE without EJB) préconise de ne pas

utiliser les EJB.
Il existe 2 types d'EJB :
- EJB Session ( avec 2 sous catégories Stateless Statefull) => contienne la
partie application et traitement métier
- EJB Entity ( aussi 2 types Bean Managed ou Container Managed) =>
Persistance des objets métiers

Ce qui est rebutant c'est la complexité de ces objets : pour un objet on
peut avoir à écrire 5 fichiers différents ( Home Interface, Remote
Interface, Locale Interface, JavaBean, descripteur de déploiement ( ce
dernier est mutualisé entre les Beans)). On a rajouté des artifices pour
simplifier la génération automatique de certains de ces fichiers ( Xdoclet,
Annotations ...).
L'intérêt des EJB est interessant dans un contexte transactionnel fort à
plusieurs datasources ( databases) devant supporter la norme XA ( 2 Phases
Commit).

Bonjour,

Il y a quelques posts, quelqu'un avait parle d'un livre ecrit par l'auteur
de SpringFramework ou il explique comment faire des trucs super bien *sans*
EJB.

Dans d'autres posts, je vois d'autres personnes qui disent que dans beaucoup
des cas, l'utilisation d'EJB n'est pas justifiee.

Moi, je debute a peine dans le JEE et je n'ai toujours pas une idee bien
claire de ce que sont les SpringFramework, Tomcat, EJB, Struts, etc .. (pour
ne pas dire que je nage encore dans l'ignorance la plus totale). Il y a 2
jours j'ai achete un livre sur les EJB, et bien sur le livre ne dit pas pour
quelle raison il ne faut pas utiliser les EJBs. Quand je vois les posts dans
cette newgroup, j'ai l'inquietude de faire fausse route en allant passer 2
semaines a lire mon bouquin.

Alors ma question est :
Quel est le probleme avec les EJB ? Pourquoi les gens parlent de l'eviter
quand c'est possible ?

je n'ai pas de reponses a ta question mais quel lien

http://www-igm.univ-mlv.fr/~dr/XPOSE2003/alexandrebole/jboss_4.html
http://jboss.com/products/jbosside/downloads
http://www.jyperion.com/jyperion-org-ws/pdfs.htm

http://www.labo-sun.com/resource-fr-essentiels-835-24-java-j2ee-ejb-2-les-entreprise-java-bean-javabeans-.htm
si tu as des liens sur de la doc en francais je prends




a+ remy

Bonjour,

Quel est le probleme avec les EJB ?

La technologie EJB est de loin la plus complexe et la plus lourde des
technologies JEE... Réaliser une application à base d'EJB est hautement
risqué et peut déboucher sur une catastrophe si les développeurs ne
sont pas experts en la matière. En particulier :
- Les EJB rendent les applications plus difficiles à tester.
- Les EJB rendent les applications plus difficiles à déployer.
- Les EJB peuvent casser le modèle objet.
- Les EJB peuvent rendrent compliquer certaines choses simples (singleton
par exemple).
- Choix de serveur d'application réduit.

Pourquoi les gens parlent de l'eviter quand c'est possible ?

Pour les raisons précédentes !


Pour revenir à un de votre commentaire :

Dans d'autres posts, je vois d'autres personnes qui disent que dans
beaucoup des cas, l'utilisation d'EJB n'est pas justifiee.

Effectivement l'utilisation des EJB n'est généralement pas justifiée.
Selon Rod Johnson (et vous aurez compris que c'est un peu mon gourou),
leur utilisation est justifiée lorsque :

- L'application à développer est une application distribuée
(Client lourd/Serveur) utilisant RMI/IIOP comme protocole de communication
naturel (Java des deux côtés).
- Les composants de l'application doivent être distribués sur plusieurs
serveurs physique.
- L'application doit supporter différents types de clients java ou CORBA.
- L'application nécessite l'implémentation de consommateurs de message
(message consumers) asynchrones (JMS).

Les considérations suivantes sont plus difficiles à trancher :

- Simplification du code d'une application multithreadée.
- Utilisation de la gestion transparente des transactions (Container
Managed Transaction, CMT).
- Utilisation du support de sécurité déclaratif basé sur les rôles.
- Les développeurs sont familiés des EJB.

Je pense que les grosse applications bancaires constituent une bonne cible
pour un projet EJB.

Moi, je debute a peine dans le JEE et je n'ai toujours pas une idee bien
claire de ce que sont les SpringFramework, Tomcat, EJB, Struts, etc ..

Tomcat : moteur de servlet faisant également office de serveur Web comme
Apache, mais pouvant aussi s'interfacer avec Apache pour ne s'occuper que
de la partie Servlet et JSP.
SpringFramework, Struts : framework s'interfaçant entre Tomcat et votre
code, rendu plus facile à écrire.
EJB : technologie JEE nécessitant un container d'EJB, un serveur
applicatif (JOnAS, JBoss, Websphere, Weblogic, JRun, etc.) Beaucoup de ces
serveur font également office de moteur de servlet comme Tomcat et de
serveur web (comme Apache et Tomcat).

Il y a 2
jours j'ai achete un livre sur les EJB, et bien sur le livre ne dit pas pour
quelle raison il ne faut pas utiliser les EJBs. Quand je vois les posts dans
cette newgroup, j'ai l'inquietude de faire fausse route en allant passer 2
semaines a lire mon bouquin.

Il est toujours intéressant de comprendre une nouvelle technologie comme
les EJB... ce n'est donc pas une perte de temps et cela fait toujours bien
sur un CV. De plus certaines société ne jurent que par les EJB... Si
vous souhaitez travailler dans de telles sociétés, mieux vaut connaitre
les EJB !


Mes sources sont toujours les mêmes :
Livres :
Expert one-on-one J2EE Development without EJB, Wrox, Rod Johnson,
Expert one-on-one J2EE Design and Development, Wrox, Rod Johnson,
http://www.springframework.org/

Bon courage !

--
David Jourand

Bonjour,

L'intérêt des EJB est interessant dans un contexte transactionnel fort
à plusieurs datasources ( databases) devant supporter la norme XA ( 2
Phases Commit).

C'est vrai, mais Spring Framework peut là aussi aider, en s'interfaçant
avec le container EJB (je ne sais pas bien comment, mais c'est a priori
possible), ce qui permettrait (a priori) de rendre des POJOs
transactionnels et de n'utiliser la technologie EJB que pour les objets
qui nécessite le support des transactions...

Si quelqu'un a des infos ou des retour d'expérience, je suis preneur.


--
David Jourand

Bonjour,

Ce que l'on t'as dit est vrai, mais les choses sont maintenant en passe
de changer drastiquement.

En premier il faut savoir que EJB est issu de Corba, est qu'il lui a
emprunté toutes ces capacités et fonctionalités (certains diront,
lourdeurs). C'est pour cette raison qu'il n'est pas toujours facile lors
que l'on débute de rentrer dans le sujet car on est tout de suite
confronté à pas mal de concepts qui sont du domaine de l'architecture
distribuée.

Il y a peu la situation était donc la suivant :
- Composant EJB Session : choix n'ayant aucun PB (sauf des choix de
clochers)
- Composant EJB Entités : complexe, lourd et peu performant
- Utilisation des EJB : complexe (bcp de code de "colle" )

Mais une la toute dernière spécification Java EE, la n°5 en phase de
finalisation change la donne en remaniant entre autre la partie entité
des EJB et en partant sur un modèle beaucoup plus léger et proche de
techno comme Hibertate ou Toplink (je fais pas de jaloux).

En clair, la situation est donc maintenant :
- EJB Session : toujours nickel, mais encore plus simple
- EJB Entités : simple et performant
- Utilisation des EJB : simple (injection via des annotations)

Enfin, Java EE 5 introduit pas mal de nouveaux concepts tels que l'IoC
que l'on trouve sous (d'autres framework comme Spring par exemple ) et
même la première étape sur une programmation orienté aspect (étonant que
gosling est laissé passé ça ;-) ).

Tu peux donc lire ton livre en diagonale pour savoir ce que sont les
EJB, mais il vaut pteut-être mieux directement passer à Java EE 5 ;..

http://java.sun.com/javaee/5/docs/tutorial/doc/

A+ et bonne découverte ...

TM

Bonjour,

Il y a quelques posts, quelqu'un avait parle d'un livre ecrit par l'auteur
de SpringFramework ou il explique comment faire des trucs super bien *sans*
EJB.

Dans d'autres posts, je vois d'autres personnes qui disent que dans beaucoup
des cas, l'utilisation d'EJB n'est pas justifiee.

Moi, je debute a peine dans le JEE et je n'ai toujours pas une idee bien
claire de ce que sont les SpringFramework, Tomcat, EJB, Struts, etc .. (pour
ne pas dire que je nage encore dans l'ignorance la plus totale). Il y a 2
jours j'ai achete un livre sur les EJB, et bien sur le livre ne dit pas pour
quelle raison il ne faut pas utiliser les EJBs. Quand je vois les posts dans
cette newgroup, j'ai l'inquietude de faire fausse route en allant passer 2
semaines a lire mon bouquin.

Alors ma question est :
Quel est le probleme avec les EJB ? Pourquoi les gens parlent de l'eviter
quand c'est possible ?

--
Un programmeur inquiet.

Vincent Cantin wrote:

Bonjour,

Il y a quelques posts, quelqu'un avait parle d'un livre ecrit par l'auteur
de SpringFramework ou il explique comment faire des trucs super bien *sans*
EJB.
J'ai mis sur mon site une présentation - formation sur Spring :

http://jmvanel.free.fr/spring-training/

....

Alors ma question est :
Quel est le probleme avec les EJB ? Pourquoi les gens parlent de l'eviter
quand c'est possible ?
Pour compléter ce qu'ont dit les autres, la tendance en 2006 est

d'écrire des classes métiers toutes simples, sans aucune dépendance à
l'infrastructure, que ce soit base de données ou serveur d'application .
C'est ce qu'on appelle POJO (Plain Old Java Object) . Ca facilite les
tests automatisés avec JUnit, et ça peut être déployé en ligne de
commande, Swing, ou Web. Ces POJO sont ensuite instrumentés par
différentes techniques d'interception au niveau du code binaire (GCLib,
AOP, ...) . C'est ce qui permet à Hibernate de gérer la persistence sur
base relationnelle mieux que CMP - EJB, et à Spring de gérer les
permissions et les transactions déclarativement, tout comme EBJ mais
sans serveur d'application.

Merci a tout le monde pour tous vos conseils et infos, vous m'etes d'une
aide tres precieuse.

Pour repondre a quelques posts, je ne cherche pas a trouver du boulot, j'ai
mon propre projet d'application a mener a bien a partir de zero. Je quitte
ma compagnie demain soir pour m'y mettre a plein temps.

J'ai fait un tour par chez spring, j'ai toujours pas trop compris mais
j'imagine que ca va venir avec de la patience. Je vais perseverer.

En attendant, je vais suivre les conseils de Jean-Marc et faire mes classes
metier en POJO. C'est ce que je pensais faire apres avoir jete un coup
d'oeil a JEE5 de toutes facons. J'imagine que quand j'aurai fini, les
nouveautes de JEE5 seront deja bien documente et plus facile a apprendre.

Je n'ai toujours pas ma reponse pour les remote objets dans JMS, mais
maintenant je pense que je vais identifier les objets distants en parametres
de maniere differente .. surement je vais utiliser un champs qui va servir
d'@ID a l'entitee distante, le serialiser tel quel, et du cote consomateur
me debrouiller pour avoir une reference sur l'entite en question.

Bon, c'est cool :-)
Encore merci.

Vincent