Services web : SOAP

Simple Object Access Protocol

Pour D-IITWM
Par Imen Ben Lahmar
2022-2023

1
 Présentation du SOAP
• SOAP est le protocole standard pour décrire les
messages en XML avec services web.

• Il définit un ensemble de règles pour structurer

des messages

• Il peut être utilisé sur différents protocoles de

transports.
– Principalement HTTP et SMTP

2
 Les messages SOAP
• Messages XML encapsulés dans une
enveloppe SOAP
• L'intérieur du message dépend de style et
format des messages
– RPC ou document
– Encodé ou litéral
• Types de données hérités de XML Schema

3
L’échange de messages

4
 Comment fonctionne SOAP ?
• L’intérieur de message est encapsulé dans des
enveloppes
• À réception côté serveur elle est ”désencapsulée”
• Le serveur extrait les données
• Puis appelle la méthode spécifiée avec les
paramètres fournis
• Idem pour le retour, les paramètres sont
encapsulés dans un message SOAP à destination
du client

5
Structure d’un message SOAP (1/2)
•Un message SOAP est un document XML composé d’une
enveloppe qui contient une entête et un corps du message.

SOAP ENVELOPPE
 Envelope
SOAP HEADER
 Contenant un message,
 Élément racine XML,
HEADER ENTRY
 Header (optionnel)
 Ex : Numéros de session.
SOAP
SOAP BODY
ENVELOPE
 Body (obligatoire)
 Ex : nom des méthodes,
nom des paramètres, BODY ENTRY
valeurs de paramètres

6
Structure d’un message SOAP (2/2)

<SOAP-ENV :Envelope>
<SOAP-ENV :Header>
... entête...
</SOAP-ENV :Header>
<SOAP-ENV :Body>
... Corps du message...
</SOAP-ENV :Body>
</SOAP-ENV :Envelope>
7
 L’enveloppe d’un message SOAP
• L’enveloppe: Élément obligatoire dans un message SOAP
– Il permet de spécifier la version de SOAP utilisée et l’espace
de nommage http://www.w3.org/2003/05/soap-envelope
– Il permet aussi de spécifier les règles d’encodage utilisés par le
message

<?xml version="1.0"?>
< SOAP-ENV:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-
envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<SOAP-ENV :Body>
---------------------------!!Contenu de la requête!!---------------------------------
</ SOAP-ENV:Body>
</SOAP-ENV :Envelope>

8
 L’entête d’un message SOAP
• L’en-tête est défini par la balise <SOAP-ENV:Header>
• L’élément peut être facultatif
• Il contient des métadonnées pour l'exécution du service et qui peuvent
être interprétées (ou non) par le serveur
– L’en-tête d’un message SOAP est utilisé pour transmettre des
informations supplémentaires sur ce même message :
• Transactions,
• sessions,
• Actor,
• L’attribut mustUnderstand
– Si absent ou = 0
» l’élément est optionnel pour l’application réceptrice
– Si =1
» l’élément doit être compris de l’application réceptrice.
Sinon le traitement du message par le récepteur doit
échouer.
• …
9
 Exemple d’une entête SOAP

<SOAP-ENV:Header>
<t:Transaction xmlns:t="some-URI" SOAP-
ENV:mustunderstant=‘’0’’>
5
</t:Transaction>
</SOAP-ENV:Header>

10
 Le corps d’un message SOAP
• La balise Body est obligatoire

• Le corps d’un message SOAP est constitué par un élément <SOAP-

ENV:Body>

• Il contient les données ( paramètres)

• La balise Body contient des entrées qui sont des données applicatives.
– Nom d’opération, valeurs des paramètres, valeur de retour
– Une entrée peut être une Fault.
• Ces informations respectent un format d’encodage déterminé

11
 Le corps d’une requête ou d’une
réponse
• Appel d’une opération représentée par une structure
– Le nom de la structure est celui de l’opération à appeler
– Chaque paramètre de l’opération est défini comme un
sous élément de la structure
– Si un paramètre est un type complexe (Personne par
exemple), une nouvelle structure est définie contenant à
son tour des sous éléments
• La réponse à une requête est également représenté par
une struct
– Le nom de la structure est celui de l’opération suivi de
Response
– Les paramètres sont également structurés

12
 Le corps d’une requête SOAP
• Si SOAP est une requête pour un service, alors le corps de
message SOAP doit être :

<SOAP-ENV:Envelope
xmlns:soap=http://www.w3.org/2001/12/soap-envelope >
<SOAP-ENV:Body>
<nm:NomOperation
xmlns:nm=" une uri spécifique ‘’
SOAP-ENV:encodingStyle=
http://www.w3.org/2001/12/soap-encoding >
encodage des paramètres d’entrées
</ nm:NomOperation >
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

13
Exemple d’un message SOAP

namespace=‘’ http://adressDemo/"
Journal of Systems and Software

namespace=‘’ http://adressDemo/"

namespace=‘’ http://adressDemo/"

14
 Exemple d’une requête SOAP

