Discussion :

[Népomucène]

Bonjour,

J'ai une application "client lourd" qui fonctionne sur des postes industriels (connectés à des chaines de production).
Cette application est un JAR qui tourne 24h/24h.

La mise à jour (simple copie de la nouvelle version du jar) est une épouvantable galère car les postes sont difficiles d'accès et il n'est pas question de demander aux utilisateurs de cliquer quelque part pour télécharger quelque chose.

J'ai fait un test en programmant, dans mon application, un thread qui va voir toutes les minutes dans un répertoire du réseau si une nouvelle version est présente. S'il trouve une nouvelle version, il la copie dans le répertoire local de l'application (poste industriel) puis lance la nouvelle version et arrête l'ancienne.

Cela répond donc à mon besoin (pas d'intervention d'utilisateur, mise à jour à distance à n'importe quel moment). Cependant je trouve mon système un peu bricolé (forte dépendance du réseau, des noms de répertoires, perte de connexion, etc) et n'importe qui peut détruire le jar de référence du réseau s'il en a envie

J'ai envisagé de remplacer la copie du jar par un chargement via une application serveur qui pourrait envoyer le jar+librairies par un port TCP/IP mais j'ai la nette sensation de ré-inventer la roue

Donc je cherche à savoir si GlassFish pourrait faire la même chose avec plus d'efficacité :
- rendre le répertoire contenant le JAR invisible depuis le poste client
- possibilité pour le poste client de consulter GlassFish toutes les minutes pour installer une mise à jour "à chaud".
Bien sûr, toute autre solution est la bienvenue ...

Cordialement

Népomucène

[alexismp]

Le support de Java Web Start est peut-être une réponse à ton besoin, mais il faut redémarrer l'application pour éventuellement trouver une mise à jour.

[Népomucène]

Bonjour Alexis,

J'ai examiné la solution WebStart qui est très pratique dans d'autres cas ; mais les postes clients sont dispersés dans toute l'usine et difficiles d'accès (claviers et unité centrale enfermés dans des armoires métalliques étanches ).
Par ailleurs, les ouvriers sur les chaines de fabrication travaillent avec un écran tactile et ne sont pas sensés arrêter et redémarrer leur application.

Aussi, pour ce cas particulier, j'ai vraiment besoin d'une mise à jour "silencieuse".
Penses-tu que GlassFish aurait la possibilité de servir une application cliente qui téléchargerait une nouvelle version quand elle existe ?

[alexismp]

Le JNLP de Java Web Start peut-être dynamiquement généré et modifié par une application hébergée dans GlassFish.
Je ne suis pas persuadé de comprendre qui fait la mise à jour sur le poste de travail.

[Népomucène]

Je ne suis pas persuadé de comprendre qui fait la mise à jour sur le poste de travail.

Sur les postes de production, à l'heure actuelle, c'est moi qui fait les mises à jour "à la main" en copiant jar+librairies sur chaque poste (j'y passe une journée à chaque fois).

Sur un poste de test, j'ai modifié mon application pour qu'un thread contrôle toutes les minutes s'il y a une nouvelle version et copie jar+librairies depuis un répertoire du réseau sur le poste local. La faille de sécurité est béante avec ce système car n'importe qui peut accéder à ce répertoire.

Dans l'idéal, je souhaite que mon application cliente interroge toutes les minutes mon serveur d'applications. Si le serveur signale une nouvelle version, alors l'application cliente télécharge jar+librairies, puis se relance automatiquement.

Ce que je ne sais pas c'est si GlassFish peut :
- indiquer via une requête qu'une nouvelle version est présente
- fournir un système du genre FTP pour récupérer les fichiers

J'ai imaginé me faire une petite application serveur dédiée à cette tâche, mais si GlassFish le fait déjà ce serait ridicule.
En revanche si tu penses que GlassFish n'est pas prévu pour cet usage très particulier ou en est trop éloigné alors je préfère laisser GlassFish et revenir à mon idée de "petite application serveur".

Ton avis, quel qu'ilsoit, me fera gagner un temps énorme.

Merci d'avance

Népo

[alexismp]

je dirais que les deux pistes sont:
- Taches ordonnancées (Cron) dans Hudson
- Binding Component - FTP de OpenESB (intégré dans GlassFish)

[Népomucène]

Merci beaucoup pour ces pistes Alexis, je vais les examiner attentivement

[Népomucène]

Bon,
Vu la quantité de boulot que j'ai par ailleurs, je vais me contenter de JWS et rester dans le périmètre des solutions "approuvées".
Je termine donc ce post ici.
Merci à tous ....

[chemical_seb]

ce qui me vient à l'esprit:

l'applic serait sur glassfish et serait appelée par java web start.

Lors d'une mise à jour de l'applic, tu redéploierais le jar sur glassfish puis à l'aide d'un petit soft d'aministration home made, tu enverrais un broadcast destiné à tous les clients en court d'activité sur un port d'écoute d'aministration des clients leur disant: la version actuelle est 1.X si vous n'êtes pas de cette version, terminer vous et appellez la nouvelle version.

[Népomucène]

En effet, c'est ce type de solution que je vais adopter :
- JWS pour le déploiement effectif
- les postes clients vont ensuite interroger toutes les 5 minutes dans GlassFish un EJB capable de donner le numéro de version du jar.
- si une mise à jour existe alors l'application affiche un message demandant à l'utilisateur de redémarrer immédiatement l'application.

dans l'idéal, j'aurai aimé pouvoir forcer un redémarrage automatique de l'application cliente, forçant l'installation par JWS ... mais bon, cela ne semble pas possible.