Version imprimable
Hello,
Je me pose la question suivante concernant les objets manipulés par le conteneur léger Spring : comment fait-on pour y accèder via une application distante ? (équivalent de l'interface Remote des EJB) 8O
Merci d'avance !
Toine
[Modéré par Didier]
Ajout de tag dans le titre
Lire les règles du forum : Règles du forum Java
Pas de réponse ?
Quelqu'un pourrait il me dire comment il utilise Spring et les avantages/inconvénients qu'il trouve à ce framework ?
Merci !
Toine
Voici ce que je pense de spring !
pour revenir a ta question initial, le container spring n'est pas distantCitation:
C'est le printemps !
Qu'est-ce qu'il raconte ! c'est pas le printemps, c'est l'hiver ! ok mais Spring, le framework, est mon nouveau printemps technologique. Ca faisait longtemps que je lorgnais sur ce fameux pattern Inversion Of Control (IOC) renommé Dependancy Injection developpé par Martin Fowler. L'occasion c'est présenté dans un projet dernierement et maintenant je suis fan ! archi fan !
Spring est plus qu'un containeur d'assemblage, il propose un mecanisme transaction calqué sur EJB mais sans EJB, un framework MVC semblable à Struct mais AMHA pas vraiment mieux, un premier support de programmation par aspect, un module d'acces au données encapsulant l'outil de persistance de votre choix (hibernate, JDO, EJB et très bientot TopLink),...
Un container dit léger mais offrant un niveau de service haut de gamme !
J'en profite, c'est le printemps, pour annoncer la sortie de la version 1.1.3 de Spring.
http://blogs.application-servers.com/roller/page/moussaud/20041215
c'est a dire qu'il ne peut exposer des objets ou services par lui même. Par contre tu peux tout a fait intéger spring dans un serveur d'application: tu n'utilise pas tout mais rien que le pattern IOC est appréciable (et aussi tout ce qui tourne autour de JDBC: tu ne code que la requete et comment remplir tes beans, le reste il gere)
Viens rejoindre le fan club de spring
Hello,
Merci pour ta réponse ! C'est rassurant de lire d'autres personnes ayant un intérêt pour ce framework :)
Pour en revenir à ma question, le fait que Spring ne soit pas distant me gêne ... En effet, je bosse sur une appli définissant un peu plus de 200 EJBs actuellement manipulés directement à travers une interface utilisateur SWING. Afin d'optimiser le développement et de réutiliser au maximum les objets déjà écrits pour une version non-réseau, je souhaitais profiter de la légèreté de Spring...
Si tu as des pistes, je suis prenneur car pour l'instant, je ne vois pas comment faire ... :(
Merci d'avance !
Toine
il me semble que dans spring, tu peux definir des objets comme etant accessible via web services, ca n'en fait pas des objets distants, mais c'est deja bien pratique
Je connais pas vraiment cet aspet de Spring encore mais je ne pense pas que ce soit adapté dans la mesure où ce sont vraiment des objets métiers que je souhaite manipuler.
Merci quand même pour cette piste !
Toine
j'ai retrouvé un vieux commentaire ...
ca doit coller quand memeCitation:
Tu peux distribuer des services pojos par simple déclaration dans le fichier xml. Dans spring par exemple, tu peux choisir entre du RMI, burlap, Hessian, Jax-RPC, Http invocker. Le choix est fait dans la déclaration. Aucune code particulier n'est nécessaire pour distribuer un service pojo, c'est la force du truc...
8O
Peux tu me donner les sources de ce commentaire ? Ou puis-je trouver plus d'info à ce sujet ? Spring est particulièrement mal documenté à ce sujet je trouve, c'est dommage !
Toine
ca vient de ce thread, http://www.application-servers.com/s...12-16-18:26:07
je connais pas bien le sujet, mais les mecs semblent savoir de quoi ils parlent
J'ai discuté un peu avec ces messieurs, mais ils ne répondent pas à mes questions ...
Je ne vois toujours pas concrètement comment accèder à mes objets gérés par Spring à distance... :cry:
Toine
hum, c'est vrai que meme en googlant, on ne trouve pas grand chose
un exemple avec axis (web service)
http://www.jroller.com/page/kbaum/20050103
des classes a lire
http://www.springframework.org/docs/...terceptor.html
http://www.springframework.org/docs/...dExporter.html
pas simple, pourtant ca doit etre faisaible... y'a meme un JMSExporter....
tu devrais fouiller la a mon avis
http://forum.springframework.org/vie...2d5bde41cdb7a7
un petit tour par ici ?
http://ego.developpez.com/spring
Oui j'ai lu ta présentation, beau travail !
Mais ça ne répond pas vraiment à ma question ...
Toine
ben non, on parle de la possibilité de mettre les objets spring a disposition (via http/soap/rmi) a distance ! y'a rien dans le tuto non ? (ou alors j'ai loupé)
bon, je crois qu'il faut lire ca... ca m'interresse, je vais potasser
http://www.springframework.org/docs/.../remoting.html
a premiere vue, ca a l'air simple et puissant (comme j'aime quoi ;-) )
Hmmm... Quelqu'un aurait un exemple simple un objet "Product" par exemple géré via Spring par un client lourd ?
Comment récupéré les "Product" existants ? Comment en créer de nouveau ? (comme on le fait avec l'interface Home des EJB)
Merci !
Toine
l'objet même des conteneurs légers est de ne pas proposer d'infrastructure lourde comme les serveurs d'applications !!!!
Il est donc NORMAL que Spring ne propose pas l'équivalent des EJBs !!
Malgré le manque de détails, tout est dit dans mon tutorial car on y dit bien, comme l'a dit bmoussaud, que Spring permet d'appeler de manière transparente des EJBs et propose des classes pour créer facilement des EJBs qui s'intègrent dans la logique de configuration de Spring (tout cela est dans le tuto !).
tu as lu ca vraiment http://www.springframework.org/docs/.../remoting.html
avant d'ecire en gras ;)
spring propose de mettre a disposition ces objets via rmi/http/ et autre protocoles. c'est pas du ejb complet, mais y'a deja beaucoup de possibilités
Si tu veux faire des EJB, tu prends WAS, WebLo, Jonas ou JBoss,Citation:
Envoyé par lunatix
Si tu veux faire du RMI, tu prends java et tu t'aides de spring pour l'exposition
si tu veux faire du http, tu prends axis + spring / axis+tomcat,....
Il ne faut pas tout mélanger: spring est un container léger qui ne se veux pas être J2EE
Houla ... Il ne faut pas s'énerver tout rouge comme ça ... :!:
J'ai relu le tuto de ego pour être sûr de ne pas passer à côté de quelque chose d'évident ... Mais celui-ci ne répond pas complètement à mes questions... :(
Pour résumer ma problématique, de manière plus concise peut être :
1. Je ne souhaite pas utiliser les EJB Entity car mes objets métier sont déjà développés en tant que POJO.
2. Je pense utiliser Spring associé à Hibernate pour gérer mes objets sur un serveur J2EE, ainsi que leur persistence.
3. Le dernier chainon me manquant est : comment pouvoir accèder à mes beans de l'extérieur ? Comment un client distant peut-il associer, supprimer, mettre à jour, etc... mes beans ?
Un début de réponse serait dans la possibilité de faire du "Remoting" avec Spring, mais je n'en connais pas encore assez à ce sujet pour maitriser la chose de bout en bout ... Et je ne vois pas encore comment faire concrètement... Donc, si quelqu'un a déjà eu une expérience, je suis intéressé !
Merci d'avance,
Toine
faut rester zen quand meme !!! on est la pour discuter non ?Citation:
Envoyé par bmoussaud
on te dit que dans spring, il y a des fonctionalités d'acces remote pour tes objets ! Ou alors on comprends rien a la doc (ce qui reste possible) auquel cas explique le au lieu de t'enerveret que cela nous interresse ! c'est tout. Acceder aux objets Spring a distance est visiblement possible (il faut que j'experimente) via rmi, http et meme bientot jms.Citation:
Spring features integration classes for remoting support using various technologies. The remoting support eases the development of remote-enabled services, implemented by your usual (Spring) POJOs. Currently, Spring supports four remoting technologies:
on dit pas que ca le transforme en conteneur lourd (entre parenthese, spring est-il toujours un conteneur leger ? je suis pas sur, Pico est resté leger a mon avis pas Spring)
donner l'accès via EJB, Burlap, Hessian, RMI ou la serialization dans un flux HTTP ne fait pas de Spring un serveur d'application.
Spring propose simplement, et c'est très bien, une intégration avec des technologies permettant la distribution.
Pour le problème initial, la question est déjà de savoir quel est ou quels sont les types de client devant accéder aux objets gérés via Spring/Hibernate ? Ces clients tournent-ils sur le même la même machine que les objets géré via Spring/Hibernate.
En clair :
- Dois-tu séparer le code client du code serveur ? si non, pas de question à se poser si oui, cf. la suite...
- si les clients sont des WebApp hébergées par la même machine que le code "serveur" (le code géré par Spring/Hibernate), pas besoin d'accès remote.
- si les clients sont des WebApp hébergées par une autre machine que le code "serveur" ou bien si les clients sont des clients Swing ou bien si les clients sont des application .Net, là il faut se poser la question de l'accès distant. Dans ce cas, tu as la possibilité d'utiliser des EJBs (si tu restes dans le monde client Java) ou des WebServices (si tes clients sont .Net et/ou Java). Pour les EJBs, Spring propose des classes facilitant l'intégration d'un EJB dans la logique d'initialisation des Beans. Pour les WebServices, je ne connais pas personnellement une intégration spécifique côté Spring avec un truc comme Axis (à voir sur le forum Spring car j'y ai vu les mots WebServices et Axis donc...)
Côté client Java, tu peux aussi utiliser Spring pour rendre transparent l'appel aux EJBs !
Voilà, c'est exactement ce cas là. Mes clients sont des applications SWING distantes.Citation:
- si les clients sont des WebApp hébergées par une autre machine que le code "serveur" ou bien si les clients sont des clients Swing ou bien si les clients sont des application .Net, là il faut se poser la question de l'accès distant.
Je ne pense pas utiliser les webservices pour mes besoins. Je rapelle que le besoin est de rendre accessible les méthodes des beans entités, comme on peut le faire avec les interfaces remote des Entity Bean.Citation:
Dans ce cas, tu as la possibilité d'utiliser des EJBs (si tu restes dans le monde client Java) ou des WebServices (si tes clients sont .Net et/ou Java). Pour les EJBs, Spring propose des classes facilitant l'intégration d'un EJB dans la logique d'initialisation des Beans. Pour les WebServices, je ne connais pas personnellement une intégration spécifique côté Spring avec un truc comme Axis (à voir sur le forum Spring car j'y ai vu les mots WebServices et Axis donc...)
Côté client Java, tu peux aussi utiliser Spring pour rendre transparent l'appel aux EJBs !
En fait, je voudrais rendre mes objets accessible dans la même idée que les EJB Entité, mais sans utiliser les EJB Entité car ils sont trop lourd à mettre en place et que ça m'obligerait de ré-écrire une bonne partie du code déjà écrit pour une version mono-poste du logiciel.
Merci d'avance pour vos prochains conseils ! :?
Toine
tu veux rendre remote tes beans entité sans vouloir utiliser des EJB ou Web services. Je vois pas d'autres solutions à part de développer toi-même la partie serveur en rmi ou socket.
Ben des EJBs comme façades ça fonctionne ! Tes EJBs déléguent l'exécution des méthodes à ton objet "entity".
Peux-tu m'en dire plus à ce sujet ? Cela consiste à avoir quelle sorte d'architechture ?
Toine
ca depends aussi de ce que tu veux dire par rendre les objets distants... si c'est de la simple consultation/manipulation distante, je dirais que le module http est pas mal !
common-http-client sur les applications swing pour finalement emuler le comportement d'un navigateur web (sauf que tu te passes de la jsp) et le Spring's HTTP invoker coté spring.
c'est illisible sous firefox :?Citation:
Envoyé par ego
(bon j'l'ai deja lu quand tu l'as publié... mais ca reste illisible sous firefox :wink: )
J'ai déjà lu cet article également il y a quelques temps ... Les principes exposés via l'utilisation d'une session façade est d'offrir des services pas directement lié à un objet entité en particulier...
Par exemple, je voudrais avoir sur mon serveur des objets POJO manipulé par Spring comme "Personne" et "Entreprise" et depuis mes clients lourds SWING effectuer une recherche de "Personne" via un ID par exemple, modifier son prénom en faisant setFirstName() sur l'objet retourner, de lui associer une "Entreprise" ....
Toine
Je te conseille le pattern Façade, le passage de grappes d'objets puis la manipulation de cette grappe sur le client puis tu renvois la grappe au serveur qui réintrègre la grappe dans un contexte transactionnel et sauvegarde la grappe.
Regardes la problématique sur les long-transactions dans la doc Hibernate.
Facade :ccool:
j'ai fait une application Swing qui accédait à des données distantes via des EJB Type Stateless , implémentant le pattern Facade, ca marche du tonnerre ! SI tu ne veux pas d'EJB Session StateLess, tu peux prendre du RMI
Dans ce cas, tu dois passer par des "Value Object" pour renvoyer les objets de la facade aux clients, c'est bien ça ?Citation:
Je te conseille le pattern Façade, le passage de grappes d'objets puis la manipulation de cette grappe sur le client puis tu renvois la grappe au serveur qui réintrègre la grappe dans un contexte transactionnel et sauvegarde la grappe.
Regardes la problématique sur les long-transactions dans la doc Hibernate.
Dans ce cas, je préfèrerai autant utilisé les EJB Session Stateless afin de ne pas avoir à réinventer la roue.Citation:
j'ai fait une application Swing qui accédait à des données distantes via des EJB Type Stateless , implémentant le pattern Facade, ca marche du tonnerre ! SI tu ne veux pas d'EJB Session StateLess, tu peux prendre du RMI
Merci pour vos éléments de réponses très intéressants !
Toine
Oui pour les EJB stateless.
Pour les ValueObjects, cela n'est pas forcément nécessaire; je m'explique.
Si tes données persistantes sont des POJOs avec partiquement aucune logique métier/applicative, il te suffira de les rendre Serializable. Pour le passage de grappes d'objets, il suffit alors de constituer la grappe sur le serveur en appelant tous les accesseurs aux collections pour qu'Hibernate fasse le load des données voulues (et/ou utiliser les options du fetch); ce point est important si tu fais du lazy loading, il ne faut pas que le client accède à une collection qui demande une requête à la base !
Si tes objets persistants ne sont pas complètement ceux que tu veux envoyer parce que, par exemple, tu veux envoyer des objets partiels (sortes de vues sur tes objets persistants), tu n'as qu'à créer des classes pour cela et utiliser les capacités de HQL. Avec HQL, tu peux en effet écrire des requêtes du genre : "select new MyPersonneView(nom,prenom) from Personne...."
Merci beaucoup pour ces précisions qui m'éclairent grandement.
Pour conclure, peut-on dire que les clients recevront systématiquement des copies des objets distants (par des Value Object, ou par Serialisation) ?
Toine
oui
Très bien... Merci à tous pour votre aide ! J'y vois plus clair à présent.
Toine