<SOAP-ENV:Envelope
xmlns:soap=http://www.w3.org/2001/12/soap-envelope
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd =‘’ http://www.w3.org/2000/10/XMLSchema’’ >
<SOAP-ENV:Body>
<m:chercherAdresse
xmlns:m=" http://adressDemo/"
soap:encodingStyle=
http://www.w3.org/2001/12/soap-encoding >
<name xsi:type="xsd:String">Paul</name>
</m:chercherAdresse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

15
 Le corps d’une réponse SOAP
• si SOAP est une réponse pour un service alors le corps de
message SOAP doit être :

<SOAP-ENV:Envelope
xmlns:soap=http://www.w3.org/2001/12/soap-envelope
soap:encodingStyle=http://www.w3.org/2001/12/soap-encoding >
<SOAP-ENV:Body>
<nm:NomOperationResponse
xmlns:nm=" une uri spécifique "
SOAP-ENV:encodingStyle=
http://www.w3.org/2001/12/soap-encoding >
encodage des paramètres de retour
</ nm:NomOperation >
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
16
 Exemple d’une Réponse SOAP
<SOAP-ENV:Envelope
xmlns:soap=http://www.w3.org/2001/12/soap-envelope
soap:encodingStyle=http://www.w3.org/2001/12/soap-encoding
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAP-ENV:Body>
<m:chercherAdresseResponse
xmlns:m=" http://adressDemo/"
soap:encodingStyle=
http://www.w3.org/2001/12/soap-encoding >
<adress xsi:type=‘’ m:address’’>
<streetNum xsi:type="xsd:int"> 11 </ streetNum >
<streetName xsi:type="xsd:String’’>fourrier </streetName >
<zip xsi:type="xsd:int"> 75</zip>
<state xsi:type="xsd:String"> France </state>
</adress>
</m:chercherAdresse >
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
17
 Les formats des messages SOAP
• Les format des messages SOAP sont précisé dans les bindings du WSDL
– Attribut style (RPC ou document)
– Attribut use (encoded ou literal )
les combinaisons possibles sont:
– RPC/encoded
– RPC/literal
– Document/literal
– Document/encoded (Ce type d'encodage n'est supporté par aucun
moteur de services web)

18
 Les messages encodés
• Le type d'encodage Encoded utilise un ensemble
de règles reposant sur les types de données des
schémas XML pour encoder les données
<?xml version="1.0" encoding="UTF-8" ?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd=http://www.w3.org/2001/XMLSchema
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<ns0:additionner
xmlns:ns0="http://axis.test.com"
soapenv:encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/" >
<valeur1 xsi:type="xsd:int">10</valeur1>
<valeur2 xsi:type="xsd:int">20</valeur2>
</ns0:additionner>
</soapenv:Body>
</soapenv:Envelope> 19
 Les messages littérales
• Les informations concernant les type sont éliminées.

<?xml version="1.0" encoding="UTF-8" ?>

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/env
elope/" xmlns:xsd=http://www.w3.org/2001/XMLSchema
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<ns0:additionner
xmlns:ns0="http://axis.test.com’’>
<valeur1 > 10</valeur1>
<valeur2> 20</valeur2>
</ns0:additionner>
</soapenv:Body>
</soapenv:Envelope>
20
 Le style RPC vs le style Document
• Remote procedure call : (RPC) permet
l'invocation d'opérations
– Le corps du document contient obligatoirement le
nom de la méthode invoquée et les données
correspondent aux arguments de cette méthode.

• Document: Le corps du message Soap peut

contenir n’importe quel document XML.

21
 Le style RPC d’un message SOAP
• Les messages
contiennent le nom de
l'opération
• La requête/Réponse est
modélisée comme une
structure dont le nœud
le plus externe est le
nom de l'opération et
les nœuds contenus
sont les paramètres
22
Le style Document d’un message SOAP
• Les messages ne
contiennent pas le nom
de l'opération
• Le contenu du corps de
l'enveloppe peut être
validé puisque tous les
éléments sont définis
dans un schéma

23
 Les messages document/literal
• chaque élément qui correspond à un paramètre ou à la
valeur de retour est décrit dans un schéma XML
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema xmlns:tns="http://ws.test.com/"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://ws.test.com/">
<xs:element name= ’’orderrequest" type="typns:order" />
<xs:element name=‘’orderResponse" type=‘’typens:result" />
<xs:complexType name="order">
<xs:sequence>
<xs:element name="name" type="xsd:String" />
<xs:element name="price" type="xsd:int" />
</xs:sequence>
</xs:complexType>
<xs:complexType name=‘’ result">
<xs:sequence>
<xs:element name= " return " type="xsd:boolean" />
</xs:sequence>
</xs:complexType>
</xs:schema>

24
 Le WSDL associé aux messages
Document/literal
<Definition>
<types>
<xsd:schema>
<xsd:import namespace="http://ws.test.com/"
schemaLocation= "http://localhost:8089/services/orderWS?xsd=1" />
</xsd:schema>
</types>
<message name="orderReq">
<part name= ’’orderrequest" element="typens: orderrequest " />
</message>
<message name= "orderResp">
<part name= ’’orderResp" element="typens:orderResponse" />
</message>
….
<Definition>

