Discussion :

[quanta]

Bonjours,

J'ai lu pas mal de choses sur JEE et j'avoue ne pas avoir encore tout saisi.

De ce que j'ai compris donc JEE c'est un ensemble de spécifications pour créer du site web (c'est pas un framework ?) à partir de Java suivant le modèle MVC.

Avec pour le C => les Servlet (qui doivent être contenus dans un conteneur (pour moi Tomcat).
Avec pour le V => les JSP (avec les expressions langages pour s'affranchir de l'écriture de Java dans la view).
Avec pour le M => Les Javabeans. Alors là, si j'ai bien compris ce sont des objets décrivant une entité et ces informations uniquement (comme un client par exemple), le but serait que cet objet puisse être utilisé par d'autres applications ?

Jusqu'ici je pense avoir compris, mais le drame vient avec tous les frameworks qui tournent autour de JEE (dans sa dernière version)...

On parle de Spring qui serait un conteneur léger...
Je n'arrive pas à comprendre le lien entre JEE et Spring. Autant Hibernate je pense avoir compris (s’affranchir de l'écriture de requête en dur)...
Mais Spring je n'en comprends pas l'utilité.

Sinon, utiliser uniquement JEE comme il est, sans tous les autres frameworks, est-ce possible ou pas du tout ?

Merci d'avance pour votre aide.

[fxrobin]

JEE n'a rien à voir avec MVC.
Même si c'est mieux de faire du MVC avec JEE, ce n'est pas impératif.

JEE est un ensemble de spec supplémentaires par rapport à JSE.
Alors oui, JEE permet entre autre, de faire des sites web (en MVC ou pas) mais pas uniquement :
- tu peux faire des applications de Web Services
- des modules EJB
- de la persistance avec JPA
- du traitement de fil de messages pour applications asynchrones ...
- etc ... (bref tout ce qui à trait à des applications "professionnelles")

Tout cela n'est pas inclus dans JSE alors que ça l'est dans JEE.

Histoire de clarifier, Tomcat n'est pas un serveur JEE, mais un "simple" serveur JSP / Servlet. Un vrai serveur JEE, c'est par exemple GlassFish, JBOSS ou encore WebSphere et Weblogic ... etc. Cependant il est vrai que tu peux étendre ton "application" avec JPA et JSF en y ajoutant les bons JARs et faire en sorte que ça commence à ressembler à un vrai serveur JEE ... mais il te manquera toujours les EJB et leur caractère performant et transactionnel.

Utiliser JEE tout seul : oui sans problème, surtout JEE6. Avec JSF 2 + JPA 2 + EJB 3.1 + CDI ...tu as tout ce qu'il faut pour bien coder ... même si perso je ne me passerait plus de tout un tas de bibliothèques "Apache Commons" pour ne pas à avoir à ré-inventer la roue ainsi qu'une bibliothèque complémentaire JSF 2 comme PrimeFaces (ce n'est pas un framework) et enfin juste Spring Security (et encore) pour la partie authentification / sécurisation.

[quanta]

Tout d'abord un grand merci pour ta réponse.

Je voudrais revenir sur les EJB. Si j'ai bien compris les EJB c'est donc des un ensembles d'objet qui vont s'occuper de tout ce qui est "métier" (par exemple gestion des clients, commande, etc...). Cette ensemble et contenu dans un serveur spécial EJB.
L'intérêt c'est donc de découplé totalement la logique métier de tout ? Les EJB peuvent donc aussi bien être attaqué via le web que en local ?
Donc si je comprend bien cette sectorisation faite c'est avec nos servlet que l'ont va attaqué les EJB (+/- comme un service web non ?).
Donc au final on aurait deux serveur, l'un pour les servlet/JSP et l'autre pour les EJB ?
J'ai tout faux ou pas ?

Question annexe : J'ai pour un projet besoin de générer/traité des images. Ces opération sont-elle considérer comme "métier" ? Si oui elle se situerait dans les EJB ?

Merci d'avance

[fxrobin]

Oui de manière logique "tu as deux serveurs" un JSP/ Servlet l'autre EJB ... mais souvent en pratique les deux "services" tournent dans le même serveur sur la même machine ... dans la même JVM. La séparation n'est pas physique mais logique.

Sinon c'est ça.

L'avantages des EJB c'est qu'ils sont créés (instanciés) par le serveur et depuis ta servlet tu ne fais appel qu'à un "Service" ... Ils sont "pré-instanciés" sous forme de pool, ce qui te fais gagner le temps d'instanciation, par le serveur EJB. En cas de trop forte consommation mémoire, certains qui ne sont plus utilisés sont "stockés" temporairement ... enfin les méthodes sont transactionnelles. Bref plein de belle chose qu'un simple objet JAVA (sans EJB) ne peut pas faire.

Essayer les EJB 3.1 c'est les adopter ...
Surtout avec JSF et CDI en fait. Avec les annotations c'est vraiment rapide de faire une "bonne" application : robuste, fiable et propre.

[quanta]

Essayer les EJB 3.1 c'est les adopter ...
Surtout avec JSF et CDI en fait. Avec les annotations c'est vraiment rapide de faire une "bonne" application : robuste, fiable et propre.

Tout d'abord un grand merci, tes réponses m'ont bien clarifié les choses.

Sinon encore quelques questions :

De ce que j'ai lu, JSF c'est uniquement pour la partie Servlet / JSP non ?
D'autre part, puisque tu dis que le conteneur de servlet et le conteneur d'EJB sont généralement hébergés sur le même serveur (d'ailleurs c'est logique ça ?), quels serveurs faut-il pour héberger les deux conteneurs ?

Merci d'avance.

[fxrobin]

Oui JSF est une "surcouche" au dessus de Servlet et JSP.
Ca se situe bien côté "conteneur Web", c'est à dire dans un WAR.
JSF te permet de faire la partie visuelle d'une application Web.
Avec JSF, sauf cas particulier, tu ne manipules plus directement Servlet et JSP (mais c'est mieux de connaitre, comme ça repose dessus).

Quant aux choix de ton serveur ... comme son nom l'indique, cela reste un choix "personnel" ou alors un choix d'entreprise.

Perso, je préfère GlassFish 3.1 ... mais JBoss est bien aussi.

Si tu débutes avec tout ça je te suggère d'utiliser plutôt NetBeans (packagé avec GlassFish) plutôt qu'Eclipse, un peu "difficile" parfois à paramétrer avec tous ses plugins et j'ai eu quelques soucis pour paramétrer le dernier Eclipse (Juno) avec le plugin GlassFish par exemple ... j'ai réussi, mais ce n'était pas très simple.

[fxrobin]

Tout d'abord un grand merci pour ta réponse ^^
Question annexe : J'ai pour un projet besoin de générer/traité des images. Ces opération sont-elle considérer comme "métier" ? Si oui elle se situerais dans les EJB ?

Traiter les images : oui dans la partie EJB
Générer des images : ça peut se discuter, mais je dirai "non", car si c'est juste une problématique d'affichage : partie WEB. Je dirais "oui" si par exemple l'image générée tu dois la stocker et lui donner une valeur métier.

Ca dépend donc de ton analyse.