Discussion :

[JonathanTC]

Bonjour,

Dans le cadre de ma reconversion professionnelle et de mon manque d'expérience en entreprise j'ai pris la décision de faire des projets Java EE que je pourrais mettre en avant lors de mes entretiens
Je suis en train de me renseigner et de suivre des cours sur java EE et je connais assez bien Java SE.

Je n'ai aucune idée de projet sur lequel je peux travailler et c'est la raison de mon poste. Je cherche un projet qui regroupe les fondamentaux de JEE.

Merci pour votre soutient.

[OButterlin]

Le cas typique d'usage est l'application web, je te suggère JSF 2.3 couplé à Primefaces pour la couche de présentation, EJB pour la couche métier et JPA pour l'accès aux données d'une DB... classique...

[deltree]

Bonjour,
Pour une première application, tu peux commencer par créer un service Web qui renvoie du Json. (utilisable par une app SPA JS externe). Ensuite tu rajoute des couches d'accès base (Hibernate ou autre). Par exemple une todo list, c'est un peu le hello world des appli web, exemple en front et back:
http://todomvc.com/
https://www.todobackend.com/

Pour ce qui est de JEE, tu peux choisir soit l'implémentation Glassfish, soit celle de redhat: Wildfly (anciennement JBoss)
J'ai trouvé ce tutoriel :
http://www.mastertheboss.com/jboss-f...forge-tutorial

Même si ce n'est pas la question, je te conseille aussi de te renseigner sur Spring boot (plutot que JEE), qui permet en gros de retrouver les mêmes concepts qu'en JEE, mais serait plus facile pour toi: déjà en JSE, pas de serveur à installer. Il y a même des annitations compatibles JEE/Spring
Pour commencer sur Spring boot: start.spring.io : ça permet de générer un projet maven directement compilable. il faut suivre les différents guides de Spring pour démarrer la dessus, exemple pour la partie JSON/web
https://spring.io/guides/gs/rest-service/

[deltree]

Le cas typique d'usage est l'application web, je te suggère JSF 2.3 couplé à Primefaces pour la couche de présentation, EJB pour la couche métier et JPA pour l'accès aux données d'une DB... classique...

Oui très bien, mais je préfère prévenir que JSF est un peu compliqué, mais surtout qu'il faut choisir entre service JSON couplé à du JS (ce que je propose) ou appli pure serveur comme tu propose.

[OButterlin]

Oui très bien, mais je préfère prévenir que JSF est un peu compliqué, mais surtout qu'il faut choisir entre service JSON couplé à du JS (ce que je propose) ou appli pure serveur comme tu propose.

Je me demande toujours pourquoi JSF à la réputation d'être compliqué, c'est au contraire extrêmement simple, il suffit d'apprendre le cycle de vie d'une requête

Pour Spring, pourquoi pas, je n'en parlais pas parce qu'il précisait JEE et Spring est carrément une techno concurrente à JEE (et je ne dis pas qu'elle n'est pas bien).
Je suggère cet axe de réflexion :

- si tu veux bosser dans une SSII, regarde peut-être plutôt Spring, ça a plutôt la cote chez eux
- si tu veux bosser dans un autre type de société, choisit plutôt JEE

Personnellement, je préfère JEE, mais sur un serveur EE bien sûr (comme Wildfly, Glassfich, Websphere etc...), pas un Tomcat où il faudra rajouter toute une liste de bibliothèques pour le rendre compatible avec EE

[deltree]

Je me demande toujours pourquoi JSF à la réputation d'être compliqué, c'est au contraire extrêmement simple, il suffit d'apprendre le cycle de vie d'une requête

Pour Spring, pourquoi pas, je n'en parlais pas parce qu'il précisait JEE et Spring est carrément une techno concurrente à JEE (et je ne dis pas qu'elle n'est pas bien).
Je suggère cet axe de réflexion :

- si tu veux bosser dans une SSII, regarde peut-être plutôt Spring, ça a plutôt la cote chez eux
- si tu veux bosser dans un autre type de société, choisit plutôt JEE

Personnellement, je préfère JEE, mais sur un serveur EE bien sûr (comme Wildfly, Glassfich, Websphere etc...), pas un Tomcat où il faudra rajouter toute une liste de bibliothèques pour le rendre compatible avec EE

Ah les gouts et les couleurs, oui comme je n'aime pas j'aurais tendance à dire que c'est compliqué mais je suis toujours tombé sur de vielles applications "legacy" usine à gaz. (ceci dit, le cycle de vie il a combien d'état déjà? )
Si je peux donc donner un conseil à notre ami: utilise une techno qui te plait (JSF ou autre JS+JSON) et si vraiment tu n'aime pas, tu peux toujours "switcher". tu trouvera toujours de l'aide. Effectivement en SSII (ESN maintenant) le couple Spring+Angular (ou react ,vue.js) est presque standard.

[OButterlin]

(ceci dit, le cycle de vie il a combien d'état déjà? )

6... à peine

Effectivement en SSII (ESN maintenant)

Vache ! J'ai pris un coup de vieux là (et j'ai vérifié, "SSII était utilisé avant 2013...")

Pour la fin de ton message, j'avais regardé angular il y a quelques temps et vue.js récemment, ce dernier me plaît assez je dois dire... le problème majeur que je vois aux framework javascript est lié aux navigateurs, on a encore de vieux tromblons dans le parc... et là, pas sûr que le javascript soit tout à fait compatible...
Mais à terme, l'idée de laisser le poste client s'occuper de générer l'IHM est plutôt intéressant, ça limite forcément le volume qui circule sur le réseau (sauf première fois).
Quid de la sécurité ? C'est au point ?

[deltree]

6... à peine

Vache ! J'ai pris un coup de vieux là (et j'ai vérifié, "SSII était utilisé avant 2013...")

Pour la fin de ton message, j'avais regardé angular il y a quelques temps et vue.js récemment, ce dernier me plaît assez je dois dire... le problème majeur que je vois aux framework javascript est lié aux navigateurs, on a encore de vieux tromblons dans le parc... et là, pas sûr que le javascript soit tout à fait compatible...
Mais à terme, l'idée de laisser le poste client s'occuper de générer l'IHM est plutôt intéressant, ça limite forcément le volume qui circule sur le réseau (sauf première fois).
Quid de la sécurité ? C'est au point ?

La sécurité est au point... mais amène de nouvelles problématiques: ex le JWT (JsonWebToken) te garanti une authent fiable en pur HTML, mais j'avais vu qu'en JS, une app tièrce pourrait éventuellement te voler to JWT , chose que tu peux éviter facilement protégeant tes cookies en HTML only, ça vient pas de moi, ça vient d'une pres que j'avais vu. (tu ne peux en théorie pas faire une confiance absolue à tous les JS que tu inclue, en pratique une lib JS avec un rootkit serait vite repérée)
Je suis pas sur que cette sécurité soit appliquée de partout.

Ceci mis à part: aucune problème de sécurité un fois authentifié: il faut servir tes ressources JSON en https, et faire un controle de droits d'accès systématique, comme tu ferais sur une page HTML.