[Java] Créer une application "updatable"

[The Lootrophile]

Coucou,

J'ai une petite application client/serveur distribuée sur pas mal de postes, et j'aimerai que dans l'avenir, mes utilisateurs n'aient pas à télécharger à la main la nouvelle version du client, supprimer l'ancienne, etc.. Ce client est développé en Java. Je souhaiterais donc faire passer le numéro de version du serveur dans les interactions client/serveur, pour que le client se rende compte qu'il est obsolète, et se mette à jour. Je n'ai pas d'idée de départ, et pas d'idée de mot clef sur google pour me donner des pistes.

Je suis intéressé par des liens explicatifs (URL, livres..) si vous en avez sur le domaine, et également sur des liens/explications sur la manière générale dont on fait ce genre de choses (j'envisage de faire une version de mon client en C++, je suppose que je ne peux pas mettre à jour en live mon application pendant qu'elle est en cours d’exécution, ne serait-ce que pour un problème de droit d'accès sur les fichiers)

Merci d'avance

The Lootrophile

[uzak]

Sinon, tu as le système de bean en java. En gros, tu définis une interface pour chaque classe, et un fichier de config se charge de lier l'implémentation de l'interface à une classe.

En tout cas, plus tu as d'objets et de classes "élémentaires", plus ce sera facile de les changer un par un.

[flibust]

Salut,

Ce que tu veux faire en Java ça existe, il faut que tu utilise un serveur d'applications tout simplement.

Je te propose deux pistes :

- Les tutoriels sur les serveurs d'applications

- Un sondage / Débat sur les serveurs d'applications

[Charles.w]

faut arrêter de déconner...gérer le versionning d'une appli n'est pas super compliqué...utiliser un serveur d'appli c'est encore une solutiondingequinariencomprisauxmecanismessousjacentsetquimetdestermesquifontbiensuruntrucquilnecomprendspas...

Dans ce que je comprends tu as une appli client / serveur relativement simple et légère utilisant sans doute RMI, et tu voudrais que lorsque tu met à jour ton serveur, tu n'aie pas à changer tous les clients à la mano...

Si tu veux vraiment rentrer dans les détails du chargement dynamique des classes côté client, de manière très pointue, tu peux regarder le chapitre "Object Serialization" du livre Java I/O...mais je ne pense pas que cela soit nécessaire...tout comme il n'est à mon avis pas nécessaire de se prendre la tête à regarder les truchement de RMI et des aspects "dynamic code downloading"...tu peux aussi regarder du côté des livres de Oreilly sur RMI pour les notions de base sur RMI ou du Pitt, une référence sur RMI, mais il faut déjà avoir de bonnes bases...

Tu peux faire quelque chose que l'on voit fréquemment...tu rajoute effectivement un "échange" ou des informations spécifiant la version du serveur...de son côté, si le client compare avec sa version...si les deux sont alignés --> OK...sinon, le serveur renvoie l'adresse de téléchargement du nouveau client...l'ancien client télécharge et installe le nouveau client, s'arrête en relancant le nouveau client et le nouveau client efface l'ancien client...

Cette solution n'est peut être pas super dynamique (une connaissance poussée de la serialisation ou de RMI permettent de faire largement mieux niveau chargement dynamique sans reload du client), n'est pas super modulaire non plus (OSGi caymieux et cayplussimple), mais a le mérite de fonctionner, et d'être extrêmement simple à implémenter...

Livres :

http://www.amazon.com/Java-RMI-William-Grosso/dp/1565924525/ref=cm_cr_pr_product_top (intro à rmi)

http://www.amazon.com/Java-I-Elliotte-Rusty-Harold/dp/0596527500/ref=cm_cr_pr_product_top (la sérialisation et les i/o en long et en large...part 1)

http://www.amazon.com/java-TM-rmi-Remote-Invocation/dp/0201700433/ref=cm_cr_pr_product_top (le must sur RMI, pas forcément pour le débutant)

[The Lootrophile]

Merci à tous, particulièrement à Charles, c'est ce que je cherchais.

[lorinc]

Tu peux aussi feinter et ne pas utiliser le classloader par défaut, mais un classloader distant. Dans ce cas, le client va télécharger les classes dont il a besoin à chaque instanciation. J'avais fait ça pendant ma thèse.

[Charles.w]

de mémoire, c'est en partie ce qui est expliqué dans le chapitre object serialization du livre java i/o. L'ennui de cette solution, c'est que tu est toujours obligé d'aller récupérer tes classes sur le serveur, ce qui n'est pas toujours souhaitable.

[fabien29200]

Ou alors, pour pas réinventer la roue, il y a Java Web Start ....

Ca fait déjà tout ça de manière automatique.

[Charles.w]

c'est pas totalement faux...mais il ne me semble pas que JWS oblige le client à passer à la dernière version...et il me semble que l'api pour passer des arguments à une application est assez mal gaulée...

Pour moi Java WebStart est une belle idée, mais l'implémentation laisse largement à désirer, et cela ne me semble pas être une bonne idée que de partir sur une techno qui existe depuis longtemps mais dont les défauts tardent à être corrigés...

Après, je n'ai jamais fait de vrais projets avec WebStart...et je n'en ait jamais vu utilisé dans la vraie vie (autrement que pour quelques démos)...et ce n'est pas faute d'avoir trainé mes souliers dans de nombreuses entreprises...

[fabien29200]

Je développe une appli chez un client qui se lance en Java Web Start.

Il y a une fois ou deux un souci qui fait que l'appli ne se met pas à jour (mais si tu gères ton numéro de version dans une base et que tu le compares à celui de ton appli, ça se contourne).

Après, la partie un peu fastidieuse est de faire un fichier JNLP et de signer les jars, mais après, ça roule.