J2EE est un ensemble de normes et d'outils permettant à des applications Java de s'intégrer à une informatique d'entreprise (lire "à un merdier sans nom").
Pour ça, un serveur J2EE doit fournir les outils correspondant à un ensemble de normes dont les noms commencet souvent par J :
JMX (Java Management Extension) pour intégrer le serveur à un Nagios, par exemple
JMS (Java Messaging System) pour l'envoi de messages événementiels sur les systèmes de messages (jai oublié le nom, mais globalement, ça n'a rien à voir avec Evolution, Outlook ou Opera)
JTS (Java Transaction Service) pour gérer les transactions, voire même les transactions distribuées
JSP (Java Server Pages) une petite techno de présentation, qui a vécu.
EJB (Enterprise Java Beans) la norme phare de J2EE, qui définit des "objets métiers" sous un certain nombre de forme qui nous font revenir à l'époque bénie des struct C. Le seul avantage étant qu'ici, les struct peuvent être persistées de manière quasi-transparente ...
Et tant d'autres que j'oublie
Tout ça c'est bien joli, mais en fait, à sens, si J2EE apporte une certaine capacité d'intégration de Java à "l'informatique d'entreprise", ça se fait au prix de nombreuses contorsions :
- Durant le développement, car J2EE est une norme ouverte, qui n'impose que peu de choses (et qui notamment n'impose pas les descripteurs de déploiement permettant d'organiser tout le bouzin). Ce qui fait qu'une appli J2EE n'est en général pas ou peu portable (à moins bien sûr d'être codée avec des outils génériques, comme XDoclet ou Ant, et encore ...). Bref, l'enfer, le véritable enfer du développement J2EE, c'est que loin de nous aider à développer plus facilement grâce à une meilleure organisation Java (ce qui est en partie fait), le code est complètement scindé entre d'un côté le développement de composants Java, et de l'autre leur organisation (qui n'est souvent pas réellement séparée, du fait que ces applications soient le plus souvent des saletés de gestion) qui elle est contenue dans des fichiers XML.
- Durant l'utilisation, on est quand même très loin d'applications rapides. D'accord, ça marche, mais comme le dit de plus en plus de monde, la complexité de J2EE le rend inaccessible à l'immense majorité des développeurs. De plus, comme toute usine à gaz qui se respecte, le coût d'exploitation n'est pas nul, puisqu'il existe désormais des postes d'administrateurs d'applications J2EE, dont le rôle, tout comme pour un admin Oracle, est de faire en sorte que ça continue à marcher (!).
Bon, pour moi, développeur Java, il est clair que c'est uin bon gagne-pain. Toutefois, je trouve ça dommage qu'une techno comme Java serve à "ça", et surtout de cette manière là.
[^] # Re: newbie
Posté par Nicolas Delsaux . En réponse à la dépêche JBoss obtient la certification J2EE. Évalué à 10.
Pour ça, un serveur J2EE doit fournir les outils correspondant à un ensemble de normes dont les noms commencet souvent par J :
JMX (Java Management Extension) pour intégrer le serveur à un Nagios, par exemple
JMS (Java Messaging System) pour l'envoi de messages événementiels sur les systèmes de messages (jai oublié le nom, mais globalement, ça n'a rien à voir avec Evolution, Outlook ou Opera)
JTS (Java Transaction Service) pour gérer les transactions, voire même les transactions distribuées
JSP (Java Server Pages) une petite techno de présentation, qui a vécu.
EJB (Enterprise Java Beans) la norme phare de J2EE, qui définit des "objets métiers" sous un certain nombre de forme qui nous font revenir à l'époque bénie des struct C. Le seul avantage étant qu'ici, les struct peuvent être persistées de manière quasi-transparente ...
Et tant d'autres que j'oublie
Tout ça c'est bien joli, mais en fait, à sens, si J2EE apporte une certaine capacité d'intégration de Java à "l'informatique d'entreprise", ça se fait au prix de nombreuses contorsions :
- Durant le développement, car J2EE est une norme ouverte, qui n'impose que peu de choses (et qui notamment n'impose pas les descripteurs de déploiement permettant d'organiser tout le bouzin). Ce qui fait qu'une appli J2EE n'est en général pas ou peu portable (à moins bien sûr d'être codée avec des outils génériques, comme XDoclet ou Ant, et encore ...). Bref, l'enfer, le véritable enfer du développement J2EE, c'est que loin de nous aider à développer plus facilement grâce à une meilleure organisation Java (ce qui est en partie fait), le code est complètement scindé entre d'un côté le développement de composants Java, et de l'autre leur organisation (qui n'est souvent pas réellement séparée, du fait que ces applications soient le plus souvent des saletés de gestion) qui elle est contenue dans des fichiers XML.
- Durant l'utilisation, on est quand même très loin d'applications rapides. D'accord, ça marche, mais comme le dit de plus en plus de monde, la complexité de J2EE le rend inaccessible à l'immense majorité des développeurs. De plus, comme toute usine à gaz qui se respecte, le coût d'exploitation n'est pas nul, puisqu'il existe désormais des postes d'administrateurs d'applications J2EE, dont le rôle, tout comme pour un admin Oracle, est de faire en sorte que ça continue à marcher (!).
Bon, pour moi, développeur Java, il est clair que c'est uin bon gagne-pain. Toutefois, je trouve ça dommage qu'une techno comme Java serve à "ça", et surtout de cette manière là.