[Architecture] Un point sur les normes EJB et les serveurs J

Version imprimable

21/12/2005, 11h31
tetram51

[Architecture] Un point sur les normes EJB et les serveurs J

Bonjour à tou(te)s,

Je bataille aujourd'hui pour faire adopter par mon entreprise les serveurs d'applications J2EE, et donc commencer à basculer vers une architecture distribuée. J'aurais aimé connaître votre point de vue sur les arguments que l'on m'a opposés, ainsi que quelques clarifications qui ne feront pas de mal.

Normes EJB
Tout d'abord, concernant l'utilisation des EJBs, je me suis vu répondre que la norme EJB n'était pas encore stabilisée et en constante évolution.
Alors que la plupart des serveurs sont validés pour la norme EJB 2.0 et qu'apparaît la norme 3.0, on peut effectivement s'interroger. Les changements entre les normes sont-ils importants ? Vaut-il mieux attendre la norme 3.0 ou bien commencer avec la mature 2.0 ?
Question complémentaire : qu'en est-il des protocoles utilisés pour la communication (CORBA, SOAP, RMI...)

Serveurs d'application
Après discussions, si serveur d'application il y a, il sera choisi entre JOnAS, JBoss ou Websphere. JOnAS et JBoss parcequ'ils sont libres, ou WAS parcequ'il est déjà utilisé dans le groupe (choix le plus probable, au passage).
Sans être redondant avec le post-it "[SERVEUR J2EE] Quelles différences entre les serveurs J2EE ?", mais pour actualiser un peu (la plupart des posts datent de 2003, la situation a certainement évolué depuis), qu'en est-il aujourd'hui de ces serveurs en terme de coût de possession, de perennité de la solution (cette dernière question concerne plus JOnAS, apparemment en perte de vitesse) et.. de performances ?

Merci pour tous vos commentaires/retour d'expériences.
Thomas
21/12/2005, 12h19
ego

Tout d'abord, l'argument "non stable" n'est pas un bon argument car il y a plein de cas de grosse sociétés qui utilisent des EJBs dans des contextes très critiques (comme ma boite, une très grosse Banque).

Les vraies questions à se poser sont :
"A t-on besoin d'une archi distribuée ?"
Si, oui, quels problèmes veut-on résoudre ?

Ensuite, si oui, tu as besoin d'une archi distribuées pour de vraies raisons, il faut voir quelle techno est la plus adaptée en terme d'intégration avec l'existant, types de clients, besoins transactionnels, sécurité,...
Actuellement, tu n'as pas 3000 solutions dans ce domaine. Tu as CORBA, WebServices, MOM, EJB, .Net Remoting si tu restes dans les "standards".

Une vraie raison pour utiliser les EJBs ou équivalent et le besoin de distribution car sinon, tu as les containers légers comme SPRING qui savent gérer pas mal de pbs techniques.

Pour le choix du serveur d'application, je regarderai plutôt les besoins en termes d'intégration avec l'existant. Par exemple, qu'y a t-il côté JBoss pour faire de l'intégration de programmes COBOL qui tournent sur MVS ? Je ne sais pas si c'est une de tes problématiques mais c'est le genre de truc qui peut faire la différence.
Ensuite, si ta boite utilise déjà WAS et a développé des trucs autour et surtout de l'expérience côté développement et administration en Production, le changement de serveur d'appli doit être bien réfléchi.

Donc en bref, les EJBs, pas de problème s'ils résolvent des problèmes identifiés, ça marche très très bien en prod.
Le problème est ailleurs en fait...........
21/12/2005, 16h03
tetram51

En réalité nous n'utilisons aujourd'hui ni serveur d'application ni distribution (c'est le groupe auquel appartient ma société qui utilise WAS). Quelque soit le serveur choisi, il y aura donc un effort en terme de formation pour acquérir les compétences tant au niveau de la production que des développements.

