|
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.
Figure 1. Introduction à la documentation des services
Web : éléments de protocole à fil, description
du service et découverte
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 (en anglais). 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" (en
anglais)).
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
(en anglais) ).
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 XML, 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
(en anglais). 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.
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/
(en anglais) et à http://www.xmethods.net/ilab/
(en anglais). 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 XML. 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.
Initialement publié le
20 juillet 2001
|
[ ,