Résumé : cet article présente une vue d'ensemble et une introduction pratique aux problèmes actuels d'interopérabilité relatifs aux appels RPC avec le protocole SOAP. Trois sources de problèmes d'interopérabilité sont étudiées : les problèmes HTTP, les problèmes XML et les discontinuités de SOAP.

Sommaire

Introduction
Qu'est-ce que le protocole SOAP ?
Problèmes courants d'interopérabilité
Problèmes de transport
Problèmes XML
Problèmes du protocole SOAP
L'avenir

Introduction

Il existe aujourd'hui un certain nombre de plates-formes pour créer des applications. Chacune d'entre elles utilise généralement ses propres protocoles, le plus souvent de type binaire, pour l'intégration de machine à machine. En conséquence, les applications fonctionnant sur des plates-formes différentes n'ont qu'une faible capacité de partage de données. La prise de conscience de ces limites a entraîné un gros effort de standardisation des formats de données et d'échange de données. En effet, les regards se tournent de plus en plus vers un nouveau paradigme informatique : une intégration transparente des services Web qui dépasse les barrières logicielles et matérielles traditionnelles.

Au cœur de cette vision se trouve le concept d'interopérabilité, c'est-à-dire la capacité pour des systèmes disparates de communiquer et de partager des données de façon transparente. C'est l'objectif des services Web. Un service Web est une logique d'application programmable accessible à l'aide des protocoles Internet standard, que l'on peut aussi décrire comme l'implémentation de standards Web pour une communication transparente entre les machines et entre les applications.

Un certain nombre de technologies des services Web, telles que le protocole SOAP (Simple Object Access Protocol), le langage WSDL (Web Service Description Language) et le protocole HTTP (HyperText Transfer Protocol), sont actuellement utilisées pour transférer les messages entre les machines. La complexité de ces messages est très variable, pouvant aller de l'appel de méthode à la soumission d'un bon de commande. Une fonction courante - de niveau plus élevé - d'un service Web consiste à implémenter la communication de type RPC (Remote Procedure Call, appel de procédure à distance permettant à un programme sur un ordinateur d'exécuter un programme sur un autre ordinateur). Cet article présente une introduction pratique aux questions courantes d'interopérabilité, notamment celles relatives à la communication de type RPC utilisant le protocole SOAP. La messagerie avec SOAP, WSDL et d'autres protocoles sera peut-être le thème des prochains articles.

Qu'est-ce que le protocole SOAP ?

SOAP est un acronyme pour Simple Object Access Protocol. La version actuelle est 1.1 et vous trouverez sa spécification exacte sur www.w3.org/tr/soap . SOAP est basé sur XML et décrit un format de messagerie pour la communication de machine à machine. Le protocole contient également plusieurs sections facultatives décrivant les appels à une méthode (RPC) et détaillant l'envoi de messages SOAP via HTTP (pour en savoir plus sur SOAP et sur les services Web, rendez-vous sur "A Platform for Web Services" ).

Voici une requête SOAP typique (avec les en-têtes HTTP) pour un appel à une méthode RPC nommée EchoString, qui prend une chaîne comme paramètre :

POST /test/simple.asmx HTTP/1.1
Host: 131.107.72.13
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction: "http://soapinterop.org/echoString"

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

 xmlns:xsd="http://www.w3.org/2001/XMLSchema"

 xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://soapinterop.org/"

 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<tns:echoString>
<inputString>string</inputString>
</tns:echoString>
</soap:Body>
</soap:Envelope>

Comme vous pouvez le voir, le nom de la méthode est codé comme le XML : <tns:echoString> et le paramètre de type chaîne est codé comme <inputString>. La méthode C# que cela représente ressemble à ceci :

public String echoString(String inputString);

Et voici la réponse du serveur :

HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

 xmlns:xsd="http://www.w3.org/2001/XMLSchema"

 xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://soapinterop.org/"

 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<tns:echoStringResponse>
<Return>string</Return>
</tns:echoStringResponse>
</soap:Body>
</soap:Envelope>

