RIA vs RDA en Java : quoi de neuf en 2008?

« Rich Internet Application » (en deux mots : architecture en client web) versus « Rich Desktop application » (en deux mots : architecture à base de client lourd 3-tiers) : un bon vieux débat classique de l’architecture applicative Java ! Lorsque l’on choisit un framework d’IHM, c’est souvent un passage obligé. Mais aujourd’hui en 2008, avec l’explosion d’innovations sur les solutions RIA qui ne faiblit pas après plusieurs années, on peut être tentés de se demander si cette question se pose encore, ou du moins si elle se pose encore en ces termes.

Tout d’abord quoi de neuf pour le Java RDA ? Aujourd’hui, si on regarde les progrès techniques en terme de packaging, d’enrichissement de frameworks ou de composants, on constate que l’effort s’est massivement déporté vers les technologies RIA. Sun et la communauté SWT / Eclipse ou de manière plus globale la « communauté RDA » a porté ses efforts sur :

• Les « Rich Client Platform » (Eclipse RCP et NetBeans Platform) : ces frameworks apportent aujourd’hui des solutions concrètes dans un cadre ergonomique bien défini (proche de celui d’un IDE, c’est-à-dire avec une approche « document-centric » avec des « vues » qui permettent d’avoir des angles de vision différents sur le « document »). Sur le papier, ces frameworks sont assez puissants, mais dès que l’on cherche à customiser l’ergonomie ou des points techniques (sécurité par exemple), la complexité augmente très fortement sachant que, de toute façon, elle est déjà bien élevée !
• Matisse et le GroupLayout : c’est pour moi LA vraie innovation de ces dernières années, avec l’introduction d’un vrai outil « WYSIWYG » pour le dessin d’écrans Swing. C’est opérationnel et ça marche : on a enfin un pendant crédible à ce qui se fait en .NET / Visual Studio depuis bon nombre d’années.
• Des enrichissements de Swing, à grand coups de JSR, qui finalement viennent à peine de sortir (ou devront attendre Java 7) et restent relativement frais et peu éprouvés. Ils viennent normaliser des choses qui tout bon framework Swing développé en spécifique adressait sans finalement une grande part d’innovation:
  • Le binding de données (JSR 295)
  • La validation des saisies(JSR 303)
  • La gestion d’un cycle de vie applicatif, avec les configurations et gestion des ressources (JSR 296)
• Le petit dernier : Java FX, qui est dans l’innovation pure et qui est encore loin d’être utilisable en entreprise. La question qui se pose est jusqu’où Sun va pousser cette solution ?

Si on repasse maintenant en revue les critères qui habituellement font pencher la balance en faveur d’une solution RDA, on trouve :

• L’ergonomie, pour la liberté totale en terme de puissance graphique et une réactivité (performance!) de l’IHM égale à celle de l’OS
• Le support d’un mode « déconnecté » (ou offline)
• La possibilité d’interactions avec le poste physique du client (le PC) sans contraintes de sécurité

Ergonomie ou « Ergonomie/ Puissance vs. Productivité / Complexité » Dans l’absolu, ce premier critère est toujours favorable au RDA puisqu’il garde toujours une courte tête d’avance en terme de fluidité, rapidité et possibilités graphiques par rapport au RIA. même si aujourd’hui beaucoup de technologies RIA cherchent à combler ce retard :

• En « trichant » via l’utilisation de plugins navigateur, ce qui les rapproche plus de technologies RDA (je pense à Flex ou Silverlight par exemple)
• Par le biais du navigateur, comme le montre l’initiative récente de Google avec Chrome et son nouveau moteur Javascript

Si les besoins d’un projet sont relativement standards en terme d’ergonomie, et que du coup l’objectif principal recherché est la productivité du développement IHM, finalement l’intérêt des technologies RDA Java reste limité, puisque les compétences ne sont finalement pas si faciles à trouver et que le surcoût de complexité peut être difficilement amortissable : on l’a vu ci-dessus, les innovations ne rendent pas le développement Swing « seemless ».

Si les besoins ergonomique du projets sont plus raffinés, avec une ergonomie « puissante » et à fortement adapter au contexte métier, l’investissement dans un framework est plus facilement justifiable. La plupart des entreprises pour lesquelles le choix RDA s’est justifié sont parties sur d’importants développements spécifiques, en développant la compétence interne Swing. Mon avis est que ces entreprises continueront à faire du sur-mesure, éventuellement en se basant sur les différentes innovations citées ci-dessus mais sans non plus refaire leur socle pour intégrer ces nouveautés : le jeu n’en vaut pas la chandelle et les nouveautés apportées par les différentes JSR ne seront pas assez « raffinées » pour ces contextes.

Support du mode déconnecté Là, il est vrai que la capacité à faire du déconnecté est une caractéristique « native » du RDA, qui vient avec un Runtime client. En même temps, il n’existe rien pour tirer partie de cette capacité native : quelle solution sur étagère pour synchroniser mes données? Pour bufferiser des appels de services lorsque je suis offlline et les dépiler (en gérant les erreurs potentielles!) lorsque je repasse online?

Dans le monde RIA des solutions (certes imparfaites) commencent à émerger (citons Adobe AIR ou Google Gears) et on peut donc espérer voir des patterns d’implémentation plus puissants suivre ces premiers pas. Côté RDA, silence radio.

Interaction avec le poste physique du client Encore une fois, c’est une capacité « native » du RDA qui ne souffre pas des restrictions de sécurité des solutions RIA. Mais finalement, dans une application de gestion, a-t-on besoin si souvent que cela d’accéder au poste physique ? Les cas les plus courants concernent l’interaction avec des périphériques (scanners, téléphone.) et, si en RIA on ne sait pas faire directement, il semble plus évident de

• Mettre en place une solution ad-hoc sur le besoin en question, à base d’un ActiveX par exemple, d’une extension du navigateur (plugin IE ou plugin Firefox) ou bien en interagissant avec le serveur en mode « polling »
• Et d’utiliser une technologie RIA pour tout le reste des développements

En effet, faire basculer le choix du RIA vers le RDA est lourd en terme de compétences, de complexité et de coût du framework à mettre en œuvre et il est sans doute plus efficace de réaliser un développement pointu sur l’interaction avec le poste physique (quitte à dégrader certains comportements si c’est acceptable) et de choisir une technologie RIA éprouvée pour développer l’ensemble des écrans.

En conclusion Aujourd’hui, le RDA-Java apparaît de plus en plus comme une technologie de niche, à mettre en œuvre dans des contextes très contraints et pour lesquels l’investissement initial en terme de framework et compétences peut se justifier. Même s’il faut saluer les dernières innovations citées au début de ce post, elles ne sont pas pour moi à même d’endiguer la déferlante RIA. Reste également l’alternative .NET, pour les contextes dans lesquels cela est possible/pertinent…