Discussion :

[ibnhamzasm]

Bonjour
Je voudrais créer une application lourde Desktop Sous Java , qui se met à jour de façon transparente et périodique sur mon serveur (distant), et de façon bidirectionnelle (client <=>serveur )
les mise à jour comprennent
1- l'application elle même ( correction de bug- amélioration)
2- les BD ( mise à jour de données existante sur le client par de nouvelle émanant du serveur)
3- les donnes des utilisateurs (coté client vers serveur)

Quelle Sont les options qui s'offre à moi :
1 - Langage et platforme (Java est t'il le mieux adapté ) SPRING ? autre?
2 - Comment peut ont gérer ces MAJ sans risque de corrompre les BD coté client-

Merci pour vos réponse

[Népomucène]

Bonjour
Je voudrais créer une application lourde Desktop Sous Java , qui se met à jour de façon transparente

Pour les mises à jour d'application :
1) Java Web Start :
avantages : c'est standard et le code téléchargé n'est pas décompilable facilement et n'est pas copiable.
inconvénients : avec les versions récentes de java, il faut un certificat et la mise à jour de l'application ne se fait qu'au moment du lancement

2) Jean baptiste Wicht propose de créer son propre système de mise à jour
http://baptiste-wicht.developpez.com...va/update/#LIV
avantage : on contrôle tout
inconvénients : le code n'est pas protégé contre la copie

2 - Comment peut ont gérer ces MAJ sans risque de corrompre les BD coté client

La réponse habituelle est que toutes les données doivent se trouver dans la base (MySQL, SQL server, PostGre, etc...)
et jamais sur le poste client.

Maintenant, pourquoi ce choix d'application lourde Java plutôt qu'une application web réalisable en Java ?

[ibnhamzasm]

Bonjour Merci Beaucoup Pour Votre Réponse

Merci le java Web Start Semble être une solution intéressante - si j'ai bien compris EN SURVOLANT à la hâte LA DOC il semble que l'installation des mise à jour passe par l'accord de l'utilisateur- ça ne serai pas plus facile et Sûr dans ce cas de fournir un patch avec l’exécutable mis à jour- puisque l'utilsateur aura à valider le téléchargement et l'installation ?

pour votre question sur le client lourd, c'est que les usagers ne sont pas connecté forcément ( offline)- la mise à jour ne se fait que lorsque il se connectent, et les BD sont essentielle pour le Fonctionnement de l'application, les mise à jours sont proposé périodiquement- ( d'autant plus que les changement sur la bd dorsale ne se fait que périodiquement)- dans ce cas là ma question persiste-

trés gentil à vous-

[Népomucène]

il semble que l'installation des mise à jour passe par l'accord de l'utilisateur

Non, l'utilisateur n'a pas le choix.
Quand il lance sont application, la mise à jour est automatique (cela fait râler un peu parfois ...)

les usagers ne sont pas connecté forcément ( offline)

Ce qui veut dire qu'il faut :
- une base de données sur le poste quand il est est hors ligne
- un système de synchronisation des données avec la base centrale quand il est à nouveau en ligne
Ce type de problème se résout en analysant précisément ce qui doit être synchronisé ou pas.
Donc là, il n'y a pas de réponse toute faite, il faut aller dans le détail.

En cas de changement de structure de la base locale (ajout de table, de colonne, etc ...)
il faut utiliser un script SQL d'instructions de manipulation des objets de la base (rien de très compliqué)
qui serait déclenché par l'application elle-même lors d'une mise à jour de celle-ci.

[ibnhamzasm]

Non, l'utilisateur n'a pas le choix.
Quand il lance sont application, la mise à jour est automatique (cela fait râler un peu parfois ...)

oui et l'histoire des certif?

[Népomucène]

Si l'application contient un certificat valide (c'est payant),
l'utilisateur n'a pas besoin de dire à chaque fois qu'il accepte la mise à jour.

On peut faire une application avec un certificat "autosigné"
l'utilisateur aura un message l'avertissant que la "source n'est pas sûre"
mais il peut tout de même lancer l'application

