SOAP est l’acronyme de Simple Object Access Protocol, c’est-à-dire protocole simplifié pour l’accès à des objets distants. C’est un protocole léger destiné à l’échange d’informations structurées dans un environnement décentralisé et distribué.

Il utilise des technologies XML pour définir un cadre extensible de messagerie fournissant une construction de messages qui peuvent être échangés à l’aide d’une variété de protocoles sous-jacents.

Plus généralement, SOAP permet à des objets (d’un code source) de toute nature – sur n’importe quelle plateforme, dans n’importe quel langage – de communiquer. À l’heure actuelle, SOAP a été mis en œuvre dans plus de 60 langages sur plus de 20 plateformes.

Le cadre a été conçu pour être indépendant de tout modèle de programmation de sémantique mis en œuvre de manière spécifique. Il est important pour le développement des applications de permettre une communication Internet entre les programmes.

Aujourd’hui, les applications communiquent en utilisant le protocole Remote Procedure Calls (RPC) entre les objets comme DCOM et CORBA. RPC représente certes une compatibilité mais pose des problèmes de sécurité : les firewalls et les serveurs proxy bloqueront normalement ce genre de trafic. Une meilleure façon de communiquer entre les applications est d’utiliser le protocole HTTP, car ce dernier est supporté par tous les navigateurs Internet et les serveurs. SOAP a été créé à cette fin, à partir de 1998, pour fournir un moyen de communiquer entre les applications s’exécutant sur des systèmes d’exploitation différents, avec différentes technologies et des langages de programmation.

Les principes de SOAP

Les deux buts de conception majeur de SOAP sont : la simplicité et l’extensibilité. Un message SOAP peut être envoyé à un site web, par exemple par un service Web, pour obtenir le prix de l’immobilier enregistré dans une base de données, avec les paramètres nécessaires à une recherche.

Le site renverrait alors en retour un document au format XML avec les données obtenues, par exemple, le prix, l’emplacement et les caractéristiques. Parce que les données sont retournées sous un format normalisé et grâce à la souplesse du langage XML qui permet un nommage proche des fonctionnalités métiers, la lecture du message SOAP est relativement aisée par un humain, permettant ainsi d’être intégrée directement dans un site Web ou dans une application tiers.

Ce protocole applicatif peut s’appuyer sur différents protocoles de transport pour des échanges synchrones ou asynchrones :

• HTTP : échanges synchrones
• Java RMI : échanges synchrones
• SMTP : échanges aynchrones
• FTP : échanges aynchrones
• etc…

L’architecture SOAP se compose de plusieurs couches de spécifications. Par exemple, pour le format de message, il est possible d’avoir une séquence d’échange de messages (MEP) – Message Exchange Patterns – qui est un squelette établissant une forme de base pour échanger des messages entre nœuds SOAP, traitant les modèles des messages, et l’extensibilité du protocole.

Par ailleurs, SOAP désigne les informations échangées dans une syntaxe correspondant aux fonctions applicatives, contrairement à XML-RPC qui utilise uniquement des nommages techniques et primitifs. De plus, SOAP permet la sérialisation/désérialisation de tout objet métier, sous une forme XML utilisable quelle que soit la technologie d’implémentation. Enfin SOAP normalise la gestion des erreurs.

Fonctionnement de SOAP

Les données utiles de SOAP sont encapsulées dans l’enveloppe SOAP (qui elle-même fait partie des données utiles d’HTTP, supposant que vous utilisez HTTP comme protocole de transport). L’enveloppe SOAP, à son tour, se compose d’un en-tête SOAP (Header) et du corps (Body). Le prologue XML peut être présent, mais dans ce cas, ne doit contenir qu’une déclaration XML (c’est-à-dire qu’il ne doit contenir ni référence à un DTD, ni instruction XML). Le message doit utiliser l’enveloppe SOAP et les namespaces d’encodage SOAP, et doit avoir la forme suivante :

