Discussion :

[minimarch76]

Bonjour à tous,

je travaille sur un projet de Web Services utilisant Spring 2 et Hibernate 3. Le projet est décomposé en couches de la façon suivante :

1. Web Service
2. Métier
3. DAO
4. BDD

Le projet tape sur deux bases de données différentes qui ne sont pas intimement liées : l'une des deux ne sert qu'à récupérer une liste d'informations que l'on retourne directement sans faire de lien avec l'autre base.

Mon problème est le suivant : j'ai configuré à l'aide de Spring une session et un transaction manager Hibernate pour taper sur les bonnes bases. Comme conseillé dans le livre "Spring par la pratique" (entre autres), les transactions manager doivent être des proxy englobant des beans de la couche Métier. Ce qui est d'autant plus logique, puisque c'est au niveau du métier que l'on sait si l'on doit taper sur la base 1 ou la base 2 (on est alors en mesure de configurer tel bean avec la transaction 1, et tel autre avec la transaction 2).

Cependant, dans mon projet actuel, j'ai configuré mes entités avec le mode lazy-loading (on ne charge les données que si l'on y fait appel). Or, j'ai parfois besoin de faire appel à ces données dans la couche Web Service, à un moment donné où la session et la transaction sont fermées.

Il faudrait donc que je puisse ouvrir une session directement au niveau de la couche Web Service (et non plus seulement métier), mais je ne sais alors pas encore quelle base va être sollicitée...

Comment résoudre ce problème ?

Si nécessaire, en fonction de la méthode Web Service qui est appelée, je dois pouvoir être en mesure de déterminer quelle base sera appelée. Mais y a-t-il moyen d'ouvrir une session et une transaction particulière, non pas en fonction de la classe, mais de la méthode ? (par la configuration de Spring dans un premier temps, ou par le code dans une deuxième temps).

Je suis ouvert à toute proposition.

Merci d'avance à vous,
MiniMarch

[fr1man]

Si j'ai bien compris ce que tu souhaites, ce n'est pas à ta couche de web services d'ouvrir directement une session ou transaction.
C'est à ta couche métier spring, de te renvoyer les bonnes données avec les collections dont tu as besoin, initialisées.
L'idée serait d'écrire une méthode qui chargerait tes collections (lazy loadées) par une requête criteria ou hql.

[minimarch76]

J'ai effectivement pensé à cela : dans les fonctions métier (donc au cours de la session Hibernate), charger les données qui seront utilisées dans les fonctions Web Services (hors session). Mais on perd ici tout l'avantage du lazy-loading, puisque certaines fonctions métier chargeraient un ensemble de données qui ne seraient pas systématiquement utilisées.

On peut par exemple vouloir récupérer un ensemble de clients mais pas leurs commandes dans une certaine fonction Web Service, alors que dans l'autre on aura besoin des deux.

J'ai également pensé à créer des fonctions métier qui ont pour rôle de charger les données dont auront besoin (spécifiquement) les Web Services. Par exemple, une fonction getClients() pour les clients uniquement, et une autre getClientsWithCommandes() pour avoir accès aux commandes. Mais dans ce cas, si l'on souhaite accéder aux produits des commandes, il faut encore une autre fonction... on n'en sort pas.

Par contre, je suis d'accord avec toi, c'est normalement au niveau de la couche Métier qu'il faut ouvrir la session et la transaction, pas au niveau du Web Service.

Une autre solution serait de créer une nouvelle couche entre celle du Web Service et la couche métier. Je m'explique : admettons que l'on aie un Web Service avec deux fonctions maFonction1() et maFonction2(), la première tape sur la base 1, la deuxième sur la base.... 2 (c'est bien, vous suivez).

Pour le moment, c'est dans ces fonctions que je fais appel à la couche métier et dans lesquelles je manipule mes objets hors session (source d'erreur). Si l'on crée deux beans (un par base accédée), et que la fonction maFonction1() soit exportée dans le bean1 et maFonction2() dans le bean2. Il est possible d'ouvrir cette fois-ci la bonne session sur la bonne base au niveau des bean1 et bean2.

