Choix d'architecture : client lourd vers appli web

Version imprimable

29/03/2010, 18h07
nonoRedDevils

Choix d'architecture : client lourd vers appli web

Bonjour!
Tout d'abord j'espere que je pose au bon endroit, si ce n'est pas le cas désolé ;)
Pour mon travail, je dois donc etudier les possibilités de deporter un client lourd en JAVA vers une appli web.
1/ Fonctionnement du logiciel
Pour faire simple, ce logiciel gère des boitiers tournant sur linux, en leur envoyant des fichiers de configurations. Il se connecte aux boitiers avec une connexion SSH avec certificat. Il peut aussi lire le fichier de configuration installé, ainsi que l'historique des fichiers. Il permet de créer plusieurs type d'objets, pouvant etre regroupés par repertoire. L'IHM contient donc des champs de bases (checkbox, combo box, etc..) mais aussi des zones de drag 'n drop où l'on peut referencer un objet.

2/Structure des données
Les fichiers de configurations (qui peuvent etre ouvert aussi sans etre connecté à un boitier), sont au format XML et leur structure est basée sur un ensemble de fichier XSD.
On utilise ce meme ensemble de fichier XSD pour décrire l"IHM, via XmlBeans qui genere à la volée le "rendu".

3/Idées pour l'appli web :
- Partie metier :
Actuellement c'est une application client <-> server. Je pensais mettre le server web entre les deux, il aura pour charge, entre autre, de lire le fichier de configuration installé sur le boitier, le parser, et générer l'IHM Html. Et inversement, recevoir les modifications, les stocker et les envoyer au boitier.
Est ce qu'un serveur Web peut lancer des commandes unix simplement? Je suppose que oui...mais comme je n'ai pas encore recherché....
- Partie GUI :
Je pensais pouvoir faire une feuille de style transformant le XML en HTML, mais vue la complexicité du schéma, la feuille XSL serait monstrueuse! Je pensais générer l'IHM directement par le code JAVA.

J'ai fait un tour rapide des technos pouvant repondre à ma problématique, à priori JAXB serait un bon début, pour faire le lien entre XML-JAVA. Pour ce qui est des composants GUI un peu complexe comme les zones de drag'n drop, j'ai vu que l'AJAX pouvait etre aussi une bonne option.
Voilà, j'espere avoir été assez claire, et pas trop verbeux! j'aimerais avoir vos avis sur les idées que j'ai émises, et si vous avez deja été confronté à cela, ca me serait tres utile !
Dans un soucis de confidentialité, je ne pourrais pas non plus préciser certains point de ce logiciel, j'espere que vous le comprendrez.
Merci :)
07/04/2010, 21h06
joseph_p

bonsoir

Personnellement, je commencerai par me demander si le désir de transposer directement l'interface client lourd en web est possible.

En effet, la navigation web et l'utilisation du web sont bien différent du client lourd. Les différences sont d'ailleurs tant dues à l'html qu'au côté java.

Par exemple, le web permet le retour arrière, utilise de multiples conventions tirées uniquement du web (peu de fenêtres modales, pas d'empilement de fenêtre, construction du menu et de la navigation très différente, menus contextuels rarissimes, complexité des différences entre navigateurs, problématique des touches de raccourcis, problématique de la session).

De même, la navigation est généralement plus lente sur du web, vu que les couches sont plus nombreuses et moins spécifiques : il faut, côté serveur, assembler un fichier html, le transmettre via le réseau, puis là le navigateur va devoir interpréter tout cela puis l'afficher. Pour avoir travaillé sur des transitions client/ lourd/web, cela fait une vraie différence.

Côté java, en web tous les clients se partagent le même serveur. Si l'architecture client/serveur actuelle repose en partie sur des calculs ou du stockage d'objets Java côté client, cela également est à reconsidérer.

In fine, la réutilisation telle quelle de l'interface me parait bien hasardeuse. La réutilisation du code Java étant elle sujette à caution et mérite probablement un approfondissement afin d'éviter de mauvaises surprises.
09/04/2010, 15h08
nonoRedDevils

En fait là, j'ai fait un brin de maquette :
- serveur tomcat
- librairie java contenue dans jar, generé par xjc à partir du xsd
- servlet qui fait une boucle sur une liste d'objet

rien que ca, ca m'a permis de voir que l'on peut recuperer une partie de la couche metier deja developper (et encore il me reste des tests à faire).

En faisait un rapide tour des solutions ihm pour appli web, j'en ai conclu rapidement que l'interface du client lourd telle qu'elle existe ne pourrait pas etre porter comme cela (basée sur le drag 'n drop, et le clic droit), et donc qu'il faudrait prendre le probleme à l'envers :
avec les moyens du "web" comment configurer mes boitiers
14/04/2010, 15h13
nonoRedDevils

