Ejb et performances

**vincent63** · 30/06/2006, 10h37

Bonjour,
J'entends régulièrement parler de la lourdeur des ejb et des conséquences sur les performances.

J'aurai voulu avoir l'avis de personnes ayant déjà eu des "expériences" ejb.

Est-ce vraiment lourd à utiliser?
Si oui, pour quelles raisons? (protocol de communication, gestion des instances ejb, ou autres...)

Existe-t-il des tests/comparatifs (graphes, courbes et tout le toutime...) permettant de voir les temps de traitement de méthodes simples en fonction du type d'Interface utilisé pour le session (remote versus Local) et du nombre de données (ie. instance d'ejb entity).

Merci pour les réponses.

**alexismp** · 05/07/2006, 15h31

EJB 2.x: complexité du développement (beaucoup de fichiers et de concepts), mais gérable avec des outils. Manque de flexibilité de la partie persistance.

EJB 3.0: plus de problème ;-)

**vincent63** · 08/07/2006, 10h05

Merci pour ce début de réponse.

Et pour les performances, les ejb sont-ils vraiment à éviter?

Dans quels cas représentent-ils une valeur ajoutée (rapport utilité/performance)?

Ce que je veux dire, c'est que l'on peut toujours remplacer un ejb par autre chose. Je connais le principe d'architecture basé sur leur utilisation (couche métier, persistence, etc...), leur valeur ajoutée sur la gestion d'accès concurrents sur les bases avec l'utilisation des entity, leur intérêt pour les couches métiers avec les session avec ou sans état. Cette techno me semble être relativement complète (possibilité de faire des WebService basés sur des ejb, avec du SOAP/ Http, SOAP/jms, utilisation de MDB etc...).

Leur mise en place me semble relativement simple même en 2.x avec des outils comme WSAD.

Mais ils restent peu utilisés en entreprise, on leur préfère d'autres technos, et l'argument avancé reste toujours leur lourdeur et les problèmes de performances dont ils souffrent.

J'aimerai savoir si ces arguments sont réellement valables ou s'il s'agit de "légendes" qui circulent. Et s'il existe des études qui montrent les différences (sur les perf) que l'on peut trouver entre une utilisation de web services classiques, de servlets, d'ejb, etc...

**robert_trudel** · 05/11/2006, 05h03

Envoyé par vincent63

Merci pour ce début de réponse.

Et pour les performances, les ejb sont-ils vraiment à éviter?

Dans quels cas représentent-ils une valeur ajoutée (rapport utilité/performance)?

Ce que je veux dire, c'est que l'on peut toujours remplacer un ejb par autre chose. Je connais le principe d'architecture basé sur leur utilisation (couche métier, persistence, etc...), leur valeur ajoutée sur la gestion d'accès concurrents sur les bases avec l'utilisation des entity, leur intérêt pour les couches métiers avec les session avec ou sans état. Cette techno me semble être relativement complète (possibilité de faire des WebService basés sur des ejb, avec du SOAP/ Http, SOAP/jms, utilisation de MDB etc...).

Leur mise en place me semble relativement simple même en 2.x avec des outils comme WSAD.

Mais ils restent peu utilisés en entreprise, on leur préfère d'autres technos, et l'argument avancé reste toujours leur lourdeur et les problèmes de performances dont ils souffrent.

J'aimerai savoir si ces arguments sont réellement valables ou s'il s'agit de "légendes" qui circulent. Et s'il existe des études qui montrent les différences (sur les perf) que l'on peut trouver entre une utilisation de web services classiques, de servlets, d'ejb, etc...

les ejb sont fait pour les gros système, le genre de système qui nécessite d'avoir des objets réparties sur plusieurs marchine..... un système distribué..... avec des tonnes d'usager de branché..... il faut donc que les performances soit là..... et les ejb réponse à ce critère

**fr1man** · 08/11/2006, 17h24

Lourd à cause des descripteurs de déploiement, des interfaces à écrire, du temps pour les déployer, des appels JNDI, etc...

Ils ont une mauvaise réputation car si on peut faire la même chose plus simplement, les gens choisissent la solution la plus simple.