25
 Le format RPC/Encoded
• Avantages :
– ce format est facilement compréhensible par un
être humain
– le nom de l'opération à invoquer est inclus dans le
message ce qui rend le dispatching par le moteur
SOAP vers la méthode correspondante très facile
• Inconvénients :
– c'est le type d'encodage génère les messages les
plus verbeux notamment à cause de l'indication
du type de chaque donnée

26
 Le format Document/ littéral
• Avantages :
– le contenu du corps de l'enveloppe peut être validé puisque
tous les éléments sont définis dans un schéma
• Inconvénients :
– le fichier WSDL est plus compliqué à comprendre pour un
être humain
– le nom de l'opération n'apparaît pas dans la requête SOAP :
le mapping vers la méthode du service web à invoquer est
donc plus limité puisqu'il doit se faire sur la séquence de
paramètres
– il n'est donc pas possible dans un même service web d'avoir
deux méthodes avec la même liste de paramètres

27
 Exercice
• Donner le corps des requêtes SOAP envoyer
pour invoquer les opérations du service web
gestion d’un compte :
– DepotDe dont le style de message est RPC
/encodé
– retraitDe dont le style de message est
Document/littéral ( à préciser également les
schémas xml des paramètres)

28
Exercice

29
 Exercice
• Voici le binding

30
31
32
33
34
 Gestion des erreurs dans SOAP
• Balise <soap:fault> contenu dans le corps.
– L’élément d’erreur est facultatif et n’apparaît que dans les messages de réponse
• Quatre sous‐balises facultatives
– <faultcode> type d'erreur
– <faultstring> message d'erreur pour l'utilisateur
– <faultactor> émetteur de l'erreur
– <detail> message détaillé pour l'application
• valeurs principales possibles pour <faultCode>
– Client  erreur provenant de la requête du client
– Server erreur provenant du serveur
– MustUnderstand incapacité à traiter un header mustUnderstand
– VersionMismatch  namespace de l'enveloppe incorrect

35
Exemple d’une réponse d’erreur SOAP
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope">
<SOAP-ENV:Fault>
<faultcode>Client</faultcode>
<faultstring>Méthode inexistante</faultstring>
<faultactor> http://www.monsite.com/calculer </faultactor>
<detail>
…..
</detail>
</SOAP-ENV:Fault>
</SOAP-ENV:Envelope>

36
 La couche de transport
• la définition de SOAP ne définit pas une couche
de transport particulière.
• Dans le « Binding » SOAP, il y a une description de
la façon dont les messages SOAP sont envoyés en
utilisant un protocole de transport donné
• Actuellement, deux couches de transport sont
fréquemment utilisées :
– HTTP (le plus courant)
– SMTP

37
 SOAP transporté par HTTP (1/2)
• HTTP définit le format des requêtes qu’un
client peut envoyer ainsi que les résultats qu’il
peut attendre.

38
 SOAP transporté par HTTP (2/2)
• SOAP peut être facilement porté sur http qui
convient au mode Request/Response de Http
– Le message SOAP est mis dans une requête POST
avec un content-type text/xml
– Définition d’un header http : SOAPAction
– Utilisation des codes http (2xx, 4xx, 5xx) pour les
réponses

39
L’entête HTTP d’une requête SOAP
•Quand un client envoie une requête, il l’envoie grâce à une
méthode POST, suivie d’une URI (Uniform Ressource Identifier)
qui identifie la ressource demandée. Après cette URI se trouve
la version du protocole HTTP (1.0 ou 1.1) ;

•Autres données dans l’entête :

•Type de contenu: text/xml
• SOAPAction : URI
•Champs d’entête supplémentaire de la requête

POST /soap/rpcrouter HTTP/1.1

Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: ""
40
 Exemple d’une requête SOAP transporté avec
HTTP

POST http://www.monentreprise.com/annuaire HTTP/1.1

Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: ""

<SOAP-ENV:Envelope >
<SOAP-ENV:Body>
<m:chercherAdresse
xmlns:m="urn:AdressFetcher2" >
<name xsi:type="xsd:String">Paul</name>
</m:chercherAdresse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

41
 Réponse SOAP sur HTTP
• La réponse du serveur contient le statut de la réponse, les
entêtes puis le corps de la réponse
• Différents statuts existent, les principaux sont :
– 200 (ok),
– 400 (mauvaise requête),
– 403 (client non autorisé),
– 404 (document inexistant),
– 500 (erreur d’exécution sur le serveur).

42
 Exemple d’une réponse SOAP
transporté avec HTTP
HTTP/1.1 200 Ok
Content-Type: text/xml; charset=" ISO-8859-1«
Content-Length: nnnn

<SOAP-ENV:Envelope >
<SOAP-ENV::Body>
<m:chercherAdresseResponse xmlns:m= " ….. " >
<adress>
…..
</adress>
</m:chercherAdresseResponse >
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
43