chargement dynamique de classes

Version imprimable

28/04/2011, 10h43
professeur shadoko

chargement dynamique de classes

bonjour
précision préliminaire: je suis croyant mais pas encore pratiquant en JMS :roll:

question:
- sur une machine un producteur envoie un message contenant un objet
- du coté de la machine récepteur on reçoit ce message mais on n'a pas la classe correspondante (eh oui ça arrive!)

existe-t-il un mécanisme (plus ou moins standard ... ou déjà écrit par un autre) qui permette le chargement dynamique de la classe correspondante et la reconstitution "propre" de cet objet?

On a déjà ça avec des mécanismes sur RMI (je penses à JINI) mais peut-on se passer d'écrire un ClassLoader qui fasse une demande à un serveur de classe (sur http par exemple)?

merci pour tout tuyau ou suggestion
28/04/2011, 11h32
Jimmy_

Bonjour,

Croyant et pratiquant JMS, le messaging d'objet utilise le mécanisme de serialization des objets.
Tu vas recevoir un java.io.Serializable, après tu en fais ce que tu veux. :D
Le travail de JMS est terminé.
28/04/2011, 11h45
professeur shadoko

Citation:

Envoyé par Jimmy_

Bonjour,

Croyant et pratiquant JMS, le messaging d'objet utilise le mécanisme de serialization des objets.
Tu vas recevoir un java.io.Serializable, après tu en fais ce que tu veux. :D
Le travail de JMS est terminé.

moui.... mais si tu n'as pas la classe sous la main l'objet ne sera pas dé-serialisé!

Il me semble (mais peut-être me trompes-je) que ça doit être assez courant d'avoir un producteur et un consommateur sur deux machines différentes avec la possibilité que le récepteur n'aie pas la bonne classe pour dé-serialiser....
C'est un phénomène hyper-courant dans des architectures réparties (c'est pour ça que je citais "feu" JINI)

edit: je peux écrire ma propre usine à gaz en faisant circuler des MarshalledObjects et en ayant mon propre ClassLoader coté récepteur ... mais pourquoi réécrire quelque chose qui a sans doute été déjà fait 8-)
28/04/2011, 12h10
Jimmy_

Ceci dit, nous on s'envoie des Bytes on ne fait transiter que la 'charge utile'.

Tu ne sais pas du tout l'objet que tu vas recevoir, même pas une liste d'objet possible ?
28/04/2011, 13h43
professeur shadoko

Citation:

Envoyé par Jimmy_

Tu ne sais pas du tout l'objet que tu vas recevoir, même pas une liste d'objet possible ?

aucune chance... on est en informatique répartie: les machines sur le réseau peuvent inclure des codes nouveaux à tout moment et donc il faut que les machines réceptrices soient capables de récupérer dynamiquement ces codes.