Quoi qu'il en soit, lorsque le poste est en ligne, si l'utilisateur refuse la mise à jour
alors l'application ne se lance pas du tout

[tchize_]

Pour les mises à jour d'application :
1) Java Web Start :
avantages : c'est standard et le code téléchargé n'est pas décompilable facilement et n'est pas copiable.

Tu peux argumenter? A ma connaissance, javawebstart ne se charge ni d'obfuscquer le code, ni d'empêcher la copie, ni d'interdire le lancement d'une ancienne version. Certe il y a des tags dans ce sens dans le jnlp, mais ce ne sont pas les lanceur jnlp tiers qui manquent capables d'ignorer ce genre de règle. C'est juste un outil qui facilite le transfert des mises à jour et qui vérifie leur signature.

[ibnhamzasm]

Si l'application contient un certificat valide (c'est payant),
l'utilisateur n'a pas besoin de dire à chaque fois qu'il accepte la mise à jour.

On peut faire une application avec un certificat "autosigné"
l'utilisateur aura un message l'avertissant que la "source n'est pas sûre"
mais il peut tout de même lancer l'application

c'est surement ce que j'ai du lire quand j'ai dit que cela nécessitait l'intervention de l'usager-
et moi mon projet c'est de rendre les MAJ aussi transparente que possible sans passer par ce genre d'allerte dont la réaction naturelle d'un utilsateur lambda est de cliquer sur le bouton Anuller!!!!

[tchize_]

Ben dans ce cas tu signe avec un vrai certificat?

[ibnhamzasm]

En faisant un peu le tour des post sur la question, les résultats ne sont pas encourageants, certains posts et notamment celui de bouye du débat lancé par Michael baron sur ce forum m'ont carrément découragé.. N'y a-t-il pas d'autre alternative à Web start.
Du moins peut ton mettre les bd de façon transparente à partir du serveur.. Quitte à fournir
des patch pour l'application. Merci encore une fois

[Népomucène]

Tu peux argumenter? A ma connaissance, javawebstart ne se charge ni d'obfuscquer le code, ni d'empêcher la copie, ni d'interdire le lancement d'une ancienne version

C'est tout simple : le jar est téléchargé dans le cache java et éclaté en plein de fichiers.
Il n'est pas copié dans un dossier que l'utilisateur peut facilement trouver.
A moins qu'il y ai une astuce que j'ignore, je souhaite bon courage à l'utilisateur moyen qui voudrait reconstituer le jar et les librairies pour le passer à son collègue.

Par ailleurs, au lancement de l'application, JWS va systématiquement vérifier la version sur le serveur et la télécharge si elle existe.
Naturellement, si le développeur créé une nouvelle version sur un lien web différent du précédent, il n'y aura pas de mise à jour car cela sera considéré comme une autre application.
Mais dans ce cas on décide délibérément de préserver les versions précédentes et ce n'est pas l'objectif de ibnhamzasm

[Népomucène]

En faisant un peu le tour des post sur la question, les résultats ne sont pas encourageants, certains posts et notamment celui de bouye du débat lancé par Michael baron sur ce forum m'ont carrément découragé.. N'y a-t-il pas d'autre alternative à Web start.

Je suis d'accord que JWS nécessite au départ un peu d'huile de coude.
Mais cela fait des années que je l'utilise dans les intranets de mes clients et cela fonctionne plutôt bien.
Chaque fois qu'on a un changement de PC il suffit de cliquer sur le lien de l'intranet et hop l'application est installée.
C'est tout de même beaucoup plus confortable que la copie "à la main"

Maintenant, il faut que le système de mise à jour de l'application corresponde aux besoins :
- s'il n'y a que 3 ou 4 utilisateurs et qu'il n'y aura qu'une mise à jour de l'application par an (après que le développement soit à peu près stabilisé) alors il vaut mieux faire des mises à jour "à la main"
- à partir de 5 postes, les mises à jour - même rares - sont pénibles à faire à la main.

