Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
OK,
Pour en revenir aux webservices, je comprend l'interet que tu leur trouve, mais dans mon cas, l'appli est une appli web et le client un simple navigateur (IE ou de préférence Firefox), dès lors je ne pense pas que les WS soient nécessaires. De plus l'appli n'est pas distribuée si ce n'est que l'archi de déploiement sera "éclatée", c'est à dire avec apache, Jonas ou Jboss (serveur d'appli) et les BD sur des serveurs différents.
Oui effectivement si ton appli n'est pas distribué , l'interet des web services est moindre, on peu imaginer qu'elle le deivendras mais dans ce cas rajouter des web services en facade ne devrait pas etre complexe.
Autre chose la mode est au web et c'est vrai que Ajax permet de combler bcp de lacune des interfaces graphique du web, mais ca reste du javascript (BEURKKK enfin c'est mon opinion), je pense (et finalement j'espere) qu'on en viendras au client "lourd" d'autant plus que java c'est bcp amelioré de ce coté la.
Et pour en revenir a ta question initiale tu n'as toujours pas de reponse finalement ?? on a juste soulever d'autres questions
UML avec VIOLET
Salut,
Je trouve ça étonnant qu'en tant qu'étudiant en école d'ingénieur on te confie une telle responsabilité : 100 000 utilisateurs ? Et tu serais celui qui va mettre en place l'architecture ? ça me parrait disproportionné, ou bien imprudent de la part de ton employeur; tu es stagiaire j'imagine ?
J'ai l'impression qu'il cherche à t'exploiter.
Bon, mis à part ça, je peux te dire que la solution "classique" maintenant qui est spring+hibernate+struts ( + tiles eventuellement ) me parrait être une solution qui d'ici 3 ans sera encore utilisée.
Le gros avantage de cette solution, est que tu n'es pas dépendant d'un serveur J2EE, et qu'un simple conteneur de servlets suffit; Si tu codes bien tes différentes couches, tu peux obtenir de très bonnes performances, avec un code compact et efficace. Tomcat dans sa version 5 est vraiment très performant ( nikalkal : quelle version de tomcat utilises-tu ? )
Utiliser EJB ( même dans la version 3 ) est à mon avis un choix à prendre avec beaucoup de précautions; Certes, les serveurs J2EE ( même opensource comme JBOSS ) gèrent plutot bien le load balancing et les accès concurrents avec les EJB, c'est d'ailleurs ce qui les fait vendre : mais si tu prends le temps de bien coder ton application avec les apis que je cite plus haut tu auras tout autant de performance; donc pourquoi déployer une usine à gaz, alors qu'il existe un moyen de faire équivalent, avec des technos qui sont largement utilisées ? Tu peux aussi faire du load balancing et du clustering avec Tomcat...
JSF : je n'aime pas trop cette solution, je ne la trouve pas très élégante.. Tapestry ou Wicket sont très interessants, car ils permettent à plusieurs personnes de collaborer sur un projet pour le front; Tapestry est mon préféré !
Je pense que faire du J2EE est une décision à faire quand le projet est vraiment très conséquent, et en l'occurence il faut donc en tant qu'architecte prévoir aussi les personnes qui vont administrer tout ça; sans administrateur, faire du J2EE est courir au suicide, et si il n'y a qu'une seule application, ça devient ridicule; J2EE c'est quand on a des admins dispo 24/24 en cas de problème et quand on a plusieurs applications à faire cohabiter, je parle d'applications lourdes.
A+
K
La dernière (5.5.17) et j'ai un problème de perf car à chaque fois que j'arrete et redémarre mon appli sur le serveur, le process prends de tomcat prend de la mémoire en+ et ne la libère jammais. Lorsque je dépasse les 110Mo d'utilisation mémoire de ce process, tomcat plante.Envoyé par KiLVaiDeN
Ps: voiçi le lien vers une discussion sur ce problème resté sans réponse : http://www.developpez.net/forums/sho...d.php?t=140695
@+
-> L’amour est à la portée de tous, mais l’amitié est l’épreuve du cœur
-> La nature nous a donné deux oreilles et seulement une langue afin de pouvoir écouter d'avantage et parler moins
-> Trois sortes de gens disent la vérité : les sots, les enfants et les ivrognes
Je vais voir ce post
K
Merci KiLVaiDen,
Pour ce qui est du nombre d'utilisateur, il est vrai que celà peut sembler plutôt étonnant. Pour expliquer simplement :
- le projet a été lancé il y a maintenant 2 ans.
- il est destiné à une administration et si je suis "dessus" c'est parceque mon école (spécialisée en techno Web) est partenaire du projet.
- nous (on est 2) sommes actuellement en train de déployer la première version et celle-ci rentrera en test "situation réelle" à partir de la semaine prochaine.
- cette version "beta" a été réalisée avec Struts et Tiles (pour le front) par d'autres étudiants.
- le premier déploiement ne concernera qu'une zone "test"
- on nous demande, après avoir mis en production cette version, de prévoir l'archi de la prochaine version, qui sera elle déployée à un niveau régionnal puis, si succès il y a, à un niveau nationnal.
- selon les responsables du projet, l'appli actuelle n'est pas à même de répondre à une telle montée en charge
- l'archi de la prochaine version devra donc être à même de supporter celà.
Pour ce qui est de la partie Front, notre choix est quasiment fait et se dirige vers Wicket (pour faciliter la reprise du projet par nos successeurs mais aussi car conceptuellement j'aime vraiment l'approche objet qui correspond, pour moi, le plus au respect du modèle MVC, car elle permet de vraiment séparer affichage et code).
Pour "enrichir" nos client, nous utiliserons Ajax. S'il est vrai, que notre interet est probablement du à la mode actuelle de cette techno, elle a tout de même l'avantage de permettre des choses qui évitent l'utilisation d'un client lourd, ce qui pour nous est très important puisque la simplicité d'utilisation de l'appli est le facteur principal pour la réussite de ce projet. L'installation d'un client "lourd", rendrait plus difficile la distibution aux clients de l'appli.
Pour ce qui est de la partie Service et Domaine, nous hésitons encore entre une approche totalement J2EE avec les EJB3 et une approche "composite" avec l'utilisation de Spring. Je pense qu'à ce niveau là, la décision reviendra à nos responsables.
Pour le mapping objet/relationnel, Hibernate nous attire beaucoup, mais idem, si nos responsables souhaitent réellement une approche totalement J2EE, nous devrions tester JPA.
Enfin pour le serveur d'appli, nous pensions à Tomcat dans le cas où nous n'utiliserions que quelques briques de J2EE, par contre si on part sur du tout J2EE, on pense à GlassFisch. (d'ailleur quelqu'un ici aurait-il déjà tester ?).
Voila, je suis totalement d'accord avec toi, sur le côté "usine à gaz", mais tu dois savoir que les projets réalisés dans le monde universitaire rentrent souvent dans ce "domaine" là.
Et puis, nous sommes la pour apprendre, donc autant essayer d'utiliser les technos les plus récentes. Parallèlement à celà, je suis tout à fait conscient qu'en entreprise, les choses ne se déroulent pas de la même manière puisque d'autres critères rentrent en compte (notemment le côté économique).
Enfin, pour répondre à FreshVic, si je commence à avoir des réponses à ma question initiale, même s'il est vrai que beaucoup de questions supplémentaires ont été levées, mais il me semble que c'est nécessaire pour faire le bon choix, sans être "aveuglé" par l'attrait de la dernière mode...
Je comprend mieux
Petite remarque importante : Ajax est une techno très interessante, mais attention aux problèmes de montée en charge : sur certains serveurs, chaque requête ouvre un nouveau thread, et lorsqu'il y a beaucoup d'accès concurrents, ça peut plomber le serveur; Ajax malheureusement multiplie les requêtes, et donc c'est un goulot d'etranglement assez important.
Miser dessus est une bonne idée malgré tout, si la mise en production au niveau "national" se fera dans les prochaines années; car d'ici là la plupart des serveurs sera équipé de systèmes permettant de mieux gérer Ajax et son "problème" de multiplication de requêtes;
Il y a déjà Jetty 6 qui offre via les Continuation une proposition pour résoudre le problème; ça sera peut-être intégré aux prochaines specs !
Tes choix me parraissent en tout cas très sage ! Tes responsables par contre y vont un peu fort en déclarant que l'application ne tiendrait pas la route en cas de montée en charge; je pense que c'est juste un pretexte pour vous faire étudier une solution plus "innovante" ! Il y a beaucoup d'applications qui tournent avec Struts Tiles Hibernate et autre Spring avec beaucoup de succès !
Une autre remarque au sujet de Wicket : je trouve que c'est interessant, mais dans le principe, JSP peut également être interpreté comme un moteur de template; Avec les taglibs par exemple, tu peux aussi très bien séparer le code de la vue !
Bon courage en tout cas ! Et amusez vous bien, c'est un projet plutot interessant je pense !!
K
Bonjour à tous,
Très instructifs ce p'tit sujet
J'aurais une question plutot d'ordre général sur les applis Web, concernant la montée en charge, existe-t-il des techniques, voire des astuces pour bien calculer se paramètre qui joue un grand role dans le choix des technos et des serveurs à utiliser ?
Merci d'avance de vos idées et suggestions.
Salut,Bonjour à tous,
Très instructifs ce p'tit sujet
J'aurais une question plutot d'ordre général sur les applis Web, concernant la montée en charge, existe-t-il des techniques, voire des astuces pour bien calculer se paramètre qui joue un grand role dans le choix des technos et des serveurs à utiliser ?
Merci d'avance de vos idées et suggestions.
Pour la montée en charge il faut utiliser des outils de type JMeter !
Sinon, il faut également profiler son application, et voir les zones d'ombre; cherche profiler j2ee pour trouver plusieurs options de profiling
A+
K
Je comprend mieux
Petite remarque importante : Ajax est une techno très interessante, mais attention aux problèmes de montée en charge : sur certains serveurs, chaque requête ouvre un nouveau thread, et lorsqu'il y a beaucoup d'accès concurrents, ça peut plomber le serveur; Ajax malheureusement multiplie les requêtes, et donc c'est un goulot d'etranglement assez important.
Miser dessus est une bonne idée malgré tout, si la mise en production au niveau "national" se fera dans les prochaines années; car d'ici là la plupart des serveurs sera équipé de systèmes permettant de mieux gérer Ajax et son "problème" de multiplication de requêtes;
Il y a déjà Jetty 6 qui offre via les Continuation une proposition pour résoudre le problème; ça sera peut-être intégré aux prochaines specs !
Tes choix me parraissent en tout cas très sage ! Tes responsables par contre y vont un peu fort en déclarant que l'application ne tiendrait pas la route en cas de montée en charge; je pense que c'est juste un pretexte pour vous faire étudier une solution plus "innovante" ! Il y a beaucoup d'applications qui tournent avec Struts Tiles Hibernate et autre Spring avec beaucoup de succès !
Une autre remarque au sujet de Wicket : je trouve que c'est interessant, mais dans le principe, JSP peut également être interpreté comme un moteur de template; Avec les taglibs par exemple, tu peux aussi très bien séparer le code de la vue !
Bon courage en tout cas ! Et amusez vous bien, c'est un projet plutot interessant je pense !!
Merci,
Pour ce qui est de Ajax, j'avoue que je n'avais pas ciblé ce problème, mais effectivement, d'ici à ce que cette version soit en production, le problème devrait être résolu (enfin il faut l'espérer). Dans tous les cas, son utilisation sera "résonnée" et uniquement la où elle apporte réellement un plus pour l'utilisateur (l'engouement actuel pour Ajax et l'utilisation qui en est faite me rappelle ce qui s'est passé il y a 3/4 ans quand Flash est arrivé sur le marché, tout le monde en mettait dans tous les sens...).
Concernant mes responsables, c'est sur qu'ils en profitent, même si on est encore de petits étudiants, on est pas totalement dupes, mais tant que ça nous permet de progresser et d'être à la "pointe "
NB : je réitère ma question au sujet de GlassFisch, quelq'un aurait déjà testé ?
En ce qui concerne GlassFish , a priori pour le moment il ne s'agit que d'une maquette , donc ca reste a voir .
http://java.sun.com/javaee/community/glassfish/
UML avec VIOLET
Non, pas vraiment une maquette!
GlassFish (ou Java EE SDK, c'est la même chose) est une implémentation complète de Java EE 5 (EJB 3, etc...)
Ses performances et ses outils de monitoring et d'administration en font un très bon candidat pour une mise en production aujourd'hui.
A noter que pour les entreprises, la version supportée est Sun Application Server 9 (basée directement sur GlassFish).
A noter que Seam fonctionne sur GlassFish.
Encore un avis de plus
Perso je suis un fan ultime de Spring. Donc je conseille Spring à toutes les sauces. Voila mon application type
Présentation
Spring Webflow //Cette un framework récent mais quand même en 1.0 qui permet de faire en sorte que les flows soient lisible ce qui est le gros défaut de struts ou plein de choses concernant l'enchainement sont planquées dans les actions
Spring MVC //Parce que si déja je suis spring fan je vais pas te vendre du struts mais honnêtement ca le fait aussi bien y compris avec spring webflow
Business
Spring pour lier le tout et surout avoir le support des transactions au niveaux des objets métiers.
DAL
Hibernate //avec support spring ca facilite grandement la vie
JDBC //avec support de spring
Donc je résume Spring+Hibernate
Concernant JSF j'ai eu une très mauvaise expérience l'été dernier avec l'implementation de sun ainsi qu'avec celle de myfaces. Cétait pas du tout mature. Peut être est ce mieux maintenant. Mais je me méfie encore.
Pour ce qui est de EJB 3.0, j'ai essayé il 2-3 mois l'implémentation de JBOSS, c'est plus simple que les 2.1 mais j trouve ca encore franchement trop compliqué pour la plupart des applications, entrement dit pour moi utiliser les EJB c'est comme utiliser un bazooka pour tuer une mouche. Si tu la touche le problème est définitivement rêglé mais c'est vraiment pas facile de toucher une mouche avec un bazooka. Mais certaines fois tu as des mouches tsé tsé qui nécéssitent des objets répartis ou de la redondance à tout les étages et la il faudra utiliser les EJB.
Pour ce qui est de la fagocitose des EJB sur Spring, j'attend de voir ce serait certainement pas mal puisque cela unifierai un peu le monde java que les appli respectent un peu plus les standard fournit par Sun.
Steve Hostettler
est ton ami(e) et le tag
aussi.
Super, on a trouvé la solution à tous nos problèmes!! ;-)
Des détails! Au passage, JSF 1.2 est dans Java EE 5 maintenant...
Idem, qu'y a-t-il de lourd/bazooka dans les EJB 3 qui sont maintenant des POJO?
Il faut bien distinguer les frameworks et les serveurs d'applications...
Les contraintes sont toujours les memes : version de JAVA (5 ou pas) et niveau de servlet/JSP/EJB du serveur d'application.
Si tu as les pleins pouvoirs de décisions :
sans hésiter : EJB3.
par contre pour la couche présentation, il est temps d'arréter struts, ca fait 2 ans que ce projet est mort et il souffre de beaucoup de défauts de conception. si tu veux garder un modele MVC, prends celui de spring qui est très souple. sinon JSF + facelets est surement est bon choix si le niveau des developpeurs est corrects ...
Il y a en ce moment énormement d'alternatives excellentes pour les couches présentations :
-wicket
-echo2
-ZK
-Lazslo
-stripes
-gwt (pas très mature)
-...
Bon courage car le choix n'est pas facile...
Qu'est ce qui te fai dire cela ?
Cours et tutoriels pour apprendre Java , FAQ Java, et Forum Java
"La liberté de tout être s'arréte là où commence celle de l'autre... Respecter l'autre, c'est préserver sa liberté d'être, de penser et de vivre"
Il y a Struts 2 qui est en préparation au fait, déjà téléchargeable sur le site de jakarta. Donc dire qu'il est mort est à mon avis prématuré
K
Et même la première version de Struts, elle est encore très largement utilisé par les entreprises développant en web/java, donc même s'il n'est plus de première jeunesse, je pense qu'il est très loin d'etre mort.Il y a Struts 2 qui est en préparation au fait, déjà téléchargeable sur le site de jakarta. Donc dire qu'il est mort est à mon avis prématuré
"La liberté de tout être s'arréte là où commence celle de l'autre... Respecter l'autre, c'est préserver sa liberté d'être, de penser et de vivre"
Oui bien sûr, 100% d'accord avec toi, Bellissima !
K
Je dis simplement que utiliser struts sur un projet tout neuf si on est pas obligé par la politique maison, c'est vraiment dommage...struts n'a pas évolué depuis 2 ans ! en informatique et surtout en nouvelles technos Java, ca fait vieux.
struts 1.x est lourd et rigide (erreurs de jeunesses du modele MVC2), il y a des alternatives mieux concues.
Il suffit d'essayer webwork (qui devient d'ailleurs le coeur de struts avec son fameux Xwork) ou springmvc pour comprendre...
struts 1.x est largement utilisé et déployé donc survivra longtemps. c'est comme le cobol. c'est pas pour ca que je me sens obligé de commencer un nouveau projet avec.
La 'nouvelle' version (ou plutot les nouvelles versions) de struts ne sont pas LE struts que tout le monde connait. Il ne reste que le nom, ca c'est du marketing. on change le produit, on garde le nom pour continuer a rassurer les décideurs informatiques...
@+
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager