Discussion :

[lotfi-g]

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.

[ego]

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 ?"

[mesken]

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.

[ray_fab]

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.

[mesken]

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

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

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...

[ray_fab]

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.