Déport d'un client (très) lourd

Bonjour,

j'ai une petite question concernant un problème faisabilité :

J'ai une application très lourde (swing avec affichage de données geographiques, et très interactive, ...) il je doit pouvoir faire une sorte de client très léger pour des postes client pauvres au niveau ressource.

L'idéal serait de transformer le client lourd en serveur d'application J2EE, mais pour le moment c'est trop long et trop couteux.

Donc je cherche un moyen de créer une sorte de programme qui serait super générique, et permettrer d'intéroger l'application lourde avec l'ajout d'une partie serveur, pour l'affichage de fenêtres, et autre.

En gros un peut comme un VNC, mais en applicatif.

J'espère que ce que je cherche à faire est faisable, et que vous pourrez me le confirmer.


Merci.

Ajout :

Mon idée de départ serais d'utilise RMI pour pouvoir transférer les données comlète contenant les dialogs qui sont à afficher

Et utiliser directement un VNC n'est pas envisageable ?

;)

et bas non, pasqu'en fait l'application lourde transformée (avec un minium de modifications) doit pouvoir adresser plusieurs clients qui auraient une affichage différent.

Et oui, c'est trop simple sinon, y a pas de chalenge :D

Citation:

---

Envoyé par BakaOnigiri

Ajout :

Mon idée de départ serais d'utilise RMI pour pouvoir transférer les données comlète contenant les dialogs qui sont à afficher

---

Pourquoi ne pas utiliser J2EE (ou JEE plutot :P) ? En ce qui concerne le coût, il y a des serveurs gratuits (JBoss par exemple) et le temps de développement n'est pas plus long que utiliser RMI (à noter que RMI est souvent "caché" dans les applications JEE...).

Le seul véritable coût est celui de l'apprentissage de JEE si tu ne connais pas... Mais si tu maîtrises le RMI, je pense qu'apprendre JEE et les EJB te seras facile (puisque tu comprendras tout ce qu'il se passe derrière, et tu n'écriras que peu de lignes...) :)

Essaye de voir du coté de Spring avec RMI car dans ton cas tu n'as pas besoins d'aller plus loin si j'ai bien compris, donc un conteneur leger te suffit.

Bonjour,

afin de tester mon idée d'utiliser RMI, j'ai fait un petit bout de code qui transmet directement un JPanel de mon client lourd, mais ce panel affiche un composant qui dépend d'une très vieille librairie, et donc je suis en train de rajouter 'java.io.NotSerializableException' un peut partout.

Mais j'ai un petit problème je tombe là dessus :

Code:

---

java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: com.baka.JTextComponent$1

---

quand il n'y a pas le '$1' çà va, je sais ce que je doit faire, mais là que signifie ce '$1' ? quel pourrais être l'objet non sérialisable ?


Merci.

PS : ces tests sont là pour voir si la piste RMI est viable ou s'il faut que je parlemente très fort avec mon supérieur pour favoriser un dev J2EE

Il s'agit d'une classe anonyme définie dans com.baka.JTextComponent

Rassure moi, tu n'essaies quand même pas de sérialiser des JPanels et autres composants SWing pour les transférer par RMI ?

Ben je pense que si, c'est ce qu'il fait :P

Ou on fait un truc propre et donc forcément, ça prend plus de temps, ou on fait du bidouillage, c'est rapide, mais faut pas en demander plus (pas d'évolution et attention en cas de bugs...).

:D et ba si :oops:

