Discussion :

[rudaill]

Bonjour à tous,

Je participe à la réalisation d'un outil de gestion d'emplois du temps. Nous utilisons un serveur Postgre + Hibernate et la techno RMI pour communiquer avec les clients.
Nous communiquons aux clients les références RMI de nos objets métiers (côté serveur).
Seulement Hibernate gère lui même les réf des objets contenus dans les tables intermédiaires de la BDD et y place les réf locales (non pas RMI).
Est-il possible de récupérer ces listes de façon à ce qu'elles contiennent les réf RMI par Hibernate ?

Merci pour votre aide.
A+
Rudy

[ego]

je ne suis pas sûr d'avoir tout compris mais si tu veux pouvoir passer les objets qu'Hibernate récupère depuis la BD via RMI sur tes postes clients, il suffit que les objets créés par Hibernate (tes objets persistants) implementent l'interface Serializable. Ensuite, tu pourras dire qu'un service RMI retourne un ArrayList par exemple et tu pourras alimenter, côté serveur, cetle liste avec les objets récupérés par Hibernate.
Attention cependant au lazy-loading. Il faut donc, côté serveur, charger toute la grappe d'objets que le client attend avant de la retourner au client.

[rudaill]

Merci pour ton intervention rapide, en fait nos objets métiers implantent Remote, ainsi les clients récupèrent la référence de l'objet sur le serveur et pas une copie.

Le problème est que ces objets contiennent des listes de références vers d'autres objets (ex : une salle contient une liste de filières auxquelles elle est rattachée).
En stockant dans la liste des filières d'un cours les réf RMI, hibernate va t il pointer vers les objets réels ?

[ego]

Hibernate est où ? je ne comprend rien. Sur le serveur ou le client ?
Attention, faire des objets persistants des objets "Remote" n'est pas une bonne idée.
Hibernate se moque de savoir que tes objets soient Remote.
Peux-tu décrire précisément la structure de tes objets ? (un peu de code...)

[rudaill]

Serveur : hibernate + postgre
Client : graphique

Communication:RMI
Pourquoi les objets Remote et Hibernate ne font pas bon ménage ?

Code : Entity extends Remote voici l'interface d'une salle de cours il manque ici les getId et setId pour hibernate

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
/**
 * L'interface <code>ClassRoom</code> représente une salle de classe gérée dans
 * GOnTime.
 */
public interface ClassRoom extends Entity
{
	public static final int TYPE_UNDEFINED = 0;
	public static final int TYPE_LESSON = 1;
	public static final int TYPE_PRACTICAL = 2;
 
	/**
         * Définit la référence RMI de l'objet courant
         * @throws RemoteException
         */
	public void setStub() throws RemoteException;
 
	/**
         * Retourne la référence RMI de l'objet courant
         * @return
         * @throws RemoteException
         */
	public ClassRoom getStub()throws RemoteException;
 
	/**
         * Définit la filière de la salle de cours.
         * @param course Filière de la salle de cours
         */
	public void setCourseList(List courseList) throws RemoteException;
 
	/**
         * Retourne la filière de la salle de cours.
         * @return Filière de la salle de cours
         */
	public List getCourseList() throws RemoteException;
 
	/**
         * Définit le nom de la salle de cours.
         * @param name Nom de la salle de cours
         */
	public void setName(String name) throws RemoteException;
 
	/**
         * Retourne le nom de la salle de cours.
         * @return Nom de la salle de cours
         */
	public String getName() throws RemoteException;
 
	/**
         * Définit le type de la salle de cours.
         * @param type Type de la salle de cours
         */
	public void setType(int type) throws RemoteException;
 
	/**
         * Retourne le type de la salle de cours.
         * @return Type de la salle de cours
         */
	public int getType() throws RemoteException;
 
	/**
         * Définit le nombre de places de la salle de cours.
         * @param nbPlaces Nombre de places de la salle de cours
         */
	public void setNbPlaces(int nbPlaces) throws RemoteException;
 
	/**
         * Retourne le nombre de places de la salle de cours.
         * @return Nombre de places de la salle de cours
         */
	public int getNbPlaces() throws RemoteException;
}

[ego]

Vous avez reproduit les "EJB Entity" en RMI et en plus simple.
Cette solution n'est pas très recommandée.
Il est préférable d'avoir des objets persistant (ClassRoom par exemple) sous la forme de simple objet Java (on parle d'objets POJO) avec des setters et getters + getXXX (XXX provenant des liens existant entre objets)
Pour les aspects services distants, il vaut mieux gérer cela dans un autre objet qui lui sera de type Remote. Pour chaque objet Entity, tu crées un objet <Entity>Home qui va te permettre de récupérer les <Entity> et autre objets associés.
Les objets Entity sont "serializable" et sont les objets manipulé par Hibernate.

Tu reproduis ici le couple EJB Session + objets persistants de type POJO manipulés par le framework de persistance.

Faire ce que tu as fait est presque de l'ordre de l'anti-pattern pour certains.

[rudaill]

En fait nous sommes d'accord sur presque tout à part le fait que les <Entity> implantent Remote dans notre archi.

(*) Dans le cas où ces <Entity> sont sérialisées et qu'elles sont fortement liées entre elles (liste d'<Entity> dans <Entity>) nous ne risquons pas de récupérer toute la BDD du côté Client ?

Et où seraient stockées les listes d'<Entity> associées :

dans EntityHome, elles ne seraient pas stockées par hibernate..
dans les Entity, elles seraient sérialisées avec l'objet...d'où (*)

Merci pour tes conseils

[ego]

Tes objets persistants contiennent entre autres des attributs de type "Collection" d'autres objets persistants. Ces collections sont représentées dans la base par des clés étrangères.
Hibernate sait gérer ces liens entre objets, cf. les éléments du fichier de mapping de type <one-to-one> ou <many-to-one> par exemple.
Si tu ne fais rien d'autre que déclarer ces éléments dans le fichier de mapping, Hibernate va alimenter les Collections de manière automatique quand tu vas charger un objet.
C'est là qu'effectivement tu risques de charger la base en mémoire.
Il y a donc le principe du Lazy-loading (attribut lazy='true' dans la déclaration des collections dans le fichier de mapping). Dans ce cas, Hibernate ne chargera les objets liés que lorsque ton code demandera la collection (il chargera la collection lors du premier appel uniquement). Tout ceci est transparent pour toi, tu n'as pas à utiliser des "collections hibernate".

Donc, quand un service doit renvoyer des données au client, tu dois identifier la GRAPPE d'objet dont il aura besoin. L'identification de cette grappe permettra au service côté serveur de déclencher tous les lazy-loading nécessaires de tel sorte à n'avoir que les objets nécessaires et suffisants. Cette grappe est alors passée au client en passant le ou les objets de "tête" (le reste va être "aspiré" car le serveur aura déjà chargé les collections). Il faut bien identifier la grappe nécessaire pour que les clients ne fasse pas d'accès à une collection non chargée car alors, c'est le code client qui va déclencher le chargement de la collection et bien sûr tout va planter car le client n'a pas les librairies hibernate, le fichier de conf ou encore accès à la base.
Dans des cas particuliers, tu peux être amené à créer une grappe d'objets qui ne correspond pas complètement à une grappe construite sur la base de ton modèle objet initial (celui qui t'a permis de créé la base). Pour ce point, Hibernate te permet d'écrire des requête HQL du type "select new MyViewObject(nom,prenom) from Client c..." (cf. la doc)
Enfin, tous tes objets persistants doivent être Serializable.