Discussion :

[raj]

Bonjour,

j'aimerais avoir l'avis de plusieurs Ingénieur J2EE sur le réel apport des EJB
pour le développement d'un projet J2EE .

Supposons un projet J2EE avec des contraintes tres fortes (grosse montée en charge et demande de temps de réponse tres court ) .
Est-ce que les EJB s'imposent dans un tel projet ?

La technologie EJB étant une technologie assez lourde, elle doit je pense avoir des avantages (bien que j'ai plusieurs collègues qui ne le voit pas sous cet angle ) .
Sinon je ne vois pas l'interet d'utiliser un serveur applicatif comme JBoss ou Websphere si Hibernate suffit pour la persistance (un simple serveur Tomcat ferait l'affaire ) .


Voilà
Merci d'apporter votre vision et votre expérience sur le sujet

[sleepy2002]

Salut,

un excellent livre de Rod Johnson qui est à l'origine de Spring :
J2EE Development without EJB

Il traite les points forts et faibles d'EJB et la confronte avec les technologies courantes.

Pour ma part, je commence à devenir accroc à Spring . C'est d'une flexibilité inouï et la productivité est bien meilleure (cad on passe plus de temps sur la logique applicative que le reste).

[dlemoing]

Si tu veux pouvoir monter en charge, il va falloir ajouter du matériel verticalement ou horizontalement (ajout de mémoire, composants... ou ajout de nouveaux serveurs avec fonctionnement en cluster).
Les serveurs d'applications offrent des fonctionnalités avancées dans le second cas, ce que ne fait pas tomcat (support limité).
sleepy2002 t'a donné une bonne référence. Les EJB se justifient rarement, en tout cas de moins en moins avec des frameworks comme Spring.

[raj]

Merci à toi dlemoing et aussi à toi sleepy2002
Donc si je comprend bien d'après vous les EJB c'est une technologie à jeter à la poubelle .

Mais la plupart des serveurs applicatifs qu'on voit aujourdh'ui sont d'abord des containers EJB, il faut donc jeter websphere et compagnie (weblogic, jboss, etc ..... ) et n'utiliser que des containers "léger" ( je rappelle que Spring est né de l'idée de disposer d'un container plus léger, faisant appel au design pattern injection de dépendance ) .

Mais je me pose vraiment la question :

N'y a-t-il vraiment pas de point positif à la techno EJB ?
(sachant que des normes comme EJB++ se développent, c un mélange d'EJB et de CCM CORBA )

[zekey]

Salut,

moi aussi je suis accro au couple spring/hibernate.
Et certaines de mes applications doivent supporter
120-150 utilisateurs (ce qui n'est certes pas enorme mais bon je connais pas bcp d'appli intranet qui doivent en supporté davantage) simultanés faisant pas mal de query et de business. Simplement la charge est partagé au niveau session par des load-balancers

Cependant si EJB n'avait aucun interet pourquoi avoir lancé la nouvelle norme 3.0. et surtout pourquoi avoir fait de hibernate 30. une implementation des EJB 3.0 ?

Je sais c'est plus de questions que de réponses

---------------------------------------------
Steve Hostettler
zekey@hotmail.com / www.zekey.net

[dlemoing]

Mais la plupart des serveurs applicatifs qu'on voit aujourdh'ui sont d'abord des containers EJB, il faut donc jeter websphere et compagnie (weblogic, jboss, etc ..... ) et n'utiliser que des containers "léger" ( je rappelle que Spring est né de l'idée de disposer d'un container plus léger, faisant appel au design pattern injection de dépendance ) .

Les serveurs d'applications fournissent un certain nombre de services que tomcat n'offre pas. L'exemple le plus connu est celui des transactions. Tomcat par défaut n'offre pas de support pour les transactions distribuées (on notera toutefois que toutes les applis n'ont pas besoin de ca), contrairement à JBoss, Weblogic, Websphere, etc... Souvent on a valorisé les EJB en utilisant cet argument des transactions distribuées, seulement la vérité est que ce service étant fourni par le serveur d'applis, il est accessible à n'importe quel objet qui en fait la demande. C'est ce que fait Spring en utilisant JTA.
Il ne faut donc pas confondre les EJB et les serveurs d'applications.

Mais je me pose vraiment la question :

N'y a-t-il vraiment pas de point positif à la techno EJB ?
(sachant que des normes comme EJB++ se développent, c un mélange d'EJB et de CCM CORBA )

Dans un cas, les EJB sont la plus simples des solutions : les Message Driven Beans. C'est le seul cas où les EJB sont vraiment intéressants. Les EJB entity (BMP et CMP) n'ont jamais été une bonne solution.
Concernant les EJB Session, c'est plus discutable...regarde dans les bouquins cités.

Cependant si EJB n'avait aucun interet pourquoi avoir lancé la nouvelle norme 3.0. et surtout pourquoi avoir fait de hibernate 30. une implementation des EJB 3.0 ?

Les EJB 3.0 ont peu de choses en commum avec les EJB version 2.x. Ils se rapprochent bcp plus du modèle de Spring (mais en moins bien à ce que j'ai vu, ca n'engage que moi) et introduisent une nouvelle norme de persistance qui semble intéressante.

[fedfil]

Pour rebondir sur les propos dlemoing, il faut bien séparer les EJB Entity (gestion de la persistance) aux EJB Session.

De part la complexité à mettre en oeuvre les EJB Entity et ses limites (comme les requêtes par exemple), les EJB Entity (dans leur version 2.0) ne sont pas beaucoup utilisés dans les entreprises.

Par contre, les EJB Session le sont beaucoup plus. (Grâce nottament à la gestion de la transaction) De plus en plus de projet utilise les EJB Session pour l'aspect service et Hibernate pour l'aspect Persistance.

Reste à connaître les contraintes de ton projet.
Quand à Spring, il est encore méconnu par les SI des boîtes (ça n'engage que moi mais pour l'instant, la référence des clients reste STRUTS) mais il vrai que Spring est très puissant !!

[dlemoing]

Par contre, les EJB Session le sont beaucoup plus. (Grâce nottament à la gestion de la transaction) De plus en plus de projet utilise les EJB Session pour l'aspect service et Hibernate pour l'aspect Persistance.

C'est vrai que c'est souvent fait comme ca. Par contre, il ne faut pas coder l'implémentation du service directement dans l'EJB. Il vaut mieux déléguer à un objet. L'EJB sert alors de proxy transactionnel.
Pour être un peu plus critique, je dirais que cette approche était valable il y a 2-3 ans. Elle l'est moins si on a la possibilité d'utiliser Spring: regarde la transformation de l'exemple de J2EE Design and Development, le premier livre de Rod Johnson (Interface21, qui deviendra Spring, POJO, EJB pour les transactions, JBDC) qui a été modifié dans son dernier livre (Profesional Java Development with the Spring Framework) pour tenir compte de la dernière version de Spring (Spring à tous les étages, POJO, Hibernate).

[ego]

Oui, la lecture de Rod Jonhson est une bonne source...
Mais attention aux réponses basiques un peu toutes faites.
Les bonnes questions à se poser sont :
1- Ai-je des ruptures de protocoles obligatoires dans mon architecture ?
2- Ai-je obligatoirements plusieurs DMZ qui m'oblige à séparer Serveur Web et Serveur applicatif ?
3- Puis-je gérer la montée en charge avec un load-balancer côté session http ou ai-je besoin d'un cluster de serveur applicatifs ?
4- Ai-je besoin de transaction distribuées ?
5- Ai-je besoin de supporter des clients autres que Web ?
6- Ai-je besoin de m'insérer dans un mécanisme de sécurité standard ?
7- ........

Dans l'affirmative pour 1, 2, 4, 5, 6, la solution EJB peut être une bonne solution et dans ce cas une solution s'appuyant uniquement sur SPRING n'est pas suffisante.
Je suis moi même un adepte de SPRING mais attention, SPRING ne résoud pas tout et même si les conteneurs légers sont à la mode et résolvent pas mal de problèmes, ils ne sont pas LA solution à tout.

Bref, il ne s'agit pas de choisir une solution parce qu'elle est sympa ou à la mode mais il faut que la solution réponde aux vraies questions qui se posent.

[raj]

Cool

Merci pour toute ses réponses ! .
Je vais faire un tour du coté de Spring dont je ne cesse d'entendre
du bien ! .

Je bosse actuellement que sur Jetty, mais je me forme des que j'ai le temps
libre sur JBoss (et les EJB ) .
Mon but étant de savoir si apprendre les EJB reste intéressant vue que j'entends tellement de mal sur cette technologie .

Spring par contre j'en entends que du bien, mais du coté des offres d'emploi dessus, ca reste le néant.

[dlemoing]

1- Ai-je des ruptures de protocoles obligatoires dans mon architecture ?

Je ne comprends pas bien ce point

2- Ai-je obligatoirements plusieurs DMZ qui m'oblige à séparer Serveur Web et Serveur applicatif ?

Pourquoi Spring ne le permettrait pas ?

4- Ai-je besoin de transaction distribuées ?

Spring peut s'appuyer sur JTA (tout comme les EJB). Dans ce cas précis, on a besoin d'un serveur d'applications avec un transaction manager mais on n'est pas obligé d'utiliser des EJB.

5- Ai-je besoin de supporter des clients autres que Web ?

Spring peut exporter/atteindre des services utilisant différents protocoles (RMI, XML-RPC, Hessian, Burlap, ...)

6- Ai-je besoin de m'insérer dans un mécanisme de sécurité standard ?

Je ne connais pas trop ce point mais ACEGI semble être très prometteur dans ce domaine.

Je suis moi même un adepte de SPRING mais attention, SPRING ne résoud pas tout et même si les conteneurs légers sont à la mode et résolvent pas mal de problèmes, ils ne sont pas LA solution à tout.

On est d'accord (je suis également un adepte de Spring).

Bref, il ne s'agit pas de choisir une solution parce qu'elle est sympa ou à la mode mais il faut que la solution réponde aux vraies questions qui se posent.

On choisit également une solution en considérant son design (flexibilité, ouverture, architecture, cohérence, principes, ...) et en considérant ce point, Spring est, à mon avis, ce qui se fait de mieux à l'heure actuelle.

Concernant les réponses "basiques", mes réponses sont courtes parceque je ne souhaite pas passer ma vie à répondre. Par contre, la plupart des choses que j'affirme viennent de ma pratique et ne sont pas des réponses toutes faites.
Je te retourne la remarque, pourquoi n'as tu pas justifier tous les points que tu cites ? Ce ne sont pas des réponses toutes faites ?

[ego]

ego a écrit:
1- Ai-je des ruptures de protocoles obligatoires dans mon architecture ?
Je ne comprends pas bien ce point

Ce point est un peut lié au point 2 sur les DMZ. Tu peux être obligé dans un SI de respecter les règles "on parle HTTP entre le browser et le ou les serveurs Web ou application" et on parle "JRMP ou IIOP" entre les autres serveurs d'applications hébergent les services métiers. C'est cela la rupture de protocole. Dans ce cas, tu ne peut pas tout héberger sur un serveur d'application puisque d'autres services existent sur d'autres serveurs d'application; tu dois donc faire des appels 'remote'. Les EJBs sont donc utilent ici même si on peut faire autrement, avec des WebServices par exemple.

ego a écrit:
2- Ai-je obligatoirements plusieurs DMZ qui m'oblige à séparer Serveur Web et Serveur applicatif ?
Pourquoi Spring ne le permettrait pas ?

Même réponse que ci-dessus mais en fait ces 2 points sont souvent liés et les avoir mis en avant séparément n'est peut être pas une bonne idées de ma part.

ego a écrit:
5- Ai-je besoin de supporter des clients autres que Web ?
Spring peut exporter/atteindre des services utilisant différents protocoles (RMI, XML-RPC, Hessian, Burlap, ...)

oui mais je voulais mettre en avant, ici, le vrai besoin de distribution induit par l'existance de client non Web. Effectivement, il y a d'autres moyens que les EJB pour faire de la distribution mais la question doit être posée et elle peut en partie justifier l'usage d'EJB ou tout au moins le fait que faire du Spring seul n'est pas suffisant. On pourrait aussi parler de l'hétérogénéité des clients. Si on a des clients J2EE et .Net, les WebServices sont probablement plus appropriés que les EJBs.

ego a écrit:
6- Ai-je besoin de m'insérer dans un mécanisme de sécurité standard ?
Je ne connais pas trop ce point mais ACEGI semble être très prometteur dans ce domaine.

Prometeur, peut être mais si dans le SI il y a déjà des EJBs avec la mise en oeuvre de la sécurité liée à J2EE, on a peu de choix pour propager le contexte de sécurité.

ego a écrit:
Bref, il ne s'agit pas de choisir une solution parce qu'elle est sympa ou à la mode mais il faut que la solution réponde aux vraies questions qui se posent.
On choisit également une solution en considérant son design (flexibilité, ouverture, architecture, cohérence, principes, ...) et en considérant ce point, Spring est, à mon avis, ce qui se fait de mieux à l'heure actuelle.

Avant d'être flexible, cohérente et ouverte, une solution doit répondre aux exigences "premières" ou contraintes imposées.

Pour ce qui est de tes réponses, ma remarque initiale n'a absolument rien d'une attaque contre toi. Je faisais cette remarque d'une manière générale car je vois trop de gens qui utilisent des trucs parce qu'ils sont à la mode sans se poser la question de ce qu'il doivent faire réellement et à quoi servent réellement ces trucs.
Donc pas de soucis pour tes bonnes réponses concises

[nico2280]

Machin a dit :
La technologie EJB étant une technologie assez lourde, elle doit je pense avoir des avantages (bien que j'ai plusieurs collègues qui ne le voit pas sous cet angle ) .

Tes collègues ont raison, ne rentre pas dans l'enfer des EJBs, vite, fuis !!!!
Il paraît qu'avec la v3 ça s'arrange mais de toute façon ça pouvait pas être pire...
Mon conseil : si tu peux faire autrement, fais-le.

[YAMKI]

Si je peux apporter mon expérience de "novice".

Pour ma part je participe à mon deuxième projet J2EE.

Le premier, nous avons fait une archi "parfaite J2EE" en utilisant des EJB. Mais bon c'était un peu utopique car dans la pratique c'est hyper lourd a gérer. Nous avions utilisé des Entity a tout va sauf pour la lecture ou nous utilisions des DAO. Les perfs n'étaient pas trop importante puisque notre appli n'est que peu solliciter par les utilisateur (environs 400 connexion/jours).

Pour le second projet. Les connexions sont bcp plus importantes et la persistance des données moindre. Résultats on va tout faire en DAO. Plus performants et plus simple à maintenir et deboguer par rapport aux EJB qui masquent tout. On n'utilise pas Hibernate/Spring pour la simple raison qu'il n'y a pas de connaissance dans l'équipe ni dans la boite. Résultat, plus dure de ce lancer dans ce genre de techno pour un projet qui a des délais très court.

En gros, je te conseil si tu n'a pas encore mis le nez dans les EJBs de ne pas t'occuper des EJB 2.0. Ils sont dépassé. Quitte a te lancer dans l'apprentissage des nouvelles techno, étudie plus Hibernate (de plus en plus utilisé dans les boite) ou vers les EJB 3.0 qui sont basé sur els même specs qu'Hibernate. Par contre cette dernière techno n'est pas encore validé si je ne dit pas de bétise donc doit faire ses preuves.

L'intentions des EJB 2.0 était très bonnes, la réalisation était trop brouillon. Mais j'aurais tendance à dire que sans eux ont aurait pas la chance de pouvoir utiliser Hibernate ou de pouvoir espérer quelquechose des EJB 3.0

[dlemoing]

Le premier, nous avons fait une archi "parfaite J2EE" en utilisant des EJB.

Ton architecture avait quoi de "parfait" (ne pas utiliser de DAO même pour un entity bean me fait douter...) ? J2EE != EJB : si tu utilises des EJB tu fais du J2EE mais l'inverse n'est pas forcément vrai.

Mais j'aurais tendance à dire que sans eux ont aurait pas la chance de pouvoir utiliser Hibernate ou de pouvoir espérer quelquechose des EJB3.0

Je ne comprends pas bien, tu dis que les EJB ont donné naissance à Hibernate ??? L'idée de l'ORM précéde celle des EJB et voila un lien pour prouver ce que je dis (je précise que le serveur d'applis d'oracle utilisera toplink pour la persistance avec les EJB3 et qu'Hibernate sera utilisé dans JBoss et pas dans toutes les implémentations de la norme...). Pour ma part, je pense que c'est la pratique des EJB 2.0 qui a donné naissance aux frameworks du type Spring (voir les objectifs de Spring) qui ont fortement influencé la norme EJB 3.0.

Sinon, je suis d'accord : pas d'EJB 2.x, attendre la norme 3.0 pour évaluation et sinon regarder du côté du couple Spring/hibernate.

[YAMKI]

Quand je disais "parfaite", je voulais dire théorique. En gros si tu prends notre dossier d'archi, tu pourrais l'utiliser pour faire un cours sur les EJB et le J2EE. Tu y retouve presque tous les design pattern et l'utilisation des EJB comme si grace à eux tout allais tourner niquel.

Pour la seconde partie, autant pour moi j'ai fais une erreur. Je ne suis pas un développeur et donc suis un peu de loin l'état de l'art je m'appui que sur mon expérience et ce que j'enbtends autour de moi. Vu que j'ai commence dans un premier temps à entendre parlé des EJB 2.0 comme un truc révolutionnaire, apres on a commencé à le descendre, puis on a parlé d'Hibernate et enfin des EJB 3.0. Je pensais que c'était leur ordre de sortie. Si ce n'est pas le cas, j'aiemrais bien qu'on m'explique pourquoi avoir fait les EJB 2.x si en parrallèle certain préparé Hibernate qui ne comporte pas tous les bug des EJB. Mais bon c'est peut etre rentré dans un grand débat.


Désolé si je n'utilise pas toujours le bon vacabulaire j'écrit comme je comprend les choses et j'ai un peu de mal a suivre le vocabulaire pure dev.

[dlemoing]

Pour être plus précis, Hibernate est apparu après les EJB 2.x mais le concept de l'ORM (mapping objet/relationnel) n'est pas nouveau et precede les EJB.
Pour comprendre le pourquoi de tout ca, il faut connaitre le fonctionnement du JCP (Java Community Process) et effectivement on risque de rentrer dans de longues explications...