Java EE 6 vs pile Spring 3
Je commence un nouveau projet maintenant. Je dois choisir des technologies. J'ai besoin de quelque chose de léger, donc pas d'EJB ou de Seam. D'un autre côté, j'ai besoin de JPA (Hibernate ou alternative) et JSF avec IceFaces.
Pensez-vous qu'une telle pile sur Spring 3 déployée sur Tomcat soit un bon choix? Ou une application web Java EE 6 pourrait être meilleure? Je crains que Java EE 6 soit une nouvelle technologie, pas encore bien documentée. Tomcat semble être plus facile à entretenir que Glassfish 3.
Quelle est votre opinion? Avez-vous des expériences?
J'ai besoin de quelque chose de léger, donc pas d'EJB ou de Seam.
Pourriez-vous expliquer ce qui rend les EJB lourds depuis EJB3? Vous rendez-vous compte que nous ne sommes plus en 2004? J'aimerais vraiment lire votre définition de la lumière et vos arguments (et je mettrai à jour ma réponse avec plaisir car je suis presque sûr que j'aurais quelques choses solides à dire).
D'un autre côté, j'ai besoin de JPA (Hibernate ou alternative) et JSF avec IceFaces.
Le profil Web Java EE 6 qui comprend JSF 2.0, JPA 2.0, la validation du bean, EJB 3.1 Lite, CDI, ... serait parfait pour cela et vous pouvez utiliser GlassFish v3 Web Profile pour exécuter une application construite avec le profil Web Java EE 6.
Pensez-vous qu'une telle pile sur Spring 3 déployée sur Tomcat est un bon choix? Ou une application web Java EE 6 pourrait être meilleure?
Eh bien, [~ # ~] i [~ # ~] comme l'idée d'exécuter mon code sur une plate-forme non propriétaire (Java EE) plutôt que sur un conteneur propriétaire (Spring). Et je pense que Java EE 6 est assez bon (et c'est un euphémisme, EJB 3.1 (Lite), JPA 2.0, JSF 2.0, CDI kick ass). Notez que j'étais un sceptique JSF mais j'ai jeté un deuxième coup d'oeil et JSF 2.0 avec CDI est tellement différent que je ne peux même pas comparer. Et si vous n'avez pas regardé CDI, permettez-moi de vous dire que ça marche.
Je crains que Java EE 6 soit une nouvelle technologie, pas encore bien documentée.
Java EE me semble assez bien documenté. Cela ressemble à une revendication gratuite. Et, croyez-moi ou non, [~ # ~] i [~ # ~] commencez à trouver Spring se compliquant tandis que Java EE devient plus facile.
Tomcat semble être plus facile à entretenir que Glassfish 3.
Avez-vous essayé quelque chose? Avez-vous rencontré un problème particulier? Encore une fois, cela ressemble à une revendication gratuite.
Je n'ai pas utilisé JavaEE6.
Cependant, j'ai été suffisamment battu par toutes les versions précédentes de JavaEE et d'EJB pour que je ne lui fasse pas confiance jusqu'à ce qu'il s'établisse comme la norme de facto, pas seulement la norme de jure. À l'heure actuelle, le printemps est toujours la norme de facto.
Trompez-moi une fois, honte sur vous. Trompez-moi deux fois, honte sur moi. Trompe-moi trois fois, EJB.
Certains diront que Spring est propriétaire. Je dirais que les implémentations des spécifications JavaEE par les fournisseurs ont été tout aussi exclusives, sinon plus.
J'ai récemment effectué une conversion majeure en déplaçant un tas de Java Applications de JBoss vers Weblogic. Toutes les applications Spring/Hibernate ont été portées sans aucune modification, car elles avaient toutes les bibliothèques dont elles avaient besoin intégrées) . Toutes les applications qui utilisaient JPA et EJB et JSF étaient un désastre à porter. Les différences subtiles dans les interprétations de JPA, EJB et JSF entre les serveurs d'applications ont causé toutes sortes de bogues désagréables qui ont pris une éternité à corriger. Même quelque chose d'aussi simple que la dénomination JNDI était complètement différent entre AppServers.
Le printemps est une implémentation. JavaEE est une spécification. C'est une énorme différence. Je préférerais utiliser une spécification SI la spécification était étanche à 100% et ne donnait absolument aucune marge de manœuvre dans la façon dont les fournisseurs implémentent cette spécification. Mais la spécification JavaEE n'a jamais été cela. Peut-être que JavaEE6 est plus étanche à l'air? Je ne sais pas. Plus vous pouvez empaqueter dans votre WAR, et moins vous dépendez des bibliothèques AppServer, plus votre application sera portable, et c'est, après tout, la raison pour laquelle j'utilise Java et pas Dot -NET.
Même si la spécification était étanche, ce serait bien de pouvoir mettre à niveau l'appserver sans avoir à mettre à niveau toutes mes piles technologiques dans toutes mes applications. Si je souhaite passer de JBoss 4.2 à JBoss 7.0, je dois prendre en compte l'impact de la nouvelle version de JSF sur toutes mes applications. Je n'ai pas à considérer l'impact sur mes applications Spring-MVC (ou Struts).
Ça n'a pas d'importance. Java EE 6 est assez bon et à cause des profils là-bas, il n'est pas "lourd" - vous allez simplement utiliser le profil Web.
Personnellement, je préfère le printemps. Mais je suis à court d'arguments rationnels contre Java EE 6 :)
(Comme un commentaire me l'a rappelé - vous voudrez peut-être essayer RichFaces , ainsi que ICEfaces et/ou PrimeFaces - selon les composants vous avez besoin).
Récemment, une de mes affectations client a consisté à évaluer la norme Spring Stack Vs Custom stack Vs a Java EE Standards. Après un mois d'évaluation et de prototypage, je n'étais pas seulement content mais époustouflé par l'ensemble de fonctionnalités Java EE 6. Pour toute nouvelle architecture de projet "entreprise" en 2011 et à l'avenir, j'irais avec Java EE 6 et des extensions potentielles comme Seam 3 ou le prochain projet d'extensions Apache JSR299. Java EE 6 L'architecture est rationalisée et intègre le meilleur des nombreuses idées open source qui ont évolué au cours des dernières années.
Considérez les fonctionnalités suivantes hors de la boîte: Gestion des événements, Contextes et DI, Intercepteurs, Décorateurs, Webservices RESTful, tests intégrés avec conteneur intégrable, Sécurité, et bien d'autres.
La plupart de mes résultats sont publiés sur mon blog expliquant les concepts clés de Java EE 6 que vous pourriez trouver utiles.
Bien sûr, il n'y a pas de règle stricte pour choisir un cadre. Java EE 6 pourrait être bien gonflé pour les "sites Web" plus simples qui ne nécessitent pas un état de session conversationnel riche. Vous pourriez aussi bien choisir Grails ou jouer! Cadre. Mais pour les applications Web conversationnelles, je ne vois pas de meilleur argument pourquoi Java EE 6 ne convient pas.
Maintenant, après un certain temps, j'ai de l'expérience avec les piles:
- Java EE 5 + Seam + GraniteDS + Flex
- Printemps 3 + Vaadin (sur GWT)
- Spring 3 + JSF 2.0 (PrimeFaces)
Mes colclusions sont:
- Spring 3 est beaucoup plus simple que Seam (presque Java EE 6) et fonctionne sur Tomcat et Jetty! (Jetty pour le développement avec le plugin maven est un trasure).
- J'adore Flex (j'étais en fait un développeur Flex depuis longtemps, donc je suis biaisé) et si vous avez besoin d'une interface riche et que vous pouvez acheter FlashBuilder, utilisez-le, mais utilisez ce backend Spring + GraniteDS ou BlazeDs. Si vous ne pouvez pas acheter FlashBuilder, ne perdez pas votre temps.
- Vaadin est super!. Le processus de développement est plus simple que Flex, mais vous pouvez créer facilement une application riche sans désordre HTML. Vous n'écrirez pas une seule ligne JS. Vous avez juste besoin d'un peu de CSS (dans Flex, vous en avez également besoin). Donc, si votre interface d'application va se comporter comme une application de bureau et que vous ne pouvez pas (ou ne voulez pas) utiliser Flex - utilisez Vaadin. Attention! Vaadin a de gros frais généraux JS pour le navigateur.
- Si vous créez une application de type site Web plus simple, utilisez JSF2.0 (avec le backend à ressort comme ci-dessus). Vous devrez vous battre avec HTML (je déteste ça) et créer une interface riche sera plus difficile que Vaadin (en particulier les mises en page). Vous obtiendrez du HTML léger pour les navigateurs/ordinateurs plus lents. J'aime PrimeFaces - c'est facile et bien documenté. La deuxième place est IceFaces
- Si vous créez un site Web (PAS une application Web) où vous devez mettre de la vie en HTML (au lieu de créer une application d'entreprise adaptée au navigateur), utilisez Wicket (si vous préférez basé sur les composants, tirez l'attitude) ou SpringMVC (si vous préférez basé sur un modèle , Push attitude) ou utilisez simplement Play! cadre. N'oubliez pas que la création de composants riches en données sera beaucoup plus difficile, mais vous aurez le contrôle sur chaque balise html (votre concepteur HTML/Graphics adorera)
Mon opinion est basée sur quelque chose qui n'est pas mentionné par d'autres, à savoir que le code à mon travail a tendance à vivre pendant des décennies (littéralement), et donc que la maintenance est très importante pour nous. Maintenance de notre propre code et des bibliothèques que nous utilisons. Notre propre code que nous contrôlons, mais il est dans notre intérêt que les bibliothèques que nous utilisons sont maintenues par autres dans les décennies mentionnées ci-dessus ou plus.
Pour faire court, j'ai conclu que la meilleure façon d'y parvenir est d'utiliser des implémentations open source des spécifications Sun jusqu'à la JVM brute.
Parmi les implémentations open source, Apache Jakarta a prouvé qu'elle maintenait ses bibliothèques, et récemment Sun a fait beaucoup de travail pour produire des implémentations de haute qualité pour Glassfish v3. Dans tous les cas, nous avons également la source de tous les modules, donc si tout le reste échoue, nous pouvons les maintenir nous-mêmes.
Les spécifications Sun sont généralement très strictes, ce qui signifie que les implémentations conformes aux spécifications peuvent être échangées facilement. Jetez un œil aux conteneurs de servlets.
Dans ce cas particulier, je suggérerais de regarder JavaServer Faces simplement parce qu'il fait partie de Java EE 6, ce qui signifie qu'il sera disponible et maintenu pendant très, très longtemps. Ensuite, nous avons choisi pour augmenter avec MyFaces Tomahawk car il donne quelques ajouts utiles, et c'est un projet jakarta.
Il n'y a rien de mal avec JBoss Seam ou autres. C'est juste que leur attention se porte moins sur le problème de maintenance qui est si important pour nous.
Lisez Adam Bien Future Of Enterprise Java ... Is Clear (Java EE avec/sans Spring et Vice Versa) , y compris des commentaires pour obtenir les deux côtés de la médaille. Je choisirai Spring pour plusieurs raisons et voici l'une d'entre elles (reproduisant l'un des commentaires du post)
'Je ne sais pas de quel Java serveur EE 6 vous parlez. Il est certifié Glassfish et TMAX JEUS. Il faudra un certain temps (lire: années) jusqu'à ce que Java les versions conformes à EE 6 de WebSphere, WebLogic, JBoss, etc. soient en production et puissent être utilisées pour une application réelle. Spring 3 a juste besoin de Java 1.5 et J2EE 1.4 et peut donc être facilement utilisé dans presque tous les environnements '
Je peux voir utiliser Spring si vous l'avez déjà, mais pour le nouveau projet, à quoi ça sert? J'irais directement avec Java EE 6 (ejb3, jsf2.0, etc.)
Si le client est d'accord avec Flex, allez-y. Utilisez BlazeDS ou similaire - pas de mvc. Vous pouvez passer plus de temps sur cette partie (échanger des données entre le serveur et le client) mais vous avez un contrôle total des deux côtés.
N'utilisez pas Vaadin, sauf si vous voulez tuer votre navigateur. De plus, vous passez plus de temps à contourner le code une fois que vos pages deviennent plus complexes. En outre, votre état d'esprit devra être complètement changé et tout ce que vous savez sur le développement frontal standard sera du gaspillage. L'argument selon lequel vous n'avez pas à utiliser HTML ou JS n'a pas beaucoup de sens. Vous devez toujours le savoir même si vous ne l'utilisez pas. Il rend finalement HTML et JS. Ensuite, essayez de le déboguer - assurez-vous que vous disposez de quelques jours pour des choses simples. De plus, je ne peux pas imaginer un développeur web qui ne connaît pas html/js.
Je ne comprends tout simplement pas pourquoi les gens essaient toutes ces abstractions au lieu d'utiliser Java EE directement.
Pourquoi y a-t-il encore des rumeurs selon lesquelles l'EJB serait un poids lourd en 2010? Il semble que les gens ne soient pas mis à jour dans les technologies Java EE. Essayez-le, vous serez agréablement surpris de voir comment les choses sont simplifiées dans Java EE 6.
La réponse à vos questions dépend des exigences de votre projet. Si vous n'avez pas besoin des fonctionnalités Java EE comme les files d'attente de messages, les transactions globales gérées par conteneur, etc., utilisez Tomcat + spring.
Par expérience, j'ai également constaté que les projets qui nécessitent beaucoup d'intégration de services Web, de planification, de files d'attente de messages sont mieux faits en utilisant une partie de la pile Java EE. La bonne chose est d'utiliser Spring, vous pouvez s'intègre toujours avec les modules Java EE exécutés sur un serveur d'applications.
Java EE 6 est très différent des versions précédentes, et il facilite vraiment tout. Java EE 6 combine les meilleures idées de la communauté diversifiée Java - par exemple, Rod Johnson du framework Spring a été activement impliqué dans la fabrication du Dependency Injection JSR dans Java EE 6. Un avantage de l'utilisation de Java EE 6 est que vous codez selon une norme, ce qui pourrait être important dans certaines organisations pour le support des fournisseurs, etc.) .
GlassFish v3 prend en charge Java EE 6 et il est assez léger et démarre très rapidement. J'ai utilisé glassfish v3 pour mes développements, et il est vraiment facile à configurer. Il est livré avec un console d'administration très conviviale qui vous permet d'administrer graphiquement votre serveur.
Si vous utilisez GlassfishV3 et JSF 2, vous pouvez profiter des fonctionnalités CDI de Java EE 6, qui vous permet de créer facilement des conversations (par exemple des pages de type assistant) dans JSF.
Cela dit, l'utilisation de Java EE 6 vous oblige également à apprendre une nouvelle API. Selon le délai disponible, ce n'est peut-être pas le meilleur choix pour vous. Tomcat existe depuis des lustres, et le La combinaison de ressorts Tomcat + a été adoptée par de nombreux projets Web, ce qui signifie que de nombreux documents/forums existent.
Si vous avez besoin de la pile complète Java EE, je vous recommande GlassFish 3.1. Il démarre très rapidement par rapport aux autres Java conteneurs EE qui implémentent une partie ou la totalité Java EE 6 (JBoss 6, WebLogic 10.3.4), le redéploiement prend quelques secondes et presque tout peut être fait par convention sur la configuration, il est très convivial.
Si vous voulez quelque chose de "léger", vous pouvez personnaliser un Apache Tomcat 7.x avec les fonctionnalités souhaitées. J'ai beaucoup utilisé les bibliothèques suivantes: Weld 1.1.0 (CDI) JPA 2.0 (Hibernate 3.6.x) - ressources uniquement pour les transactions locales JSF 2.x (Mojarra) RichFaces 4.0 BIRT runtime
J'ai été Java développeur EE au cours des 10 dernières années (je souffre des premières technologies EJB, JSF et Web), Java EE 6 est très facile, bien couplé et le matériel actuel fonctionne sans heurt, donc original les raisons qui ont motivé le printemps ne sont plus valables.
J'ai travaillé à la fois dans Spring et Java EE 6. Ce que je peux dire de mon expérience est que si vous optez pour l'ancien JSP ou Flex propriétaire, vous êtes en sécurité si vous restez avec Spring .
Mais si vous devez aller de l'avant avec JSF, il est temps de passer à Java EE 6. Avec Java EE 6, vous passez à Facelets et à des bibliothèques de scripts standardisées). et les bibliothèques de composants. Plus d’incompatibilités de script et de matrices de bibliothèques de composants.
En ce qui concerne Spring MVC, c'est bien tant que votre projet ne grossit pas trop. S'il s'agit d'une énorme application d'entreprise, tenez-vous à Java EE 6. Parce que c'est la seule façon de gérer vos propres bibliothèques de composants et ensembles de ressources de manière ordonnée.
Je préfère toujours le printemps.
Et je transmettrais JSF. Je pense que c'est une technologie morte. Spring MVC serait une meilleure alternative. Flex aussi. Pensez en termes de contrat de services XML premiers et vous pouvez découpler complètement le back-end de l'interface utilisateur.
Je n'ai pas tout lu, mais juste pour dire que vous pouvez maintenant utiliser EJB3 dans une guerre contre Java EE 6 afin que vous puissiez utiliser EJB3 sur Tomcat (je pense).
Je recommanderais Spring + Tomcat à moins que vous ne puissiez attendre que Glassfish v3 et Weld deviennent plus matures. Il y a actuellement quelques problèmes avec la consommation de mémoire/la charge du processeur lors de l'exécution de glassfish avec des applications compatibles CDI.