[EJB3] Théorie: Session bean ou entity?

Le
Raphael Tagliani
Bonjour,

J'ai cherché un forum j2ee dans les newsgroup, mais je n'ai pas trouvé,
alors je me permets d'écrire ici (j'ai aussi peur que si j'en trouve un,
il soit désert)!

J'ai une table, dans une base de données, dans laquelle je veux modifier
des valeurs à intervalle régulier. Pour se faire, je veux lancer un
traitement en utilisant un Timer (@Timeout). Ce traitement étant un
traitement métier, je me demande simplement si je dois mettre ma méthode
annotée @Timeout dans un Stateless Session bean, ou dans l'Entity bean
qui gère la table.

Alors, SBean ou Entity bean?

En fait, l'idée du session bean me dérange un peu, car la modification
des valeurs dans la table n'est pas liée à un utilisateur. D'un autre
côté, c'est bien là qu'on met le code métier non?

Merci!
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Renaud
Le #228653
Bonjour, je ne suis pas specialiste mais je vais tacher de repondre.

Le code metier doit se retrouver dans un session bean, stateless ou
stateful.
Les entity bean ne servent qu'a "representer" la base de données, en aucun
cas il ne faut mettre du code metier dedans.
De plus, un session bean stateless n'est pas lié à un utilisateur, c'est le
session bean stateful qui l'est.
Il faut donc bien mettre ton code dans un stateless.

J'espere avoir correctement repondu,
Renaud.

"Raphael Tagliani" news:
Bonjour,

J'ai cherché un forum j2ee dans les newsgroup, mais je n'ai pas trouvé,
alors je me permets d'écrire ici (j'ai aussi peur que si j'en trouve un,
il soit désert...)!

J'ai une table, dans une base de données, dans laquelle je veux modifier
des valeurs à intervalle régulier. Pour se faire, je veux lancer un
traitement en utilisant un Timer (@Timeout). Ce traitement étant un
traitement métier, je me demande simplement si je dois mettre ma méthode
annotée @Timeout dans un Stateless Session bean, ou dans l'Entity bean
qui gère la table.

Alors, SBean ou Entity bean?

En fait, l'idée du session bean me dérange un peu, car la modification
des valeurs dans la table n'est pas liée à un utilisateur. D'un autre
côté, c'est bien là qu'on met le code métier non?

Merci!


Maxime Daniel
Le #228652
On 30 mai, 17:17, "Renaud"
Bonjour, je ne suis pas specialiste mais je vais tacher de repondre.

Le code metier doit se retrouver dans un session bean, stateless ou
stateful.
Les entity bean ne servent qu'a "representer" la base de données, en au cun
cas il ne faut mettre du code metier dedans.
De plus, un session bean stateless n'est pas lié à un utilisateur, c' est le
session bean stateful qui l'est.
Il faut donc bien mettre ton code dans un stateless.

J'espere avoir correctement repondu,
Renaud.

"Raphael Tagliani"
Bonjour,

J'ai cherché un forum j2ee dans les newsgroup, mais je n'ai pas trouv é,
alors je me permets d'écrire ici (j'ai aussi peur que si j'en trouve un,
il soit désert...)!

J'ai une table, dans une base de données, dans laquelle je veux modif ier
des valeurs à intervalle régulier. Pour se faire, je veux lancer un
traitement en utilisant un Timer (@Timeout). Ce traitement étant un
traitement métier, je me demande simplement si je dois mettre ma mé thode
annotée @Timeout dans un Stateless Session bean, ou dans l'Entity bean
qui gère la table.

Alors, SBean ou Entity bean?

En fait, l'idée du session bean me dérange un peu, car la modificat ion
des valeurs dans la table n'est pas liée à un utilisateur. D'un aut re
côté, c'est bien là qu'on met le code métier non?

Merci!



Renaud,
permettez-moi de n'être pas d'accord.
Historiquement, les session beans ont été essentiellement introduits
pour :
- améliorer les performances des systèmes J2EE ;
- capturer la notion de connexion active au système, ou session.
Lorsque que l'on a décidé d'implanter des entity beans *malgré les
pénalités induites en termes de performances*, les entity beans
doivent être responsables de tous les accès au modèle. Ils doivent
présenter au monde extérieur une vue cohérente du modèle métier, et
tout accès doit leur être délégué.
La confusion provient de ce que, de façon pragmatique, l'utilisation
de session beans plus ou moins bien écrits permet, *en sacrifiant le
paradigme objet*, d'obtenir de meilleures performances à environnement
matériel et logiciel constant, sur les requêtes qu'ils implantent
(pour s'en convaincre, il suffit de réaliser que la couche entity,
intermédiaire obligatoire dans une architecture puriste, disparaît
purement et simplement - qui dit chemin d'appel plus court dit
meilleures performances ; sans négliger que, quelques progrès qu'ils
aient fait depuis leurs débuts à la fin des années 90, les serveurs
d'application souffrent avec les objets métier, de la même façon
qu'auparavant les moniteurs transactionnels "meulaient" régulièrement
les serveurs CORBA, ou que les SGBD relationnels ont toujours une
avance considérable en performances sur les SGBD OO).
Pour faire un parallèle simpliste, les session beans sont aux entity
beans ce que le C est au Java...

