Java JEE + Batch

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.

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 ?

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.

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