justement, on me demande un truc rapide et que ne devrait pas être utilisé longtemps (enfin çà c'est le papier, en général un truc qui doit durer 2 jours sera utilisé 10 ans et il faudra magouiller un max pour le maintenir)

Mais bon ba le monde de l'entreprise est bien souvent éloigné de l'idéal du développeur.

Donc je sérialise des JPanel et bien d'autre trucs suivront si çà 'passe', je sais que c'est moche mais j'y peut pas grand chose :roll:

Bon, j'ai bien une classe anonyme dans mon code :

Code:

---

DataListenerI _dataListener = new DataListenerI(){....};

---

DataListenerI étant une interface, comment on rend _dataListener sérialisable ?

Explique un peu ce que tu cherches à faire, car je crois que je n'ai pas compris.
Tu veux sérialiser les éléments de ton inferface Swing pour les transférer par RMI et les afficher sur le poste du client ?
Si c'est cela, quel est l'intérêt ?
Autant que le client ait l'interface graphique et que tu ne transfères que les données.

en rajoutant "implements Serializable" au bon endroit ?

Bon courage pour ta bidouille :lol:

fr1man, le but c'est de faire un client très léger niveau ressources mémoires et proc avec un minimum de modification dans le code existant, donc je pensais utiliser la réflexion et rmi pour transférer certaines parties de l'ihm (le client léger ne proposera qu'un certains fonctions de ce que sait faire le client lourd).

Et donc comme l'idée c'est de coder le moins possible le client léger, donc éviter de décrire l'ihm dans ce client, puisque çà changerais pas grand chose sinon.


Je sais que les besoins sont louches et encore plus la façon de coder, mais comme j'ai le côté J2EE (ce qui serait le mieux à faire) est pour le moment à proscrire.

Je suis un peu sceptique.
Déjà, on ne peut pas vraiment parler de client léger, dans le sens où le client aura une application Swing sur son poste, même si elle est réduite en fonctionnalités.
Je ne vois pas en quoi les performances seraient meilleures avec cette approche.

on va dire plus léger que le programme complet ;)

mais si tu as autre chose de mieux (hors J2EE, j'ai déjà proposé et pour le moment çà passe pas :?) je suis preneur

Disons que pour moi, il y a deux cas:
- la machine de ton client ne peut pas faire fonctionner une application swing dans de bonnes conditions, car elle est trop ancienne (je demande quand même à voir la machine en question): dans ce cas là, on peut effectivement penser à une application web.
-la machine de ton client peut faire fonctionner une application swing: dans ce cas là tout va bien.

et ba je sais même pas ce qui devrait faire tourner le 'client léger'

En fait, l'application lourde, affiche une carte en vectoriel, et prend en mémoire environ 300Mo pour la carte.

Et je sais que déjà les machines que executent ce programme sont déjà à la ramasse pour l'utiliser exemple avec ma machine de dev, on doit mettre environ (depuis certaines optimisations) 45 secondes à lancer l'appli, sur les machines du client çà doit tourner aux alentours de 5 mins.


Donc on cherche plus léger, mais bon je viens de tester depuis ce matin de transférer par RMI le panel qui contient la carto, et déjà il faut que je serialise toutes les classes qui ne le sont pas, et y en a beaucoup trop .... et puis récupérer l'objet est super long, et çà change rien au problème en fait, on récupère l'objet tels qu'il est de l'autre côté, donc il prend la même place en mémoire.

La solution serait peut être de convertir en image la partie à afficher et ne transmettre que çà, mais à ce moment je vais avoir plein de code à rajouter, puisque cette carte est intéractive avec des objets cliquables....


pfff, je suis mal barré.

Citation:

---

La solution serait peut être de convertir en image la partie à afficher et ne transmettre que çà, mais à ce moment je vais avoir plein de code à rajouter, puisque cette carte est intéractive avec des objets cliquables....

---

Peut-être qu'en compressant bien les images, ça devrait pouvoir passer, mais effectivement, tu vas avoir pas mal de code à rajouter.

Dans ton cas, le passage en mode ne changera pas grand chose, car tu devras également faire transiter les images.

Bon ba suites aux tests, ce 'projet' est mis pour le moment en standby (pour plus tard peut être du J2EE).

Donc merci beaucoup de votre aide.

Je résume pour ceux qui seraient intéressés par ce genre de manip : RMI ne semble pas trop adapté au transfert de composants graphiques lourds, c'est faisable, mais du point de vue mémoire çà change pas grand chose, et la désérialisation est très longue et lourde du point de vue processeur.