(pour moi ce n'est pas une situation exceptionnelle...)
28/04/2011, 14h05
Logan Mauzaize

JMS n'étant qu'une spécification, ils ne doivent pas avoir prévu ça dans l'API, si t'as besoin d'envoyer des informations dont la forme et la nature peut changer à tout moment pourquoi passer par la sérialisation Java.

Je pense que le mieux c'est de sérialiser via un processus plus standard que celui proposé par Java.

Il y a aucun miracle qui fera passer le code (comportement) de tes classes et celui de leurs dépendances.

Je te conseille éventuellement de consulter la documentation de ton implémentation pour savoir comment la paramétrer et si par exemple tu peux spécifier le ClassLoader.
28/04/2011, 14h39
Jimmy_

J'ai connu il fut un temps un middleware qui utilisait massivement l'introspection via l'API de reflection Java.

Je ne sais pas si ton besoin est couvert par cette API. Surtout si tu n'as pas à priori l'objet sous le coude ou dans un jar.
28/04/2011, 16h49
professeur shadoko

Citation:

Envoyé par Nemek

Je pense que le mieux c'est de sérialiser via un processus plus standard que celui proposé par Java.

Il y a aucun miracle qui fera passer le code (comportement) de tes classes et celui de leurs dépendances.

Sans faire de miracles ça se fait couramment dans d'autres contextes
d'informatique répartie et Java est très bien fait pour ça.

le seul truc est de savoir si quelqu'un l'a déjà fait dans un contexte JMS.

Citation:

Je te conseille éventuellement de consulter la documentation de ton implémentation pour savoir comment la paramétrer et si par exemple tu peux spécifier le ClassLoader.

là tu as raison .... mais tu me demandes de lire une documentation! :aie:
(de plus l'implantation des agents qui écrivent et lisent dans JMS doit être abstraite par rapport au produit support JMS -il y a une raison pour ça-)
28/04/2011, 17h09
tchize_

Toute solution impliquant le transport des classes serait propriétaire, et donc adieu l'abstraction.

Transférer les classes ne résoud rien. Comment les utiliser puisqu'on ne les a jamais vues avant? RMI a un tout autre fonctionnement, il arrive qu'on code par exemple une fenetre coté serveur et qu'on l'envoie pour affichage au client par RMI. Je vois mal l'intéret de ce genre de chose en java. Un message se sont des données auquel le consommateur s'attends. Il faudrait plutot que vous revoyez votre formattage des messages. JMS est un bus à message, RMI est une interface permettant d'invoquer des méthodes à distance, la logique n'est donc pas la meme ;)

En "gros" MapMessage a été créé dans l'idée de plutot y tapper des List, des Map ou des choses dans ce gout la, pas des classes custom. Pour les structure complexes, préférer l'envoi d'un chaine JSON et son traitement coté client ;)
28/04/2011, 17h25
professeur shadoko

Citation:

Envoyé par tchize_

Toute solution impliquant le transport des classes serait propriétaire, et donc adieu l'abstraction.

soit.... :?

Citation:

Transférer les classes ne résoud rien. Comment les utiliser puisqu'on ne les a jamais vues avant?

là je sais: le code recepteur fait de l'introspection puis utilise ces informations en fonction de tas de critères sur la nature de ses découvertes.

la bonne idée serait sans doute de faire ces opérations avant d'envoyer le message mais il faut que je vérifie si les exigences de découplage permettent ça effectivement de façon réaliste (je veux dire c'est le code récepteur qui a sa logique de collecte/structuration/utilisation des informations et le code émetteur n'en a -presque- aucune idée)
28/04/2011, 17h31
tchize_

mais pourquoi dans ce cas aller f*** ces données dans une classe qu'on sérialize après plutot que les mettre dans un truc genre JSON ou xml?
28/04/2011, 17h39
professeur shadoko

Citation:

Envoyé par tchize_

mais pourquoi dans ce cas aller f*** ces données dans une classe qu'on sérialize après plutot que les mettre dans un truc genre JSON ou xml?

parce que ce sont de vraies classes pas simplement des structures de données.
encore une fois utiliser des classes qu'on n'a jamais vu ni d'ève ni d'adam ça se fait pour des tas de raisons: ici le transfert des objets est asynchrone et obéit à une logique "message" au lieu d'être directement livré (comme en RMI ou JINI).
29/04/2011, 08h33
Logan Mauzaize

RMI a besoin que le Stub soit déployé sur le client RMI, non ?

Si je cromprends bien tu veux également faire transiter les classes de tes objets ? Dans ce cas JMS n'est vraiment pas le bon choix.

Car ce genre de système suppose une négociation entre les deux parties afin d'échanger au préalable les classes (comment gérer les différentes version d'une même classe ?).

Ensuite l'envoie de données si tout est ok.

Il ne faut pas oublier que dans JMS le broker doit être capable de stocker pour transmettre le message même si l'émetteur est déconnecté.
29/04/2011, 09h10
tchize_

Pour le problème de déploiement des classes, j'aborderais éventuellement le problème de cette façon:

un repository central avec les classes de transfert en version X

