Spring ou EJB3

Bonjour

J'aimerai savoir sur quels critére nous nous basons pour choisir que technologie utilisé pour notre application est ce que Spring ou EJB3. c'est sur que vous me diriez selon les besoins du clients mais on se base sur quel critéres.

merci.

Il faut déjà savoir s'il y a des standards chez le client. Utilise t-il un serveur d'application JEE ou un "simple" moteur de servlets ?
Sinon, un critère peut être les types de clients devant appeler les services. S'ils sont hétérogènes, il est préférable de passer par des WebServices. Si tu es dans le monde Java pur, tu peux faire des EJB3.
L'intégration d'une framework de sécurité peut aussi orienter ton choix.
Maintenant EJB3 ou Spring n'est pas trop la question. Spring n'est pas une techno de distribution. Tu peux faire des EJB3 avec Spring. En fait Spring te permet justement, côté client, de t'affranchir de la techno côté serveur. Maintenant, comme dit précédemment, la question est surtout "quels clients ?"

Je comprends bien ce que tu dis ego j'ai en fait une préoccupation qui va dans le même sens que lotfi-g mais je ne suis pas encore satisfait.
Le projet sur lequel nous travaillons est robuste et nous nous sommes lancer dans la technologie Java / EE que nous sommes entrain d'étudier afin de choisir définitivement la combinaisons adéquate pour effectuer la migration technologique.
Ici il ne s'agit pas d'un client particulier, il s'agit d'une solution qui sera commercialisée peu importe le client. Voici quelques points
1) Nous avons déjà opter pour GXT comme Framework Web Tier
2) Nous nous étions déjà décidé à 80% sur EJB3.
Nous entendions parler de Spring sans en connaitre tellement les avantages et depuis quelques jours nous nous y penchons. Voici mes questions :

a) j'ai appris que on peut utiliser Spring + EJB3 et d'autres parts que Spring concurrence EJB3, qu'est ce qui me permet de décider si je ne dois qu'utiliser Spring ou le combiner aux EJB3 ? Qu'est ce que Spring na pas que les EJB3 viennent combler.
b) Est que avec Spring simplement sans EJB j'ai encore besoin d'un serveur d'application (Jboss, JonAS...) ou alors il joue déjà ce rôle ? Si non dans ce cas le déploiement de l'application à n-tier se déploie comment ?
c) Y-a-t-il une documentation qui détail tous ces éléments ?
d) Le déploiement devra pouvoir se faire même en client serveur pour les petites entreprises (La Base Données et la Logique Métier sera sur la même machine) et en J2EE pour les grandes entreprises.

La question qui doit se poser n'est pas de savoir Spring ou EJB3, mais plutôt un conteneur web ou un serveur JavaEE ou comme l'a posé ego quels types clients?Si la réponse est un serveur JavaEE ou un client distribué, alors le choix est automatique, c'est les EJB3 qui emportent car Spring n'est pas distribué, maintenant si la réponse est un conteneur web, une autre question se pose Spring ou EJBLite? Car avec la nouvelle version des EJB, ces derniers proposent une version légère d'un conteneur utilisable dans une application JavaSE ou un moteur de servlet, ce qui permet la réalisation des tests unitaires...Et la réponse de savoir Spring ou EJBLite revient à poser d'autres questions et je reviens à ce qu'a dit ego quelle framework de sécurité?et aussi quelle framework de présentation? Toutes ces questions doivent se poser avant de faire le bon choix même si Spring dispose d'une légère avantage pour cette question la.
Maintenant avec ce que vous avez à faire, la réponse serait alors de combiner Spring et les EJB3, comme ça vous aurez facillement une application distribuée pour les serveurs JavaEE et Spring pour les conteneurs web, sinon une application 100% EJB3 avec EJBLite pour pour les conteneurs web. Mais une bonne reflexion doit se faire avant de prendre la décision.

Là, j'ai un problème sérieux ray_fab , je suis en train d'apprendre et d'étudier afin de faire un choix définitif, et lorsque tu dis que

Citation:

---

Si la réponse est un serveur JavaEE ou un client distribué, alors le choix est automatique, c'est les EJB3 qui emportent car Spring n'est pas distribué,

---

ton affirmation m'embrouille d'avantage quand aux informations que je reçoit des autres Forums où on affirme sans aucune ombre de doute que Spring fait parfaitement du distribué

http://www.javaworld.com/javaworld/j...31-spring.html

