janvier
2008
Un article de Hikage
Comme le dis Rod Johnson dans son article , une indication sur la réelle adoption d’une technologie est le nombre de propositions de jobs qui lui est associé.
En effet, plus le nombre est important, plus la confiance de la part des entreprises pour cette technologie est grande. Il est sous entendu à cela que les entreprises l’ont testée, et que le résultat a été suffisamment bon ( en terme de temps de développement, de performances, de maintenance, de cout ) que pour l’utiliser sur d’autres projets.
Dans ce but, le site JobTrends permet de se faire une idée.
On peut remarquer que le nombre de demandes pour des connaissances de Spring ont dépassé le nombre de demandes pour les EJB :
Attention, cela ne veut pas dire que EJB est à jeté aux oubliettes, mais l’on peut estimer que le nombre de nouveau projets basés sur le framework Spring est toute même plus important que le ceux basés exclusivement sur les EJB.
Je dis bien exclusivement, car si vous connaissez un tant soit peu Spring, vous savez qu’il est tout à fait possible d’utiliser les EJB et Spring conjointement.
16 Commentaires + Ajouter un commentaire
Commentaires récents
- dans SpringSource acquiert Hyperic
- dans Sortie de la huitième béta de SpringSource Application Platform (S2AP)
- dans Sortie de la huitième béta de SpringSource Application Platform (S2AP)
- dans Sortie de la huitième béta de SpringSource Application Platform (S2AP)
- dans Spring One 2008 en direct – Jour 1
Bonjour,
@Zedros: comme l’a dit lunatix, il ne faut plus confondre JPA et EJB3: JPA = EJB – la partie persistance, qui c’est vrai est une superbe idée et JPA peut être utilisé indépendamment et même dans un environnement Java SE.
@Lunatix: pour les annotations, je comprends ton point : les POJOS annotés sont liés à des bibliothèques externes, mais justement, les autres ont eux aussi compris ce point, et de ce fait, on assiste à un mouvement de standarisation et d’intégration des annotations dans le JRE de base (javax.annotation) comme par exemple PostConstruct,Resource, etc.
De plus,même pour les annotations non encore integrés dans le JRE, on n’a pas org.hibernate.Entity et com.oracle.toplink.Entity mais toujours javax.persistence.Entity quelque soit l’implémentation si tu voix ce que je veux dire
Je trouve que les annotation pour gerer les injections, ca colle pas trop. on fini par relier le code a l’implementation, alors que c’est ce qu’on cherchait a éviter.
par contre, dans le cadre de JPA, c’est du bonheur, ou le @Transactional pour gerer les transasctions
implementation pure JPA/EJB 3 : ben non, puisque tout l’interet de cette spec, c’est d’avoir un jpa plugable EJB3, mais independant (du coup, on peut utiliser jpa en java SE classique)
(@lunatix) au final il existe des solutions purement JPA/EJB 3 ? Arf, faudrait qu’j’trouve le temps d’avancer dans mon chtit EJB 3 In action !
Clairement Spring fait plus, mais il me semblait aussi qu’il voulait gagner en vitesse (en réaction à Guice). Je ne sais plus bien s’ils en parlaient dans les releases notes de la 2.5. Je regarderai plus tard.
Pour les annotations, il me semble que certaines annoatations d’injection sont désormais un standard JEE non ?
Par ailleurs, il me semble aussi (mais j’ai jamais testé vraiment en fait lol) que si jamais il y a des annotations mais sans le framework qui les traite, alors elles sont tout simplement ignorées à la compilation. Ca reste du non strictement POJO ceci dit, on est d’accord
Perso, à propos, j’ai un mauvais souvenir d’XML hell avec une application Spring/Struts. On passait notre temps à grenouiller dans des fichiers de config, et franchement on aurait bien apprécié des annotations, j’t’l’dis moué
As tu un avis sur la question ?
Y a pas de problème, je n’y vois pas d’attaque non plus
Je n’ai pas encore regarde à Guice non plus, mais comme le dit Lunatix et ce que j’ai pu en lire, Spring fait nettement plus.
Par contre, on doit à Guice la réaction de Spring pour ce qui est annotation en effet. Mais d’apres ce que j’en ai entendu, il y a beaucoup d’avis mitigé.
Oui, les annations permettent de réduire fortement un ficheir de configuration, mais les POJOs développé ne sont plus completement indépendant de Spring .. vu qu’ils sont liés au framework par les annotations.
guice demarre plus vite, mais ne fait pas le 1/100 de spring. c’est un pur petit moteur d’injection. c’est tout
pour JPA : hibernate : JPA, c’est une api de persistance (implementé par hibernate par exemple), qui est utilisé dans les EJB pour la persistance des Ejb entity. En clair, JPA c’est independant des EJB3, mais utilisé dedans (superbe idée)
Spring et les web services : oui,c’est de l’integration, et avec l’intergration d’une api JAX-WS c’est pareil que dans un serveur d’application
merci Hikage.
Je ne cherche pas à défendre/attaquer mais juste à comprendre, n’y voit pas d’attaque ! =)
Si jamais mes questions sont mal tournées n’hésite pas à me le faire savoir !
Tient, à propos de question, j’ai en encore
: as tu déjà essayé/comparé Guice et Spring ? J’pense surtout à Spring 2.5 où les annotations sont bien plus présentes si je me souviens bien :$
Pour ma part, de mémoire toujours et d’après des tests faits à l’époque de la sortie de Guice, il me semblait que Guice avait un temps d’arrêt/relance bien plus court. Qu’en dis tu ?
Pour ta culture, non je n’ai pas encore eu l’occasion de faire une comparaison EJB3 Spring sur ces points.
J’avoue ne pas connaitre les fonctionnalités non plus l’intégralité des EJB3, faute de temps.
Mais comme tu peux t’en douter si tu suis ce blog, je m’intéresse beaucoup à Spring, donc je peux défendre plus facilement celui-ci.
Pour ce qui est de l’intégration, oui tu n’a pas « tord » en soit. Spring est un conteneur au départ. Il ne fait donc pas office de serveur JMS il te faut donc un ActiveMQ ou autres à coté, mais Spring fournit des classes de connection, et d’aide à l’utilisation.
En ce qui concerne le remoting, HttpInvoker est interne à Spring si je m’en rappelle bien. Burlaps et Hessian sont externe et nécessite des jars sur le coté, mais un service sera sous la forme d’un POJO que les classes d’export de Spring « décoreront » ( via un proxy ou des aspects ), pour en faire un service Hessian ou Burlaps.
En ce qui concerne la facilité, j’ai parle d’un système que j’ai teste que je sais que cela marche ( export via interface, implémentation ).
Maintenant, il est possible d’utiliser des classes annotées par @WebService pour faire un export XFire/Spring aussi, mais je n’ai encore jamais testé
De toute manière, je vais devoir approfondir tout cela dans le cadre de mes études pour la certification, et j’en profiterai sans doute pour faire des articles sur Developpez.
Tu auras ainsi l’occasion de voir les possiblités de Spring en terme d’intégration avec d’autres framework existants
@lunatix : je ne savais pas qu’un serveur d’application pouvait se servir de JPA pour fournir une couche DAO avec comme implémentation Hibernate, merci.
Autrement dit, si je comprends bien (pas évident ça ;)) : faire de l’hibernate via JPA (+ annot hibernate), c’est faire de l’EJB 3 pour la couche DAO, on est ok ? Ou alors c’est juste le cas où on fait la couche DAO via JPA + serveur d’applications fournissant l’implémentation ?
@Hikage : aucun souci, au contraire, ton post est très intéressant
Perso je ne faisais que répéter les propos d’une connaissance et, surtout, ce que je suis en train de lire dans EJB 3 in action, qui vante les avantages en termes de remoting/JMS d’EJB 3 sur Spring.
Pour ce qui est de :
« XFire/Spring permettent de déployer des WebService sans annotations aucune.. à partir d’une simple interface et implémentation. »
-> euh, ce n’est pas plus simple d’utiliser une simple annotation @Remote/@WebService que de devoir implémenter une interface ?
Autre remarque, dans le cas cité Spring ne ferait il pas plutôt de l’intégration de frameworks tiers ? Pour toi est ce toujours « du Spring » ?
Pour JMS, le bouquin semble dater de 2007 (merci tout de même au copain qui me le prête) et que du coup Spring 2.5 a pu changer la donne depuis.
Pour ma culture perso, Hikage, as tu pu comparer par toi même EJB 3 et Spring/httpinvoker ou la partie JMS ?
Encore merci en tout cas
++
« A l’inverse, pour autant que je puisse en croire mon EJB 3 In action et un contact récent, les EJB 3 c’est aussi un moyen efficace et aisé de consommer/produire des messages JMS et de faire du remoting, ce qui n’est pas le cas de Spring »
Je ne suis pas du tout d’accord…
XFire/Spring permettent de déployer des WebService sans annotations aucune.. à partir d’une simple interface et implémentation.
A coté de cela, si on travaille de Java à Java, Spring intègre HttpInvoker, qui est ultrasimple à utiliser.
Il y aussi des intégrations RMI, Burlaps et Hessian ..
Coté remoting, je doute que Spring soit à la traine.
Pareil pour JMS, Spring permet de déclarer des producteur et consommateur de messages facilement. Et cela a encore été amélioré depuis Spring 2.5 avec un namespace dédié pour réduire la complexité.
Voila
Pour information Joseph/ZedroS, je ne t’agresse pas, mais comme tu le dis toi meme, beaucoup de monde utilise Spring parce que c’est à la mode, mais ne connaissent pas l’intégralité des fonctionnalités
En fait, il n’y a pas de difference !
que tu utilises JPA avec hibernate comme implementation (sans passer pas les couches du serveur d’applications) ou JPA et la couche de persistance du serveur d’application (qui peut etre hibernate, ou toplink ou autre)
c’est comme utiliser JDBC en direct, ou via un data source du serveur d’application
En fait, pour l’instant, je sais que l’on peut faire du Hibernate à la sauce JPA (+ un poil de sauce hibernate).
Par contre je n’ai toujours pas compris s’il y avait des distributeurs de solutions « uniquement » EJB3. Parce que JPA n’est là que pour harmoniser les différentes solutions pour autant que je sache :$
Qu’en est il ?
++
ZedroS/Joseph
EJB 3 ou Hibernate ? –> JPA bien sur
Salut
djo.mos : dire que Spring = EJB3 est complètement faux.
D’ailleurs il ne me semble pas que la volonté ait été de concurrencer Spring sur l’injection de dépendance ou l’AOP, mais juste de les utiliser pour faciliter l’usage d’EJB 3, ni plus ni moins. D’où les différences.
A l’inverse, pour autant que je puisse en croire mon EJB 3 In action et un contact récent, les EJB 3 c’est aussi un moyen efficace et aisé de consommer/produire des messages JMS et de faire du remoting, ce qui n’est pas le cas de Spring.
Bref, si vous voulez un moteur d’IoC/AOP, Spring ou d’autres conviennent sans doute mieux (Guice, qui a dit Guice ?). Par contre, pour le remoting et le JMS… EJB 3 semble pas mal.
Quant à la partie DAO… je ne sais pas quoi en dire :EJB 3 ou Hibernate ?
Enfin, ne pas oublier non plus que beaucoup de personnes utilisent Spring « parce que c’est à la mode » sans trop se poser de questions, là où à l’inverse un standard en « EJB * » a une sacrée mauvaise réputation à défaire.
Bref, vaste sujet
++
Joseph/ZedroS
Bonjour,
Si seulement Sun acceptait sa défaite sur ce coup là et concentrerait son énergie sur autre chose …
En effet, je suis d’avis avec Rod Jhonson que les EJBs sont loin derrière Spring en ce qui concerne l’IoC (injection des dépendances) et sur l’AOP (intercepteurs).
Je suis tout à fait d’accord sur le fait que le nombre de jobs est un indicateurs pertinent du moins sur les indications de tendances.
Merci beaucoup pour ces informations
Le probleme pour les EJB, c’est que les serveurs JEE 5 sont encore rares en production (voir meme pas encore disponibles cf websphere).
Et a coté de ca, spring est vraiment tres tres mature maintenant.