AJAX sur la route de la SOA. (22.9.2005)


L'un des "tags" les plus populaires sur le site del.icio.us ces derniers temps est mystérieusement le nom "AJAX". (On peut d'ailleurs en voir graphiquement l'évolution sur l'extraordinaire site cloudalicious.)


Loin d'indiquer un engouement soudain pour le héros homérique ou un intérêt approfondi pour les détergents ou pour un club de football hollandais, cette popularité reflète le volume croissant de discussions techniques sur forums et blogs, dans les séminaires et dans les conférences diverses (dont "Web 2.0" organisée dans 2 semaines, à San Francisco, par l'éditeur technique O'Reilly) sur l'architecture des applications Web.


Car il apparaît bien que l'architecture des applications Web fait encore débat !


On aurait pu croire que la cause entendue avec l'immense travail de spécification technique et l'effort massif de vulgarisation marketing des grands éditeurs de logiciels, entamé dès la publication de XML comme recommandation du W3C en 1998, pour aboutir à une définition et une implémentation des Services Web.


Au fait, lorsque l'on examine l'ensemble des différentes spécifications qui constituent l'univers des Services Web -- certaines stables et "embarquées" dans la génération moderne d'outils de programmation et de développement, d'autres encore en suspens ou en attente d'implémentation de référence -- il n'est guère surprenant d'y retrouver, traitées avec XML et la gamme des spécifications connexes édictées par le W3C, toute l'expérience accumulée par les précédents praticiens de l'architecture client-serveur puis de l'architecture d'objets distribués (créée en 1991, l'OMG est toujours présente sur le front des technologies, qui, sa mission une fois accomplie sur CORBA, s'est lancée dans la promotion de MDA, "Model Driven Architecture"). Ces styles d'architecture antérieurs sont nés et ont mûris dans l'environnement de l'informatique d'entreprise et visent à délimiter précisément les processus du cycle de vie d'une application d'entreprise dans son système d'information. À ce titre, on peut lire tout le courant de recherche et de développement qui porte les Services Web comme une tentative de récupération du Web (et de ses avantages économiques évidents : ubiquité, coût d'accès faible) par l'informatique d'entreprise : une sorte d'acclimatation des protocoles et des standards rendus populaires par le Web à l'écosystème des applications d'entreprise.


Et ça marche ! Maintenant à peu près centralisé dans des consortium comme le W3C ou OASIS, le travail de spécification des Services Web, la R&D pourrait-on dire, se stabilise autour d'un ensemble de notions généralement acceptées. De même les grands éditeurs de logiciels et des nouveaux arrivants issu de l'Open Source s'activent à fournir des implémentations de référence et des outils de développement en simplifiant la mise en oeuvre. La concomitance de l'arrivée dans les entreprises d'une génération de développeurs formé avec le Web et Internet laisse augurer d'une adoption banalisée de l'architecture SOA (Service Oriented Architecture) qui sous-tend les Services Web.


Mais il y a plus que l'informatique d'entreprise dans l'avenir du Web !


Les limites de cette vision selon laquelle le Web ne resterait qu'un outil supplémentaire, mais envahissant, de la panoplie de l'urbaniste des systèmes d'information et du développeur d'applications d'entreprise apparaissent de tous bords, plus nombreuses chaque mois. Google, en particulier, se pose comme alternative, à la fois technique et media, à cette perspective disciplinée, "business-as-usual", d'une architecture de SI d'entreprise étendue par le Web certes, mais maîtrisée rationnellement. (Personellement, il me semble que Microsoft et IBM l'ont très bien compris qui y voient l'annonce d'une invasion de leurs plates-bandes historiques, cf. la réorganisation annoncée hier de Microsoft et l'effort massif d'IBM vers l'Open Source.) Le succès incomparable du "Jeune Turc" Google ne doit pas non plus faire oublier la multiplication des idées individuelles ou de communautés très actives et influentes autour du nouveau modèle d'architecture symbolisé par le terme "AJAX".