quand l'émetteur upgrade ses classes, il poste un message sur une queue précise (ou un topic persistant si de nombreux clients) disant à quelle version il passe. Le clients, en recevant ce message, se déconnectent, téléchargent la mise à jour et redémarrent.
29/04/2011, 09h40
professeur shadoko

Citation:

Envoyé par Nemek

RMI a besoin que le Stub soit déployé sur le client RMI, non ?

non.

je reprends mon raisonnement à la base: dans un service comme "feu" JINI on recevait des objets dont on n'avait pas nécessairement la classe. Si la classe était inconnue le ClassLoader demandait la classe à l'émetteur et zou on pouvait se servir de cet objet (il s'agit bien d'objets avec un comportement pas de simples données emballées dans un objet).

Naïvement je vois JMS comme un moyen de diffuser des objets sur la base du paradigme publish/subscribe. Le mot "message" est relativement trompeur à ce niveau: il ne s'agit pas forcément de données portant diagnostic d'un évènement mais bien de véritables objets. Dans ce cas il me semble évident que le récepteur n'a pas forcément la classe de l'objet reçu et qu'un mécanisme de chargement de classe doit rentrer en action. Je suis surpris que ça ne soit pas dans la spec et je serais encore plus surpris qu'une implantation (ou des librairies ad-hoc) ne traitent pas le problème.
Avant de réaliser ça "à la main" je préfère profiter de librairies déjà écrites.
29/04/2011, 09h45
professeur shadoko

Citation:

Envoyé par Nemek

Il ne faut pas oublier que dans JMS le broker doit être capable de stocker pour transmettre le message même si l'émetteur est déconnecté.

tu veux dire que le broker doit aussi avoir la classe?
il ne devrait pourtant pas avoir a deserialiser le flot d'octet .... je n'y connais rien mais ça me semble peu probable.
29/04/2011, 09h49
professeur shadoko

Citation:

Envoyé par tchize_

Pour le problème de déploiement des classes, j'aborderais éventuellement le problème de cette façon:

un repository central avec les classes de transfert en version X

quand l'émetteur upgrade ses classes, il poste un message sur une queue précise (ou un topic persistant si de nombreux clients) disant à quelle version il passe. Le clients, en recevant ce message, se déconnectent, téléchargent la mise à jour et redémarrent.

moui.... je vais réfléchir à cet aspect. (dans le cas d'espèce il y a peu de clients et beaucoup d'émetteurs).
mais pourquoi se déconnecter et redémarrer?
29/04/2011, 10h26
Logan Mauzaize

Citation:

Envoyé par professeur shadoko

non.

~~RMI nécessite au moins l'interface.~~ Il semblerait que non en faite.

Citation:

Envoyé par professeur shadoko

je reprends mon raisonnement à la base: dans un service comme "feu" JINI on recevait des objets dont on n'avait pas nécessairement la classe. Si la classe était inconnue le ClassLoader demandait la classe à l'émetteur et zou on pouvait se servir de cet objet (il s'agit bien d'objets avec un comportement pas de simples données emballées dans un objet).

Là clairement le protocole de base de JMS n'est pas fait pour ça.

Citation:

Envoyé par professeur shadoko

Naïvement je vois JMS comme un moyen de diffuser des objets sur la base du paradigme publish/subscribe. Le mot "message" est relativement trompeur à ce niveau: il ne s'agit pas forcément de données portant diagnostic d'un évènement mais bien de véritables objets. Dans ce cas il me semble évident que le récepteur n'a pas forcément la classe de l'objet reçu et qu'un mécanisme de chargement de classe doit rentrer en action. Je suis surpris que ça ne soit pas dans la spec et je serais encore plus surpris qu'une implantation (ou des librairies ad-hoc) ne traitent pas le problème.
Avant de réaliser ça "à la main" je préfère profiter de librairies déjà écrites.

Un message c'est une donnée, pas un comportement.

Citation:

Envoyé par professeur shadoko

tu veux dire que le broker doit aussi avoir la classe?
il ne devrait pourtant pas avoir a deserialiser le flot d'octet .... je n'y connais rien mais ça me semble peu probable.

