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! ;-)

Author: alexismp

Google Developer Relations in Paris.

3 thoughts on “Valtech et le client riche”

  1. 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.

Comments are closed.