Validation et logique de traitement

les stateful session EJB peuvent tout deux
appeler des méthodes dans les objets d’aide, qui seront mis
en oeuvre soit comme des POJO soit comme des stateful session
EJB. Les POJO sont simples à  écrire et conviennent pour
le code d’aide qui n’est nécessaire qu’au frontal d’une application
particulière ou au stateful session EJB principal.
On préfèrera les stateless session EJB pour les fonctions
ou opérations (routines de tarification, par exemple) qui font
partie du modèle de gestion sous-jacent et seront probablement
présentes dans de multiples applications. Les stateless
session EJB conviennent également pour mettre en oeuvre
une opération impliquant l’accès à  la base de données ou
toute autre opération qui doit faire partie d’une transaction,
comme expliqué dans la section suivante.
Un stateless session EJB contient du code Java que
l’on peut appeler à  partir de servlets, d’autres EJB ou de
POJO. On peut assimiler un stateless session EJB à  une « bibliothèque de procédures ». Contrairement
à  un stateful session EJB
(ou à  une procédure HLL iSeries), un
stateless session EJB ne peut pas maintenir
un état propre à  une session ou à 
un appelant, d’une méthode d’invocation
à  la suivante. (Ne vous laissez pas
déconcerter par le médiocre choix des
noms pour les stateless session EJB : ils
n’ont pas grand chose à  voir, il est vrai,
avec le concept d’une session.)