Conteneur de Servlet+Spring vs. JEE. Quelle direction prenez-vous ? [Débat]

[Hikage]

Envoyé par OButterlin

Ça ne fait pas l'ombre d'un doute

Un conteneur d'EJB fait ça très bien, et bien plus encore...

Je ne nie pas que Spring et JEE propose des fonctionnalités similaires

- Gestion des transaction : Si maintenant il est tout aussi simple de le faire en JEE qu'en Spring, au début de Spring ce n'était pas forcement le cas.
De plus, Spring permettant l'utilisation de transaction déclarative en déhors mêne d'une application JEE. Ce qui était tout de même fort pratique.
Notons par ailleurs que Spring gèrent aussi les annotations de JEE pour les transactions.

- l'AOP : Je ne connais pas trop les fonctionnalités de JEE 6, mais jusqu'ici, l'AOP de Spring est tout de même bien simple et souple

D'autre part, Spring est entrain de mettre la main sur tout ce qui touche aux développements web avec Spring MVC, Spring Web, Spring machin Spring truc... Donc, s'il s'agit de réécrire à sa sauce propriétaire ce que fait un environnement et/ou des frameworks existants normalisés par JEE... ça devient...

Je viens mal en quoi Spring MVC est une réécriture propriétaire de ce qui existe en JEE. Le seul framework JEE pour le Web est JSF. Qui est complètement différent de Spring MVC.

Spring MVC serait eventuellement au départ une réécriture de Struts .. mais cela n'a rien a voir avec JEE.
Il y a bien Spring Face ? Ce n'est pas une réécriture, juste une extension.

[fr1man]

Je comprends bien ton point de vue et je le partage également.
Ce qu'il faut voir, c'est que Spring a proposé des concepts absents à l'époque des EJB 2. Donc à cette époque, l'intérêt était bien réel.
Actuellement, c'est moins le cas, mais Spring a l'avantage d'évoluer plus vite que la "norme". Donc son utilisation ne me dérange pas, s'il y a une valeur ajoutée derrière.

[Hikage]

Envoyé par OButterlin

Je sais bien, mais le problème n'est pas là...
Pourquoi toujours multiplier les façons de faire quand il existe déjà quelque chose d'abouti...
Et on a le même problème avec les frameworks... struts1, struts2, jsf, etc...
A la fin, on ne sait plus quoi choisir et lequel sera pérenne...
Pour ce qui est de Spring vs EJB, EJB a le gros avantage de faire partie de JEE.

Je suis d'accord, le fait que cela soit standard peu être perçu comme un plus.
JEE 6 à l'air super intéressant, je te l'accorde. Il faut avouer aussi qu'il y a eu une inflence de Spring derrière ..


Cependant, est-ce qu'être standard est toujours aussi important ?
Solution perenne ? Certes .. si tu utilise Glassfish et qu'il devait etre sacrifié, tu pourrais passer sur Websphere ?
En théorie, peut être, en pratique pas forcemment aussi facilement.

Tu veux passer de JEE 5 à JEE 6 ? Il faut changer de serveur, et donc cela impose des couts.

Spring n'est pas parfait, mais il à l'avantage d'etre léger, tu peux passer de Spring 2.5 à Spring 3.0 sans devoir revoir ton parc de serveur.

De plus, un standard n'évolue pas aussi rapidement qu'un produit comme Spring, qui reste OpenSource et donc évoluera plus vite si la communauté suit derrière.

Tu vas dire que Glassfish ou JBoss sont OpenSource aussi .. Oui d'accord !
Mais si tu utilise une fonctionnalité propre à un de ses serveurs, tu perds ton fameux standard...

[OButterlin]

Envoyé par Hikage

Je viens mal en quoi Spring MVC est une réécriture propriétaire de ce qui existe en JEE. Le seul framework JEE pour le Web est JSF. Qui est complètement différent de Spring MVC.

Spring MVC serait eventuellement au départ une réécriture de Struts .. mais cela n'a rien a voir avec JEE.
Il y a bien Spring Face ? Ce n'est pas une réécriture, juste une extension.

Euh là d'accord, je me suis mal exprimé... je ne mettais pas cet aspect particulier en face de JEE, c'était plus une réflexion globale... désolé...

[Hikage]

Attention, je ne décrie pas JEE ou les EJBs.

Pour l'instant, il n'y a pas d'équivalent Spring au EJB Statefulll ( et donc des WebService statefull ).