Le broker ne fait certes que transiter des bytes mais si tu veux échanger les classes c'est pas le broker qui va les stocker !

Citation:

Envoyé par professeur shadoko

moui.... je vais réfléchir à cet aspect. (dans le cas d'espèce il y a peu de clients et beaucoup d'émetteurs).
mais pourquoi se déconnecter et redémarrer?

Un classloader ne peut maintenir qu'une seule version d'une classe. Une fois que tu auras récupérée une version tu pourras plus la faire évoluer.
29/04/2011, 10h29
tchize_

Citation:

Envoyé par professeur shadoko

tu veux dire que le broker doit aussi avoir la classe?
il ne devrait pourtant pas avoir a deserialiser le flot d'octet .... je n'y connais rien mais ça me semble peu probable.

Non, ce qu'il veux dire c'est que le récepteur doit être capable de lire le message même si l'émetteur (qui est le seul pouvant fournir les classes manquantes) est arrêté. Hors si t'as besoin de contacter l'émetteur pour avoir les classes manquantes, t'as un problème.
29/04/2011, 10h30
tchize_

Citation:

Envoyé par professeur shadoko

moui.... je vais réfléchir à cet aspect. (dans le cas d'espèce il y a peu de clients et beaucoup d'émetteurs).
mais pourquoi se déconnecter et redémarrer?

Parce que ça évite de se faire chier avec des classloader bidouilleé. C'est plus basé sur le système "mise à jour automatique" qui est plus facile à mettre en oeuvre ;)
29/04/2011, 11h00
professeur shadoko

Citation:

Envoyé par Nemek

Un message c'est une donnée, pas un comportement.

euh ... je pense que c'est un vision restrictive (comme souvent dans la POO les termes empruntés au langage courant -héritage, objet, etc...- peuvent induire en erreur car la signification du langage courant ne recouvre pas celle du langage de programmation)

Citation:

Envoyé par tchize_

Non, ce qu'il veux dire c'est que le récepteur doit être capable de lire le message même si l'émetteur (qui est le seul pouvant fournir les classes manquantes) est arrêté. Hors si t'as besoin de contacter l'émetteur pour avoir les classes manquantes, t'as un problème.

touché: ça c'est un bon argument.... je vais y réfléchir. .... ça me fait penser que le problème est plus compliqué que prévu et que les implantations JMS ont du prévoir ça dans un coin (mal documenté comme d'ab!)
29/04/2011, 11h15
Logan Mauzaize

Citation:

Envoyé par professeur shadoko

euh ... je pense que c'est un vision restrictive (comme souvent dans la POO les termes empruntés au langage courant -héritage, objet, etc...- peuvent induire en erreur car la signification du langage courant ne recouvre pas celle du langage de programmation)

Le terme message me paraît assez clair. Et je suis prêt à mettre ma main à couper que c'est comme ça que l'API et ses implémentations ont été pensées et codées.

Citation:

Enterprise messaging provides a reliable, flexible service for the asynchronous exchange of critical business data and events throughout an enterprise.

source

Sinon ils auraient appeler ça EJB ou RMI. :roll:

Citation:

Envoyé par professeur shadoko

touché: ça c'est un bon argument.... je vais y réfléchir. .... ça me fait penser que le problème est plus compliqué que prévu et que les implantations JMS ont du prévoir ça dans un coin (mal documenté comme d'ab!)

Il n'y a pas de solution JMS à ce problème à part stocker l'ensemble des classes avec leurs différentes versions pour chaque message dans le broker :?
29/04/2011, 11h25
Jimmy_

Et en faisant transiter le .class ou le .jar en BytesMessage, puis en le copiant dans un folder du récepteur. Il le charge et l'utilise.
29/04/2011, 11h28
tchize_

attention aussi à la taille des messages échangés. Beaucoup de broker sont surtout optimisé pour l'échange rapide de très nombreux messages de petite taille, pas pour l'échange lent de gros message ;)

Faire un message JMS de quelques M peux vitre foutre en l'air les perfs du broker ;)