Bonjour tous les monde,
 
Déjà je présente le dilemme. Je travaille actuellement pour une société (une PME) qui à besoin de faire un outil de reporting. Cette outils devra gérer 4 rôles d'utilisateurs différents et de nombreuses données. Suite aux besoins du système (monté en charge max de 10000 utilisateurs, beaucoup de traitement avec une base de données), j'ai décidé d'utiliser du J2EE pour le développement. Maintenant reste à sélectionner le framework et c'est la que ça coince. Après une recherche fastidieuse sur les différents framework du marché, deux d'entre eux ont retenu mon attention:
- Struts
- Wicket
 
Je pense que tout le monde connait Struts, pas besoin de le présenter. Wicket est un jeune framework (2007), qui admet le même principe que JSF (basé sur l'événementielle).
 
Voici la raison de mes choix,
Struts est actuellement la référence au niveau des frameworks J2EE, il admet une grande communauté,  une très bonne documentation, il est facile de trouver quelqu'un afin de le maintenir et admet beaucoup de fonctionnalités. Cependant, il est lourd à configurer et admet une courbe d'apprentissage plutôt lente.
Wicket est un jeune framework donc tenant compte des échecs des autres framework. Développé par Apache (on peut se dire que c'est du sérieux). Il gère bien l'Ajax et l'événementiel. Et surtout il est très simple d'utilisation. Cependant, il n'est pas encore mature et admet une petite communauté.  
 
Je tiens a signaler que je suis dans une société composé de deux programmeurs n'ayant jamais fait de J2EE (qui seront chargés de la maintenance et moi du développement) et que la courbe d'apprentissage du framework admet un rôle important dans le choix du framework. De plus, tous les applications déjà existantes sont amenées à migré sur ce framework.
 
Dès lors, j'aimerais avoir votre avis sur la question. Quel framework semble le plus adapté? Quel est votre avis sur ces deux frameworks? Avez vous des exemples de réalisation de Wicket pour la grande production? Si vous avez des informations en plus sur ces frameworks qui m'aurai échappé n'hésitez pas à me les transmettre.

Je tenais juste à signaler que j'ai regarder sur le site officiel de wicket pour avoir des exemples de site utilisant wicket

Est-ce que tu as regardé GWT ?
GWT est peut être plus rapide à apprendre que Struts ou Wicket, et permets aussi de developper plus vite.
Après ce n'est peut-être pas le genre de framework que tu recherches...

Merde je l'ai posté en double.

 
J'avoue que je ne connaissait pas GWT, enfin juste de nom sans plus. C'est surtout orienté Ajax ça non? C'est bien pour les rôles?

GWT ne gère pas de role utilisateur, ca serait à toi de l'implémenter.

 
ok, il ne correspond pas à se que je recherche alors. Je cherche un framework qui automatise ces taches la (un peut comme struts, wicket, JSF et autres). En effet, si on doit migrer toutes les applications web sur le même framework, je me vois pas refaire la gestion de la sécurité à chaque fois.    Merci quand même du conseil.

Au fait, vu que Wicket est peu connu, j'aurais aimé savoir aussi ceux qui connaissent Wicket, ca m'aiderait peut-être dans ma décision.

Salut,
 

 
Wicket ca dechire sa race, on est a fond pour.
Prochain progiciel de la boite tout en Wicket, apres choix tatillon et exhaustif.
 
@++

Un des avantages de Wicket, c'est que ce n'est pas difficile de trouver de développeurs, encore moins que Struts en fait. Il suffit en effet de connaitre Java et le xhtml. Le débogage permet de bénéficier des débogueurs d'eclipse & co et donc le débogage est plus rapide qu'avec les frameworks basés sur les JSP. En fait on bénéficie de tous les outils Java pour le développement. Un autre avantage, est qu'on peut plus facilement capitaliser, avec Wicket, et enfin, le déploiement est simplifié.
 
Par contre, c'est très adapté pour une appli web complexe, du style intranet ou GUI d'une appli d'entreprise, mais coté performances, je ne choisirais pas pour des sites à forte fréquentation, parce que le serveur est fortement sollicité.  
Quand tu dis que tu comptes avoir 10000 utilisateurs en ligne, c'est réellement 10 000 en simultané ou 10 000 abonnés  et au mieux une centaine en simultané ? Je pense qu'au-dela d'une ou deux centaines, il faut commencer à se renseigner sur la tenue en charge de Wicket, ou mieux, faire des tests sur une maquette. Mais à mon avis, il ne tient pas. C'est un serveur "statefull", càd que le serveur garde en RAM les données de session de chaque utilisateur,  contrairement aux frameworks basés sur les JSP. Bien que ce comportement soit localement débrayable, on entre dans le domaine de l'optimisation. Cela peut limiter la scalabilité du système sur de grosses charges.  
Struts de son coté tient la charge et certainement plus rapide que Wicket. . Struts2 est par contre bcp plus lent que Struts, p-ê même plus lent que Wicket. De même pour JSF, qui semble décidément être un assez mauvais choix (sauf p-ê avec Seam).
 
Enfin, quitte à faire du Struts, un framework digne d'attention est Stripes, et ses perfs sont apparemment comparables.
De toute façon, si tu as 10 000 utilisateurs simultanés (ce dont je doute fort tout de même, une telle charge, c'est un truc du genre site de la SNCF, c'est pas trop un projet pour 2 personnes), c'est qq chose d'énorme, et là, il vaut mieux passer à PHP (malheureusement), et surtout, surtout, optimiser au maximum le modèle de données de la BD, càd optimiser les requêtes, utiliser les caches, mettre un maximum de données dans des tables read-only, écrire des procédures stockées, etc.

 
Je suis daccord avec toi sur ce point la. Cependant, le vrai problème ne reside pas dans la recherche de personnes pouvant maintenir l'application Web, mais dans le suivit de Wicket (correctif et mise à jours du framework).

Quand je parle de 10000 utilisateurs c'est la monté en charge maximale que doit supporter l'application. En gros, il y a potentiellement 10000 clients concernés, se qui ne veut pas dire qu'ils se connecterons en même temps. En moyenne, il devrait y avoir 1000 utilisateurs en même temps maximum je pense.
 

Je connais pas du tout!!! Je vais regarder ca, si tu as des informations dessus te gène pas pour me les données.

Le PHP est 100 plus lent que le Java à être executer. Je crois pas qu'il soit adapté dans se type d'application. Du moins pas encore. En plus le Java permet quand même une meilleur gestion de la monté en charge. Tout ca pour dire que le Java me semble plus adapté dans se type d'application Web.

Quitte à faire du struts

J'aimerais que tu évites ce genre de comparaisons douteuses entre un framework qui rendrait presque le développement web en java agréable (presque) et Struts, qui est la pire horreur que j'ai eu l'occasion de tester

J'aime pas les gens qui tirent des chiffres de leur chapeau comme ça

Tu n'as pas dit que tu t'étais renseigné sur les frameworks java? J'ai pas mentionné stripes précédement parce que je pensais que tu avais déjà couvert tous les trucs dispos

Intrinsèquement oui, quand on fait du web non. Les webapps PHP ne créent pas des stacks de 300+ d'épais et ne tentent pas de lire 15 fichiers XML à chaque requête.

Et accessoirement, PHP est infiniment supérieur à java quand on se met à prendre en compte la vitesse de développement en compte (parce que la vélocité d'une solution java/Struts, comment dire...)

Ben t'aurais tord

Absolument, mais alors vraiment beaucoup absolument pas.

Ton estimation me parait pour le moins curieuse. Quelle est l'application ?

J'ai entendu parler de ce framework en lisant un peu sur le web. Veille technologique en quelque sorte.

Oui mais comme il n'y a pas des dizaines ou des centaines d'appels sur la pile, au final, les applis PHP sont souvent plus véloces, bien que moins structurées qu'en Java.
De gros sites comme Yahoo ont adopté le PHP.

Houla, tu t'effrayes de peu, on fait bien pire chez Porcos. On fait du MVC modèle 1 selon la terminologie Sun.

Je dis pas le contraire, mais j'ai pas eu l'occasion de tester (science merci), et Struts c'est déjà bien assez merdique pour moi, même avec XDoclet histoire d'avoir moins mal au cul

 
Se sont les impératifs de l'application, c'est un développement professionnel et non personnels, même si mon supérieur à tendence à être optimiste, je préfère une appli qui tien trop bien, plutôt que l'inverse.    
 

 
Honnêtement, j'ai pas beaucoup d'échos sur se framework. En plus, j'ai eu que 2 semaines donc j'ai pu creuser que 7 frameworks et j'ai donc du faire des choix.
 

 
Je suis d'accord sur le fait, que le PHP est beaucoup rapide à développer et déployer, par contre si le PHP est si véloce, pourquoi est il si peut utilisé dans le cadre d'applications Web conséquentes.
 
Enfin, bon le débats, n'est pas sur le fait que le PHP est plus rapide ou lents que le J2EE, mais plutôt le quels des deux frameworks est adapté. Si on rentre dans se débats la on en à plus finit.    

Un point intéressant a été abordé par el muchacho, Wicket est il capable de gérer beaucoup d'utilisateurs à la fois? Si se n'est pas le cas, ça m'aiderait beaucoup dans ma décision

Que ce soient des chiffres tirés de ton chapeau ou de celui de ton chef, ça revient au même. http://www.zedshaw.com/rants/programmer_stats.html tout ça.

1. Faudrait éviter de changer de cible en permanence, tu veux rapide de suite ou tu veux scalable? Parce que l'architecture par défaut de PHP est beaucoup plus facilement scalable que celle de J2EE
2. Java le langage est rapide, J2EE et les frameworks associés sont lents. Faut pas confondre. PHP le langage est extrèmement lent, mais PHP + bytecode cache ça rivalise sans gros problème avec pas mal de combos (framework, serveur) J2EE
3. Dans nombre de webapps, la limitation reste de toute façon la DB (ou les accès aux WS remote), pas les pages même
4. peu utilisé dans le cadre d'apps web conséquentes? Facebook, Livejournal, Digg, Wikipedia, c'est tout du front PHP quand même Il y a beaucoup plus de sites web publics en PHP qu'en java, et de très loin.

 
Je veux bien te croire, je suis d'accord que la base de données limites beaucoup le temps de réponse (les ORM résolvent ils se problème?). Je cherche pas à changer de sujet, je cherche juste à parler du sujet du topic. Je ne comprend pas pourquoi les gens cherches systématiquement à imposer leur technologies. lol. Je ne pense pas qu'actuellement PHP soit adapté pour les besoins de l'entreprise où je travail. Certes il admet ces avantages et ces inconvénients, si tu veux en discuter, n'hésite pas à ouvrir un nouveaux sujet et je me ferais un plaisir d'y participer pour te donner mon avis avec plus de précision (car il y aura toujours des choses à dire, même si j'aime bien le PHP c'est pas non plus LE langage). Tu me signal le sujet en MP et j'y participerai avec plaisir car je trouve les débats toujours très instructifs.
 
J'aimerais juste qu'on reparle de la comparaison entre Wicket et Struts, c'est très important pour moi. Merci de votre compréhension.
Une information supplémentaire, l'application devra fonctionner avec les 15 compagnies travaillant en partenariat avec la société (chiffres certifiées et pas sorties du chapeau cette fois ). Ceci impose une grande modularité de l'application. De plus, je ne crois pas avoir signalé que les rôles sont très importants dans le cadre de l'application. Le quel des deux framewok est le plus modulaire selon vous? Qui gère mieux les rôles? Et est ce que quelqu'un à déjà testé la monté en charge de Wicket pour savoir si il tien la route?

au fait pour ceux que ça intéresse, voici un comparatif intéressant que j'ai trouvé lors de ma recherche. Je vous le transmet au cas ou.
http://blog.xebia.fr/2007/10/26/xe [...] k-contest/

Non, ils l'empirent.

Je ne vais pas dire le contraire dans la mesure où je hais PHP

Personne n'a encore testé la monté en charge de Wicket?

Non, mais je ne crois pas une seconde qu'une société composée de 2 programmeurs puisse être retenue pour faire une application ayant une montée en charge de 10 000 personnes, surtout si les deux personnes ne connaissent pas JEE.

edit: je vois que vous n'êtes pas 2, mais un paquet de sociétés, ce qui rend le projet nettement plus crédible.

Si c'est une application publique, je pense que vous vous trompez de deux ordres de grandeur. Ce forum-ci, a plus de 300 000 inscrits, et il y en a environ 3000 en simultané (il est en PHP). Un rapport de 1/100 entre le nombre de connectés et le nombre d'inscrits est observé sur les forums. Je pense que ce rapport est déjà une borne supérieure de l'affluence moyenne pour les sites publics (style voyagistes), avec à la grosse louche des pics de x10 à certaines périodes (vacances dans le cas du site de voyages) par rapport à l'affluence moyenne. J'ai l'impression que l'appli de votre client est une appli de ce genre.
Si c'est une application d'entreprise que vous créez, il y a rarement plus de quelques centaines d'utilisateurs en simultané (pour des très gros clients), mais par contre, leur usage est bcp plus régulier. Tout cela est certainement prévu et quantifié par le client et il (ou les autres boîtes) va/vont choisir la techno qui va bien, pas vous.
 
De toute façon, avec Wicket, au pifomètre, je ne parierais pas sur plus de 100 utilisateurs simultanés/processeur pour un temps de réponse acceptable. Mais encore une fois, sans tests de charge sur une page complexe, c'est impossible de répondre précisément.

Si je me plante pas, Twitter a initialement été développé par genre 3 personnes

Bon, j 'avoue que mon 10000 est un peu exagéré.  En gros il sera utilisé par 10 voir 15 sociétés différentes (chaque sociétés comprennent entre 500 et 1000 personnes). Enfin bon, le chose étant que wicket ne semble pas tenir la monté en charge, donc déjà la dessus c'est régler.
 
PS: Le nombre de programmeur ne fait pas la force d'un programme.  

Ce qui compte, c'est de savoir quelle est la fréquence d'utilisation par les utilisateurs.
Si c'est un annuaire téléphonique, même avec 15000 personnes, chacune tapera dans l'appli une ou deux fois par jour au plus, ce qui fait qu'en réalité, il n'y aura guère plus de 50 utilisateurs simultanés. Si ce sont 15000 secrétaires ou démarcheurs téléphoniques, par contre, ils seront connectés en permanence et là, tu peux multiplier ce nombre par dix.

A mon avis, Stripes est une solution viable. C'est en tout cas la-dessus que je partirais si j'étais dans le genre de cas de figure que tu décris.

 
En gros c'est un outils de rédaction de compte-rendu est diffusion de ces derniers. Donc entre les personnes qui écrivent les comptes rendu (et y en a pas qu'un par jours) et ceux qui les lisent ça fait du monde. Finalement wicket a été écarté, car pas assé mature et c'est possible qu'il soit qu'une simple mode. Je me suis orienté finalement sur la triplette JSF, Hibernate et PostGres. (Je connais pas bien Stripes, mais je vais me renseigner dessus quand même, merci du conseil).

M'ouais, s'il y a un choix que je ne ferais pas, c'est bien JSF.
D'après le lien que tu as donné (Xebia http://blog.xebia.fr/2007/10/29/re [...] xebia-29/) et divers retours sur le net qui donnent à peu près tous le même son de cloche, JSF tout seul n'est pas un très bon choix, sauf éventuellement dans le cadre de JBoss Seam.
JSF a déjà montré ses limites, au point qu'il y a déjà une spec 2.0 en préparation. De plus, JSF n'est semble-t'il pas très performant.

Comparaison JSF-Stripes:
http://radio.javaranch.com/gthough [...] 66323.html

 
Je sais mais malheureusement j'ai pas trop eu le choix la dessus. Finalement c'est la solution qu'a retenu mon boss

Sur quels critères, à part le marketing ?
Si tu peux lui copier-coller quelques retours d'expériences glanés sur le net (google "JSF sucks", tu en as pas mal...), n'hésite pas.

JSF Implementation sucks - Sun please read
"

You have an interesting hypothesis there. In short, the only reason JSF “sucks” is that people think it “sucks”. Frankly, I don’t buy it. The majority of people who hate JSF hate it because of the headaches they’ve had to go through to get some seemingly simple functionality to work correctly.

I know I hate JSF for just that reason. I’ve had nothing but endless headaches trying to build a JSF based interface for a Java system. There are so very many things that just don’t work, there’s little to no feedback on why things aren’t working, and the actual process that goes on behinds the scenes is intentionally opaque. If anything does go wrong, debugging it is sheer hell. When you do get an error message that indicates an actual problem, rather than the wrong error message entirely, there is a total lack of helpful supporting information to help determine what, exactly is wrong.

The _Real_ problem with JSF is that it is immature, buggy, and dysfunctional. It might still be better than Struts, but that’s a case of proving how bad Struts is, not how good JSF is."
http://www.spenceruresk.com/2007/0 [...] -with-jsf/

Ca rejoint l'expérience de Xebia. Et des commentaires comme cela, on en trouve des dizaines. Quand ce genre de commentaires se répète à divers endroits du net de façon indépendante, moi je dis que statistiquement, ça ne sent pas bon.

En gros, si ton boss se sent rassuré en partant sur JSF, qui ressemble à une norme (presque) aussi foireuse que JSP, essaye d'inclure JBoss Seam dans la boucle pour éviter de souffrir trop, et ça devrait le faire. Quitte à le faire en douce.

Heuu c'est moi qui comprend pas, ou le monsieur dit que pour utiliser stripes faut savoir coder en java et que c'est mal?

http://blog.developpez.com/djo-mos [...] d_the_ugly
 
Les perfs mauvaises de JSF:
http://blog.developpez.com/djo-mos [...] cesseur_da
 

 
Je suis pas expert en JSF, mais j'ai cru comprendre qu'il y avait deux styles de librairies qui se faisaient la guerre sur JSF, la open source et celle développée par sun. J'ai l'impression que les tests on été effectuées sur celle de sun. Je me demande se que ça donne sur l'autre?

 
t'as des sources pour étayer un peu tes discours grandiloquents ou juste tu t'écoutes parler ... ?

il dit pas qu'il faut savoir coder en java, il dit qu'il faut etre bon+mordu, alors que t'as des millions d'indiens pour te faire des applis en jsf

ouais mais bon, en même temps, si tu compares une appli web java avec 320 framework lourdingues qui servent a rien ou ne sont pas appropriés, avec une appli php customisée aux ptits oignons pour la db qui va aller avec, bon, ... Parce que d'un autre coté, je sais pas ou ça en est maintenant, et comment c'est documenté et accessible pour le niveau moyen d'un mec qui fait du php, mais y'a qques années, j'avais voulu faire une appli con-con en php, mais je voulais pas aller dans la base a toutes les requetes pour remplir les dropdown d'un formulaire.. ben pour mettre ces données en cache.. j'avais l'impression de faire du C, là, d'un coup...
 
Le prob de base ici c'est qu'on dit Java et qu'on pense de suite aux 300 frameworks qu'on va empiler, et qu'on met a coté un truc developpé plus pragmatiquement en php ..

On compare les solutions "classiques" dans les langages  
 
Donc en java c'est un truc avec 300 frameworks lourdingues en même temps, en PHP c'est soit la méthode la rache soit un des frameworks sortis ces dernières années (Zend, Cake, Symfony, CodeIgniter), en Ruby c'est Rails, ...    
 
Les gens qui font du web en java en tapant directement dans les servlet brutes ça fait un moment que j'en ai pas vu

C'est bien vrai (meme si j'en ai rencontré un pas plus tard que ce matin :-) ). Mais t'es pas obligé d'utiliser 300 framework non plus. Dans le cas de Struts, beh t'utilises Struts comme framework et basta, a la limite tu rajoutes un framework pour le ORM genre hibernate ...

J'ai des sources. Que toi tu n'en aies pas, ça ne m'étonne guère, mais ça ne t'autorise nullement à te la jouer petit chef, merci.
Ceci dit, venant de toi, personne n'est surpris, d'ailleurs je m'étonne qu'on t'ait autorisé à sortir du seul topic où quelqu'un te supporte encore.