Le choix primordial est donc entity beans ou pas. Une fois le choix
effectué :
- soit on n'a pas d'entity beans ; on code alors des session beans
pour tout, en projetant éventuellement une lecture pseudo objet sur un
outil essentiellement fonctionnel ;
- soit on a décidé délibérément d'ajouter des entity beans ; dans ce
cas, les session beans doivent uniquement servir de façade, et
améliorer la qualité de service, par exemple en permettant une
urbanisation intelligente des transactions les plus sollicitées, et
gérer l'aspect session (comme leur nom l'indique), c'est-à-dire les
données transientes qui ne doivent pas survivre à la connexion
utilisateur ; des architectures en plusieurs couches sont possibles ;
l'un des design patterns usités consiste à faire correspondre les
session beans à des 'use cases' ; mais les entity beans doivent
conserver l'exclusivité de l'accès aux données, parce que ce sont eux
qui sont les garants du modèle ; (on admettra que des processus
puissent être implantés en utilisant des techniques plus adaptées aux
traitements de masse, mais il seront *toujours* chers à développer et
à maintenir, devront s'exécuter quand le système est isolé du
transactionnel - pas d'utilisateurs, et on a alors tout intérêt à
choisir des techniques *vraiment* performantes, donc plus de beans du
tout).

Il y a des subtilités dans tous les scénarios possibles (aka stateless
vs statefull session beans, avec ou sans réplication des serveurs
d'applications), mais, personnellement, je m'en tiendrais assez
volontiers aux deux règles suivantes :
- n'introduire les entity beans que si l'on est disposé à en payer le
prix (en mémoire, CPU, etc.) ;
- si on introduit les entity beans, alors leur déléguer rigoureusement
la gestion du modèle de l'application, selon un design OO.


Alexandre Touret
Le #228651
Bonjour,

J'ai cherché un forum j2ee dans les newsgroup, mais je n'ai pas trouvé,
alors je me permets d'écrire ici (j'ai aussi peur que si j'en trouve un,
il soit désert...)!

J'ai une table, dans une base de données, dans laquelle je veux modifier
des valeurs à intervalle régulier. Pour se faire, je veux lancer un
traitement en utilisant un Timer (@Timeout). Ce traitement étant un
traitement métier, je me demande simplement si je dois mettre ma méthode
annotée @Timeout dans un Stateless Session bean, ou dans l'Entity bean
qui gère la table.

Alors, SBean ou Entity bean?

En fait, l'idée du session bean me dérange un peu, car la modification
des valeurs dans la table n'est pas liée à un utilisateur. D'un autre
côté, c'est bien là qu'on met le code métier non?

Merci!
Bonjour,

le principal pb c est qu'ils n ont rien a voir. Ds la specification JPA,
les entites ne peuvent pas etre appeles a distance et sont (presque)
obliges d etre appeles dans le cadre d un contexte de persistance.
Le code metier est donc centralise dans le SB et les entites ne sont que
la representation des donnees. Pour information, la specification n est
qu une evolution des implementations HIBERNATE et TOPLINK et n a rien a
voir avec les anciens EJB.


Dans ton cas, je pense que le timer doit etre place dans le session
bean. La transaction demarre a ce niveau par defaut. Il ne faut pas
oublier que les entites sont lies a un contexte de persistance qui est
lui meme lie a une transaction et une connexion.
Enfin, la specification indique qu une entite ne contient pas de code
metier ( impossible d etre appele sauf a partir d un sb ...)

Bon courage

Alexandre

TestMan
Le #228628
Bonjour,

J'ai cherché un forum j2ee dans les newsgroup, mais je n'ai pas trouvé,
alors je me permets d'écrire ici (j'ai aussi peur que si j'en trouve un,
il soit désert...)!

J'ai une table, dans une base de données, dans laquelle je veux modifier
des valeurs à intervalle régulier. Pour se faire, je veux lancer un
traitement en utilisant un Timer (@Timeout). Ce traitement étant un
traitement métier, je me demande simplement si je dois mettre ma méthode
annotée @Timeout dans un Stateless Session bean, ou dans l'Entity bean
qui gère la table.

Alors, SBean ou Entity bean?

En fait, l'idée du session bean me dérange un peu, car la modification
des valeurs dans la table n'est pas liée à un utilisateur. D'un autre
côté, c'est bien là qu'on met le code métier non?

Merci!


Bonjour,

Je ne pense pas que la spec JPA accepte les annotations @Timeout sur des
@Entity (à vérifier par vous même). Car à moins de disposer d'un système
de selection de l'instance à cibler on ne saurait envoyer le timeout à
qu'à toute les instances de l'entité persistée.

Le plus simple me semble d'être un @Stateless qui contient le code JPA
"qui va bien" pour récuperer les instances de votre entité que vous
voulez puis appeler sur chacune une méthode style incremente() qui
encaspule une logique metier pour l'instance.

Pour ce qui est des performance des entités, les EJB3 étant basés sur
JPA aucun soucis ni paramétrage en perspective pour des applis courantes.

A+
TM

Raphael Tagliani
Le #228528
Merci à tous pour vos réponses! J'ai finalement opté pour un SBean
Stateless avec un @Timer, qui fonctionne très bien.
Bonne journée!
Publicité
Poster une réponse
Anonyme