Poursuivons l'analogie et constatons qu'à l'instar de l'histoire humaine chaque évolution informatique apporte son cortège de bénéfices mais aussi quelques régressions.
Ainsi, si le client-serveur a permis il y a une dizaine d'années de mettre en place des applications départementales aux IHM (autrement dit les interfaces) séduisantes, cela s'est fait au détriment des performances, effaçant d'un coup des années de laborieux progrès. Souvenez-vous des applications SQL*Forms3 en mode caractère, certes austères mais rapides. Quelle frustration de passer par la suite aux premières applications Powerbuilder (ne parlons même pas de Forms 4), belles mais lentes. Heureusement, au cours des mois qui suivirent, des optimisations permirent de passer au client-serveur de 2ème (puis de 3ème) génération et tout rentra dans l'ordre.

Le répit fut de courte durée.

L'émergence du Web annonce le retour des IHM pauvres
L'émergence du Web ouvrit le champ des applications universelles et ce fut de nouveau le cauchemar avec le retour des logiciels hyper-lents aux IHM ineptes.

Il faut dire que le cahier des charges était contraignant (accepter un grand nombre d'utilisateurs sur de multiples O/S, sans déploiement, et passer à travers les firewalls) et fit porter sur ce pauvre navigateur HTML des responsabilités insoupçonnées à sa création.

Les premiers bidouillages technologiques pour générer des pages dynamiques passèrent par les CGI, l'enrichissement des IHM s'accommoda de Javascript et (moins bien) des applets Java, et on obtint en fin de compte des applications jetables, difficilement maintenables.

Parallèlement à l'arrivée depuis trois ans de solutions plus élégantes et plus professionnelles (serveurs d'applications, servlets / JSP), le besoin lui-même a évolué, d'applications grand public purement web à des solutions d'entreprise intranet puis extranet, voire ASP (Application Service Provider).

L'offre J2EE se banalise mais les IHM sont toujours inadaptées aux applications d'entreprise
On est aujourd'hui bien engagé sur la voie de la maturité avec la banalisation de l'offre J2EE (réduction des coûts, vivier de compétences, serveurs open source) offrant une plateforme technologique ouverte, fiable et aisée à mettre en oeuvre.

Pourtant, il n'y a toujours pas matière à être pleinement satisfait, que ce soit d'un point de vue utilisateur ou développeur, et les griefs se tournent essentiellement vers l'IHM : ces écrans HTML offrent toujours un affichage et une dynamique aussi limités, agrémentés de performances insuffisantes en raison des incessants aller-retours vers le serveur.

Oui, mais quelle alternative proposer ?

Revenons aux écritures, j'entends par là aux fameux "J2EE blueprints" qui présentent les patterns architecturaux des solutions basées sur un serveur d'applications J2EE.

Le plus connu est certes le pattern du client léger servlet / JSP sur HTTP (diagramme ci-dessus, option 1). Une autre configuration proposée pour des applications départementales est la solution client lourd Swing sur RMI / IIOP (option 2).

La maturité de Swing
Contrairement aux idées reçues, il existe aujourd'hui un grand nombre d'applications professionnelles Swing, même si on les prend souvent pour des applications Windows. Prenons par exemple JBuilder, Idea, PVCS, toutes ces applications complexes sont écrites en Swing.

Il est loin le temps où les implémentations Swing (et à fortiori Java) étaient lourdes et lentes. Depuis le JDK 1.3 on peut considérer les performances de Swing comme tout à fait satisfaisantes.

Deux obstacles pour le client lourd : déploiement et firewall
Les principaux écueils pour créer des applications J2EE à client Swing se résument en ces deux mots : déploiement et firewall. Il est en effet hors de question de devoir déployer manuellement une application en extranet, de même que je ne connais aucun responsable d'un réseau d'entreprise qui accepterait d'ouvrir son firewall à IIOP !

Heureusement les solutions existent.

Webstart pour déployer automatiquement
l'apparition de JNLP et de Webstart a permis depuis deux ans déjà d'automatiser le déploiement des applications Java pour tout utilisateur disposant sur sa machine (quelqu'en soit l'O/S) d'un JDK et du bootstrap Webstart. Lors du premier lancement, l'application cliente est automatiquement téléchargée par HTTP sur le poste de l'utilisateur, et chaque nouvelle utilisation lancera l'application locale tant que sa version est à jour (sinon la mise à jour sera automatiquement effectuée).

Ce premier obstacle étant écarté, intéressons-nous maintenant aux aspects protocole.

Le JCP (Java Community Process) propose l'emploi de SOAP pour les échanges inter-applicatifs sur HTTP. Ce protocole nécessite de lourds traitements de sérialisation XML et ses performances sont bien trop insuffisantes pour des échanges client - serveur, quoi qu'en dise Microsoft qui soutient cette solution pour sa plateforme .Net.

Du Swing sur HTTP
Heureusement, la problématique RMI sur firewall peut aisément être contournée par l'utilisation d'une couche transport HTTP, ceci par exemple à l'aide d'une servlet encapsulant les appels RMI (comme le propose le framework open source de Bright Side Factory).

On dispose ainsi désormais d'un pattern architectural particulièrement adapté aux applications intranet, extranet et ASP : du véritable 3-tier combinant serveur J2EE et IHM riches et flexibles.

Des applications d'entreprise rapides aux IHM riches grâce à J2EE et Swing
Les avantages du couple J2EE / Swing sont multiples.

L'adoption d'un client lourd permet au serveur de se concentrer sur le code métier, tandis que le client est en charge des aspects présentation, contrôle et validation. D'autre part, il est possible d'établir un cache client, ceci toujours dans le but de minimiser les roundtrips serveur et par conséquent s'offrir des bonnes performances.

Du point de vue du programmeur, celui-ci peut se concentrer sur du code client élaboré, sans pour autant devoir posséder une connaissance approfondie de l'API Swing depuis l'apparition des frameworks applicatifs basés sur Swing et manipulant des widgets de haut niveau.

Alors, maintenant que tout est en place pour l'émergence d'applications d'entreprise à client lourd Swing, va-t-on enfin effacer les régressions historiques du client léger et profiter pleinement de l'extraordinaire potentiel des applications 3-tier ?

Liens :
J2EE blueprints : http://java.sun.com/blueprints/
Webstart : http://java.sun.com/products/javawebstart/