Ce terme, pas vraiment un acronyme, n'a pas de définition extrêmement précise, mais Wikipedia suggère "Asynchronous JavaScript and XML" qui capture bien l'essence du modèle d'architecture. Tout part d'un retour à la base sur les protocoles Web : classiquement, un navigateur Web établit une connexion avec un serveur Web (HTTP) et demande la transmission d'une page HTML, qui est ensuite affichée sur le poste client. Un aller-retour, une demande et une réponse, quoi de plus basique, en effet ? Evidemment il faut prévoir quelques "exceptions" lorsque la page n'existe plus ou quand la connexion n'aboutit pas, mais rien qui ne change la nature synchrone de l'échange. Le navigateur envoie une demande simple d'une page et le serveur exécute tous les traitements. Ce qui, au passage, signifie qu'en théorie chaque fois qu'une information supplémentaire est requise du côté client, une nouvelle demande de page est envoyée au serveur qui ré-exécute des traitements avant de renvoyer les données suivantes. S'ensuit donc une séquence synchrones de demandes du navigateur client, de traitements sur le serveur et de retours de résultats vers le navigateur client en attente.


Or quatre innovations technologiques majeures ont été, au fil récent des années, incorporées dans le dispositif et sont à l'origine de l'architecture AJAX :

1) Les navigateur Web embarquent tous plus ou moins un interpréteur JavaScript permettant l'exécution de traitements dans le navigateur client lui-même (soit avant, soit pendant, soit après l'affichage d'une page).

2) Le W3C a stabilisé les spécifications de DOM ("Document Object Model") un représentation programmable d'une page Web que l'on peut manipuler, entre autres, directement avec JavaScript.

3) HTML s'est enrichi de nombreuses extensions liées à la présentation de la page (cf. CSS, XHTML, "Dynamic HTML", etc.).

4) XML est utilisable comme message dans une demande HTTP simple (le fameux objet de programmation XmlHttpRequest) pour passer, en plus de la demande d'une page au serveur, tout un ensemble de données pouvant servir au traitement distant. De plus, cette transmission de données est asynchrone : elle ne bloque pas le navigateur en attente des résultats ; le serveur notifie au navigateur client l'envoi des résultats qui sont alors traités localement, par exemple en JavaScript.


Ainsi à l'affichage d'une page Web demandée par l'utilisateur via le navigateur, peuvent s'établir une collection de conversations et d'échanges "privés" entre la page et divers sites Web fournisseurs de services variés. Ces échanges de données ne pénalisent pas la navigation de l'utilisateur : elles sont asynchrones et ne bloquent pas le navigateur en attente de réponse d'un serveur.


Au final, une page Web peut alors être vue comme une véritable orchestration d'appels à d'autres applications, sous formes de sites Web, pour constituer à la volée une nouvelle application Web. Cette idée, déjà répandue dans les forums et blogs de développeurs, a acquis ses lettres de noblesse lors de la sortie de GoogleMaps qui met en oeuvre cette architecture pour naviguer, sans raccord apparent, dans les cartes satellites que l'on peut superposer aux cartes routières et aux informations de géolocalisation.


Aujourd'hui on assiste du coup à une explosion des "Applications GoogleMaps" (cf. le site Google Maps Mania). Celle qui compose les services de CraigList et de GoogleMaps pour localiser en temps réel les offres immobilières de vente et de location sur une carte est devenue rapidement très visitée. Mais on commence aussi à voir des applications se réclamant de la sphère de l'informatique d'entreprise : Salesforce.com permet de localiser géographiquement ses contacts et de visualiser une tournée ou une visite de clients ; SmugMug qui héberge les photos numériques des internautes à lancé SmugMaps pour localiser l'endroit où sont prises les photos hébergées -- le lien avec la mobilité grâce aux mobiles qui sont tous, ou peu s'en faut, dotés d'un appareil photo promet d'être fascinant.

Au fur et à mesure que prolifèrent ces nouvelles applications Web, tournées vers le grand public ou vers l'entreprise, le courant d'intérêt pour AJAX s'amplifie. Déjà on en mesure les effets dans la disponibilité de nombres de bibliothèques de programmation JavaScript "toutes faites" pour développer avec AJAX (script.aculo.us, Ajax.NET, xajax, sajax, rico, dwr, jpspan, mochi...) souvent en liaison avec un langage également de script pour le serveur comme PHP, Perl, etc. Même Microsoft s'y met avec Atlas, le "framework" de programmation Ajax maison.


Voilà donc qu'à peine ouverte par les acteurs traditionnels de l'industrie informatique l'autoroute de la SOA voit se défricher de façon passablement anarchique mais passionnée et entraînée par le charisme actuel de Google, tout un réseau maillé de routes secondaires (pittoresques !) menant elles aussi à une seconde génération d'applications Web.