• Une déclaration XML (optionnelle)
• une Enveloppe SOAP (l’élément racine) qui est composée de :
  • Une En-tête SOAP (optionnel)
  • Un Corps SOAP

Le prologue XML contient seulement une déclaration XML <?xml version="1.0" encoding="UTF-8" ?> spécifiant la version de XML et l’encodage des caractères du message XML.

Le tag de l’enveloppe SOAP (<soap:Envelope xmlns:soap:"http://schemas.xmlsoap.org/soap/envelope/">) dans le message de requête, optionnel, spécifie tout d’abord que le style d’encodage de ce message SOAP suit le schéma défini dans http://schemas.xmlsoap.org/soap/encoding/. L’Enveloppe SOAP contient également des définitions de namespaces. Les identifiants des namespaces sont standards et la spécification SOAP demande à ce que ces namespaces soient définis correctement ou pas du tout.

La partie Header (<soap:Header>), facultative, porte des informations complémentaires pour le traitement des données (identification de l’émetteur du message, règles de sécurité pour la lecture du message, algorithme de chiffrement à utiliser pour la lecture du message, etc.) Il est important de rappeler que l’authentification et la gestion de session sont en dehors du cadre du protocole SOAP, même si SOAP autorise une certaine flexibilité dans la transmission des messages, de telle façon que les personnes qui les implémentent puissent inclure de telles informations.

La partie Body (<soap:Body>), porte les données propres du message, et matérialise la requête ou la réponse SOAP (structure de données spécifique). Les données sont sérialisées en XML en utilisant une combinaison d’éléments et d’attributs XML. La partie encapsule un unique tag de méthode qui porte le nom de la méthode elle-même <ns1:maMethode ... > (ou, le même nom suivi du mot « Response » dans le cas du message de réponse). Notez que le tag de la méthode reçoit typiquement le namespace correspondant au nom du service, pour assurer l’unicité (un service web, qui peut contenir n’importe quel nombre de méthodes nommées différemment, a un nom de service unique à l’URL sur lequel il est accessible.

Le tag de méthode encapsule à son tour un certain nombre de paramètres, tel que le tag <param1 ... > dans l’enveloppe d’une requête et dans le message de réponse, on ne trouve qu’un seul tag de paramètre représentant la valeur de retour de la méthode (généralement appelé <return>).

SOAP utilise couramment le protocole HTTP et est donc très évolutif dans sa forme native. C’est probablement le protocole le plus évolutif, particulièrement si le modèle d’HTTP demande/réponse est maintenu. SOAP est extensible, parce que les clients SOAP, les serveurs et le protocole lui-même peuvent évoluer sans rupture des applications existantes. Il est par ailleurs utile en termes de soutien intermédiaire et dans les architectures en couches. Cela signifie que le traitement des nœuds peut être réalisé avec une demande entre le client et le serveur. Ces nœuds intermédiaires traitent les parties du message spécifié par SOAP, grâce à l’utilisation des en-têtes, permettant aux clients d’identifier le nœud qui fonctionne sur telle ou telle partie du message.

Les limites de SOAP

Si les messages XML utilisés dans SOAP sont facilement lisibles par des humains, ils sont verbeux ce qui entraîne des problématiques en terme de performances :

• D’une part, le poids d’un message SOAP (codé en mode texte) est beaucoup plus important qu’un message codé en binaire, ce qui a un impact sur son temps d’acheminement.
• D’autre part, le travail de construction et de lecture du message par les applications imbriquées dans la communication est gourmand en terme de temps processeur

La première partie permettant de décrire les principes, le fonctionnement et les limites de SOAP se termine. Dans la prochaine, on analysera le modèle de traitement de SOAP, le format du message et la sécurité.

J’espère avoir répondu à vos attentes. N’hésitez pas à m’apporter votre point de vue sur cette technologie qui est en émergence.