Les règles de sérialisation du type de données de chaîne, ainsi que la forme de l'appel à une méthode, sont définies dans SOAP 1.1, sections 5 et 7 (www.w3.org/tr/soap ).

Problèmes courants d'interopérabilité

Les problèmes d'interopérabilité qui affectent la messagerie SOAP de type RPC peuvent avoir plusieurs causes. En fait, la plupart de ces problèmes ne concernent pas directement SOAP, mais plutôt le transport sous-jacent ou les moteurs XML. En d'autres termes, les problèmes d'interopérabilité peuvent être :

• des problèmes HTTP,
  
  
• des problèmes XML ou
  
  
• des discontinuités de SOAP.

Il faut aussi dire que les auteurs de ces spécifications ne sont pas parfaits, d'où certaines ambiguïtés qui rend parfois difficile la détermination d'un seul comportement correct.

Problèmes de transport

Pour tout message des Services Web, le transport utilisé pour l'envoi est primordial. Pour les appels RPC via SOAP, HTTP est de loin le transport le plus populaire. Cela signifie que l'interopérabilité HTTP doit exister entre les piles de SOAP.

Un exemple simple de problème d'interopérabilité HTTP concerne l'utilisation de SOAPAction. SOAPAction est un en-tête HTTP qui doit être présent dans les messages SOAP via HTTP. Plusieurs valeurs différentes peuvent être affectées à cet en-tête, telles que :

SOAPAction: "http://tempuri.org/"

La valeur de SOAPAction doit être entre guillemets, sauf s'il s'agit d'une valeur null :

SOAPAction:

Le problème ici est le suivant : si un serveur requiert cette SOAPAction de valeur null, certains clients ne pourront pas suivre, car toutes les API client HTTP ne peuvent pas définir une valeur d'en-tête HTTP null. Dans ce cas, il existe deux solutions : régler les API clientes et/ou s'assurer que certains serveurs ne requièrent pas une SOAPAction de valeur nulle. En règle générale, la seule façon d'éviter ce genre de problèmes est de s'assurer que l'API HTTP utilisée est robuste et a déjà fait ses preuves sur le Web. De tels problèmes pouvant néanmoins survenir, il est conseillé de procéder à des tests pour les prévenir.

Problèmes XML

Le deuxième type de problèmes d'interopérabilité concerne l'analyse XML et la gestion de schémas XSD. SOAP utilise à la base XML et les schémas XML, de sorte que son interopérabilité dépend de l'interopérabilité des deux.

Un exemple intéressant de problème d'interopérabilité impliquant à la fois l'analyse XML et les transports HTTP concerne la marque d'ordre de tri (BOM, Byte Order Mark). Lorsque vous envoyez des données via HTTP, vous pouvez indiquer le codage des données, comme UTF-16 ou UTF-8, dans l'en-tête Content-Type. Vous pouvez également indiquer le codage d'un fragment XML en insérant un ensemble d'octets. Lorsque vous envoyez UTF-16, la BOM est requise, même si le codage est présent dans l'en-tête Content-Type (pour préciser big-endian ou little-endian), mais elle ne l'est pas pour UTF-8. Par exemple :

HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length

n++<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

 xmlns:xsd="http://www.w3.org/2001/XMLSchema"

 xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://soapinterop.org/"

 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<tns:echoStringResponse>
<Return>string</Return>
</tns:echoStringResponse>
</soap:Body>
</soap:Envelope>

Les trois premiers caractères sont hexadécimaux pour la marque d'ordre de tri indiquant UTF-8, mais comme vous pouvez le voir, le Content-Type en fait également part. Certaines implémentations envoient la BOM pour UTF-8, même si elles n'en ont pas besoin. D'autres ne peuvent pas traiter XML avec une BOM. La solution est de ne l'envoyer que lorsque c'est nécessaire et de la gérer correctement. En effet, il est essentiel de bien gérer la BOM pour le traitement des messages UTF-16, car elle est requise dans ce cas. Indéniablement, il n'existe pas de solution idéale pour régler ces problèmes avant l'heure. Mais une fois qu'ils sont identifiés, le mieux est de se référer aux spécifications exactes (généralement consultables au W3C) qui décrivent les standards, puis de les appliquer scrupuleusement.

