Valtech et le client riche


J'ai assisté aujourd'hui à un séminaire d'une demie-journée sur le "Client Riche" organisé par Valtech Training. Je dois dire qu'à mes yeux Valtech a toujours cette image de précurseur compétent. Là il s'agit d'un sujet difficile à traiter de manière exhaustive. La gratuité de ce séminaire très suivi (80 personnes?) rend l'exercice de style plus périlleux encore,  certains étant plus là pour voir comment est traitée sa technologie fétiche par rapport aux autres (je suis bien entendu un peu dans ce cas) beaucoup plus que pour apprendre (cas des formations traditionnelles).

C'est donc Denis Peyrusaubes, consultant formateur chez Valtech qui s'y est collé pour faire face à cette auditoire. Les sujets traités sont nombreux: historique/introduction (un peu longue), évolution navigateurs et technologies web, flash et ses dérivés, Java, Eclipse RCP et middleware de communication, le tout avec beaucoup (trop?) de démos d'illustration. L'absent de l'agenda était XUL, mais le sujet a été traiter en fin de séminaire. Ci-dessous quelques remarques et réflexions inspirées par cette présentation.

Dans les démonstrations qui montrent l'évolution des navigateurs et des technologies web (HTML, CSS, JavaScript, DHTML, ...), il ne faut pas oublier d'observer la qualité des développements. Il y a peu de temps (quelques mois), tout le monde développait pour Internet Explorer dont on connaît les limites dans l'implémentations des standards et ca reste encore généralement le cas en entreprise.

Denis parle d' "accessibilité" pour faire référence à la facilité de déploiement. C'est pas un terme très heureux, mais le problème est réel et la différence entre un client lourd et léger tient essentiellement dans sa facilité à être déployé. Evidemment, un problème fondamental est de vendre le client riche à son management qui ne jure encore (et pour quelques années encore) que par le client "léger" (un navigateur). Pourtant la productivité et la simplicité des clients Web n'est pas au rendez-vous. C'est d'ailleurs probablement le meilleur angle d'attaque.

