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…

Mots-clés: ,

7 commentaires pour “RIA vs RDA en Java : quoi de neuf en 2008?”

  1. Merci pour ce post intéressant …
    Quelques points me semblent cependant aller trop vite dans votre analyse, qu’en pensez-vous ? :

    * ‘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’
    Effectivement la question est difficilement formulable en ces termes pour la simple raison que les solutions RIA sous toutes leurs formes (Browser mainstream, spécifique, embeded runtime…) se veulent résolument indépendante de la technologie serveur. Le RDA Java (aka, Swing, SWT etc..) c’est à contrario seulement le prolongement de la philosophie Java sur le desktop.
    A mon sens la question du RDA vs RIA doit se poser à l’échelle des besoins et des enjeux utilisateurs sous-jacent, indépedamment des technologies d’implémentation.

    * ‘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 ?’
    ‘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’
    Comme indiqué c’est natif, structurel des applications RDA de pouvoir offrir des modes offlines. S’il n’y a pas de framework c’est qu’il n’y a pas de besoins identiques, de récurrences forte et/ou qu’il n’y a pas de difficulté majeure à réaliser une implémentation qui somme toute peut être spécifique aux besoins d’une application particuliére, d’une fonction particuliére de cette application.
    A l’inverse, le RIA part nativement avec un handicap sur ce terrain, tente de faire émerger des patterns, des implémentations parceque l’effort à fournir pour une application donnée est insurmontable autrement (sans l’aide de l’industrie officielle ou officieuse). D’où l’émulation sur ces sujets.

    * De la productivité/efficacité/complexité
    Alors RIA ou plutôt HTTP + Browser Engine spécifique +Modules externes + Ajax + Comet + Solution serveur + ….. serait moins complexe que RDA (Swing) ? Pire serait plus productif ? La je le crois objectivement pas. Je crois au contraire et c’est une tendance des solutions mainstream ces 10 dernière années dans la rupture de paradigme (Browser, Engine, MVC, Objet, Relationnel) au sein d’une même application. Sous cette angle l’analyse de la productivité, complexité, efficacité entrainerait des conclusions à mon sens différentes

    * ‘En conclusion Aujourd’hui, le RDA-Java apparaît …niche..’
    Pour toutes les raisons précédentes, je ne le crois pas et pense au contraire (mais là ce n’est pas le moment :) de l’exposer) que c’est une solution qui s’inscrira dans les véritables innovations (matérielles et logicielles) à venir…

    A+

    MAC

  2. Merci pour tes commentaires. Mes réponses aux différents points :

    – …c’est bien l’enjeu de ce post! Techniquement, la frontière est de plus en plus floue et donc c’est selon 3 critères fonctionnels / d’usabilité (ergonomie/puissance de l’IHM, support du déconnecté, interaction poste physique) que je cherche à présenter le problème

    – sur l’offline, place toi du point de vue utilisateur (comme tu le suggères toi-même!): peu importe la techno, j’ai des use cases métier qui font que j’ai besoin de pouvoir passer d’offline à online et gèrer des synchronisations. Du coup, je persiste dans mon propos : le RDA dispose de capacités natives par contre je n’ai pas de frameworks pour gèrer ces synchronisations de données ou pour stocker une pile d’appels. En RIA, je ne l’ai pas encore non plus mais je fais le pari que la stimulation intellectuelle qui règne fera émerger de telles solutions du fait de ce handicap structurel

    – concernant la complexité, aujourd’hui si je fais du Flex j’ai ? ma disposition dans un framework intégré avec une ergonomie puissante + de l’outillage me permettant d’être productif (accessoirement du push serveur) et l’infra de fonctionnement (plugin + stack de protocole serveur) m’est fournie. La question des compétences se pose par contre également, je te le concède. De même, si je fais du GWT, je code tout en Java et j’ai éventuellement besoin de Gears pour faire du offline mais je sais faire des IHMs puissantes – et niveau productivité, je suis pas mal aussi.

    Enfin, si j’ai besoin d’ergonomie puissante + offline + interaction poste client sans mode de contournement possible, pour moi on est bien dans la case ‘environnements très contraints’ (la niche!) qui font que je partirais sur une solution comme RDA. Attention, mon propos n’est pas ‘RDA c’est nul’ (ce qui est le contraire de ce que je pense) mais plutôt ‘repensez les raisons qui font que vous partez sur du RDA’.

  3. Beau billet, mais je suis plutôt de l’avis de Mac. J’aimerais également ajouter un petit mot sur Java Web Start. Faire une comparaison de RIA et de RDA sans parler de Java Web Start c’est comme faire une tarte aux Mirabelles sans.. Mirabelles :)

    L’une des raisons qui a fait adopter les RIA en entreprise est le mécanisme inéxistant d’installation sur le poste client.

    Grâce à Java Web Start, on est capable de faire des applications qui peuvent effectuer des algorithmes complexes sur le poste client tout en ayant une facilité d’installation qui se rapproche des applications légères.

    Philippe

  4. Tu as le droit de ne pas être d’accord ;)

    Tu remarqueras que je n’ai pas mentionné de critère ‘mode de déploiement’ comme discriminant entre RDA et RIA: c’est parce que, comme tu le suggères, Java Web Start a réglé le débat et mets RIA & RDA sur un pied d’égalité concernant ce critère!

  5. Je ne résiste pas !

    privatelab.blogspot.com/2…

    Cela date de 2005, mais je trouve que la situation est toujours aussi floue. A cela près que la maturité de Swing (versus les autres frmk) est indiscutable.
    Ce que l’on pourrait ajouter pour remettre à jour, c’est la dimension ‘mobile’ de l’IHM. Pas sûr que le RIA soit mieux positionné que le RDA.
    Un seul exemple: les applications iPhones, sont des clients lourds; pas en java, mais lourds quand même.
    Et la tendance – pour les applications mobiles – ne semble pas se porter vers le RIA.
    Si google continue à jouer son rôle de prescripteur, alors le futur est bipolaire: iphone à gauche, Android à droite et RIA pour les grands écrans et le hardware puissant.

    Laurent.

  6. Oui, je partage ton analyse.
    Et sur les terminaux mobiles les plus en vue, on peut noter que ce n’est pas Swing ni Java ME qui semblent prendre le dessus mais plutôt des SDK propriétaires comme celui de l’iPhone ou Android.

  7. http://www.pushing-pixels.org/?p...
    Un post encore plus radical : Sun considérerait Swing comme du ‘legacy’

Laissez un commentaire