Discussion :

[A&N_L]

Bonjour à tous,

Je suis actuellement à rédiger les spécifications d'une nouvelle application.

Il s'agit plus précisément d'une grosse évolution d'une application d'administration, de back office, suite à la refonte complète du métier de l'application à administrer.

J'en suis donc à me poser un certain nombre (voir un nombre certain...) de questions architecturo-logicio-existentielles (si si, il existe ce mot !).

Cette application devra opérer tous les opérations de CRUD possibles propres à une application d'administration.

Au final, une application web de gestion pleine de formulaires...

Rentrons dans le vif du sujet...

Le métier de l'application à administrer sur lequel s'appuie(ra) mon application de gestion a été développé en EJB 3.0.
Pour l'instant, hors de question d'en changer (touche pas à ça petit con !)...

Quant à la partie présentation des données, l'existant a lui été développé en JSP/Servlet JEE 5 ; à cela, rajoutez un peu d'AJAX (DWR et DataTables).

Comme il m'est plus ou moins donné carte blanche (les fous !!) quant aux choix technologiques à mettre en oeuvre, je me demande s'il ne serait pas opportun de passer à autre chose...?

Changer pour quoi...? Pour rendre l'application plus maintenable, plus évolutive, plus performante...? Pour le plaisir de changer...? Pour voir du pays, se former...?

Tout le métier est donc en EJB 3.0 : session stateless & entity, le tout déployé sur GlassFish v3.

Mes questions "changement" :

- Que pensez-vous de passer à JSF 2.0 ? Si oui, ne vais-je pas rencontrer des problèmes de "compatibilité" entre JSF 2.0 (JEE 6) et mes EJB 3.0 (JEE 5) ?
- Passer au duo JSP/Servlet JEE6... (même si, de prime abord, je n'en vois pas trop l'intérêt...?) ?
- Tout autre chose...?
- Devrais-je au contraire rester avec le duo JSP/Servlet JEE5 ?

Merci par avance pour vos retours d'expérience en la matière !

[OButterlin]

Je ne sais pas trop où on en est d'un point de vue stabilité avec JSF 2.0...

S'il y a un problème, tu peux te retourner vers JSF 1.2 + Facelets + Seam + RichFaces.

Pour les EJB 3.0, bon choix... le passage à 3.1 apporte certains petit plus (comme le tri des listes sous-jacentes dans un entity).
La migration de 3.0 -> 3.1 ne devrait pas être gênante.

Après, il y a tellement de façons différentes de faire pour la même application, on peut vouloir limiter les risques et rester sur des framework connus... à toi de voir...

[A&N_L]

Salut OButterlin,

Merci pour ton éclairage.

S'il y a un problème, tu peux te retourner vers JSF 1.2 + Facelets + Seam + RichFaces.

JSF 1.2 et RichFaces, ceux-là, je les ai.
Facelets + Seam, ceux-là par contre, je ne les ai pas...
Qu'apporteraient-ils/quels seraient donc leurs rôles au sein de mon architecture/application ?
Pour rappel, il ne s'agit que d'une "simple" application de gestion, aussi fournie soit-elle...
Ne serait-ce pas sortir le bazooka pour flinguer une simple mouche...?

Pour les EJB 3.0, bon choix... le passage à 3.1 apporte certains petit plus (comme le tri des listes sous-jacentes dans un entity).
La migration de 3.0 -> 3.1 ne devrait pas être gênante.

Même si je partage ton avis (je pense notamment aux EJB 3.1 Lite et du coup au web profil car nous n'utilisons que le métier des stateless et des entities, rien d'autre), nous sommes une toute petite équipe actuellement, je ne suis donc pas certain que mes collègues soient enthousiastes à cette idée-là, aussi noble soit-elle, la charrette débordant depuis déjà bien longtemps !

Après, il y a tellement de façons différentes de faire pour la même application, on peut vouloir limiter les risques et rester sur des framework connus... à toi de voir...

Je suis d'accord avec toi.
Ainsi, la première remarque qui m'est faite quand je fais part autour de moi de l'éventualité de "changer", c'est : "Mais pourquoi tu veux changer...?".
Le couple JSP/Servlet ayant effectivement fait ses preuves...

Mais moi, justement, je changerais bien !

[OButterlin]

Globalement, JSF + Facelets + Seam = JSF 2.0