Problèmes du protocole SOAP

À présent, nous somme arrivés au cœur de la question : les problèmes propres au protocole SOAP. Comme indiqué précédemment, l'interopérabilité pour SOAP requiert d'abord la résolution des problèmes de transport (généralement HTTP) et des problèmes XML. Ceci étant fait, les questions sur le protocole SOAP peuvent être abordées.

En lui-même, SOAP est relativement simple. Il requiert que les messages soient placés dans une enveloppe, avec le texte du message inclus dans un élément du corps. SOAP propose des éléments facultatifs tels que les en-têtes et donne toute latitude quant à ce qui peut entrer dans l'élément du corps. Voici l'exemple d'un message SOAP simple qui n'aurait aucun problème d'interopérabilité avec la plupart des piles :

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body >
<foo />
</soap:Body>
</soap:Envelope>

Ce n'est pas très intéressant, mais SOAP propose également une façon de coder les types de données communs (voir la section 5 des spécifications SOAP) et il donne une description détaillée du codage des appels à une méthode RPC. Comme vous l'avez vu dans l'exemple précédent, les noms de méthode deviennent les balises enfant du corps et les arguments deviennent les balises enfant du nom de la méthode.

Même sans tenir compte de ce type de complexité, il existe un certain nombre de problèmes d'interopérabilité intéressants. Par exemple, les spécifications SOAP indiquent que si vous recevez un en-tête SOAP avec un attribut mustUnderstand défini sur "1", vous devez le comprendre, sinon il y a défaillance. Au début, un grand nombre d'implémentations ne le faisaient pas. Voici un exemple d'en-tête mustUnderstand :

HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length

n++<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

 xmlns:xsd="http://www.w3.org/2001/XMLSchema"

 xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://soapinterop.org/"

 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header>
<Foo SOAP-ENV:mustUnderstand="1">
Hello!
</Foo>
</SOAP-ENV:Header>
<soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<tns:echoStringResponse>
<Return>string</Return>
</tns:echoStringResponse>
</soap:Body>
</soap:Envelope>

Cet exemple est l'un des nombreux problèmes découverts par le biais des tests d'interopérabilité de SOAP. D'autres exemples de problèmes d'interopérabilité sont consultables dans les archives de http://groups.yahoo.com/group/soapbuilders . Dans l'ensemble, les travaux faits sur cette liste et de par le monde pour assurer l'interopérabilité de SOAP dans l'implémentation de communications de style RPC ont eu des résultats époustouflants. Du 8 au 10 mai, à Networld+Interop (Las Vegas), la communauté SOAP se réunit pour présenter cette réussite. Si vous avez une pile SOAP, ou si vous êtes simplement curieux, allez-y et découvrez les démos.

Une grande partie des discussions et des tests concernant les services Web XML ont également eu lieu sur http://groups.yahoo.com/group/soapbuilders, à http://www.mssoapinterop.org/ et à http://www.xmethods.net/ilab/ . Ces sites contiennent des liens vers plusieurs points terminaux pour les tests d'interopérabilité. Quiconque construit une pile SOAP est encouragé à lire l'archive et à participer aux tests d'interopérabilité.

L'avenir

Cet article présente brièvement les premiers problèmes d'interopérabilité trouvés dans le monde des Services Web. Toutefois, la route est encore longue. Au-delà de l'appel de procédure à distance (RPC) via HTTP, un grand nombre de scénarios intéressants avec SOAP n'ont pas encore été traités. On peut citer le transfert de messages de style "document", le protocole SOAP via SMTP et d'autres transports, WSDL et plusieurs tests des en-têtes SOAP, autant de sujets qu'il faudra aborder dans les prochains articles.

Dernière mise à jour le vendredi 20 juillet 2001

• Le protocole SOAP dans Microsoft .NET Framework et dans Visual Studio .NET
• Spécification de XML for Analysis
• Les ressources .NET pour les développeurs