Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
(Spring && EJB3) Vs. (Spring || EJB3)
Bonjour,
malgré mes recherches, je n'arrive toujours pas à savoir avec certitude si on peut ou non coupler Spring avec les EJB3 ?
Spring à ce que j'ai compris "simule" un conteneur JEE en fait c'est bien cela ?
Dans un premier temps (), j'aimerais juste savoir la chose suivante : y'a t-il un intérêt ou non à avoir une application tournant avec Spring et les EJB3 ?
Je dirais que non mais sans en être vraiment sur
Merci pour les éclaircissements
oui
car spring n'est pas un remplaçant (ou pas que) des EJB
Personnellement, je ne vois pas l'intérêt de coupler Spring aux EJB3...
Et entre les 2, je n'hésite pas longtemps, c'est EJB3...
Tu peux coupler les deux technologies.
Après coupler les deux peut avoir de l'intérêt si tu utilise Spring pour des fonctionnalités qui ne sont pas disponibles avec les EJB3.
Par exemple on peut utiliser de l'EJB3 et choisir de le coupler avec Spring pour utiliser de l'AOP.
Merci à tous pour vos éclaircissements
En fait pourrait t-on résumer en disant ceci finalement ?
Spring existait avant les EJB3 et les EJB3 s'en sont grandement inspirés sans pour autant reprendre toutes les fonctionnalités de Spring ?
Autre chose encore, Spring étant un conteneur dit "léger", quel peut être l'avantage d'utiliser les EJB ("lourds") dans un contexte je dirais basique mis à part que les EJB sont la "norme" ?
Merci encore
PS: et au niveau de la sécurité (authentifications et autorisations) qui prend le dessus sur l'autre ?
Euhhhhhhhh Spring existait avant les EJB3. Certes avant la version 3 des EJB mais la technologie EJB est plus ancienne que Spring il me semble.
Le but des deux technologies n'est pas de même à l'origine, les EJB sont une solution d'entreprise proposant de mettre en place des composants distribué nécessitant d'être déployé au sein d'un serveur d'application.
Spring lui est une solution déployable dans des conteneurs léger (comme Tomcat qui est juste un conteneur de servlet et ne possédant pas de gestion de transaction par exemple) qui permet de réaliser de l'injection de dépendances.
Spring est un framework a "tout" faire, les EJB ne concerne que la mise en place de services, de messages et de gestion d'entités.
le problème n'est pas conteneur "léger" vs conteneur "lourd". Ca c'est un peu le marketing des conteneurs légers.
Ton problème est avant tout un problème d'architecture.
Si tu restes dans le monde Java depuis le client jusqu'au serveur et que tu as besoin de distribution alors tu peux faire le choix des EJB. Si tu es dans un monde hétérogène, tu devras exposer tes services côté serveur avec une techno appelable depuis d'autres langages. Et là, tu devras passer par des WebServices au dessus de SOAP ou tout au moins en sérialisant en XML les données IN et OUT.
Tu as aussi le problème de l'administration des serveurs en production et là, il faut compter avec le savoir de l'équipe d'administration. S'ils sont câblé WebSphere, tu auras sûrement du mal à impose Tomcat par exemple.
Si tu utilises Spring tu pourras facilement exposer un même service avec plusieurs "protocoles", par exemple une exposition en EJB et une autre en WebServices (utilisation de CXF par exemple).
hum...en fait j'ai pas fais d'études d'informatique et je code pour le plaisir d'où probablement mes lacunes concernant les architectures de mes applications.
Pour faire simple, j'ai commencé avec PHP puis Flex (Flash) et j'ai fini par assembler les 2 ensembles via une passerelle utilisant le protocole de [dé]sérialisation AMF (Zend_Amf pour ne pas la nommer).
J'ai ensuite remplacé PHP par Java et accédé à des services (POJOs) sur un serveur Tomcat basique.
Maintenant j'essaie de concevoir un backend Java sur serveur Glassfish afin de profiter des possibilités de messaging notamment avec la WebApp GraniteDS (passerelle JEE -> Flex), mais JEE6 est plus compliqué que PHP
Avec tous ces nouveaux termes pour moi (jndi, messaging voir même construction/déploiement de projet avec Maven) je suis un peu perdu, je bricole pas mal et avance lentement avec notamment des questions existentielles telles que : peut on se passer d'un serveur d'applications en couplant un conteneur de servlets avec Spring ? Ou bien sur JPA par exemple : JPA est la nouvelle norme de persistance JEE comme l'était avant Hibernate (?) mais maintenant Hibernate est aussi une implémentation de JPA à par entière ? Et puis plein d'autres questions encore
Ce que je pense de spring à première vue (car je l'ai jamais utilisé) c'est qu'il est "has been" et voué à disparaître (dans le cadre d'une utilisation sur un serveur d'applis), je pense qu'on l'utilise le plus souvent pour des MAJ de projets existants ou bien parce qu'on l'a appris et qu'on le maîtrise bien. Mais comme ici on est sur le forum Spring on risque de pas être d'accord avec moi je pense
Imaginons que je marche dans le désert depuis 1 semaine et que j'arrive à un croisement. A gauche est affiché "Spring" et à droite est affiché "EJB3", je dois prendre quelle voie d'après vous à gauche ou à droite ?
Merci
A droite ou à gauche ? ça n'a pas de sens sans informations complémentaires, tu restes dans le hasard...
Si tu as plus de gens qui partent à droite, mieux vaudrait aller avec eux... mais ça ne garanti rien sur l'avenir
Rassure toi, ce n'est simple pour personne au début.
Spring est un bon framework à la base, EJB est bien plus vieux et plus orienté composants distribués (comme le disait Shinzul) là où Spring devient un gros bazar à tout faire.
En ce qui me concerne, j'ai eu l'occasion de faire du Spring pour un projet et je fais exclusivement de l'EJB en ce moment. Hormis l'injection de dépendances (qui existe aussi avec EJB3), je ne trouve rien qui m'attire ou qui ne soit pas disponible (et dont j'ai besoin) avec les EJB.
EJB étant dans la "norme" JEE, je te conseille donc EJB (mais le choix du forum risque de faire réagir les pro-Spring)
J'oubliais, pour ce qui est de JPA vs Hibernate, il n'y a pas vraiment de "vs" puisque Hibernate est une implémentation de JPA.
On peut donc se référer à la norme JPA ou attaquer directement avec de l'Hibernate "natif" qui aura quelques fonctionnalités intéressantes en plus.
L'avantage du premier réside dans le fait que ton application passera d'une implémentation à une autre théoriquement sans problème (Glassfish utilise TopLink là où JBoss utilise Hibernate)
un truc bien avec Spring et l'injection des dépendance + programmation par interfaces c'est que l'on peut tester en dehors du serveur d'application.
Il y a en plus plus de possibilités de config / utilisation d'autres frameworks avec Spring : Hibernate, CXF, Ageci,...
Personnellement j'ai une préférence pour Spring tout simplement parce que c'est justement un framework "a tout faire". Il se combine très bien avec d'autres technologies et ses fonctionnalités sont appréciables.
Après je n'irai pas cracher sur de l'EJB et conseillerai même de passer par la pour une approche car justement il est moins fourre tout que Spring.
ok, merci pour tous ces feedbacks et ces conseils
je vais donc essayer de tester les 2 et de me faire une idée par moi même en espérant finir avant les EJB4
Merci encore
Répondre avec citation
Partager