Pour la persistance et la couche métier, il faut bien reconnaître que les ORM apportent un plus dans la modélisation.
On peut effectivement faire autrement, plus performant, en utilisant JDBC.
A priori, la performance optimale sera atteinte avec des procédures stockées. On pourra cependant avoir des problèmes de migration d'une base vers une autre si le besoin devait exister...
Bref, je préfère pour ma part perdre une milliseconde et avoir un modèle objet, mais ça reste un débat philosophique...
D'ailleurs, par endroits, j'utilise des accès natifs quand il faut optimiser certaines requêtes de recherche.
J'irais même jusqu'à dire que le modèle métier devrait être géré par un ORM et les requêtes de recherche par un accès natif. Pour ça, JPA propose des choses intéressantes.

Dernier point : pourquoi changer ?
Parce qu'à un moment, on ne trouve plus personne pour maintenir
Plus sérieusement, de plus en plus d'ajax entre dans les applications web, on peut le faire avec du javascript de base (surtout avec jQuery) mais avoir un framework de présentation comme RichFaces qui englobe le tout permet de développer plus vite...

[manblaizo]

Globalement, JSF + Facelets + Seam = JSF 2.0

Hmmm, pas tout à fait quand même, Seam représente bien plus qu'un simple complément à JSF 1.2... En gros, Seam 2 a pour ambition de faciliter l'intégration entre EJB3.0 et JSF1.2, et au passage il apporte aussi des améliorations et autres solutions aux manquements de JSF1.2

Mais la plupart des gros problèmes qu'il y avait dans JSF1.2 ont été corrigés dans JSF 2.0, en s'inspirant d'ailleurs des workarounds qu'apportaient Seam, RichFaces, ICEFaces, etc. Et il y a bien plus encore dans JSF2.0

Tous ces correctifs ayant été apportés à JSF, Seam3 se concentre dorénavant sur l'intégration et l'extension des services Java EE en se basant totalement sur la jsr-299 (CDI) dont le spec lead n'est autre que Gavin King, le créateur de Hibernate et Seam.

Bon, tout ça pour dire qu'à mon avis JSF 2.0 est déjà stable, parce que ça fait quand même au moins deux ans que c'est sorti, bien avant la sortie officielle de Java EE6. C'est vrai qu'il y a encore des améliorations à faire, surtout au niveau de l'interopérabilité entre les différentes librairies de composants (RichFaces, PrimeFaces, ICEFaces...), mais les équipes de développement de ces dernières se coordonnent déjà en ce moment, et apparemment ça devrait être plus simple de faire coexister des composants de différentes librairies que par le passé. La JSR pour JSF 2.1 a déjà été ouverte et on peut déjà faire des propositions pour des améliorations...

En tout cas, à partir du moment où tu déploies déjà sur GlassFish3, donc un serveur d'applications compatible Java EE6, il serait dommage de pas profiter de toutes ces nouveautés qui facilitent le développement (CDI, JSF2.0, EJB3.1, JPA2.0, Bean Validation...), d'autant plus qu'elles sont déjà là par défaut.

Pour tes EJB3.0, je ne vois pas pourquoi tu ne continuerais pas à les utiliser même dans GlassFish3, il n'y a rien de nouveau de côté là, l'API n'a pas changé pour qu'on ait des problèmes d'incompatibilité. Par contre, tu pourrais profiter du déploiement de tes EJB dans un simple WAR, des Singletons, des méthodes asynchrones, de global jndi names, d'un service Timer amélioré...

Il y a plein de docs sur Weld (CDI), JSF2.0, JPA2.0, EJB3.1, pour explorer et ensuite prendre ta décision.

Bon courage.

[Jacobian]

-JSF:au niveaux des performances je déconseille l'utilisation de JSF tu va payer de 5-10 % en perf par contre il est bien en terme de maintenabilité de la couche présentation.

-Struts ou JSp/servelet : au niveaux perfr il sont bien mais tu vas payer aux niveaux maintenance

[OButterlin]

-JSF:au niveaux des performances je déconseille l'utilisation de JSF tu va payer de 5-10 % en perf par contre il est bien en terme de maintenabilité de la couche présentation.

C'est vrai...
Mais le choix devrait être dicté par le besoin.
S'il s'agit d'une application avec énormément d'utilisateurs connectés, ça risque de se payer... Par contre, s'il s'agit d'une application type "intranet" ou "extranet" (au sens large), ça se défend bien.

[manblaizo]

-JSF:au niveaux des performances je déconseille l'utilisation de JSF tu va payer de 5-10 % en perf par contre il est bien en terme de maintenabilité de la couche présentation.

