Permutation dans et hors logique sur un système de fonctionnement

Question

Je veux concevoir ce système qui comporte deux volets principaux:

1. trucs de base/de base. Ne change jamais.
2. Truc fonctionnant sur le noyau. Changements plutôt fréquemment.

Ceci va être développé en Java, mais le problème s'applique à n'importe quel langage OO classique. Comment puis-je remplacer 2 ci-dessus dans un système en cours d'exécution sans recompiler 1, et sans même arrêter 1 lorsqu'il est en cours d'exécution. Il est possible de recompiler 2, mais je ne devrais pas déranger 1.

Existe-t-il un motif de conception pour cela? Je pense que c'est un peu similaire au comportement du plugin, mais 2 est en fait critique pour le fonctionnement de l'application, pas seulement un add-on.

Answer 1

Sans plus d'informations, il est difficile de répondre ... mais vous pouvez consulter OSGi comme point de départ pour quelques idées.

Answer 2

Nous avons besoin de plus d'informations pour résoudre ce problème. Si vous parlez de charger une nouvelle logique au moment de l'exécution, cela pourrait être assez difficile. Si vous parlez juste de l'échange d'implémentations, cela peut facilement être fait avec le modèle de stratégie.

Answer 3

Vous voudriez un modèle de plugin pour vos trucs qui changent fréquemment, couplé avec une interface pour redémarrer les plugins. Votre core/base (1) serait responsable du chargement dynamique des assemblées/pots contenant vos trucs qui changent fréquemment (2).

Answer 4

Il est assez facile de diviser votre code source en deux arbres. Les formes compilées de celles-ci peuvent être livrées séparément, avec les éléments non-core compilés avec le noyau ajouté à -classpath.

Le code peut être chargé à l'exécution avec les chargeurs de classe (URLClassLoader.newInstance). Vous devez faire attention à ce que l'ancien code soit déchargé. Vous devez vous assurer qu'il n'y a absolument aucune référence (forte) à cela.

Answer 5

C'est exactement le même problème que les conteneurs de servlets lors de l'échange à chaud de servlets. Le serveur Web/conteneur doit fonctionner en continu, mais doit pouvoir charger de nouvelles servlets à la demande.

Je vous suggère de commencer par jeter un oeil au code source Tomcat (available via these subversion URLs.)

Answer 6

Ceci est essentiellement ce que la réflexion est pour. Comme d'autres l'ont dit, si vous suivez un modèle de crochet ou de plug-in, cela devrait vous permettre de passer le plus clair de votre temps. Fondamentalement, cela se passe comme suit:

1. Créez des interfaces bien définies dans votre code qui décrivent le contrat entre l'application principale et le plugin.
2. Trouver une façon de stocker les informations de pot/classe dans votre configuration afin que vous pouvez charger des types par réflexion à l'exécution
3. plugins de charge par réflexion et appeler des méthodes sur les interfaces décrites dans # 1

Maintenant, si vous commencez à vous embourber dans la mise en œuvre du workflow, il est peut-être temps d'étudier un moteur de workflow standard. Il y a trop de choses à mentionner ici, mais une recherche Google devrait vous aider à démarrer.

Answer 7

J'ai déjà fait quelque chose qui ressemble à votre objectif en utilisant JRuby sur Java. La partie centrale était en Java et serait toujours en cours d'exécution, et les scripts Ruby ont été chargés dynamiquement en utilisant JRuby. De cette façon, je pourrais ajouter des fonctionnalités sans redémarrer (ou compiler) la partie Java.

Answer 8

Évidemment, c'est exactement le genre de chose qui a été développé pour quelque chose comme Eclipse; ils ont construit un framework de plugin en utilisant OSGi. Cela dit, je voudrais un langage de script qui peut fonctionner sur une JVM comme Jython, Rhino/JavaScript ou JRuby. Les cadres tels que Spring prennent désormais en charge the ability to define beans in these languages et les recompilent de manière dynamique.

Ils devraient être largement adoptés dans le futur car plus de support pour les langages dynamiques (en plus des scripts JDK6) arrive dans la JVM.