Bonjour,

Nous nous posons pas mal de questions à propos de l'utilisation d'Hibernate dans un contexte SOA.

En effet, nos DomainObjects sont exposés via des services métiers (SPRING) sous la forme d'interfaces. Leurs implémentation sont directement les objets Hibernate.

Nous souhaiterions avoir les avantages suivants:

- Navigation en lecture en/hors transaction avec lazy.
- Updates obligatoirement contrôlés par les services métier avant apel au DAO (plusieurs niveaux de services, transactionnel au niveau service)
- Possibilité d'avoir des règles métier dans les services sur les changements de valeurs effectués

PROBLEME:

Le principal problème est qu'en transaction une modification sur un objet rattaché à une session hibernate est suceptible de partir en base sans avoir fait appel à la couche DAO ni SERVICE (de premier niveau) qui l'aurait contrôlé.
Le principe est donc de "blinder" les services pour que les applications ou autres services bâtis au dessus ne puissent pas outrepasser les règles métier qu'ils implémentent.

SOLUTION 1) (implémentée)

Une méthode consiste à cloner par sérialisation tous les objets en sortie de DAO (par AOP) si la transaction est en écriture

inconvénient: le LAZY ne fonctionne plus et l'on clone beaucoup trop d'objets (30% perf en moins observé)

SOLUTION 2)

Une solution consiste à ce que les interfaces publiques des DomainObjects exposées par les services ne présentent que les méthodes de lecture (pas de set/add...)
les modifications se font via des appels aux services de base qui connaissent les implémentations et peuvent avoir accès aux méthodes d'écriture, via des objets de transfert (State Holder) ou des objets clonés.

