SOAP
Fin 1997, Microsoft commence à explorer une idée qui va transformer la communication entre applications : utiliser XML pour des appels de procédures distantes via HTTP. L’ambition est simple : faire dialoguer des machines à travers le réseau avec des types de données standard, sans les complications des protocoles propriétaires. DevelopMentor, habitué à collaborer avec Microsoft, et Userland, qui voit le Web comme un terrain de publication, rejoignent l’aventure. Le nom SOAP émerge au début de 1998.
Mais les choses se compliquent vite. L’équipe DCOM chez Microsoft freine des quatre fers. Plutôt que d’adopter cette nouvelle approche, elle préfère exploiter la position dominante de l’entreprise pour imposer DCOM via un tunneling HTTP. Les experts XML maison trouvent l’idée séduisante mais prématurée : ils attendent les fonctionnalités avancées que promettent XML Schema et les espaces de noms. Face à ce blocage, Userland prend les devants et publie sa propre version des spécifications sous le nom XML-RPC durant l’été 1998.
En 1999, Microsoft avance sur XML Schema et intègre les espaces de noms dans ses produits. SOAP regagne du terrain, l’équipe BizTalk restant réticente car leur modèle repose sur la messagerie, pas sur les appels de procédures distantes. Le 13 septembre 1999, SOAP 0.9 sort pour examen public et se retrouve soumis à l’IETF. Trois mois plus tard, SOAP 1.0 voit le jour avec peu de changements.
En mars 2000, le W3C annonce qu’il envisage une activité autour des protocoles XML. À la conférence XTech, une session animée rassemble plusieurs visionnaires qui débattent des orientations futures sans parvenir à un consensus. Mais le 8 mai 2000 marque un vrai tournant : SOAP 1.1 arrive au W3C avec IBM comme co-auteur. Ce soutien inattendu change tout. La nouvelle version se révèle bien plus modulaire et extensible, dissipant les craintes que SOAP n’impose des technologies propriétaires Microsoft. IBM publie aussitôt une implémentation Java qu’il confie au projet Apache XML pour un développement open source. Les sceptiques commencent à s’intéresser sérieusement au protocole. Sun manifeste son intérêt et travaille à intégrer les services Web dans J2EE. D’autres fournisseurs et projets libres emboîtent le pas.
En septembre 2000, le W3C forme un groupe de travail dédié au protocole XML, qui prend SOAP 1.1 comme point de départ. Après des mois de modifications, d’améliorations et de décisions difficiles sur ce qu’il fallait conserver ou abandonner, SOAP 1.2 devient une recommandation officielle en juin 2003.
SOAP s’impose parce qu’il représente le meilleur compromis industriel pour standardiser l’informatique distribuée multi-plateformes basée sur XML. Sa simplicité est son atout majeur : historiquement, les architectures adoptées massivement l’ont été grâce à cette qualité.
Le protocole définit l’unité de communication via une enveloppe qui encadre toutes les informations. Un message contient un corps où du XML arbitraire peut prendre place, accompagné d’en-têtes qui transportent des données en dehors du corps principal. Le modèle de traitement fixe des règles précises pour gérer les messages quand des extensions entrent en jeu. Les SOAP faults gèrent les erreurs en identifiant leur source et leur cause, tout en autorisant l’échange d’informations de diagnostic entre participants.
L’extensibilité passe par les en-têtes SOAP qui transportent des données d’extension avec le message et peuvent cibler des nœuds spécifiques le long de son parcours. SOAP propose un mécanisme flexible de représentation des données : il accepte des données déjà sérialisées dans divers formats (texte, XML) et fournit une convention pour représenter des structures abstraites comme les types des langages de programmation en XML.
Les appels de procédures distantes et leurs réponses se « mappent » naturellement en messages SOAP. C’est un type d’interaction courant en informatique distribuée qui correspond bien aux constructions des langages procéduraux. Le cadre de liaison définit une architecture pour construire des liaisons qui envoient et reçoivent des messages SOAP via des transports arbitraires. Ce cadre sert notamment à déplacer les messages SOAP à travers HTTP, le protocole omniprésent sur Internet.
SOAP reste largement utilisé dans les entreprises pour l’intégration d’applications et de services, surtout avec les systèmes existants. Les secteurs bancaires et financiers comptent parmi ses utilisateurs fidèles. Google l’emploie pour la plupart de ses applications, tout comme PayPal, Amazon et eBay. Le protocole conserve sa pertinence grâce à sa robustesse technique et sa capacité à gérer des opérations complexes qui nécessitent de maintenir des états conversationnels et des informations contextuelles. Son évolution a permis le développement des services Web et l’essor de l’informatique distribuée.