Discussion :

[flamant]

Bonjour,

je vais travailler sur une application utilisant AngularJs et les EJB.

j'aimerai savoir quel composant parmi les EJB faut il utiliser pour recevoir les requêtes de la couche présentation (AngularJs). les web services EJB sont fait pour recevoir les requêtes CRUD (GET, POST, PUT, DELETE) mais lorsqu'il ne s'agit pas d'opération CRUD, faut-il utiliser des servlets ou peut on utiliser toujours les web service REST ?

Merci d'avance pour vos réponses

[Alkhan]

Bonjour,

bien sur que les requetes REST peuvent faire autre chose que du CRUD !

[OButterlin]

Ceci dit, la servlet reste une très bonne candidate

[flamant]

Merci Obutterlin pour ta réponse

[flamant]

Rebonjour,

je suis en train de lire un livre sur les EJB où ils disent qu'il vaut mieux ne pas utiliser des session Beans pour traiter les requêtes car cela utilise des ressources inutilement. Qu'en pensez vous ?

[OButterlin]

Je dirais que soit l'article est mal fait, soit tu as zappé un détail de taille...
Il existe 2 sortes d'EJB session :
- stateful
- stateless

Le premier à "mauvaise réputation", mais je dirais que c'est surtout quand il est mal utilisé... dans certains cas, il économise du traitement et est donc bien plus performant... dans un contexte web, on peut généralement s'en passer parce qu'on utilise la session (HttpSession) pour stocker les données.
Le deuxième, en utilisant l'interface @Local, est tout à fait similaire à un simple "pojo" dans son utilisation... on consomme, on libère... mais avec toute la puissance des EJB au niveau des transactions.
Maintenant, si la gestion des transactions par le conteneur fait partie des "ressources inutiles", là, c'est clair... c'est vachement moins bien

Avec l'interface @Remote, il faut bien comprendre qu'il y a sérialisation-désérialisation dans chaque sens et à chaque appel de méthode, donc là, c'est un peu plus gourmand en temps. Par contre, on peut utiliser un autre serveur (pour découper les traitements et optimiser les ressources).

Bref, c'est comme pour tout, il y a les pro et les anti... généralement, tout dépend de ce qu'on connaît et de ce qu'on maîtrise

[flamant]

Bonjour OButterlin et merci pour ta réponse

Voici un extrait de EJB 3 in action p52

As of Java EE 6, technically you can use EJBs directly as JSF-backing beans. Although this is possible and might be useful for rapid prototyping, this is generally an approach we recommend that you avoid. Session beans shouldn’t be used for page navigation or processing the request parameters from a web form. These are tasks best suited for JSF-backing beans or plain CDI-managed beans. Putting this logic in a session bean pushes the session bean up into the UI layer. Mixing UI logic and business logic makes for messy code that’s hard to maintain in the long run.

[OButterlin]

Là ils font référence à un EJB Stateful... et je partage leur avis, ce n'est pas l'endroit où on devrait stocker les informations de navigation.
Un stateful devrait être limité à la partie "métier", dans l'optique de conserver l'état "attaché" des entités entre plusieurs requête http.
Comme dit précédemment, en pratique, on n'en a pas besoin dans les applications web, sauf cas particulier et problème de performance sur des requêtes longues (par exemple pour une liste paginée).
Personnellement, je n'en utilise pas... que du stateless avec une façade et une couche DTO pour les vues

[flamant]

Merci OButterlin pour ta réponse