L'alternative à JWS en Java est ce que Wicht propose :http://baptiste-wicht.developpez.com...s/java/update/

Sinon, tu peux aussi regarder du côté des installateurs tiers :
IzPack pour java
autres

Du moins peut ton mettre les bd de façon transparente à partir du serveur.. Quitte à fournir des patch pour l'application.

Quand tu parles de mise à jour des BD :
- est-ce que tu parles de la structure (nouvelle table, nouvelle colonne ...)
- est-ce la synchronisation des données avec la BD centrale ?

[ibnhamzasm]

Les Bd garde la même structure , il n'ya changement que rarement (et ça sera dans ce cas un ajout d'une colonne par ex ) mais ça n 'arrive que rarement, là ça vaut le coup de tout mettre à jours l'appli+ le schema et les bd dans un patch- mais sinon cs sont les Donnees qui changent..

[Népomucène]

Donc pour les données c'est un système de synchronisation base client nomade <==> base centrale serveur qui doit être mis en place.

[ibnhamzasm]

Je suis d'accord que JWS nécessite au départ un peu d'huile de coude.
Mais cela fait des années que je l'utilise dans les intranets de mes clients et cela fonctionne plutôt bien.

Justement la majorité de ceux qui ont eu à l'utiliser en intranet- se sont dit satisfait à la différence de ceux qu l'ont utilisé via des serveur distant sur internet- je ne comprend pas mais ça été rapporté.

[ibnhamzasm]

Donc pour les données c'est un système de synchronisation base client nomade <==> base centrale serveur qui doit être mis en place.

absolument

[Népomucène]

Justement la majorité de ceux qui ont eu à l'utiliser en intranet- se sont dit satisfait à la différence de ceux qu l'ont utilisé via des serveur distant sur internet- je ne comprend pas mais ça été rapporté.

Là c'est toujours difficile de savoir exactement ce qui s'est passé.

Le JWS fonctionne dans les deux cas.

[Népomucène]

Pour la synchronisation des données, il faut voir dans le détail :
- quelles tables, quels champs
- qui a le droit de faire quoi et sous quelles conditions
- etc.

[ibnhamzasm]

Pour la synchronisation des données, il faut voir dans le détail :
- quelles tables, quels champs
- qui a le droit de faire quoi et sous quelles conditions
- etc.

les changement dans la structure se font toujours dans un seul sens - serveur -- client et ça concerne l' ensemble des champs d'une table ( on doit écraser toute la table par une autre )- Bien sur l'utilisateur final n'aura qu'un seul droit est de visualiser les résultat de requête sur la table locale- copier manipuler les donnes mais sans toucher à la table-
il est possible qu 'on aura besoin de récupérer certain donnée de champs dans la table locale pour alimenter le même champs sur la base centrale- ( champs feed back).

je pensait qu'une telle procedure était simple ( de mémoire cela se faisait globalement sans problème sur SharePoint de MS à moins que me trempe )

[tchize_]

A moins qu'il y ai une astuce que j'ignore, je souhaite bon courage à l'utilisateur moyen qui voudrait reconstituer le jar et les librairies pour le passer à son collègue.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
davidd@davidd-Laptop /tmp $ wget http://www.yworks.com/resources/yed/demo/yed.jnlp
--2016-08-04 19:15:47--  http://www.yworks.com/resources/yed/demo/yed.jnlp
Resolving www.yworks.com (www.yworks.com)... 217.160.0.52
Connecting to www.yworks.com (www.yworks.com)|217.160.0.52|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1396 (1,4K) [application/x-java-jnlp-file]
Saving to: ‘yed.jnlp’
 
yed.jnlp            100%[===================>]   1,36K  --.-KB/s    in 0s      
 
2016-08-04 19:15:47 (111 MB/s) - ‘yed.jnlp’ saved [1396/1396]
 
davidd@davidd-Laptop /tmp $ cat yed.jnlp | grep codebase
  codebase="http://www.yworks.com/resources/yed/demo"