JEE 6 est très intéressant aussi, et est une alternative à Spring (ou le contraire).
Mais pour moi, le fait de se cacher derrière le mot standard me fait un peu sourire, car c'est du pure marketing ou une utopie en pratique

[OButterlin]

Envoyé par Hikage

De plus, un standard n'évolue pas aussi rapidement qu'un produit comme Spring, qui reste OpenSource et donc évoluera plus vite si la communauté suit derrière.

Moi je rêve que tout le monde s'unisse autour d'UNE excellente idée et la fasse évoluer (ah utopie quand tu nous tiens )
Il y a du bon partout, mais trop de choix tue java (au sens large, jee, jse...) au profit de solutions propriétaires payantes (Microsoft par exemple)
A la fin, on s'y perd... et ça devient casse pied de toujours se former au nouveau standard du moment qui apporte UN petit plus dans UN domaine par rapport à ce qui existait... pourquoi ne pas avoir fait évolué cela...

Envoyé par Hikage

Tu vas dire que Glassfish ou JBoss sont OpenSource aussi .. Oui d'accord !
Mais si tu utilise une fonctionnalité propre à un de ses serveurs, tu perds ton fameux standard...

C'est l'intérêt de certaines des api de jee comme JPA par exemple dans un domaine particulier... on s'y plie, on peut faire énormément de choses... et on passe d'une implémentation de JPA à une autre sans modification de code (Hibernate -> TopLink par exemple)

[antony810]

Dans nos projets, nous avons testé java ee 5 et du 6. Nous testons en ce moment Spring avec son conteneur léger.

Nous allons sans doute prendre des EJB version 3.1 avec jndi pour l'acces au EJB entity. Nous avons deja tout fait sur glassfish.

Bref Spring peut tres bien utilisé EJB à coté.

Nous allons utilisé Spring MVC pour la partie MVC et testé sur un tomcat par la suite.

Bref les deux poids lourds pour les applications entreprises se completent bien.

[joseph_p]

Envoyé par OButterlin

Moi je rêve que tout le monde s'unisse autour d'UNE excellente idée et la fasse évoluer (ah utopie quand tu nous tiens )
Il y a du bon partout, mais trop de choix tue java (au sens large, jee, jse...) au profit de solutions propriétaires payantes (Microsoft par exemple)
A la fin, on s'y perd... et ça devient casse pied de toujours se former au nouveau standard du moment qui apporte UN petit plus dans UN domaine par rapport à ce qui existait... pourquoi ne pas avoir fait évolué cela...

hum... je ne partage pas ton avis : le choix est justement une des forces de Java. Sans la communauté open source (ou plutot les communautés), où en serait java aujourd'hui ? Certes, cela fait du choix. Certes, cela est plus compliqué de choisir. Mais quelle liberté, quelles marges de manœuvres ! Des expérimentations dans tous les sens qui finissent par intégrer les standards "officiels" et débordent ensuite sur les autres langages !

De plus, perso, je cherche plus la meilleure "pile" technologique possible, celle qui me rendra productif tout en étant robuste à souhait, plutôt que le standard du moment. Et là encore, si on sait ce qu'on veut au delà des buzz, la richesse de java ouvre des horizons insoupçonnés.

J'ai eu l'occasion de bosser avec des produits propriétaires... ah la la, toutes ces rengaines à 2 sous : "c'est dans la prochaine version", "on n'a pas ça mais on a ça qui s'en approche" (la bonne blague !) et autres "ça viendra".

Alors oui c'est plus dur de choisir, mais être à même de comprendre et de choisir est l'essentiel du métier non ? Quand à "devoir" apprendre de nouveaux standards, ouarf, l'informatique tourne entièrement autour de la notion d'apprentissage permanent, alors que ce soit un standard ou le framework xyz... Surtout que le dit framework peut sacrément te faciliter la vie (pour le standard, ouarf, je sais moins, peut etre que oui mais généralement avec un décalage de quelques années).

