P
'
t
i
t
e
C
h
a
t
t
e
 
spacer~ ETHERNET (N): SOMETHING USED TO CATCH THE ETHERBUNNY Articles | Connexion
 
~Le protocole SOAP

 Présentation

SOAP se trouve aujourd'hui au cour des Services Web. Il fournit une architecture de messages simple et extensible s'appuyant sur XML. Nous allons voir comment ce protocole permet de faciliter l'interopérabilité dans un environnement distribué.

Bien que connu et répandu depuis peu de temps, les premières versions publiques de ce protocole datent de 1998. La spécification SOAP 1.1 représente à l'heure actuelle la dernière recommandation validée par le consortium W3C. Depuis quelque temps déjà, la spécification 1.2 se trouve en préparation mais ne bénéficie pas encore d'une recommandation officielle. Remarquons que si SOAP signifiait à l'origine Simple Object Access Protocol, l'acronyme a été définitivement abandonné, puisque la technologie n'avait finalement pas grand-chose à voir avec des accès objets.

En termes simples, SOAP désigne un protocole permettant l'acheminement d'un message XML d'un point A à un point B. L'utilisation de XML permet aux implémentations de s'affranchir de dépendances non seulement par rapport aux protocoles réseaux sous-jacents mais également par rapport aux langages de programmation utilisés.

 Sommaire


 Une messagerie ?

Les messages encapsulés par SOAP se répartissent en deux catégories, à savoir les requêtes et les réponses. La nature de ceux-ci reste à l'entière discrétion des développeurs. Dans les faits, ils représenteront soit des documents, soit des appels de procédures distantes, RPC, comme nous le verrons par la suite. Ces messages donc se représentent sous la forme d'un arbre XML composé de deux sections : l'en-tête et le corps, réunis dans une enveloppe. Vous trouverez sur le CD-Rom du magazine le fichier XMLSchema_SOAP.xml contenant le schéma XML employé pour les décrire. Le listing 1 pour sa part présente un modèle de message SOAP.

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
    <!-- en-tête optionnel -->
  </soap:Header>
  <soap:Body>
    <!-- corps -->
  </soap:Body>
</soap:Envelope>
       
      
JextCopier dans Jext | Jext | Plugin Codegeek
L'utilisation de namespaces revêt ici une importance capitale puisque le corps de l'enveloppe sera appelée à recevoir tout type de structure XML, pouvant eux-mêmes contenir des éléments qui risqueraient sans cela de se voir pris en charge par SOAP. Le message le plus simple que nous pouvons imaginer se compose seulement d'un corps. Le listing 2 propose un exemple de requête pour obtenir le solde d'un compte bancaire. Le Service Web qui devra prendre en charge ce message pourra alors envoyer une réponse. Cette dernière peut faire suite à la requête, et ainsi émettre le solde du compte comme dans le listing 3, ou encore signaler une erreur, ou en terminologie SOAP, émettre une faute (voir listing 4).

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <banque:Solde xmlns:banque="urn:exemple-login">
      <compte>00200571330</compte>
    </banque:Solde>
  </soap:Body>
</soap:Envelope>
       
      
JextCopier dans Jext
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <banque:SoldeReponse xmlns:banque="urn:exemple-login">
      <solde>
        <compte>00200571330</compte>
        <montant devise="EUR">12761</montant>
      </solde>
    </banque:Solde>
  </soap:Body>
</soap:Envelope>
       
      
JextCopier dans Jext
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <soap:Fault>
      <faultcode>soap:Server</faultcode>
      <faultstring>Compte inconnu</faultstring>
      <detail>
        <banque:SoldeErreur xmlns:banque="urn:exemple-login">
          <compte>00200571330</compte>
        </banque:Solde>
      </detail>
    </soap:Fault>
  </soap:Body>
