inria.lognet.cluster ¶
Le but est d'offrir une plateforme de déploiement sur des equinox clients les simples possibles
Phase 0 : manager ¶
Il faut au moins un manager ouvert.
Phase 1 : boot ¶
Le bundle inria.lognet.cluster.boot est chargé de télécharger un Bundle à l'adresse spécifié avec la propriété système inria.lognet.cluster.boot=http://mirage/inria.lognet.cluster.layncher_1.0.0.jar par exemple. L'adresse donnée peut être statique ou dynamique provenant du inria.lognet.cluster.manager.
Le JAR inria.lognet.cluster.launcher_1.0.0.jar sera téléchargé, installé et démarré par le boot, et le boot s'éteint en toute fin.
La phase 1 peut être sautée si launcher est déjà installé dans l'Equinox.
Phase 2 : launcher ¶
Le but de ce bundle est d'installer une série de bundles embarqués dans son JAR (en resources). Il va installer inria.lognet.cluster.client et ses dépendances (inria.lognet.virtpipes, open-chord et gwt).
Dans le cas d'open-chord, une propriété système lui permet de booter, et c'est hard-codé dans launcher.
La phase 2 peut-être sautée si l'équinox a le client statiquement installé.
Phase 3 : client ¶
Le client ouvre un tuyau virtuel d'entrée pour recevoir des communications de managers. Le client recherche dans open-chord les managers ouverts et lui communique son tuyau virtuel. Le manager enregistre le fait qu'un nouveau client est découvert, informe les interfaces graphiques.
L'utilisateur derrière le manager sélectionne un client à partir de l'interface GWT. Certaines commandes s'activent, comme la possibilité de visionner les bundles du clients et leurs états, ou encore d'installer un bundle à distance.
Toutes ces commandes offertes par le managers sont communiquées par le tuyau virtuel du client, qui se charge de les exécuter.
A partir de là, il est possible de déploier et commande n'importe quelle architecture logicielle à distance.