Je me suis orienté vers gwt pour ce qui est de l'ihm (pour le code métier, j'ai fait des tests avec de simple servlet, j'arrive à faire quasiment tout ce que je veux avec mes fichier de données), et ca a l'air tres prometteur, bien qu'il faille se palucher à la main tous les panneaux.. :cry:

En regardant de plus pres mon appli actuelle, voici comment est genérée l'ihm :
- parsing des schema xsd par une feuille xsl
- pour chacun des simpleType xsd on a une class java "hard codé" par exemple pour les champs textes
- pour les champs complexes, ce n'est qu'une "simple" agregation d'objet simple
- chacun des objets complexes est lié au noeud xml correspondant au fichier de données

même si c'est un peu floue pour moi, ca ressemble grosso modo à ca.

Ma question, est de faire plus ou moins la meme chose avec gwt, mais ca existe peut etre déjà ou est ce completement debile/infaisable ?
;)
14/04/2010, 15h43
Jimmy_

Drag&Drop sur le clic droit en client léger ce n'est juste pas possible, il te faut réflechir à une autre ergonomie.
14/04/2010, 16h17
nonoRedDevils

Citation:

Envoyé par Jimmy_

Drag&Drop sur le clic droit en client léger ce n'est juste pas possible, il te faut réflechir à une autre ergonomie.

oui je sais c'est ce que j'ai mis dans mon second message :

Citation:

En faisait un rapide tour des solutions ihm pour appli web, j'en ai conclu rapidement que l'interface du client lourd telle qu'elle existe ne pourrait pas etre porter comme cela (basée sur le drag 'n drop, et le clic droit), et donc qu'il faudrait prendre le probleme à l'envers :
avec les moyens du "web" comment configurer mes boitiers
14/04/2010, 16h22
Jimmy_

Citation:

Citation:

Envoyé par nonoRedDevils

oui je sais c'est ce que j'ai mis dans mon second message :

avec les moyens du "web" comment configurer mes boitiers

Une applet ... :aie: tu gardes l'érgonomie client lourd et tu es sur du web. Si ton responsable de sécurité ne met pas son veto.
14/04/2010, 21h24
nonoRedDevils

Citation:

Envoyé par Jimmy_

Une applet ... :aie: tu gardes l'érgonomie client lourd et tu es sur du web. Si ton responsable de sécurité ne met pas son veto.

euh...j'ai dit precedent que les moyens utilisés pour l'ergonomie (drag 'n drop, menu contextuel) ne sont pas necessaires :roll:

pour ce qui est de l'applet : no! choix technique refusé par ma direction (et accessoirement par moi)

je repose ma question sur gwt :
est ce qu'il existe un framework, une api (autre?) qui genere des composants graphiques GWT à partir de schema XSD?

je vois assez bien comment le faire à la main, mais ca risque d'etre monstrueux
:roll:
21/04/2010, 10h14
nonoRedDevils

Citation:

Envoyé par nonoRedDevils

est ce qu'il existe un framework, une api (autre?) qui genere des composants graphiques GWT à partir de schema XSD?

je vois assez bien comment le faire à la main, mais ca risque d'etre monstrueux
:roll:

apres quelques recherches j'aurais besoin de faire du data binding :
à chaque modification d'un champ via l'interface web (ie. widget gwt), il faudrait modifier le xml qui est chargé (par le fichier en lui meme). Et plus largement repercuter les limitations sur les champs de mon fichier xsd, comme les tailles max, min, pattern, valeur des combo box etc..etc..
Merci bien ! :P;)