Par exemple, au boulot, on évalue en ce moment le framework lombok (http://projectlombok.org/features/index.html)... Encore des gains d'efficacité en perspective ! On avance, la vie est belle

[Kimious]

Au boulot, c'est plutôt JBoss/EJB/JSF/RichFaces,

[OButterlin]

Envoyé par ZedroS

Alors oui c'est plus dur de choisir, mais être à même de comprendre et de choisir est l'essentiel du métier non ? Quand à "devoir" apprendre de nouveaux standards, ouarf, l'informatique tourne entièrement autour de la notion d'apprentissage permanent, alors que ce soit un standard ou le framework xyz... Surtout que le dit framework peut sacrément te faciliter la vie (pour le standard, ouarf, je sais moins, peut etre que oui mais généralement avec un décalage de quelques années).

Ce n'était pas vraiment le sens de mon propos... je me suis (encore) mal exprimé...
Évidemment, l'informatique est une discipline où il faut sens cesse renouveler ses connaissances, personnellement, c'est même ce qui m'attire... ce qui me gêne le plus était résumé dans "...se former au nouveau standard du moment qui apporte UN petit plus dans UN domaine par rapport à ce qui existait...", l'effet buzz, l'effet DSI, on l'appelle comme on veut...

Sinon, je suis d'accord avec toi sur la notion de recherche de "la meilleure pile technologique possible". Là, on n'a pas tous les mêmes besoins ni les même contraintes, ce qui fait qu'on n'aura pas forcément les mêmes choix... de là à dire que le choix des autres est nul est un raccourci que je ne ferai pas...

[lunatix]

Perso, je pense que JEE6 réussi enfin a arriver au niveau qui pourrait m'intéresser niveau back, mais quand je vois les commentaires sur la partie web, je me dis que je ne suis pas pret a refaire confiance.

par exemple : JSP ne va plus évoluer et tout est basculé vers JSF... ces gens ne comprennent rien au web : je bosse sur des sites web et portails a forte charge : jsf est totalement inutilisable dans ce cas, et j'aurais grand besoin d'une evolution des jsp (pour améliorer les perfs, la capacité a faire du cache, le templating etc....)

la ou spring mvc3 va dans le bon sens (approche restful, view switchables etc...) jsf c'est juste n'importe quoi.

[ReaM]

Bonjour , j'ai voté tout de même J2EE 5 + spring dans le sens ou il est vrai il est assez simple et rapide de developper une application web grâce à Spring en se rebassant sur des fichiers de configurations déjà existant. La première fois , je dois bien avouer que ca été un peu galère pour moi de faire les choses correctement. Cependant dans mes anciennes missions je n'ai pas eu l'occasion de mettre ce profil en action dans une cadre "entreprise" , celle-ci préférant rester au maximum dans les standards J2EE "officiel" pour ne pas être victime de la mode du moment, Spring étant souvent déprécié.

Envoyé par lunatix

Perso, je pense que JEE6 réussi enfin a arriver au niveau qui pourrait m'intéresser niveau back, mais quand je vois les commentaires sur la partie web, je me dis que je ne suis pas pret a refaire confiance.

par exemple : JSP ne va plus évoluer et tout est basculé vers JSF... ces gens ne comprennent rien au web : je bosse sur des sites web et portails a forte charge : jsf est totalement inutilisable dans ce cas, et j'aurais grand besoin d'une evolution des jsp (pour améliorer les perfs, la capacité a faire du cache, le templating etc....)

la ou spring mvc3 va dans le bon sens (approche restful, view switchables etc...) jsf c'est juste n'importe quoi.

Je suis tout à fait d'accord avec toi ! Au niveau performance "front-end" JSF et consort sont des gouffres à process . J'ai fait quelques benchmark sur la génération d'une page en JSP / JSF / MyFaces / IceFaces & RichFaces et c'est hallucinant les différences que l'on peut avoir pour afficher la même chose ! Ok , chacun apporte des fonctionnalités et des facilités qui ont un cout mais quand même !

Pour ma part dans des dev personnelles , j'opte souvent pour RichFaces qui est à mon gout très beau, skinnable et pour lequel ajouter des fonctionnalités ajax en plus de celle de base n'est pas compliquer ( comparé à JSP + DWR par exemple) je sais que derrière tout ca , j'ai un cout en process qui ne serait pas négligeable .

[joseph_p]

A propos de comparaison, petit topo dispo ici :
http://ptrthomas.wordpress.com/2009/...-5-and-grails/
++

[alexismp]

Envoyé par Hikage

Mais pour moi, le fait de se cacher derrière le mot standard me fait un peu sourire, car c'est du pure marketing ou une utopie en pratique

Je pense que mes clients qui utilisent maintenant GlassFish et qui utilisaient d'autres platformes j2ee/javaee avant ne seront pas d'accord avec toi. Le standard est ce qui leur a permit de changer de crémerie à moindre frais.

[Hikage]

Envoyé par alexismp

Je pense que mes clients qui utilisent maintenant GlassFish et qui utilisaient d'autres platformes j2ee/javaee avant ne seront pas d'accord avec toi. Le standard est ce qui leur a permit de changer de crémerie à moindre frais.

C'est clairement plus facile de passer d'un Weblogic à un Glassfish que d'un Weblogic à un Spring. Je ne dis pas le contraire.

Mais c'est pas non plus complètement transparent, et indolore. C'est pas simplement "je prends mon ear et je le place de l'un à l'autre".
Et c'est malheureusement souvent comme cela qu'on essaie de le vendre

"Si tu choisi JEE, tu n'es pas du tout lié à un produit".
En pratique, c'est pas forcement le cas. si le code est à 95% portable d'un serveur à l'autre, le 5% te bloque parfois pas mal non plus.

La philosophie de JEE est super intéressante, de vouloir s'abstraire de tout fournisseur. C'est une bonne chose, que j'applaudis.

En pratique, le problème est que chaque fournisseur doit se distinguer d'un autre serveur pour se "vendre", et fournir d'autre services supplémentaires, non standards . Et on est toujours tenté un jour ou l'autre de s'en servir. Et la, fini la portabilité (aussi) facile.

[alexismp]

Envoyé par Hikage

C'est clairement plus facile de passer d'un Weblogic à un Glassfish que d'un Weblogic à un Spring.

Je pensais plus à passer de Spring à Java EE

Envoyé par Hikage

Mais c'est pas non plus complètement transparent, et indolore.

Non, mais dans cette industrie on n'a jamais eu un tel niveau de portabilité et rares sont les cas ou les clients qui sont passés sur GlassFish avaient prémédité le changement avec un respect scrupuleux de J2EE/JavaEE. Preuve que la portabilité est bien réelle. Je n'ai qu'un cas (plutôt extreme) de client ou la migration a échoué (dans le temps imparti très court).

Envoyé par Hikage

En pratique, le problème est que chaque fournisseur doit se distinguer d'un autre serveur pour se "vendre", et fournir d'autre services supplémentaires, non standards . Et on est toujours tenté un jour ou l'autre de s'en servir. Et la, fini la portabilité (aussi) facile.

Je ne suis pas d'accord. Il y a plein de façon de se différencier sans proposer des API propriétaires. En tout cas, rien de qui est mis en avant pour GlassFish v3 n'implique un modèle de programmation non standard et je ne vois pas ce genre de discours ailleurs non plus.

[Hikage]

Envoyé par alexismp

Je pensais plus à passer de Spring à Java EE

Je me doute bien ;-)
Ma question, pourquoi migrer ?