inconvénient: lourdeur / appel fréquent aux services, double interfaces des DomainObjects (RO + RW ou interf d'objet de transfert)

QUESTION:

Hibernate offre-t-il un moyen de garantir que tout objet de la session modifié soit bien passé par une couche logicielle particulière avant de partir en base.

dirty flag spécial contrôlé par la couche DAO ?
flush granulaire à l'entité ?
véto possible sur flush d'entité ?
événement au moment de la modification ?
clonage à la volée au moment de la modification ?
...

Merci d'avance pour tout éclairage.

- Navigation en lecture en/hors transaction avec lazy.
hors => ne fait pas ça, cela brise l'ACIDité de tes données.

- Updates obligatoirement contrôlés par les services métier avant apel au DAO (plusieurs niveaux de services, transactionnel au niveau service)
event model d'hibernate ou Interceptor

- Possibilité d'avoir des règles métier dans les services sur les changements de valeurs effectués
event model d'hibernate ou Interceptor

PS tu veux faire quelquechoe de fondamentalement bizarre, tu veux utiliser un service et après la fin de l'appel pouvoir continuer à avoir un lien avec ce service. Ce n'est plus vraiment un service au sens traditionnel parce que non borné.

Bonjour Olivier,

Je vois que tu n'as pas changé :-)
J'ai fait une super AntTask qui te genere toutes les daos (interface, implementation) ainsi que les cas tests transactionnels et les fichiers de configuration spring (appContext-hibernate, appContext-dao) et ca m'a rappelé de bons souvenirs Cegedim
J'ai utilisé velocity pour faire ce tool ce qui laisse beaucoup de liberté sur les fichiers de sortie (template vm).
J'ai bien poussé sur la tache Ant aussi
Cela évite un travail répétitif ou l'on perd bcp d'énergie
Si ca t'interesse je te l'enverrai. C'est une espèce de super HibernateSynchroniser sauf que ca fonctionne pour Hibernate 2 et 3.
De plus je pense que tu peux le plugger dans un goal maven.

Bonjour à tout le monde et bon courage à vous
jean-remi (jrpinna@noos.fr)

Je travaille avec orouits. Dans une architecture SOA, on cherche a s'assurer que les services que l'on fournit et les objets métiers que l'on met à disposition sont tels que l'on ne peut pas outre-passer la validation (cohérence des données). Style : si le statut est passé à XYZ alors la date Machin doit être non nulle. Ou alors plus complexe, un objet Parametrage est valable entre deux date, et un seul objet peut être valable à une date donné pour un individu donné, je voudrais faire en sorte que si on crée un nouveau Paramétrage, alors je modifie la date de fin de l'objet Paramétrage qui était valide pour cet utilisateur jusqu'alors. Etc.

Mon équipe réalise l'objet Parametrage, un service métier qui va bien avec ParamétrageService.createParametrage(). Mais rien n'empeche qu'une autre équipe de développement, sur le même projet, écrive son propre service manipule mon objet métier, et crée des Paramétrage sans se soucier de mes règles métiers.

La notion d'Interceptor me parait interessante.


Bon, peut-être qu'on abuse en cherchant à blinder notre code contre nos propres équipes, mais le nombre d'intervenant (surtout prestas) est tel qu'il est vite fait de se retrouver avec des bouts de code cassant les règles métiers.

Bonjour Emmanuel,

Tout d'abord merci pour ta réponse.
Je suis tout à fait d'accord avec toi sur le thème de la navigation hors transaction, ce n'est pas ma priorité, bien que sorti de la transaction (couche applicative), attention au lazy dans les DomainObjects.

Le problème comme le dit "hayron" (salut!) est surtout la garantie que les modifications soient "persistées" que si mes services de base les ont vérifiées.

Dans le cas ou l'on a 2 niveaux de services
- SH (haut niveau, process métier, batch transactionnel...)
- SB (bas niveau, vérification cohérence métier, en contact avec le DAO)
avec transaction gérée au niveau SH.

Au sein d'une transaction, les objets modifiés par SH peuvent être flushés en base sans avoir été vérifiés par le service de bas niveau ni passés par le DAO.

Appeler le service de bas niveau via un intercepteur Hibernate au moment du flush casse l'algorithmique métier implémentée par les 2 couches de services car le flush est contrôlé par Hibernate et non piloté par l'algorithmique explicite.

Je n'ai peut être pas saisi la portée des intercepteurs (nous les utilisons déjà pour résoudre génériquement d'autres exigences techniques comme l'historique des changements en base avec "marquage" transactionnel),

Je suis toujours preneur pour des éclaircissements.

Bien cordialement.

Olivier.

Je ne comprends pas ton inquiétude. Tu as un comportement transverse de persistence d'une entity et tu as la possibilité de plugger des vérifications lors de ces appels transverses. Cela ne casse aucun algorithme métier.
C'est le même type d'architecture que l'on a utilisé pour Hibernate Validator: une déclaration des contraintes et une implémentation qui se fait exécuter lors des evenements pre-insert et pre-update.
Si tu ne veux pas qu'Hibernate persiste les changements d'objets faits dans tes couches haut niveaux, travaille sur des objets détachés et oblige tes couches hautes à les réattacher via des appels aux couches basses. Evidemment tu perds beaucoup des optimisations inhérentes au cache de premier niveau d'hibernate.

PS: ton service de haut niveau pourras toujours créer une connection JDBC et passer derriere ton dos pour changer des valeurs en bases. Si, fondamentalement, tu ne crois pas en ton équipe de dev, fait tout toi même.

Bonjour Emmanuel,

Pas d'inquiétude, ce n'est pas une question de confiance :-)
Je souhaite introduire un minimum de sécurité et un contrat de service clair, pour que ceux qui utiliseront mon service en transaction ne puissent faire involontairement des bugs alors qu'ils ont bien d'autres choses à régler. (tiré de l'expérience).

Je comprends ta proposition au sujet de la vérification par événement qui peut convenir à des contraintes relativement simples.

- nous avons des opérations métier lourdes qui ne se résument pas à modifier des champs et vérifier grosso modo unitairement que ces champs soient bons pour un objet donné. Elles peuvent aussi impliquer un certain nombre d'actions supplémentaires ou vérifier une cohérence de modification inter-objets avec des règles dépendantes du contexte.
- déduire les actions métiers réelles à partir des modifications sur les entités n'est pas envisageable. Toute opération métier correspondant à la psécif est duement loguée en base, rejouable, prouvable, distribuable, etc...
- le séquencement des actions métier et le contrôle qui en résulte est parfois primordial (nous avons le cas), il ne peut en aucun cas être piloté par un mécanisme comme le FLUSH dont le but est purement technique.
- je ne souhaite pas rendre mon code métier "adhérant" à une couche de persistance quelconque. Si un mode de persistance particulier pilote l'appel aux services métiers de base, que faire avec les DAO non Hibernate (accès système de fichier par ex...) présents aussi dans certains modules ? Quel coût de migration dans le cas d'un changement de mode de persistance ? Les DAO sont là pour assurer ceci, pas les services métiers.

L'architecture (séduisante) qui consiste à avoir des DO qui se comportent comme des entités en transaction et comme des POJOs hors des services (hors transaction) pose un certain nombre de problématiques à résoudre. D'autant plus si la granularité de la transaction (session) n'est pas connue à l'avance (réutilisation de services métiers embarqués).

Je m'arrête là pour les "bizarreries" ;-) et te remercie pour le temps que tu as pris.

Olivier.