Ou alors cette réponse de Enrico Pizzi en Juillet 2010 qui est un Senior Member au Forum de Spring

Citation:

---

Hi,

I'll give you my opinion here, not a general truth because there isn't one. My personal advice is to drop both ejb and struts, and just use Spring, with Hibernate or JPA annotations. Basically, ejb 3 (do not even consider prior ejb standards) are made of 3 types of ejb:

- Session beans: those will be substituted by Spring core functionality. The Spring application context replaces ejb deployment environment (which must be provided by an app server) and strongly simplifies everything, since your beans are just pojos and don't need to implement interfaces, have homes and proxies defined, be programmed and deployed with certain strict rules. Spring core does also much more through its DI paradigm;

- Entity beans: Spring + Hibernate is a far better solution than using entity beans. Here, as well, you get all the benefits of ORM without all the pain of using ejbs and having to write 3 classes per bean. Hibernate's powerful hql language gives you far more control over your mappings; Hibernate integrates seamlessly with Spring, which in turn contributes with very handy transactional capabilities;

- Message beans: here as well Spring offers seamless JMS integration, plus additional benefits like Spring Web Services. This makes message beans as useless as the other two.

Thus, as you can see if you use Spring and Hibernate there is no added value in using ejb, and I am against using them, even if Spring also offers great facilities for ejb 3 integration.

For what concerns Struts, it has been the first widely distributed mvc framework and as such it deserves respect. But its oldness make him suffer when compared with fresher mvc frameworks, especially with Spring 3 web mvc which is simply amazing in that you can drive the whole mvc behaviour of your application with just a few lines of xml configuration and a bunch of annotations on normal java classes. For that reason, I suggest Spring web mvc over Struts.

This is very condensed info, if you are interested just google Spring vs ejb and you'll find dozen of articles on the subject...

---

Le problème est que, le conteneur de Spring a une infrastructure similaire à un serveur JavaEE mais ce n'est pas un serveur JavaEE en elle même donc pas distribué, c'est pour cette raison qu'on dit qu'il est léger, il faudra combiner Spring pour avoir une application distribuée. C'est pour la raison du conteneur léger, que EJB3 est obligé de sortir sa version légère (EJBLite) pour se rivaliser avec Spring, c'est cette version qui est censée être au même niveau que Spring et non tout EJB3, même si cette version est un peu loin de Spring. Pour être distribué, Spring a besoin de sa couche d'abstraction afin de s'intégrer à d'autres technologies. Mantenant il t'appartient de faire le choix des EJB3 ou Spring et sa couche d'abstraction.

Merci ray_fab. S'il te plait je suis encore en train d'apprendre, est ce à dire que pour faire une application distribué avec Spring on a besoin d'outils en dehors de Spring ou alors tout se trouve dans Spring. En passant qu'entends-tu par Spring et sa couche d'abstraction ?

Bonjour, en fait tout ce que fait Spring se trouve dans sa définition. Et la définition de Spring se base sur 3 principes:
1-L'inversion de contrôle ou injection de dépendance (Spring IOC) :C'est la définition même du conteneur de Spring.
2-Spring AOP : Le conteneur de Spring étant de
conception Orienté Objet, il ne peut aller au-delà des limites fondamentales du paradigme de la programmation orientée aspect; c'est là qu'on voit la différence avec les conteneurs EJB, qui sont eux, des serveurs JavaEE. Avant la version d'EJBLite, on pouvait pas faire des EJB hors d'un serveur JavaEE ce qui fait que lorsqu'on disposait d'un serveur web tel que Tomcat, on pouvait pas faire des EJB, c'est ce que Spring a apporté dans le monde Java. Maintenant la plus part de ce qui se fait dans un serveur JavaEE peux se faire dans un moteur de servlet et je pense même que le fait de dire "la plus part", certaines personnes se sont dit "tout", or c'est pas tout...
3-Une couche d'abstraction: Elle permet d'intégrer Spring à d'autres frameworks et bibliothèques avec une plus grande facilité. C'est à l'aide de cette couche qu'on peux utiliser la classe HibernateDaoSupport par exemple pour l'intégration à Hibernate.
Maintenant, il t'appartient de choisir quelle technologie tu dois utiliser pour la distribution. C'est même pour cette raison d'applications distribuées qu'on fait Spring avec les EJB3 des fois...
Retient seulement ceci: Les EJB sont exécutés à l'intérieur des serveurs JavaEE, et un serveur JavaEE possède en plus d'être un serveur web tout ce dont le monde Java Entreprise a besoin, alors que le conteneur de Spring est de orientée objet, donc il possède es limites. En aucun cas dans la définition de Spring, il y a eu question d'application distribuée, ce qui est la base des EJB. Mais Spring a pour but d'étendre les serveurs web et d'apporter des ouvertures à tout et n'importe quoi dans le monde Java, en se dotant d'une couche d'abstraction tellement puissante qu'il est capable d'aller n'importe où dans le monde Java, alors par abus de langage on dit de lui c'est une framework à tout faire. Mais je n'ai pas dit que le fait d'étendre les moteurs de servlets les rendaient distribués, nuances, cette extension devient distribuée que quand Spring a une technologie distribuée.
J'espère que ces définitions t'apporteront beaucoup plus d'idées.
Bon courage pour la suite.

