Discussion :

[lunatix]

Il ne faut pas tout mélanger: spring est un container léger qui ne se veux pas être J2EE

faut rester zen quand meme !!! on est la pour discuter non ?

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'enerver

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:

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

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)

[ego]

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 !

[onlytoine]

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

Voilà, c'est exactement ce cas là. Mes clients sont des applications SWING distantes.

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 !

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.

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

[trungsi]

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.

[ego]

Ben des EJBs comme façades ça fonctionne ! Tes EJBs déléguent l'exécution des méthodes à ton objet "entity".

[onlytoine]

Peux-tu m'en dire plus à ce sujet ? Cela consiste à avoir quelle sorte d'architechture ?

Toine

[lunatix]

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.

[ego]

cf. http://knotty.developpez.com/j2ee/

[lunatix]

cf. http://knotty.developpez.com/j2ee/

c'est illisible sous firefox
(bon j'l'ai deja lu quand tu l'as publié... mais ca reste illisible sous firefox )

[onlytoine]

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

[ego]

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.

[bmoussaud]

Facade
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

[onlytoine]

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, tu dois passer par des "Value Object" pour renvoyer les objets de la facade aux clients, c'est bien ça ?

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, je préfèrerai autant utilisé les EJB Session Stateless afin de ne pas avoir à réinventer la roue.

Merci pour vos éléments de réponses très intéressants !

Toine

[ego]

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

[onlytoine]

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

[ego]

oui

[onlytoine]

Très bien... Merci à tous pour votre aide ! J'y vois plus clair à présent.

Toine