Développement Java d'Entreprise : Quelle direction ?

Le , par Hikage, Rédacteur
Avec l'arrivée de JEE 6 et de Spring 3.0, le développement Entreprise est de plus en plus facile.

De son coté, Spring est largement utilisé à l'heure actuelle. Cependant, celui-ci n'étant pas un standard, il est fort décrié et nous lie fortement avec SpringSource.
Pa contre, un simple conteneur de servlet, comme Tomcat 6, suffit pour tirer partie de ses fonctionnalités.

JEE 6 de son coté apporte une nouvelle jeunesse à JEE en tirant de l'expérience de framework comme Spring ou encore Hibernate et en le standardisant.
La seule chose qui risque de freiner un peu son adoption est l'obligation d'un serveur JEE compatible, ce qui impose des couts de migration de serveur.

D'où ce sondage, afin de voir à l'heure actuelle, quel infrastructure est la plus utilisée : Conteneur de Servlet ou JEE ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de michael.isvy michael.isvy - Futur Membre du Club http://www.developpez.com
le 09/12/2009 à 18:44
@ZedroS, tu peux lire les commentaires de cette thread, c'est assez intéressant :
http://www.theserverside.com/news/th...hread_id=53529
Avatar de alexismp alexismp - Membre émérite http://www.developpez.com
le 10/12/2009 à 22:42
Citation Envoyé par michael.isvy  Voir le message
@ZedroS, tu peux lire les commentaires de cette thread, c'est assez intéressant :
http://www.theserverside.com/news/th...hread_id=53529

Ah oui, très bon thread effectivement (rare ces temps-ci sur TSS).
Avatar de joseph_p joseph_p - Membre expérimenté http://www.developpez.com
le 14/12/2009 à 9:24
Citation Envoyé par michael.isvy  Voir le message
@ZedroS, tu peux lire les commentaires de cette thread, c'est assez intéressant :
http://www.theserverside.com/news/th...hread_id=53529

