Discussion :

[grosFab]

Bonjour ;

Cela fait plusieurs jours que je me suis décidé à réaliser un petit état de l’art sur les frameworks Web tiers actuels et les standards incontournables du futur proche.

Actuellement lorsqu’on évoque les framework Web, une liste toujours presque identique nous est présentée. A savoir :
• Struts 1.X
• Spring
• WebWork2
• Tapestry
• Cocoon
• JSF

Mais également Struts-Shale, myFaces et Sun JSF-RI et les frameworks clients legers riches basés sur « Ajax ».

En même temps le web2.0 est en pleine effervescence, durant de nombreuses années, l’évolution des applications clients legers n’a concerné que la partie serveur, ce qui n’est pas une mauvaise chose en soit mais le coté client s’est donc trouvé laissé pour compte ainsi que l’utilisabilité des interfaces web (même si des grands pas ont été fait avec CSS etc…). Aujourd’hui avec la maturité des navigateurs et l’essor d’Ajax et XUL on est en passe de « révolutionner » la manière de naviguer sur le net.

C’est identique avec JSTL, JSF, taglibs_struts… pour le design des IHM web. Avec JSF et cette nouvelle manière de penser les interfaces, des outils RAD peuvent désormais s’appuyer sur ce standard pour améliorer l’activité des designers.

Le souci c’est qu’aujourd’hui cette effervecence provoque des mots de tetes aux chefs de projet. En effet si la multitude d’outils est un point positif, dans quelques mois, parmis eux nombreux seront les projets abandonnés/fusionnés en cours de route. La standardisation comme la selection naturelle est implacable. Mais dans un environnement économique, la pérénité d’une solution est indispensable pour garantir le contrôle des couts, des ressources humaines, etc…

La grande problèmatique dans un développement et l’organisation d’un projet est de trouver des outils capables de séparer les domaines de compétences. Les frameworks Web tiers du moment sont arrivés à un niveau avec MVC model 2 qui permet plus de souplesse dans l’organisation des équipes. JSTL marque une standardisation des librairies.

Mais voila qu’arrive JSF à grande pompe. myFaces premiere implementation OSS qui a pris une belle avance sur JSF-RI. Shale un framework completement repensé de Struts dont le but est d’intégrer une implementation de JSF (myFaces ou JSF-RI par exemple) et de fournir autour des fonctionnalités à valeurs ajoutées.

La question est aujourd’hui en l’état actuel des choses, pour des projets existants doit-on préparer une future migration en douceur ou attendre un meilleur retour d’expérience sur JSF. Doit on alors commencer à integrer JSF à Struts 1.X ou peut dont déjà débuter des projets sur Shale. Quand sera-t-il de JSF ? Si l’avance de myFaces est indiscutable sur JSF-RI, Sun ne va-t-il pas rattraper et même devancer demain « son concurrent » ?

Doit-on conseiller aux entreprises de rester sur leur schéma traditionnel STRUTS, SPRING ou autres ou adopter le modèle par composant immédiatement sur leur base actuelle ? Doit-on leur affirmer que les RAD travaillant avec JSF sont performants ou non ?

L’environnement ASP.NET rassure par sa consistence et l’objectif est de savoir si avec J2EE ont peux désormais proposer la même chose.

C'est un peu fouilli je digère grande quantité de données mais c'ets à l'image de l'état des outils J2EE d'aujourd"hui.



[Modéré par Didier] : ajout de tag dans le titre - Les règles du forum Java

[gailuris]

Salut,

C'est vrai que tu met le doigt sur une question assez complexe, maintenant, la difficulté dans la réussite d'un projet se déplace : avant il était difficile de trouver des outils, maintenant, c'est le choix de ces outils qui peux poser problèmes...

[sleepy2002]

Bonjour,

il est vrai que l'on peut se perdre un peu dans les middleware java proposés sur le marché. Si .NET à l'avantage de proposer un pack tout en 1, l'avantage je dirais (avis personnel, pas de troll en vue ) est que dans le monde java on a justement la liberté de choisir. Aucune imposition et donc suivant tes besoins tu peux préférer telle ou telle solution.

On parle beaucoup des Framework MVC2 en ce moment et du terme pompeux et marketeux du Web 2.0. Après tout il ne s'agit que d'une couche de l'application. Si JSF semble prometteur, il est encore jeune et certains "Strutistes" préfererront sans doute une transistion en douceur avec Struts-Shales.

Pour les containers, Spring est "à la mode" en ce moment. Je ne connais pas Tapestry mais je serai ravi de lire un avis dessus.

Ce que je pense appliquer (ou faire la demande à mon chef ) pour un application de base :
MVC: MyFaces
Container : Spring
Persistence : Hibernate

[grosFab]

Je suis en train de rédiger une doc synthétique sur les framework Web et petit à petit je me fais une idée de ce que je pourrais utiliser

MyFaces
+ Struts Shale (il n'est pas intrusif tu fait dépendre tes classes de shale uniquement si tu as besoin de services supplémentaires, il intégre Clay qui est la même chose que les facelets qui peuvent etre utilisable avec Myfaces d'ailleurs)
+Spring
+ Hibernate ou Ibatis

Ensuite je me tate vraiment avec XUL car XulFaces (basé sur JSF) est vraiment une très bonne idée surtout avec l'utilitaire qui permet d'éxécuter une application XUL sans navigateur ...

[alexismp]

Bonjour ;

Cela fait plusieurs jours que je me suis décidé à réaliser un petit état de l’art sur les frameworks Web tiers actuels et les standards incontournables du futur proche.

Actuellement lorsqu’on évoque les framework Web, une liste toujours presque identique nous est présentée. A savoir :
• Struts 1.X
• Spring
• WebWork2
• Tapestry
• Cocoon
• JSF

Mais également Struts-Shale, myFaces et Sun JSF-RI et les frameworks clients legers riches basés sur « Ajax ».

Doit-on leur affirmer que les RAD travaillant avec JSF sont performants ou non ?

C'est un peu fouilli je digère grande quantité de données mais c'ets à l'image de l'état des outils J2EE d'aujourd"hui.

Oui, la bonne nouvelle avec Java, c'est qu'on a le choix, mais c'est aussi une mauvaise nouvelle car il faut faire ce choix en connaissance de cause....

Attention de ne pas confondre standard et implémentation (JSR vs. JSF-RI) d'une part et projet open source et standard JCP d'autre part (Tapestry vs. JSF).

Je suis suis curieux d'avoir des détails sur les différences JSF-RI et myFaces.

Pour ce qui est de la productivité des outils RAD avec JSF, je pense que c'est réel (mais bon, je ne suis pas neutre).

[Sniper37]

Salut,

Il est vrai qu'actuellement, il y'a l'embarras du choix en ce concerne les framework web. Mais, il est difficile de faire un choix unique pour tous projets.
Je pense qu'il faut comparer les framework, pour un besoin particulier, d'abord comprendre le besoin de l'entreprise, ensuite chercher le framework adapté. On pourrait même preferer developper notre propre framework fait sur mesure.

[grosFab]

Salut,

Il est vrai qu'actuellement, il y'a l'embarras du choix en ce concerne les framework web. Mais, il est difficile de faire un choix unique pour tous projets.
Je pense qu'il faut comparer les framework, pour un besoin particulier, d'abord comprendre le besoin de l'entreprise, ensuite chercher le framework adapté. On pourrait même preferer developper notre propre framework fait sur mesure.

je pense pas que ce soit une bonne solution

