Est-ce que quelqu'un sait-on utiliser Java pour Mobilité de code forte ? L'avez-vous déjà fait avant?
Voici ce que j'essaie d'atteindre.
Supposons que nous disposions de 2 applications Java distinctes qui communiquent sur le réseau. App A et app b.
APP A a une classe X instanciée comme objet et l'utilise. L'application B n'a aucune connaissance préalable de cette classe X.
APP a besoin de migrer l'instance de la classe X sur l'application B. L'application B doit pouvoir charger de manière dynamique la classe X et conserver l'état l'état de la classe x .
J'ai googlé et j'ai trouvé un tas de ressources sur la manière de charger de manière dynamique la classe au moment de l'exécution. Cependant, je ne sais pas si le mécanisme de transfert d'une instance d'objet sur le réseau avec son état et de l'invoquer de manière dynamique est couverte.
Tous les pointeurs seraient très utiles et merci d'avance!
6 Réponses :
Il y a un projet appelé Cajo qui peut déplacer des objets de manière dynamique sur le réseau. Je ne suis pas sûr de l'état d'exécution cependant.
Dans la normale Java, vous auriez besoin d'une bonne façon de disposer d'une application B charger la classe pour l'objet, alors vous devez sérialiser l'objet à partir de l'application A à l'application B. Vous pouvez peut-être le faire, si les classes sont disponibles dans un emplacement central tel qu'un serveur HTTP. Mais dans le cas général, où vous souhaitez transférer un objet complètement nouveau à l'application B, vous devez implémenter votre propre chargeur de classe (ou trouver une bibliothèque qui le fait).
Si tous vos objets sont sérialisables et que vous disposez d'un emplacement central pour stocker les classes, cela devrait être assez simple à mettre en œuvre. Vous pouvez utiliser l'URLClassloader pour charger des classes à partir d'un serveur HTTP, puis la sérialisation de Java normale pour transférer sur l'objet sérialisé. Une certaine coordination entre les applications A et B serait nécessaire pour que B sache quelle classe à charger et de savoir quand envoyer l'objet, et B sait comment poursuivre l'exécution des méthodes de l'objet. Avec cette approche, il n'y a probablement aucun moyen que l'objet X soit en cours d'exécution d'une méthode; Il faudrait arrêter et ensuite redémarrer son exécution en coopération avec l'application A.
Vous posez des questions sur la forte mobilité, mais vos exigences sont remplies avec une faible mobilité, avec laquelle certaines limitations sont fournies par le protocole RMI. RMI ne prend pas seulement seulement en charge les graphiques d'objet RPC, Object Serialization et Distributed Object, mais également le partage de code habituellement utilisé de sorte que le client puisse charger le bytecode de classes seulement connu sur le serveur et exécuter ce bytecode localement.
La mobilité forte n'est pas prise en charge par Java et je ne peux pas penser à un moyen de la mettre en œuvre sans effectuer des extensions exclusives au VM. Essentiellement, une forte mobilité dans un contexte Java signifierait que vous suspendez ou suspendez un fil dans une machine virtuelle, transférer tous les instances d'objet accessibles à partir de ce thread, potentiellement bypode requis pour l'exécution et le fil interne (pile d'appels, etc.) à un Différents VM et le faire recréer l'état du thread et poursuivre l'exécution au point où le fil a été mis en pause dans l'original VM.
Si vous utilisez JDK6, vous pouvez envoyer un code source dessus, le compiler, le chargeur de classe peut donc trouver cette nouvelle classe, car elle a été compilée de manière dynamique.
L'astuce est alors que vous devrez peut-être utiliser certaines di pour que cela soit chargé dans votre application, vous avez donc besoin d'un cadre DI pouvant fonctionner de manière dynamique.
Ensuite, lorsqu'il est injecté dans votre classe, vous définissez les propriétés à ce point.
Ceux-ci devraient avoir une interface connue. Il doit y avoir un contrat que les deux peuvent dépendre de.
Je ne l'ai pas essayé, et je ne pense pas que Java soit la langue correcte pour cela. Si vous devez avoir cette fonctionnalité, vous voudrez peut-être examiner quelque chose comme l'une des langues de script de jvm ou de la clojure, car je m'attends à ce que cela fonctionnerait également avec cela, puis que votre application Java interagisse avec cet autre cadre dynamique, comme il serait Tous fonctionnent sur la JVM.
Voici un lien sur la compilation à la mouche, avec JDK5 comme il est quelque chose que beaucoup de gens peuvent ne pas être familiers.
Vous avez besoin de deux choses transférées de A à B afin de déplacer une instance I de la classe c.
Premièrement la définition de la classe C (généralement sous la forme d'une liste de codes d'octets), puis la forme sérialisée de I. Veuillez noter que vous devez utiliser la sérialisation XML Instad de l'ancienne sérialisation binaire.
La partie vraiment délicate consiste à obtenir les dépendances de C transféré, car vous devez également transférer toutes les superclasses de C aussi, ainsi que tous les types de retour et les types de champs, ainsi que leurs superclasses et leurs superclasses. types, etc., etc., etc.
Si vous avez vraiment besoin de le faire pour toutes les valeurs possibles de C, votre meilleur pari utilise un cadre conçu pour le faire comme une grille une ou une terre cuite. Si vous pouvez vous retenir à E.G. Une interface donnée et étroite, vous serez probablement beaucoup mieux. Considérons également simplement en utilisant des propriétés pour cela, car ils sont très simples et peuvent vous rendre loin.
J'ai écrit une bibliothèque open source qui prend en charge la mobilité de code exactement comme demandé ci-dessus. En fait, il prend également en charge l'utilisation du type RPC.
voir: Mobility-RPC - Code sans soudure Mobilité et RPC pour la plate-forme Java
en termes d'où cela représente une faible mobilité par rapport à la mobilité forte: Lorsque vous transférez un objet sur une machine distante, vous pouvez contrôler quelle méthode sur l'objet est invoquée et avec quels arguments, lorsqu'il arrive sur la machine distante. Donc, si vous écrivez un agent mobile, cela peut décider de la manière dont il souhaite reprendre l'exécution sur la machine suivante avant de se transferter, il n'est pas nécessaire de reprendre du même endroit.
Ça a l'air intéressant! Si j'étais du tout informé de ce sujet, je poste cela comme une réponse, mais je le posterai comme un commentaire à la place. Pourriez-vous transférer l'objet, en envoyant d'abord la définition de la classe sérialisée, chargez-le dans l'assemblage, puis envoyez-le l'objet et chargez-le puis à l'aide de la définition de la classe (regardez la réflexion si vous ne l'avez pas fait). Ce serait assez friggène cool!
J'ai supprimé ma réponse comme il est clair que je devrais lire quelque chose avant de descendre à la lèvre. Cela dit, je pense que la conception simplifiée de la conception de données mobiles est opposée au code. Toutefois, si vous effectuez des opérations critiques de temps distribué, la mobilité du code peut être idéale.