davidd@davidd-Laptop /tmp $ cat yed.jnlp | grep jar | grep href
    <jar href="yed.jar"/>
    <jar href="lib/vectorgraphics.jar"/>
    <jar href="lib/common-image.jar"/>
    <jar href="lib/common-io.jar"/>
    <jar href="lib/common-lang.jar"/>
    <jar href="lib/imageio-core.jar"/>
    <jar href="lib/imageio-icns.jar"/>
    <jar href="lib/imageio-ico.jar"/>
    <jar href="lib/imageio-iff.jar"/>
    <jar href="lib/imageio-jpeg.jar"/>
    <jar href="lib/imageio-metadata.jar"/>
    <jar href="lib/imageio-pict.jar"/>
    <jar href="lib/imageio-psd.jar"/>
    <jar href="lib/imageio-thumbsdb.jar"/>
    <jar href="lib/imageio-tiff.jar"/>

on ouvre un notepad à la con et on copie colle avec 2 changement tout bête à faire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
wget http://www.yworks.com/resources/yed/demo/yed.jar
wget http://www.yworks.com/resources/yed/demo/lib/vectorgraphics.jar 
wget http://www.yworks.com/resources/yed/demo/lib/common-image.jar
wget http://www.yworks.com/resources/yed/demo/lib/common-io.jar
wget http://www.yworks.com/resources/yed/demo/lib/common-lang.jar
wget http://www.yworks.com/resources/yed/demo/lib/imageio-core.jar
wget http://www.yworks.com/resources/yed/demo/lib/imageio-icns.jar
wget http://www.yworks.com/resources/yed/demo/lib/imageio-ico.jar
wget http://www.yworks.com/resources/yed/demo/lib/imageio-iff.jar
wget http://www.yworks.com/resources/yed/demo/lib/imageio-jpeg.jar
wget http://www.yworks.com/resources/yed/demo/lib/imageio-metadata.jar
wget http://www.yworks.com/resources/yed/demo/lib/imageio-pict.jar
wget http://www.yworks.com/resources/yed/demo/lib/imageio-psd.jar
wget http://www.yworks.com/resources/yed/demo/lib/imageio-thumbsdb.jar
wget http://www.yworks.com/resources/yed/demo/lib/imageio-tiff.jar

on copie colle dans la console, et on finis par

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
davidd@davidd-Laptop /tmp $ mkdir lib
davidd@davidd-Laptop /tmp $ cp *.jar lib/
davidd@davidd-Laptop /tmp $ java -jar yed.jar

J'aurais mis plus de temps à rédiger ce post qu'à réaliser l'opération (moins de 10 minutes), et le copain informaticien de l'utilisateur peut rapidement lui expliquer la manoeuvre. Pas besoin de courage là dedans. le CE1D de mathématique est plus dur à réaliser



Et si l'utilisateur est moins que moyen, ce ne sont pas les outils automatiques qui sont durs à trouver avec google

https://github.com/codewatchorg/jnlpdownloader

On est loin du "difficile à décompiler, incopiable"

Pour résumer, ne pas utiliser webstart en protection contre la copie ou pour empêcher d'utiliser de vieilles versions, ca n'est pas fait pour et ce n'est pas difficile à contourner. Javawebstart est là pour faciliter la vie des utilisateurs (toujours accès à la dernère version, pas besoin d'install), et des administrateur (déploiement aisé). Mais il n'est pas là pour empêcher le moindre contournement ou offrir la moindre protection à l'éditeur. Il offre uniquement des protections à l'utilisateur en sandboxant l'application et en vérifiant l'intégrité des certificats.


Pour le reste c'est un très bon util, bien adapté au déploiement réseau et en tant qu'utilisateur, je préfère javawebstart à des système de mise à jour sauce maison qui seront des trous béant de sécurité dans mon PC. Je dis juste que si tes critère interdisent absolument que l'utilisateur bidouille, tu va devoir rajouter des surcouches destinées à ça dans ton code, ce n'est pas un service offert par webstart.