Applets: elles ont plein de défauts (disponibilité de la bonne version de JVM), mais pas celui d'avoir des problèmes de sécurité (Denis, il faut qu'on en parle)! A noter que dans la présentation, les technologies Java sur le poste client ont été regroupées sous l'appellation de Java Web Start qui n'est réellement qu'un moyen de déployer des applications Java (pas des applets). Les applets ne sont pas caduques pour autant: elles servent dans un flux d'enchaînement de pages web (pour signer des données saisies dans des formulaires par exemple). Les applets peuvent être mises en cache (ce n'est pas réservé aux applications déployés avec Java Web Start). Simplement avec Java 5, ce mécanisme de cache (et son administration) est unifiée. Le "conteneur" c'est plutôt la JVM, pas Java Web Start.

Sur le sujet AJAX, il est intéressant de noter que le message d'encapsulation de la partie JavaScript (difficile à écrire et à débugger) doit être encapsulée dans des composants est bien passé. Je doit montrer à Denis la démo JSF/AJAX dans Sun Java Studio Creator et (sur un sujet proche) lui parler de xulfaces d'Olivier Schmidt. Un intérêt naturel, mais pas réellement exprimé c'est qu'avec AJAX, on a la puissance d'un serveur (mémoire, CPU) en ligne. La contrainte, c'est que la technologie qui met AJAX en oeuvre doit couvrir la couche de présentation et la couche d'accès aux services. C'est ce que propose Java EE (ex-J2EE) et JSF en particulier. Pour ceux qui s'intéressent au sujet, il y a des Blueprints sur AJAX et Java EE.

Flash (Flex et Laszlo) est certainement très intéressant grâce à sa relative ubiquité (même si 95% des postes sont équipés en plugin Flash, tous ne sont pas dans la bonne version, mais le runtime à installer est assez léger). L'image de technologie d'animation véhiculée par Flash et son coté propriétaire reste à mon sens un frein important (cf. post précédent). Flex, c'est Flash + back-end Java EE. La question est de savoir si Java EE (avec JSF+AJAX) n'est pas suffisant.

Le constat naturel est que l'approche de description déclarative en XML d'une IHM est très répandue (mais pas encore très utilisée). Cette approche a des limites dans son expressivité (pas forcement mises en évidence dans des applications de gestion simples) ce qui explique l'approche en couche de JDNC: Extensions à Swing -> Composants de plus haut niveaux, Langage XML de description. Chaque couche étant construite sur la précédente. Plus de détails sur JDNC ici

Eclipse RCP (qui est Open Source quoi qu'en dise Denis...) est une bonne idée ne serait-ce que par son approche modulaire, mais il s'agit d'un conteneur d'applications, pas de la technologie pour écrire ces applications: SWT. Il n'apparaissait pas dans la présentation quelque chose pourtant d'essentiel, les développements et compétences Swing ne sont pas recyclables dans Eclipse RCP. Par contre NetBeans Platform (écrit lui en full-Swing, modulaire et Open Source) ne présente pas cette restriction lourde (sans parler d'une certaine maturité en faveur de NetBeans). Dans la mesure ou la capacité de déploiement d'une solution est critique, la présence de SWT a des conséquences non-négligeables (qui va déployer les DLL et autres .SO? Ces bibliothèques partagées existent-elles sur toutes mes plate-formes cibles? Qui les supporte?). Sur le sujet de la modularité (versionning et dépendances) des développements (qui ne s'applique qu'à partir d'une certaine taille d'application), il y a le JSR 277.

Quelques points non-traités (suggestions d'améliorations?):
- Impact de ces technologies sur le trafic réseau (ex: AJAX vs. données "en dur" dans la page).
- Complexité relatives des développements entre les différentes technos. Courbe d'apprentissage, coût de maintenance, ... Besoin de retour d'expérience et de métriques.
- Le besoin de notification ou de mode déconnecté impose certaines technologies (ou en exclu d'autres). C'est un point d'aiguillage important.
Fast Infoset (Fast Web Services) est la solution initiée par Sun pour résoudre le problème de verbosité des Web Services (question dans l'assistance).

Maj: l'autre remarque que je me faisais, c'est qu'avec la présentation de toutes ces technologies, XAML de Microsoft n'a été traité qu'en fin de séminaire dans un seul slide. Le poste de travail c'est pourtant encore la chasse gardée de Microsoft. Finalement, la portabilité et le "Write Once, Run Anywhere" de Java d'il y a 10 ans continue de se vérifier...

Maj2: C'est finalement peut-être pas étonnant de voire qu'il y a 12 raisons pour lesquelles les Entrepreneurs Web 2.0 n'utilisent pas la technologie Microsoft...

Cet après-midi c'est EJB avec Sun, JBoss et nombre de consultants Java dans la salle... Quand je vous dis qu'il faut une forme de courage pour faire ces séminaires! ;-)

Comments:

Du courage il en faut sûrement mais tu nous donnes au moins la possibilité d'avoir quelques infos intéressantes :)

Posted by Romain Guy on septembre 24, 2005 at 05:50 AM CEST #

Bonne présentation, Mais comme d'habitude, on ne parle pas des solutions existantes et mature comme la notre http://www.xwidglets.com cela sera peut être évoqué lors de la table ronde du forum intégration de 24 novembre ;-) Dans tous les cas, comme dit romain du courage il en faut et merci pour les infos.

Posted by pierre dezon on novembre 04, 2005 at 10:48 AM CET #

merci pour ce retour très instructif meme 1 an après...

Posted by Nadir on mai 06, 2006 at 07:40 AM CEST #

Post a Comment:
Comments are closed for this entry.
About

This blog has moved

Alexis Moussine-Pouchkine's Weblog

GlassFish - Stay Connected

Search

Archives
« avril 2014
lun.mar.mer.jeu.ven.sam.dim.
 
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
    
       
Today
Blogroll

No bookmarks in folder

News

No bookmarks in folder