Discussion :

[Romz82]

Bonjour,

je me pose quelques questions sur l'utilisation d'EJB en grand nombre dans une application:
je travaille sur un projet de taille moyenne (un peu plus de 100.000 lignes) qui utilise 120 EJB.
En fait, quasiment toutes les classes métier de l'application sont des EJB locaux, et c'est seulement la propriété d'auto-injection des EJB qui est utilisée.

Je me demande si c'est une bonne pratique de déployer un tel nombre d'EJB, et si la seule utilisation de l'injection justifie de faire de chaque classe métier un EJB?
Est-ce que ça ne risque pas de poser des problèmes de performance une fois l'application en production?

Est-ce qu'il ne serait pas préférable d'utiliser d'autres frameworks d'injection?

[fr1man]

Vous n'utilisez pas les aspects transactionnels, voire sécuritaires ?

[youx]

Vous n'utilisez pas les aspects transactionnels, voire sécuritaires ?

comme vu dans quelques projets et leurs justifications: c'est beaucoup plus simple à instancier, il n'y a pas à faire de "new" à faire.

[fr1man]

Ca me parait un peu léger comme explication.
Dans ce cas, depuis java ee 6, on peut faire de l'injection de bean sans pour autant qu'ils soient des EJB.

[Romz82]

Bonjour fr1man,

oui ça me semblait aussi un peu léger d'utiliser les EJB juste pour éviter le new! Et c'est un peu ce qui est fait sur ce projet...

Au sujet des transactions, certaines classes utilisent les transactions mais pas la plupart. La sécurité est gérée uniquement à la connexion, je ne crois pas qu'on utilise les fonctionnalités de sécurité des EJB (à vérifier, là je suis en vacances et je n'ai pas le code sous la main ^^)

Je ne savais pas qu'on pouvait faire de l'injection de bean sans les EJB, tu aurais des liens sur le sujet?
Une recherche Google sur java ee 6 bean injection me renvoie justement vers les EJB...

[fxrobin]

Si tu fais des EJB 3, par défaut ils sont transactionnels.
Par défaut aussi leur cycle de vie est géré par le conteneur (donc, pool d'EJB) ce qui est un vrai gain de performance puisque cela évite les "new".

Pour éviter "autant" d'EJB (si ça te gène, car perso, je ne trouve pas cela gênant) tu peux toujours les inclure dans quelques "Facades" qui frontalise justement les autres.

[fr1man]

Regarde du coté de CDI (contexts and dependency injection).
http://docs.oracle.com/javaee/6/tutorial/doc/gjbnr.html

Coté EJB, j'oubliais, entre autre, l'aspect accès distant via les interfaces remote qui peut etre intéressant.
Donc avant de tout jeter, il vaudrait mieux etre certain de la raison exacte pour laquelle ils ont été mis en place, car j'ai du mal à croire que la personne qui a choisi cela, a simplement vu le coté instanciation facile.

[Romz82]

Oui fxrobin, ce sont bien des EJB3.

Je vois bien l'idée de transaction pour l'accès en base, par ex nos DAO sont des EJB transactionnels, mais pour les services je ne vois pas trop ce que ça signifie?

C'est à dire que si j'ai une classe EJB de service et qu'une erreur s'y produit, eh bien... quoi donc? S'il y a eu un appel de DAO qui s'est bien déroulé avant l'erreur, la base retournerait à son état initial?

[Romz82]

Oui c'est ça, l'accès distant, mais on a aucun EJB remote!

Côté client on utilise Spring, et donc les appels serveurs sont faits depuis notre propre HttpInvoker qui gère justement la sécurité.

C'est pas que je veux tout casser mais ça me semble un peu curieux comme architecture: côté serveur on n'a que des EJB locaux mais en grand nombre, et côté client on fait nos appels avec un HttpInvoker fait maison. Disons que ça m'interpelle, et pour l'instant je n'ai pas obtenu d'explications vraiment satisfaisante...

Après pour les perf je m'inquiétais du nombre d'EJB car je suis habitué à la lourdeur des EJB2, mais si je comprends bien ce que dit fxrobin, c'est plus performant de faire des EJB que des new.

[fxrobin]

C'est à dire que si j'ai une classe EJB de service et qu'une erreur s'y produit, eh bien... quoi donc? S'il y a eu un appel de DAO qui s'est bien déroulé avant l'erreur, la base retournerait à son état initial?

Oui, car le commit ne se fait que si aucune exception ne survient.

[Romz82]

Ok, merci à tous les deux pour vos réponses

[geforce]

Mais 120 EJB3 me semblent très exagéré.

Je sais aussi que chaque EJB ouvre son propre pool de connexion mais s’ils sont déployés sur des serveurs différents le problème ne se pose plus

Et une des itérés de EJB c'est que sa peux être déploya de façon distribué.

J'ai déjà utilisé 5 EJB pour un développement d'un ERP pour société national qui c'est y avait une bonne infrastructure et mais aussi tous les interfaces été en local et coter performance y a pas de différence notable (en a fait le test de performance avec 1 et 5 EJB dans 1 seul serveur)

[fxrobin]

Je sais aussi que chaque EJB ouvre son propre pool de connexion

Non ce n'est pas vrai. Je pense que tu dois confondre avec les Pool d'EJB ce qui n'est pas la même chose que le pool de connexions JDBC.

Perso je préfère avoir 120 EJBs dont le cycle de vie est géré (pré-instancié, passivé, etc.) par le serveur d'applications plutôt que mes propres instanciations de simple POJO non transactionnels qui vont tôt ou tard me poser des problèmes lors de fortes montée en charge.

[geforce]

Non ce n'est pas vrai. Je pense que tu dois confondre avec les Pool d'EJB ce qui n'est pas la même chose que le pool de connexions JDBC.

oui je m'excuse c'est tout a fait exacte ta bien fait de me corrigé.

Perso je préfère avoir 120 EJBs dont le cycle de vie est géré (pré-instancié, passivé, etc.) par le serveur d'applications plutôt que mes propres instanciations de simple POJO non transactionnels qui vont tôt ou tard me poser des problèmes lors de fortes montée en charge.

C’est plus que sûr : mais fait comprendre sa a chef de projet qui peur que il y des incohérences de données (données cœur du métier) parce que tu ne peux faire de relationnel direct entre deux entité qui sont des EJB différant (c'est ce qui passé dans notre cas)

ce qui fait que initialement en avait 5 EJB et que nous avons rassemblé en 1 seul

[fxrobin]

oui je m'excuse c'est tout a fait exacte ta bien fait de me corrigé.

pas besoin de s'excuser, on ne peut pas savoir tout sur tout, surtout en JAVA ...