Il ne reste plus qu'à faire un genre de mapping au niveau du Web Service : la fonction maFonction1() fera appelle à bean1.maFonction1() et maFonction2() à bean2.maFonction2() sans autre code.

Qu'en penses-tu (si j'ai été assez clair... je voulais faire un schéma mais on ne peut pas le mettre sur le message) ? As-tu un moyen plus simple ?

Merci d'avance,
MiniMarch

[Hikage]

Donc si je capte bien tu aimerai que lorsqu'on fait un get sur une collection ( du coté client ) , celle-ci soit loadé à ce moment la ?

[minimarch76]

Pas tout à fait. Le get sur la collection se fait sur le serveur (avant renvoie de la réponse au client), mais hors de la session ouverte au niveau de la couche métier.

Il faut donc que je trouve un moyen de remonter mon ouverture de session un peu plus haut que la couche métier (mais pas jusqu'au niveau de la couche Web Service, puisqu'à ce moment, je ne sais pas encore quelle base va être utilisée), voire de redescendre mon code du Web Service vers la couche métier.

La solution que je suis en train d'envisagé (et que j'ai tenté d'expliquer, mais sans schéma j'ai du m'embrouillé) serait de créer une couche supplémentaire entre la couche de Web Services et la couche métier.

[Hikage]

Oui je vois le problème.

Je ne sais pas si cela peut t'aider mais le même problème existe lors de l'utilisation d'objet lazy loadé dans des pages JSP.

En Web JSP, la solution est le filtre OpenSessionInViewFilter.

D'après ce que je peux voir dans la javadoc :

This filter makes Hibernate Sessions available via the current thread, which will be autodetected by transaction managers. It is suitable for service layer transactions via HibernateTransactionManager or JtaTransactionManager as well as for non-transactional read-only execution

Donc, il n'est pas impensable de croire que cela peut marche au niveau de la couche WebService, vu que Axis & autre se base sur des servlets pour les WebService, et donc que le traitement se fait au sein d'un même thread.

A voir

[minimarch76]

(pour info, nous utilisons déjà OpenSessionInViewFilter, mais il se peut que j'aie loupé un paramètre de configuration, l'idée est donc à prendre)

Sauf si je ne m'abuse, le problème sera le même... OpenSessionInViewFilter permet aux transactionsManagers d'avoir accès à une session, mais laquelle ? Comment dire que la session à utiliser est celle sur la base1 (donc utiliser la sessionFactory1) ou sur la base2 (donc sur la sessionFactory2) ?

Cette configuration ne se fait-elle pas dans les fichiers de config de Spring, et donc (pour le moment dans mon projet), au niveau de la couche métier ?

[Hikage]

Effectivement, j'avais oublié ce point

J'avoue que je ne connais pas le fonctionnement interne de Spring pour la gestion des transactions, et donc je ne ais pas te dit comment cela va réagir avec le OpenSessionInView dans ce cas précis.

Je réfléchis

[minimarch76]

Je viens de discuter avec l'un de mes collègues, et nous sommes d'accord avec la solution que j'avais proposé :

le Web Service va désormais faire appel à deux beans, chacun ayant sa propre session/transaction. Ce sont ces beans qui contiendront l'appel aux fonctions métiers, et se chargeront des différentes conversions vers les objets véhiculés à travers le réseau.

Ces deux beans seront totalement indépendants l'un de l'autre, tant au niveau des métiers qu'ils manipuleront, que des sessions qu'ils auront à disposition.

En y réfléchissant, le principe est en fait de dissocier totalement les parties de l'application tapant sur des bases différentes. Les seules liaisons possibles entre ces différentes parties doivent se faire au niveau de ces fameux beans (qui pourront s'appeller mutuellement si nécessaire, à l'aide de Spring). Les sessions seront alors ouvertes et fermées au moment où il le faut.

De plus, cette solution à l'avantage de pouvoir exporter facilement une partie ou l'autre de l'application, tapant sur l'une des bases.