Nombreuses sont les sociétés qui ont décidés il y a quelques années de développer des applications Web autour d’un framework « from scratch ». Aujourd’hui ces projets sont arrivés à maturités et leur évolution semble compromise du fait de l’historique complexe de l’application.
En effet si monter sa propre architecture permet d'en avoir la maîtrise totale, ou toutes les fantaisies sont possibles, le prix du coût de développement et de maintenance s’en retrouve exorbitant :
• Réaliser une structure logicielle soignée impose l’implantation de mécanismes standards tels les design patterns, les workflows, la gestion des couches métier, persistance, la prise en charge des erreurs etc… Or si cela peut aboutir à une architecture performante, sa diffusion restera dans la plupart des cas restreinte à l’entreprise initiatrice du projet. Aucun outil AGL ou WYSIWYG ne supportera ce standard comme le font Sun Java Creator 2 pour JSF, Lomboz pour JSP,…
• Afin d’assurer la pérennité et la maintenance des futurs développements, concevoir une architecture logicielle propriétaire impose également d’écrire une documentation technique complète à son sujet;
• Les nouveaux employés n’auront pas forcement la connaissance du framework. Une formation couteuse en temps et en argent sera nécessaire pour leur donner les qualifications nécessaires à tout développement ;
• Les technologies évoluent plus vite au niveau mondial qu’au niveau de l’entreprise. Afin de garder une solution performante et concurrentielle, le projet nécessitera sans cesse des phases critiques de refactoring pour moderniser ses composants ;
• Les frameworks propriétaires sont alors une source de perte de profit. Les initiateurs du produit ne sont plus utilisés à plein temps pour développer des applications pour les clients. Ils doivent le réserver en partie pour réaliser du transfert de compétence vers les nouveaux arrivants.
• …
Les raisons pour ne pas développer son propre framework sont assez nombreuses pour motiver ses choix vers des frameworks web OSS (Open Source). Bien testés et documentés ces outils assouplissent les évolutions fonctionnelles et la maintenance de l’application. En favorisant l’investissement humain et financier sur l’aspect fonctionnel, ils améliorent la productivité ainsi que la satisfaction du client.

Il ne faut pas pour autant utiliser un marteau pour écraser une mouche, mettre en place un framework ne se fait pas sans justifications valable. Pour un petit projet par exemple on pourrait même se demander si J2EE est bien la solution.

Extrait de mon étude

[sleepy2002]

Au delà de la technologie utilisée l'important est de se focaliser sur la couche métier.

Les couches présentation et persistence pouvant être remplacées en cas de migration technologique.

Sans faire l'apologie de Spring je trouve que sa vision de concevoir une application est vraiment bien: framework non intrusif, découplage des couches avec le pattern IoC, support des divers frameworks MVC et persistence disponibles, facilitation de l'écriture des tests unitaires.

Développer son propre framework, il faut vraiment avoir des besoins spécifique pour le faire. Je pense que les solutions qui existent sur le marché sont suffisamment évoluées et bien pensées pour que l'on évite ce genre de tâche douloureuse et coûteuse.

Je pense que le problème du monde J2EE, c'est que dans cette diversité, on manque effectivement de comparatifs et analyse approfondie des frameworks. On a tendance à lire des messages du genre "Laisse tomber Struts, c'est devenu obsolète face à JSF" sans trop d'argumentation. Je pense qu'il faut instaurer un débat sur ce que chacun apporte (quelle valeur ajoutée à mon application ?) tout en évitant les divers trolls de bases venant de pro ceci ou pro cela.

[grosFab]

entièrement d'accord avec toi, pour moi le couche présentation c'est du jetable car tout évolue trop vite d'ou l'approche RAD qui parai intéressante.

quelques liens pour les comparatifs entres frameworks. Struts classic n'est pas mort il fusionne avec WebWork2 on a encore beaucoup à attendre dans les mois qui suivent !

JSF c'est alléchant je n'ai pas encore eu l'occasion de l'utiliser mais les concepts semblent tout à fait inciter à croire que ce sera le framework standard comme l'est struts de demain.

Après la popularité d'un framework est dissocié de ses qualités ...
http://weblogs.java.net/blog/batate/archive/2005/12/popular_vs_grea.html


[1] « Comparing web frameworks Struts, Spring MVC, WebWork, Tapestry & JSF »
Matt Raible (2005)
https://equinox.dev.java.net/framework-comparison/WebFrameworks.pdf

[2] « The evolution of Web Application architecture »
Craig R. McClanahan (Aout 2005)
http://people.apache.org/~craigmcc/oscon_2005_web_architectures.pdf

[3] « Comparing web frameworks »
Greg Hinkle, Erin Mulder & Brian McCallister (mars 2005)
http://www.chariotsolutions.com/slides/osconf2005-webframeworks.pdf

[4] « Java Web Frameworks »
Matt Raible (juin 2005)
http://virtuas.com/files/osl-jwf-01.pdf

[5] « Rich Web Interfaces »
Philip Feairheller (mars 2005)
http://www.chariotsolutions.com/slides/osconf2005-richweb.pdf