Spring est venu à l'époque car il y avait un gros soucis dans JEE : sa complexité.
Il est donc devenu intéressant de passer sur Spring car plus simple et plus souple.

Depuis, JEE s'est grandement simplifié, et est redevenue intéressante.
Aussi simple ? Certainement :-)
Aussi complète ? Certainement plus sur certains sujet, peut être moins sur d'autres ( c'est discutable ;-) )

Mais est-ce qu'il est aussi intéressant de revenir vers JEE alors que Spring s'est super bien implanté? Depuis le temps, Spring est plutot bien compris par les équipes, pas mal de framework "home made" sont basés sur Spring.

Et même si JEE 6 à l'air génial, le seul avantage qu'il m'apporte est ce coté Standard .. Je suis pas sur que les développements seront simplifiés, ou plus rapides. Il faudra réapprendre un modèlè de développement .. et donc investir du temps et du budget sans avoir un gain "réel".

Du moins, c'est mon avis pour l'heure, je changerai peut être d'avis en m'y mettant plus à sa sortie.

Envoyé par alexismp

Non, mais dans cette industrie on n'a jamais eu un tel niveau de portabilité et rares sont les cas ou les clients qui sont passés sur GlassFish avaient prémédité le changement avec un respect scrupuleux de J2EE/JavaEE. Preuve que la portabilité est bien réelle. Je n'ai qu'un cas (plutôt extreme) de client ou la migration a échoué (dans le temps imparti très court).



Je ne suis pas d'accord. Il y a plein de façon de se différencier sans proposer des API propriétaires. En tout cas, rien de qui est mis en avant pour GlassFish v3 n'implique un modèle de programmation non standard et je ne vois pas ce genre de discours ailleurs non plus.

