Discussion :

[benoitstock]

Bonjour,

J'ai besoin d'avis/d'aide.

Je travaille actuellement sur un nouveau projet pour pouvoir utiliser JEE au sein de mon entreprise.
Le POC est concluant mais le jour de la présentation, une question est survenue:

--> Dans un but de réutilisation de code, de standardisation, que se passe-t-il, pour une classe annotée Stateless (ou autres).
Si nous voulons utiliser celle-ci dans un batch par exemple... Quid aussi de tout ce qui est laissé géré par le conteneur comme les transactions, l'entityManager ?

Je remarque qu'il y a un nouveau standard dans la version 7 "JSR 352" qui permet de faire du batch... Quelqu'un a-t-il de l'expérience dans ce domaine, quel est son avis, est ce que cela pourrai être la solution à notre question ?

Merci d'avance de votre participation.

[Ithildine]

Je ne suis pas certain de bien comprendre ton soucis mais voici malgré tout quelques éléments quant à la réutilisabilité du code.

Même s'il est possible d'invoquer un Stateless bean depuis pas mal d'endroits, je recommande généralement à mes développeurs de placer la logique de traitement plutôt dans des beans CDI, le Stateless ne gérant alors que l'aspect transactionnel et d'éventuels conversions d'exceptions. A mon sens, la meilleure brique, la plus facilement réutilisable en environnement JEE, est le bean CDI. CDI est un outil fantastique de souplesse pour la réutilisabité et l'extension. Je recommande également de faire de petits beans CDI et de déléguer les traitements à un autre bean CDI de manière à avoir des classes à très forte cohésion (elle ne gère qu'un aspect du problème et un seul). Ainsi, grâce à CDI, plus les classes sont petites et ont une forte cohésion, plus le code est extensible, simple à comprendre et lisible (EDIT: et surtout testable unitairement !!). Le contract fonctionnel de chacun de ces beans CDI doit être extrêmement précis et clair. Le seul point point à garder en tête est alors le nombre de beans que l'implémentation de CDI devra scaner au démarrage du conteneur.

Ai-je répondu à ta question ?

[Ithildine]

Quant à la "JSR 352", il s'agit d'une reprise presque à l'identique des batchs de Spring qui sont un standard éprouvé depuis pas mal d'années. Je n'ai malheureusement aucun retour concret au niveau d'un environnement de production à faire pour le moment. Sans doute que d'autres ont déjà mis en production cet outil très intéressant qui vient combler un manque dans JEE.

[manipas]

EJB ou CDI c'est presque la meme chose, la difference est comment ils sont invoqués.
CDI le container regarde le scope (session, application, requete , conversion)
EJB le container regarde le hashmap si le bean is stateful ou stateless ou singleton
Les CDI ou EJB sont reutilisables s'il sont deployés dans un serveur d'app. qui est java EE 6+ compliant, en ce qui concerne leur design, les principes sont les memes.
En voici quelques uns

- forte cohesion (comme le dit le post precedent)
- couplage faible
- Separation on concerns (pense a la separation des pouvoirs dans la vie courante )
- Single responsability principle (ton EJB ou CDI ne doit s'occuper que d'un domaine d'affaire bien precis)
- keep it simple and clear (soit clair et concis dans ta conception)
...

Concernant java EE + batch
- Dans un passé pas tres lointain, on utilisait des servlets, puis on les appelait dans la crontab unix en utlisant la commande wget. ça fonctionnait assez bien.
Puisque dans la servlet etait injecté le EJB qui faisait la logique d'affaire, qui lui etait deployé dans le container java EE et beneficiait ainsi du context transactionnel et qui utilise une implementation JPA (entityManager) pour l'access au data,
- Quartz/Spring est arrive et il est vraiment bon pour ça, il est largement utilisé il utilise la notion de crontab expression (comme unix crontab) pour l'appel de ta classe batch, qui elle va appeler ton ou tes EJB qui sont deployes dans le container
- Java EE avec JSR 352 vient combler ce vide

Moi je partirai avec le JSR 352