C'est pourquoi je tente d'actualiser les connaissances sur les produits du marché, et je valorise beaucoup plus vos retour d'expérience que les brochures publicitaires (va savoir pourquoi ? :roll:)...

Après, comme tu dis, le choix ou non d'adopter une architecture distribuée correspond à une reflexion de fond sur l'évolution du système d'information de l'entreprise, les besoins en distribution etc.

Mes questions complémentaires seront donc :
- faut-il attendre la norme EJB 3.0 pour lancer des développements ?
- avez de récentes expériences sur WAS / JOnAS / JBoss à faire partager ?
21/12/2005, 17h31
ego

Pour ce qui est d'attendre les EJB3.0, je dirai non dans la mesure où tu peux faire pratiquement pareil en mieux avec SPRING. Moi j'utilise SPRING et des objets métier type POJO et si j'ai besoin de distribution, je crée simplement une "facage" EJB qui délègue directement à mon POJO.
C'est plus flexible et très facile à tester.
Pour les expériences WAS et JBoss et bien tout fonctionne correctement en prod. Je dirai juste que JBoss est plus simple à tout les niveaux (dév. et prod.)
21/12/2005, 18h25
tetram51

Merci beaucoup pour tes réponses !
21/12/2005, 21h12
FreshVic

Citation:

Envoyé par ego

Pour ce qui est d'attendre les EJB3.0, je dirai non dans la mesure où tu peux faire pratiquement pareil en mieux avec SPRING. Moi j'utilise SPRING et des objets métier type POJO et si j'ai besoin de distribution, je crée simplement une "facage" EJB qui délègue directement à mon POJO.
C'est plus flexible et très facile à tester.
Pour les expériences WAS et JBoss et bien tout fonctionne correctement en prod. Je dirai juste que JBoss est plus simple à tout les niveaux (dév. et prod.)

Salut,
Je vais peut etre dire une connerie mais pour le coté distribué les Web services sont aussi une solution envisageable non?
21/12/2005, 22h44
ego

oui mais je trouve cela un peu chi..t pour le moment
29/12/2005, 11h27
alexismp

Re: [Architecture] Un point sur les normes EJB et les serveu

Citation:

Envoyé par tetram51

Normes EJB
Tout d'abord, concernant l'utilisation des EJBs, je me suis vu répondre que la norme EJB n'était pas encore stabilisée et en constante évolution.
Alors que la plupart des serveurs sont validés pour la norme EJB 2.0 et qu'apparaît la norme 3.0, on peut effectivement s'interroger. Les changements entre les normes sont-ils importants ?

EJB 3 change la vie du développeur de manière sensible. Ce que certains outils de développement arrivaient à masquer au développeurs (nombre de fichiers à maintenir en synchro, packaging, rédaction descripteur de déploiement), la spec l'impose presque de fait. EJB 3 (Java EE 5) c'est pour le printemps 2006. Ne pas oublier non plus la nouvelle API de persistence introduite dans Java EE 5 (il n'y a pas que l'aspect POJO).

Citation:

Envoyé par tetram51

Serveurs d'application
Après discussions, si serveur d'application il y a, il sera choisi entre JOnAS, JBoss ou Websphere. JOnAS et JBoss parcequ'ils sont libres, ou WAS parcequ'il est déjà utilisé dans le groupe (choix le plus probable, au passage).

Je rajouterai GlassFish, probablement un des premiers serveurs Java EE 5 à sortir (également Open Source). Au moins pour apprendre EJB 3 et Java EE 5 (beaucoup de docs, et blogs (AJAX, EJB 3, Persistence EJB 3 avec ou sans EJB, etc...)). Des offres commerciales avec support suivront rapidement.

Pour le passage d'un serveur d'applications à un autre (ou l'utilisation de plusieurs en //), je te conseille de regarder l'AVK (kit gratuit) qui permet de mesurer le niveau de portabilité d'un application J2EE.