Je vais essaye de te trouver un cas particulier ;-)


Dans le même style de soucis : JPA.
J'ai vu plusieurs projets qui utilisait JPA 1.0. Mais il n'était pas rare de les voir utiliser des fonctions propres à leur implémentation de JPA (Hibernate) car plus puissante.
Bon depuis, je crois qu'il y a pas mal de nouveauté qui sont dans JPA 2.0. Donc "standardisé". C'est mieux d'accord.

[alexismp]

Envoyé par Hikage

Je me doute bien ;-)
Ma question, pourquoi migrer ?

Facile! Parce qu'après on pourra passer d'un conteneur à un autre.

Envoyé par Hikage

Spring est venu à l'époque car il y avait un gros soucis dans JEE : sa complexité.
Il est donc devenu intéressant de passer sur Spring car plus simple et plus souple.

Spring est la meilleure chose qui soit arrivée à Java EE.

Envoyé par Hikage

Mais est-ce qu'il est aussi intéressant de revenir vers JEE alors que Spring s'est super bien implanté? Depuis le temps, Spring est plutot bien compris par les équipes, pas mal de framework "home made" sont basés sur Spring.

Et même si JEE 6 à l'air génial, le seul avantage qu'il m'apporte est ce coté Standard .. Je suis pas sur que les développements seront simplifiés, ou plus rapides. Il faudra réapprendre un modèlè de développement .. et donc investir du temps et du budget sans avoir un gain "réel".

Pas très utile de toucher aux applications existentes, c'est sûr. Il y a d'ailleurs encore pas mal d'applications EJB CMP dans la nature

[joseph_p]

Je pense qu'il y a aussi un avantage fondamental avec un standard avec de nombreuses implémentations (dans la misère où elles ne diffèrent pas trop) : la garantie vis à vis de l'avenir.

Si jamais Glassfish n'est pas repris correctement par Oracle, ou bien si tel ou tel fournisseur décide de passer à une stratégie qui ne convient pas, les options sont assez aisément envisageables.

A l'inverse, un framework qui n'est pas un standard, avec un seul fournisseur, nous lie à son égard. Et la dépendance augmente au fur et à mesure que le framework englobe de plus en plus d'aspects.

J'ai toujours le cas d'ext js en tête dans cas cas là : si jamais springsource décidait de faire ainsi, les difficultés pour ses utilisateurs seraient bien plus grandes que si un fournisseur de conteneur d'EJB fesait de même.

[michael.isvy]

Pour commencer, je retiendrai cette citation d'Alexis que j'aime beaucoup:
"Spring est la meilleure chose qui soit arrivée à Java EE."

Je vais me mettre du côté Spring, mais c'est mon boulot après tout . Certes Java EE6 a fait un très gros buzz à Devoxx et c'est très bien.
Mais on a des clients qui sont passés à Spring parce qu'ils étaient déçus des précédentes versions de Java EE. Au-delà de ça, Spring a généralement très bonne réputation auprès des développeurs (en terme de stabilité, qualité de code, documentation etc).

Le retour aux EJB est donc loin d'être gagné d'avance. D'autant plus que Java EE6 propose un panel de fonctionnalités plus limité que Spring (notamment sur la Sécurité, les transactions, le Remoting, les Aspects et bien évidemment l'injection de dépendances).
Par ailleurs, la carte de l'extensibilité n'est pas forcément jouable. Certes ça serait idéal d'utiliser une syntaxe Java EE6 quand c'est possible et de rajouter des annotations Spring pour enrichir en cas de besoin. Dans la pratique les annotations Java EE ne sont pas héritables (aka. @Inherited). Par ailleurs, je n'ai pas trouvé non plus de façon exploitable de rajouter une couche d'aspects aux EJBs (à moins d'utiliser AspectJ en Compile-Time-Weaving, ce qui est loin d'être à la portée de tout le monde). Pourtant les aspects sont loin d'être une fonctionnalité gadget: ça permet de gérer ses exceptions proprement, d'injecter des logs à faible coût etc.

Donc pour moi, le vrai débat est le suivant : nos clients seront-ils prêts à sacrifier certaines des fonctionnalités dont ils ont besoin aujourd'hui au bénéfice de la standardisation ?

Bref, on en reparlera dans quelques années .