Merci bcp ray_fab, bien sûr que j'ai bcp d'élément qui me me rapprochent du choix. Tu sais le problème ici c'est qu'il y a bcp d'outils et il faut choisir une fois pour toute avant de se lancer dans l'étude définitive, mais avant il faut avoir une connaissance général de tout.
Si tu me permets, une autre question importante.

Si tu devais concevoir une application J2EE que devrai utiliser des petites entreprises qui ne peuvent pas s'offrir un serveur d'application et la même application devra être utilisée par des grosses entreprises avec des milliers d'employés répartis dans plusieurs agences dans un pays, cette deuxième catégorie peux supporter plusieurs serveurs d'applications(EJB) sans problème . Comment t'-y prendrais-tu ?

Par contre la je peux vraiment t'aider parce que je ne sais pas ce que doit faire ton application , je ne connais les besoins de tes clients, je vais pas m'hasarder à te mettre sur une fausse piste ou mauvaise direction. Le mieux pour toi c'est de consulter les membres de ton équipe.
Bon courage!

Merci beaucoup

Bon, mon point de vue puisqu'il s'agit d'un "progiciel".
Le plus facile à mettre en oeuvre chez un client, si ce client risque d'imposer un type de serveur d'application (attention car même si tu vends un progiciel, les entreprises ont des standards et notamment en production ils savent ou pas faire de la supervision de tel ou tel serveur d'appli; donc tu n'as peut être pas le choix), c'est de ne pas tourner dans un conteneur EJB.
Pour cela, il faut donc que ta communication "client -> serveur" passe par des WebServices. Ainsi tu pourras tourner sur un moteur de servlet (tomcat par exemple).
Ensuite, côté WebService tu as le choix en fonction de la partie cliente, et encore avec Spring rien n'est arrêté définitivement si ta conception est bien faite. Je m'explique, si tes services serveur sont implémentés sous la forme de POJO, tu peux, avec Spring, "exposer" ces POJO suivant différents "protocoles" car Spring propose des "dynamic proxies" que tu n'as qu'à configurer dans le fichier de config (ou avec annotations).
J'ai déjà fait des applis ou le même service était exposé en WebService via Hessian et en EJB. Pour le premier protocole pour les WebService, là ça dépend de la techno de la partie cliente. Si tu es dans le monde full java, tu peux passer par le protocol "Spring" qui est de la serialization Java sur HTTP, c'est efficace et tu n'as pas à te faire chi..r avec XML. Sinon, tu peux passer à SOAP et là je te recommande l'usage de CXF qui encapsule tout ça.
Pour l'aspect sécurity, utilises Spring Security (ex ACEGI) c'est extrêmement complet.

Merci beaucoup ego . Il est vrai que qu'il y a des termes que je ne maitrise pas encore surtout sur pring que je suis encore en train d'étudier. Si je comprend bien, pour résumer, je peux faire avec Spring et mettre de coté les EJB, vue que le type de client va varier avec le même progiciel. C'est pourquoi ma question se pose au niveau du Load balancing/Clusting et le déploiement de l'application dans un environnement distribué. Avec Tomcat et Spring simplement, il n'y aura pas de problème ??

Pour le load-balancing, ça dépend où tu le fais. Ca peut être fait avec du hardware, au niveau d'Apache en frontal avec un Tomcat, avec un serveur JEE (même si tu n'utilises pas des EJB).
Regardes sur le Web les solutions de clustering avec Tomcat par exemple (http://tomcat.apache.org/tomcat-6.0-...ter-howto.html)

Merci beaucoup ego, je comprend et je suis fixé sur ce que je cherchais. Merci encore.