</soap:Envelope>
       
      
JextCopier dans Jext
La possibilité de gérer les erreurs directement par SOAP évite à chaque application de définir son propre système d'exception. Une faute prend place dans le corps du message et possède trois attributs : un type, un nom et des détails. De manière générale, le nom de la faute sera employé pour afficher un message d'erreur à l'utilisateur. Les détails permettent pour leur part de rappeler à l'application ayant émis la requête l'origine de l'erreur. Rappelons-nous que SOAP peut fonctionner de manière totalement asynchrone, ce dernier point s'avère donc primordial. Enfin, le type de faute peut prendre quatre valeur : VersionMismatch, MustUnderstand, Client et Server. Les deux premières ne sont utilisées que par les processeurs SOAP pour signifier un problème de construction du message, par exemple une mauvaise déclaration de namespace. La valeur Client signifie pour l'initiateur du dialogue que le contenu du corps n'a pu être interprété par le serveur. Le message ne devra donc pas être renvoyé sans modification. La dernière valeur, Server, précise au client que le traitement du contenu a généré une erreur. Dans notre exemple, le compte bancaire spécifié n'existe pas, malgré un corps de requête bien formé.


 Les en-têtes

Nous avons vu qu'un message peut posséder un en-tête. La manipulation de ce dernier servira au contrôle des informations. Ainsi, une application pourra y faire appel pour mettre en place un système d'authentification, ou encore spécifier une date d'expiration du contenu. Imaginons-nous un instant à la place d'un développeur d'outil de messagerie instantanée (comme ICQ ou Jabber). Un message transmis entre deux clients pourra correspondre à un fichier ou à du texte qui, pour garantir le transfert par l'entremise de SOAP, code le contenu des messages en base64. L'en-tête accueillera ici le type de message transmis, "file" ou "text", ainsi que le nom de l'algorithme de codage, ainsi que le démontre le listing 5.

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
    < msg:IM xmlns:msg="urn:instant-messaging:header">
      <encoding>base64</encoding>
      <type>text</type>
    </msg:IM>
  </soap:Header>
  <soap:Body>
    <im:Message xmlns:im="urn:instant-messaging:content">
      SGVsbG8gV29ybGQgYXZlYyBTT0FQ
    </im:Message>
  </soap:Body>
</soap:Envelope>
       
      
JextCopier dans Jext | Jext | Plugin Codegeek
Le bloc contenu dans la section d'en-tête peut posséder un attribut particulier intitulé soap:mustUnderstand. Ce dernier a pour valeur 1 ou 0 (par défaut). Si celle-ci est 1, toute application recevant ce message devra impérativement savoir traiter l'en-tête. Dans le cas contraire, le client recevra une faute de type MustUnderstand. Les bénéficiaires de ces attributs seront par exemple les en-têtes destinés à l'authentification par nom d'utilisateur et mot de passe.

Cette découverte de SOAP nous a permis d'en faire le tour et de comprendre que, en accord avec l'appellation d'origine, ce protocole s'avère bel et bien simple d'emploi. En théorie une application n'a besoin d'aucune bibliothèque particulière pour générer un message SOAP, même si un support du DOM aide beaucoup. En pratique, le programmeur fera appel aux services de bibliothèques spécialisées, comme celle de la fondation Apache. Les quelques lignes suivantes démontrent avec quelle aisance nous sommes en mesure de réaliser un tel message :

Envelope envelope = new Envelope();
Body body = new Body();
Vector bodyElements = new Vector();
Element message = doc.createElementNS("urn:instant-messaging:content", "im:Message");
message.appendChild(doc.createTextNode(encodeBase64("Hello World")));
bodyElements.add(message);
body.setBodyEntries(bodyElements);
envelope.setBody(body);
       
      
JextCopier dans Jext
Nous vous conseillons de vous intéresser de près au Java Web Services Developer Pack qui réunit Tomcat et toutes les bibliothèques, notamment pour SOAP, nécessaires au développement et déploiement de Services Web. Vous pourrez également vous procurer des APIs adaptés à Python, Ruby, Perl ou tout autre langage de votre choix.



Schéma 1. Structure d'un message SOAP




Schéma 2. Utilisation de SOAP



par Romain Guy
romain.guy@jext.org
http://www.jext.org
Dernière mise à jour : 14/10/2006



 
#ProgX©2005 Mathieu GINOD - Romain GUY - Erik LOUISE