merci bien, y avait en effet de la matière (et je n'ai pas encore attaqué l'ebook sur infoq.

Concernant les transactions read only, tant Mike Keith que l'auteur du sujet semblent réservés quant à leur usage.

En gros, leur argument est, si j'ai bien compris, que passer en read only implique de facto l'utilisation de transactions et que celles ci peuvent tuer le système (si grosses charges ou transactions trop longues).

Par contre je n'ai pas bien compris si une pile Hibernate + Spring (sans passer par JPA donc) permet d'éviter des transactions s'il y a un flag read only.

De façon plus générale, d'ailleurs, j'ai un peu de mal à bien me représenter les cas d'usages majoritaires, dixit Mike et Mark, de lecture de BDD sans read only/transactions (et quand, précisément et dans des cas bien moins fréquents, un read only/transaction serait approprié),

Perso j'aurai tendance à considérer l'aspect transactionnel en lecture dès que les données en dessous ne sont pas read only, histoire de m'assurer de la consistence de ma lecture.

Peut etre que l'ebook m'éclairera sur le sujet !
++
Avatar de NaZeF NaZeF - Membre à l'essai http://www.developpez.com
le 18/08/2010 à 16:10
Citation Envoyé par OButterlin  Voir le message
A la fin, on ne sait plus quoi choisir et lequel sera pérenne...

Longue vie à ton clavier, j'imagine que dorénavant va falloir standardiser tout ça.. pour un JEE newbie comme moi, on se perd avant même d'avoir commencer à coder, quoi utiliser au juste.. et s'il faut essayer toutes les technologies pour se faire un avis et savoir quel est le meilleur, on est bien partie pour une très longue chevauchée.. et c'est même pas sur que ça va payer

mais bon.. peut être me trompe-je..
Avatar de hhfr hhfr - Membre régulier http://www.developpez.com
le 31/07/2011 à 13:01
Tant qu'a attaquer un nouveau projet direction les derniers standards
Pour le metier EJBs sans hésitation.
EJB 3.1, MDB, CDI, JPA 2.0, Servlet 3....
Interceptors, Singletons, EJBs Asynchrones. On essaye et on adopte.

Pour l'ihm, je suis en revanche perplexe. j'opte pour Flex actuellement, mais je ne demande qu'a changer d'avis. Un faible pour XUL aussi, mais non standard et surtout un je m'en foutisme total de la part de mozilla qui on loupé le coche des RIAs.
JavaFX ? ce que j'en ai vu ne m'a pas convaincu.
HTML5 ? incomplet pour le RIA, non typé (javascript)
Quoi d'autre ?
Avatar de lunatix lunatix - Rédacteur http://www.developpez.com
le 31/07/2011 à 14:00
Coté RIA : il semble que HTML5 soit la solution d'avenir. Par contre, rien de folichon coté JEE. Si tu es pret a faire du javascript : tu peux partir sur jax-rs pour faire la partie serveur en rest (excellente api, tres bien pensée), et te trouver un systeme de templating correct (google closure template par exemple, ou StringTemplate)

(sinon le framework officiel web JEE, c'est JSF. bon perso, a part sous la torture, je ne l'utiliserais pas)
Avatar de OButterlin OButterlin - Modérateur http://www.developpez.com
le 31/07/2011 à 17:38
Citation Envoyé par lunatix  Voir le message
(sinon le framework officiel web JEE, c'est JSF. bon perso, a part sous la torture, je ne l'utiliserais pas)

Il y a une raison à cela ?
Avatar de lunatix lunatix - Rédacteur http://www.developpez.com
le 01/08/2011 à 0:07
1 : c'est complexe : faire son propre composant est difficile, le life cycle d'un bean jsf est horrible, il y a encore du xml de navigation inutile etc... Pire que tout, c'est un framework de composant ou il faut ensuite faire du xml dans le html a coups de <h:text etc... : le pire des deux mondes : des composants et un langage de templating mediocre.
Si on a pas le composant necessaire dans une lib : il est quasi impossible d'aller le chercher dans une autre.

2 : ca n'est adapté qu'aux applications : impossible de faire un site web qui ressemble a quelque chose. pas possible de faire du portail, du cms. Il est quand même evident qu'un framework a base de composants n'est pas adapté a tous les developpements web : sauf dans le monde JEE ou pour JEE6, les jsp ont été depreciées sans remplacement.

3 : ca rame : ca consomme beaucoup de memoire et de cpu. Un vrai probleme sur les sites a forte charge.

4 : ca genere du html horrible.

Au final : c'est tout sauf du web. Pas d'url restful, une integration d'ajax mediocre, pas d'acces au js. impossible d'integrer facilement un plugin jquery, utiliser les nouvelles fonctionnalités des navigateurs est compliqué... etc..
Avatar de OButterlin OButterlin - Modérateur http://www.developpez.com
le 02/08/2011 à 18:21
On dirait que ton appréciation date un peu. JSF 2.0 inclue pas mal de choses dont :

templating facelets
support total d'ajax
la création de composent ultra simple

Après, pour l'intégration de jQuery, je ne sais pas trop ce que tu cherches à faire mais on peut référencer et utilier jQuery avec JSF 2 avec
Code : Sélectionner tout
<h:outputScript library="jquery-ui-1.8.6/js" name="jquery-1.4.2.min.js"/>
Les JSP ne sont plus le standard, et c'est tant mieux pour les performances, c'est du xhtml avec facelets.
Ca ne veut pas dire qu'on ne peut plus utiliser les jsp, pour les vieilles applications, voir les 2
Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
<web-app> 
     <context-param> 
         <param-name>javax.faces.DEFAULT_SUFFIX</param-name> 
         <param-value>.jsp</param-value> 
     </context-param> 
 
      <!-- Facelets pages will use the .xhtml extension --> 
     <context-param> 
         <param-name>facelets.VIEW_MAPPINGS</param-name> 
         <param-value>*.xhtml</param-value> 
     </context-param> 
     
     <servlet> 
         <servlet-name>Faces Servlet</servlet-name> 
         <servlet-class>javax.faces.webapp.FacesServlet</servlet-class> 
     </servlet> 
 
      <!-- Use prefix mapping for Facelets pages, e.g. http://localhost:8080/webapp/faces/mypage.xhtml --> 
     <servlet-mapping> 
         <servlet-name>Faces Servlet</servlet-name> 
         <url-pattern>/faces/*</url-pattern> 
     </servlet-mapping> 
 </web-app>
Mais bon, pour les performances, il semble qu'il y ait mieux... pour les applications à fortes demandes.
Là, je n'ai pas assez de recul pour en parler, je ne fais que des applications d'entreprises, l'aspect performance n'est pas trop important.
Avatar de Logan Mauzaize Logan Mauzaize - Rédacteur/Modérateur http://www.developpez.com
le 03/08/2011 à 12:34
La partie AJAX est déléguée aux bibliothèques de composant comme RichFaces.

Côté performance, je suis peu dans le même cas qu'OButterlin. Cependant on a fait une maquette avant de lancer la migration de Struts1 + Framework Ajax maison ultra-simple ver JSF/RichFaces. Et on arrive à des charges similaires.

Pour la création de composants, un gars tout neuf en dev web a créée une nouvelle Combobox qui répondait à notre ancien framework maison en quelques jours.

Pour le XML de navigation, tu voudrais un système d'annotation ? Franchement je suis pas fan des annotations à tout va mais pourquoi pas. Ceci étant les règles de navigation de situe au dessus des beans selon moi.

Concernant les bibliothèques de composant, je te rejoins sur le principe. Quand tu en choisis une, tu ne pourras pas en sortir et il faudra utiliser des composants prévues pour cette bibliothèque.

Tu peux très bien faire des portlet avec JSF et c'est même prévue pour !
Tu peux même accéder indépendamment en mode portlet/servlet à une application déployée.

Pour le CMS, je pense que c'est possible. Mais il te faudra une bibliothèque (pas nécessairement de composant) ou une implémentation orienté dans ce sens.
D'ailleurs la gestion de contenu n'est clairement pas la cible de JSF qui s'inscrit dans une logique Java EE.

Pour le côté RESTFUL, comme le CMS ca reste possible. Je vois rien qui l'empêcherait.

Concernant le HTML générer j'avoue ne pas avoir regardé mais ca doit respecter le XHTML donc au moins ca devrait passer le validateur du W3C.

JSF n'est pas orienté Ajax à la base. C'est simplement un framework web, l'Ajax est une partie spécifique du web.
Avatar de achref05 achref05 - Membre à l'essai http://www.developpez.com
le 27/10/2011 à 17:38
Bonjour;
est ce vous avez une tutorial pour une application
hibernate spring vaadin?
merci
Offres d'emploi IT
Reconversion ingénieur informatique h/f
Adaming - Ile de France - Paris (75000)
Analyste programmeur cobol (h/f)
ABASE - Provence Alpes Côte d'Azur - Aix-en-Provence (13100)
Développeur java (H/F)
CITECH - Provence Alpes Côte d'Azur - Aix-en-Provence (13100)

Voir plus d'offres Voir la carte des offres IT
Responsables bénévoles de la rubrique Java : Mickael Baron - Robin56 -