C'est une affirmation un peu gratuite quand même. Quelle version de JSF? Et comparé à quels autres frameworks?
Je n'ai pas encore vu de benchmarks sur les performances de JSF2.0 par rapport à d'autres frameworks. C'est vrai que JSF n'avait pas une bonne réputation de ce côté-là, mais les choses ont beaucoup changé aussi depuis. Donc pour moi, tant qu'on ne me démontre pas le contraire, pour le moment je ne trouve pas mon application Struts2 que je réécris en JSF2.0 plus lente qu'avant.

Mais il faut dire aussi que les problèmes de performances peuvent venir de tout à fait autre part (la couche persistence surtout). Si les requêtes JPA/Hibernate ne sont pas optimisées, quel que soit le framework web utilisé, l'application pourrait être lente.
Donc, bon...

[Jacobian]

ouiii JSf en terme d'architecture il est très très bon par rapport aux autres freamwork MVC par contre on a pas besoin d'une étude pour approuvé que le temps de réponse des pages JSf sont plus que celles du struts ou une simple jsp du fait que jsf utilise plus de skin pour customisé des composantes HTML et lorsqu’on dit du code de plus c'est-à-dire des perfs moins.

[manblaizo]

... et lorsqu’on dit du code de plus c'est-à-dire des perfs moins.

... sur une vieille machine avec un vieux cpu et peu de mémoire...

Non, sérieusement, pas la peine de polémiquer là-dessus, tu as sûrement raison. Mais plusieurs critères rentrent en ligne de jeu quand il faut faire un choix, et comme tu l'as dit toi-même, la maintenabilité du code peut être très importante aussi.

[OButterlin]

...la maintenabilité du code peut être très importante aussi.

Souvent plus importante qu'une perte de quelques millisecondes...
Et plus l'application est grosse et plus c'est vrai...
L'aspect facilité de mise en œuvre est un critère important également.

[A&N_L]

Bonjour messieurs,

Je suis avec une très grande attention l'évolution de ce post quant à vos retours d'expérience sur le choix d'un framework de développement web Java.

Merci donc...

Nous en sommes encore au stade de la réflexion.

En gardant ainsi à l'esprit que cette application sera une application de gestion "classique" avec un nombre certain d'annuaires et de formulaires (donc pas mal de templating et de contrôles de saisie), ce framework devra se plugger le plus naturellement et le moins douloureusement possible à nos EJB 3.0.

Vu que cette application sera du type "intranet" ou "extranet" -merci OButterlin ! - et qu'il n'y aura pas pléthore d'utilisateurs connectés dessus, la facilité de mise en oeuvre, la maintenabilité et l'évolutivité seront les critères les plus importants.

Les tendances du moment seraient JSF et Flex.

Mais ne sommes pas fermés au reste pour autant !

(Arrêtez-moi si je me trompe...). JSF car spécification JEE , pas mal de ressources sur le sujet, se collant naturellement aux EJB, (presque) tout intégré, maintenabilité, évolutivité...

Flex (là aussi un paquet de ressources à dispo...) avec ou sans (donc développer les web services qui vont bien) BlazeDS...?

Flex car dans notre rélexion nous songeons à cette techno pour notre gamme de produits.

Ainsi, une seule techno à assimiler pour l'ensemble de nos applications : nos produits et leur plateforme d'administration.

Aussi, que ce soit pour ces deux technos ou n'importe quelle autre, quid de la partie purement "affichage/cosmétique" actuellement développée en HTML/CSS et JavaScript (JavaScript natif + DWR + DataTables) ?

=> JSF + ICEFaces ou RichFaces...?
=> Flex, évidemment...?
=>...?

A suivre...!

[OButterlin]

D'un point de vue Look&Feel, RichFaces ou PrimeFaces sont vraiment sympas

RichFaces
PrimeFaces

Pour ce qui est de Flex, personnellement, je ne l'ai pas essayé, je ne peux donc rien en dire... mais c'est propriétaire...

[Jacobian]

Alors si vous avez des compétences technique pour mettre en place ce projet avec la technologie Flex c'est la meilleure solution existe pour la coté présentation dont voici les problèmes d’une maniéré exhaustifs oui ils ne sont pas beaucoup que tu peux y avoir avec cette technologie c’est a vous de voire :
- si l'application est destinée aux utilisateurs web tu auras un gros problème de référencement
- téléchargement lent du premier écran
- si vous voulez l’intégré avec java donc tu vas obligatoirement utiliser le Framework open source blazDS mais tu vas y avoir des problèmes du lazy loading dans se cas ta trois solutions soit t’achète la version payant life cycle et la ta une configuration de plus pour le lazy loading, soit t’implémente une couche coté présentation via un proxy pour empêcher le lazy loading soit tu passe via la couche DTO

A part ça Flex reste la meilleure solution en termes de sécurité, flexibilité, maintenabilité,... :

[A&N_L]

Pour ce qui est de Flex, personnellement, je ne l'ai pas essayé, je ne peux donc rien en dire... mais c'est propriétaire...

C'est là où le bas blesse...

Alors si vous avez des compétences technique pour mettre en place ce projet avec la technologie Flex

Nous ne connaissons ni Flex, ni JSF, d'où le critère de la "facilité" (il faudra quand même bien s'y coller !) de mise en oeuvre...

- si l'application est destinée aux utilisateurs web

Cela ne sera pas le cas.

si vous voulez l’intégré avec java donc tu vas obligatoirement utiliser le Framework open source blazDS

N'est-il pas possible de faire l'impasse sur BlazeDS en passant par des web services ?

soit t’implémente une couche coté présentation via un proxy pour empêcher le lazy loading

Justement, passer par des web services ne s'apparente-t-il pas à passer par un proxy ?

[Jacobian]

N'est-il pas possible de faire l'impasse sur BlazeDS en passant par des web services ?

- oui tu peux passer par des web services, mais la question triviale qui se pose est comment tu va gérer le parsing des fichiers XML to AS ou XML to JAVA ? alors la c'est la cata du fait que si vous avez des fichiers volumineux même avec les fichier normale vous aurez surement une dégradation des performances
- selon mon expérience utilisez BlazeDS sauf si vous avez plusieurs application qui peuvent communiquer avec le front-end.

• BlazeDS :

-Avantages: des appels rapids, plus petit paquet de données (c'est binaire) par conséquent le serveur est moins intense
-Inconvénients:lazyLoading, client Flex seulement

• WebServices:

-Avantages:peuvent utilisé avec plusieurs technologies
- Inconvénients:serveur intense, fichier XML a parser, paquet volumineux,...

[A&N_L]

Salut Jacobian,

Merci à toi pour ces précieuses informations !

... mais tu vas y avoir des problèmes du lazy loading

Oups... j'avais oublié un détail...

L'actuelle (et la future en Flex...?) couche de présentation n'est pas directement pluggée à nos EJB, nous avons déjà une couche web services :

Actuellement : JQuery/PHP => Web Services SOAP/EJB.
A venir...? : Flex => Web Services SOAP/EJB.

Du coup, arrêtez-moi si je me trompe, nous ne devrions pas être confrontés au problème de lazy loading puisque nous avons la couche Web Services SOAP, si...?

fichier XML a parser

Flex ne permet-il pas de faire nativement appel à des web services sans avoir recours à un parseur...?
Cf. : http://www.flex-tutorial.fr/2008/06/...ultat-exemple/
http://blog.flexexamples.com/2008/04...service-class/

Autre réflexion, BlazeDS et GlassFish font-ils bon ménage...?

Réflexion de dernière minute : quid de Flash Player en entreprise ?

Les grandes entreprises n'empêcheraient-elles pas, pour des raisons avancées (par elles-même et la presse/communauté spécialisée) de sécurité (je dis ça, je dis rien !), du contenu Adobe de passer au travers de leurs firewalls...?

Plus simplement, est-ce que Flash Player est massivement présent/installé chez les grands comptes... ou pas...?

[OButterlin]

Attention, ton étude porte sur la présence du plugin, ça ne veut pas dire grand chose, c'est surtout utilisé pour afficher des vidéos.
De là à dire que des applications flash sont massivement présentes, bof, je n'y crois pas trop... sans remettre en cause cette techno...

[A&N_L]

Attention, ton étude porte sur la présence du plugin, ça ne veut pas dire grand chose, c'est surtout utilisé pour afficher des vidéos.
De là à dire que des applications flash sont massivement présentes, bof, je n'y crois pas trop... sans remettre en cause cette techno...

Je suis d'accord... c'est pour cela que nous allons continuer à investiger, notamment en donnant les coups d'fil qui vont bien à droite à gauche...

Ce sur quoi nous partirions :

Pour nos besoins en terme d'animations pour nos produits : Flex !

Pour la plateforme d'administration : JSF tiendrait la corde.

J'm'y colle sérieusement et à la fin de la semaine j'vous fais mon rapport !

[A&N_L]

Suite & fin...

Après bien des réflexions (merci à vous !), il a été décidé que la partie présentation serait développée en (rrrrrrrrrrrrrrr... => roulement de tambours !) Flex !

Ainsi, une seule techno à appréhender pour l'ensemble de nos produits/applications...

Encore merci à vous pour vos éclairages !