Cours 04

Masters 1 Resin, SITW,RSD,ADSI,IIEP
Laboratoire
Le protocole SOAP
Partie I : Echange avec un service ‐
Format du message
Les Services Web H. Meziane 1

XML et Remote Procedure Call (1/2)
 Dans un système d’information distribué, les
applications interagissent les unes avec les autres
souvent à laide du XML‐RPC1 (remote Procedure Call).
 XML‐RPC est un langage XML qui permet de décrire
et de déclencher des fonctions ou des procédures
distantes à travers l’internet.
 XML‐RPC utilise le protocole HTTP pour faire passer
les messages XML du client vers le serveur en
décrivant la nature des requêtes et des réponses avec
un vocabulaire XML restreint .
1. RPC (Remote Procedure Call) est un protocole réseau permettant de faire des appels de procédures sur un ordinateur distant à
l'aide d'un serveur d’application. Ce protocole est utilisé dans le modèle client‐serveur et permet de gérer les différents messages
entre ces entités.

XML et Remote Procedure Call (2/2)
 Le client transmet un message XML qui contient le nom de la
procédure à exécuter et la valeur des paramètres de cette
procédure et le serveur exécute le traitement et retourne la
valeur du résultat sous forme d’un document XML indiquant si
l’exécution a réussi et en précisant la (ou les) valeur(s) de
retour.
 À partir de la publication de XML‐RPC, l’activité autour des
spécifications et des technologies qui constituent aujourd’hui
l’ensemble des «services Web», s’accélère et se diversifie.
 XML‐RPC est la source d’inspiration de SOAP (Simple Object
Access Protocol). Le protocole SOAP est une forme de RPC
mais qui est utilisé dans les services Web.

Protocole SOAP (Simple object Access Protocol) (1/2)
 Le principale objectif du SOAP est de permettre la normalisation
des échanges de données.
 Le protocole SOAP définit un moyen uniforme d’échange de
données encodées XML sous forme d’appels de procédure à
distance RPC en utilisant HTTP comme protocole de
communication, mais aussi les protocoles SMTP2 (Simple Mail
Transfer Protocol ) et POP3 (Post Office Protocol ).
 SOAP assure l’interoperabilité entre composants tout en restant
indépendant des plates‐formes et de langage de programmation.
Il repose sur deux standards, XML pour la structure des messages
et HTTP pour le transport.
2. SMTP, est un protocole de communication utilisé pour transférer le courrier électronique vers les serveurs de
messagerie électronique.
3. POP (protocole de bureau de poste) permet d'aller récupérer son courrier sur un serveur distant (le serveur POP). Il
est nécessaire pour les personnes n'étant pas connectées en permanence à Internet afin de pouvoir consulter les
mails reçus hors connexion.
Protocole SOAP 1.1 (2/2)
 SOAP représente la pierre angulaire des architectures Web
services permettant à diverse applications d’échanger facilement
les services et les données.
 SOAP fournit un mécanisme qui permet d’échanger de
l’information structurée et typée entre applications dans un
environnement réparti et décentralisé.
 SOAP ne véhicule pas de modèle de programmation ou
d’implémentation, mais fournit les outils nécessaires pour définir
des modèles opérationnels d’échange (styles d’échange) aussi
diversifiés que les systèmes de messagerie asynchrone et l’appel
de procédure distante (RPC).
Echange asyncrone : le client demande l’exécution d’un service sur un serveur et il
poursuit son exécution sans attendre la réponse.

Les principes du protocole SOAP 1.1
 SOAP spécifie l’utilisation de documents XML comme messages. Pour
ce faire, il possède un certain nombre de traits :
 une grammaire pour définir le format et la structure des messages (en

termes de documents XML) ;
 une convention pour désigner les agents logiciels habilités à traiter les
différentes parties du message ainsi que le caractère obligatoire ou
optionnel du traitement ;
 une représentation codée pour véhiculer les données atomiques et
structurées manipulées par les langages de programmation (style de
codage) ;
 un ensemble de consignes pour transporter les messages sur le
protocole de transport HTTP ;
 une représentation de la requête et de la réponse d’un appel de
procédure distante.
Structure de la spécification SOAP 1.1 (1/3)
 La structure SOAP 1.1 peut être organisée en plusieurs niveaux :
Message Requête/réponse SOAP Autre

Echange one‐Way SOAP RPC Document style d’échange
Format Enveloppe SOAP

Contenu
Contenu littéral
littéral Contenu codé
Contenu XML XML Autre Autre codage autre
Codage
XML
bien formé Schema formalisme SOAP Codage
Schema
SOAP SOAP
Liaison Autre Liaison
Sur HTTP Sur SMTP
Transport HTTP SMTP Autre protocole

 Pour l’échange, la spécification prévoit pluralité de styles
d’échanges possibles (One Way, requête/réponse, notification…..)
Message Requête/réponse SOAP Autre

Echange one‐Way SOAP RPC Document style d’échange
 Tous les styles d’échange reposent tous sur un seul et unique

format de message : le format XML de l’enveloppe SOAP 1.1 et
de ses éléments descendants.
Format Enveloppe SOAP

 Le message à format unique peut héberger un contenu littéral
(du XML bien formé ou valide par rapport à des schémas XML
schema,….), ou codé ( en suivant une pluralité de style de
codage).
Contenu
Contenu littéral
littéral Contenu codé
Contenu XML XML Autre Autre codage autre
Codage XML
bien formé Schema formalisme SOAP Codage
Schema
 Le message fait l’objet d’un ensemble de convention de liaison

(binding) avec une pluralité de protocoles de transport.
SOAP SOAP
Liaison Autre Liaison
Sur HTTP Sur SMTP
Transport HTTP SMTP Autre protocole

Usages de base et étendus de SOAP 1.1
Echange Format Contenu Liaison Transport
Message XMl bien

One Way formé
SOAP (littéral)
XML Soap
SOAP sur HTTP
Schema
Document Enveloppe HTTP
(littéral)
SOAP
SOAP Codage Autre Autre

RPC SOAP liaison Protocole
Autre Autre
style codage
d’echange Schéma

SOAP 1.1 et XML
La spécification SOAP définit deux parties principales :
• Un framework de messagerie
• Un standard d’encodage

Framework de messagerie SOAP (1/5)
 La spécification SOAP 1.1 définit un vocabulaire XML
SOAP 1.1 pour les éléments et les attributs propres
au format du message.
 L’identifiant du vocabulaire XML SOAP 1.1 est associé
à l’URI http://schemas.xmlsoap.org/soap/envelope/.
 La déclaration du vocabulaire XML
http://schemas.xmlsoap.org/soap/envelope/ est
obligatoire, car elle désigne la version de SOAP
revendiquée par le message.
 Le préfixe associé au vocabulaire XML
http://schemas.xmlsoap.org/soap/envelope/ dans
SOAP1.1 est SOAP-ENV.
 Le framework de messagerie SOAP requiert que le message SOAP soit
composé d’une enveloppe qui contient un header et un body.
L’exemple suivant présente le squelette d’un message SOAP ne
contenant aucun message : Envelope est l’élément « document racine »
englobant et structurant du message.
<SOAP‐ENV:Envelope xmlns:soap‐env =
"http://schemas.xmlsoap.org/soap/envelope/"
SOAP‐ENV : encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
< SOAP‐ENV : Header>

</ SOAP‐ENV : Header> SOAP header du message : véhicule les
metadonnées du message.
< SOAP‐ENV: Body>
</ SOAP‐ENV: Body> SOAP Body du message : Il contient le
corps du message.
</ SOAP‐ENV: Envelope>
13
Les Services Web H. Meziane
Les messages SOAP sont échangés entre l’utilisateur de

service et le fournisseur de service dans des
enveloppes SOAP contenant une requête pour réaliser
une action et une réponse contenant le résultat de
cette action. Les enveloppes SOAP sont formatées XML
et assez faciles à décoder.
L’exemple suivant est une simple requête SOAP qui peut

être envoyée via une requête HTTP à un service Web :

Framework de messagerie SOAP : Requête (4/5)
<env: Envelope
xmlns:env="http://www.w3.org/2001/06/soap‐envelope/">
<env : Body> Ce manespace est utilisé pour vérifier les
incohérences de version.
<m:ValiderCodePostal
env:encodingStyle="www.w3.org/2001/06/soap‐encoding "
xmlns:m="http://www.somesite.com/codePostal">
Sérialisation
<codePostal> 78570 </codePostal>
<Pays> France </Pays> Les éléments essentiels de l’enveloppe SOAP sont 2
paramètres codePostal et Pays. Ils sont contenus dans un
</m:validercodepostal> élément nommé ValiderCodePostal qui est le nom de service
web que nous appelons.
</env : Body> Les autres données de l’enveloppe telle que le SOAP version
</env : Envelope> et style encoding facilite l’encodage des données pour le
traitement du service web.
Framework de messagerie SOAP : Réponse (5/5)
Une réponse à cette requête peut ressembler à ceci:
<env: Envelope
xmlns:env="http://www.w3.org/2001/06/soap‐envelope/">
<env : Body>
<m:ValiderCodePostalReponse
env : encodingStyle="www.w3.org/2001/06/soap‐encoding "
xmlns:m="http://www.somesite.com/codePostal">
<Valide> Oui </Valide>
</m:validercodepostal>
</env : Body>
</env : Envelope>
A l’élément ValiderCodePostal de notre requête correspond un élément

réponse ValiderCodePostalReponse dans le message de réponse SOAP, qui
contient un simple élément valide, indiquant si le code postal est valide ou non.

Les bases de SOAP 1.1
 Les styles d’échange proposés par SOAP 1.1 sont le
message à sens unique et du type requête/réponse,
avec ses deux variantes document et RPC.
 Un message à sens unique SOAP 1.1 part d’un nœud
expéditeur pour atteindre un nœud destinataire.
Expéditeur Destinateur
Réseau
Figure 1 : Style d’échange message à sens unique
Note : la codification orientées RPC, indique que les messages associés traitent des
paramètres et des valeurs de retour (et sont donc conformes au format RPC de SOAP 1.1 :
voir http://www.w3.org/TR/SOAP/#_Toc478383532), ou orientées document, c’est‐à‐dire
que ces messages traitent des documents (et sont donc conformes au format standard de
SOAP 1.1).
Chaine de message SOAP (1/3)
 Un message peut être transféré directement de l’expéditeur au
destinataire, ou bien transiter par un nombre illimité de nœuds
intermédiaires qui forment une chaîne d’acheminement (Figue 2).
 Chaque nœud intermédiaire est récepteur du message émis du
nœud précédent dans la chaîne, et émetteur du message pour le
nœud suivant. Dans une chaîne d’acheminement, l’expéditeur est
le premier émetteur et le destinataire est le dernier récepteur.
 Un Nœud intermédiaire est une application SOAP 1.1 capable de
réceptionner et d’émettre des messages SOAP 1.1.
Expéditeur Intermédiaire Intermédiaire Intermédiaire Destinateur

1 2 3
Figure 2 : Une chaîne d’acheminement

 L’utilité du mécanisme de la chaîne d’acheminement est à la fois
technique et fonctionnelle :
 Du point de vue technique, le mécanisme normalise le rôle et la
fonction du routeur applicatif.
 Du point de vue fonctionnelle, les possibilités offertes par ce
mécanisme sont multiples. Il permet de composer des services
tiers sur la base de fonctions réparties sur la chaîne
d’acheminement,
 Les différents éléments d’un message SOAP 1.1 sont produits et
consommés par les nœuds de la chaîne d’acheminement. Produire
un élément d’un message revient à le constituer. Consommer un
élément d’un message équivaut à le traiter et, pour les
intermédiaires, à réémettre le message après avoir supprimé
l’élément consommé.

 L’expéditeur du message est le premier producteur du message. Le
récepteur du message, qu’il soit intermédiaire ou destinataire, doit
exhiber un comportement normalisé, qui peut être résumé ainsi :
1. Il doit examiner le message pour chercher les informations qui lui sont
destinées.
2. Parmi les parties du message qui lui sont adressées, il y en a certaines
dont la consommation de la part du nœud est obligatoire : si le nœud
est « capable » d’effectuer cette consommation, il doit l’effectuer, et
s’il n’en est pas « capable », il doit rejeter le message.
3. S’il s’agit d’un intermédiaire, alors il doit supprimer du message les
parties qu’il consomme, et il peut ainsi produire des éléments
nouveaux, posés dans les endroits du message destinés à cet effet,
puis il doit émettre à nouveau le message vers le nœud suivant de la
chaîne d’acheminement.

Structure du message SOAP
 Le format de message SOAP est présenté dans la figure suivante : Un message
SOAP comporte trois parties :
SOAP  L’enveloppe (obligatoire) – Envelope – contient le

Envelope nom du message suivi d’un domaine de nom
(namespace) qui indique la version du schemas
SOAP header XML SOAP supporté.
Header Entry
 L’entête (optionnel) – Header – est utile quand le

Header Entry
message doit être traiter par plusieurs
intermédiaires.
SOAP Body
Body Entry
 Le corps (obligatoire) – Body – renferme les
méthodes et paramètres qui seront exécutés par
Body Entry le destinataire final.

SOAP Enveloppe (1/2)
 L’élément enveloppe est obligatoire est sert de conteneur aux

autres éléments du message SOAP.
 Le mot clé Enveloppe est suivi d’un espace de nom indiquant la

version de SOAP utilisée et optionnellement de l’attribut
encodingStyle permettant d’identifier les règles d’encodages
mises en œuvre pour un message. La valeur de l’attribut est un ou
plusieurs URI identifiant la règle de sérialisation ou les règles qui
peuvent être utilisées pour désérialiser le message.
 SOAP utilise Les namespaces pour différentier les versions. La

version doit être référencée par l’élément enveloppe.

SOAP Enveloppe (2/2)
Exemple :
<SOAP‐ENV: Envelope
xmlns:SOAP‐ENV= http://schemas.xmlsoap.org/soap/envelope/.
soap : encodingStyle= http://schema.xmlsoap.org/soap/encoding/
…>
</soap‐ENV: Envelope>
 URI de namespace de SOAP 1.1 est http://schemas.xmlsoap.org/soap/envelope/

 URI du namespace de SOAP 1.2 est http://www.w3.org/2001/09/soap‐envelope.
 ……
Si une Enveloppe fait référence a un autre namespace alors on
considère qu’il y a une erreur de versionning.

 Le format de message SOAP est présenté dans la figure suivante :
SOAP envelope Un message SOAP comporte trois parties :

SOAP header  L’enveloppe (obligatoire) – Envelope – contient
Header Entry
le nom du message suivi d’un domaine de nom
(namespace) qui indique la version du
schemas XML SOAP supporté.
Header Entry
 L’entête (optionnel) – Header – est utile quand
SOAP Body
le message doit être traiter par plusieurs
intermédiaires.
Body Entry
Body Entry méthodes et paramètres qui seront exécutés
par le destinataire final.

SOAP Header (1/3)
 L'élément Header est optionnel et permet d'intégrer au

message SOAP des directives lui permettant d'externaliser
certains services.
 Le message contiendra différentes instructions destinées à

être prises en charge par des services extérieurs
(intermédiaires). Il contient un ou plusieurs sous‐éléments
appelés Header entries (l’entrée de l’en‐tête).
 Header entries sont composés de deux attributs qui ont pour

but de déterminer comment le destinataire d'un message
doit le traiter.

SOAP Header (2/3)
Les attributs dans Header entries sont :

SOAP‐ENV:actor et SOAP‐ENV:mustUnderstand
 L'attribut SOAP 1.1 SOAP‐ENV:actor dans une entrée de l’en‐tête
est utilisé pour désigner le consommateur de l’entrée de l’en‐tête.
La valeur de l’attribut SOAP‐ENV : actor est un URI.
 L’attribut SOAP 1.1 SOAP‐ENV : mustUnderstand est utilisé pour
indiquer que la consommation de l’entrée de l’en‐tête par le
consommateur potentiel désigné est obligatoire (valeur "1") ou
facultative (valeur "0", valeur par défaut).
 SOAP 1.1 utilise des entiers 1/0 pour l’attribut MustUnderstand

 SOAP 1.2 utilise des valeurs boolean true/1/false/0

SOAP Header (3/3)
La spécification SOAP 1.1 considère explicitement

que les entrées de l’en‐tête sont destinées à la
mise en oeuvre de couches supérieures et
transversales de la technologie des services Web,
comme :
• la gestion des chaînes d’acheminement,
• la gestion des transactions,
• la gestion de la sécurité, etc.
Cours 2 slide 10

SOAP Header : Exemple (1/2)
La figure 3 présente une chaîne d’acheminement avec un seul

intermédiaire :
nice.net veut envoyer un message à pretty.net par l’intermédiaire
de office.postalservice.com.
Nice.net 1. Message A office.postalservice.com 2. Message A’ Pretty
Figure 3 : Une chaîne d’acheminement avec un seul intermédiaire.

<SOAP‐ENV:Envelope
xmlns:SOAP‐
ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP‐ENV:Header>
<pbs:postmark xmlns:pbs="http://www.postalstandards.org Le message A est bien reçu par
/basicservices/" l’intermediaire office.postalservice.com
SOAP‐ENV:actor="http://office.postalservice.com/" qui :
SOAP‐ENV:mustUnderstand="1" >
<pbs:action> 1. parcourt l’en‐tête du message ;
http://www.postalstandards.org/send
</pbs:action>
2. identifie dans l’entrée pbs:postmark la
<pbs:sender> valeur de SOAP‐ENV:actor comme son
<pbs:senderURI>http://nice.net/</pbs:senderURI> propre URI ;
</pbs:sender>
3. Verifie si la consommation de l’entrée de
<pbs:receiver>
<pbs:receiverURI>http://pretty.net/</pbs:receiverURI> l’en‐tête est obligatoire (valeur "1")
<pbs:receiverPort>http://pretty.net/home.asp 4. note que l’action demandée est l’envoi
</pbs:receiverPort> simple du message, désignée par l’URI :
</pbs:receiver> http://www.postalstandards.org/send
</pbs:postmark>
</SOAP‐ENV:Header> 5. note la valeur de l’élément
<SOAP‐ENV:Body> pbs:receiverPort ;
…..
</SOAP‐ENV:Body> 6. ignore l’élément SOAP‐ENV:Body
</SOAP‐ENV:Envelope>

29
<?xml version="1.0" encoding="UTF‐8"?>
xmlns:SOAP‐ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP‐ENV:Header>
<pbs:postmark xmlns:pbs="http://www.postalstandards.org/basicservices/"
SOAP‐ENV:actor="http://office.postalservice.com/">
SOAP‐ENV:mustUnderstand="1">
<pbs:action>http://www.postalstandards.org/send</pbs:action>
<pbs:sender>
<pbs:senderURI>http://nice.guy.net/</pbs:senderURI>
</pbs:sender>
<pbs:receiver>
<pbs:receiverURI>http://pretty.girl.net/</pbs:receiverURI>
<pbs:receiverPort>http://pretty.girl.net/home.asp</pbs:receiverPort>
</pbs:receiver>
</pbs:postmark>
</SOAP‐ENV:Header>
<SOAP‐ENV:Body>
<g:Greeting xmlns:g="http://www.greetings.org/greetings/">
Le message A complet émis
<g:text>Ciao !</g:text>
</g:Greeting>
par nice.guy.net à l’intention
</SOAP‐ENV:Body> de office.postalservice.com :
SOAP Header : Exemple (2/2)
La figure 3 présente une chaîne d’acheminement avec un seul

intermédiaire :
nice.net veut envoyer un message à pretty.net par
l’intermédiaire de office.postalservice.com.
Nice.net 1. Message A office.postalservice.com 2. Message A’ Pretty
Figure 3 : Une chaîne d’acheminement avec un seul intermédiaire.

xmlns:SOAP‐ENV="http://schemas.xmlsoap.org/soap/envelope/"
…>
<SOAP‐ENV:Header> Le message A’ est bien emis par
<pbs:postmark office.postalservice.com qui :
xmlns:pbs="http://www.postalstandards.org/basicservices/">
<pbs:postmarker> 6. construit un nouveau message dans
<pbs:postmarkerURI>
lequel l’entrée pbs:postmark est
http://office.postalservice.com/
</pbs:postmarkerURI> modifiée :
</pbs:postmarker> l’attribut SOAPENV:actor et l’élément
<pbs:dateTime> 2002‐06‐30T23:59:59 </pbs:dateTime> pbs:action sont enlevés, en outre,
<pbs:action>http://www.postalstandards.org/send</pbs:action>
les éléments suivants : son propre URI,
<pbs:sender> la date et l’heure de réception du
<pbs:senderURI>http://nice.net/</pbs:senderURI> message (à l’heure de Greenwitch,selon
</pbs:sender> le format ISO 8601), le pbs:sender et
<pbs:receiver>
pbs:receiver, sont ajoutées;
<pbs:receiverURI>http://pretty.net/</pbs:receiverURI>
7. envoie le nouveau message sur le
<pbs:receiverPort>http://pretty.net/home.asp</pbs:receiverPort> port de réception
</pbs:receiver>
http://pretty.net/home.asp.
</pbs:postmark>
</SOAP‐ENV:Header>
<SOAP‐ENV:Body>
…
</SOAP‐ENV:Body>
message A’ émis par office.postalservice.com à
</SOAP‐ENV:Envelope> l’intention de pretty.girl.net
32
 Le format de message SOAP est présenté dans la figure suivante :
SOAP envelope Un message SOAP comporte trois parties :

SOAP header  L’enveloppe (obligatoire) – Envelope – contient
Header Entry
le nom du message suivi d’un domaine de nom
(namespace) qui indique la version du
schemas XML SOAP supporté.
Header Entry
 L’entête (optionnel) – Header – est utile quand
SOAP Body
le message doit être traiter par plusieurs
intermédiaires.
Body Entry
Body Entry méthodes et paramètres qui seront exécutés
par le destinataire final.

SOAP BODY
L'élément SOAP Body contient les données

spécifiques à l'application, c'est à dire, les méthodes
et les paramètres qui seront exécutés par le
destinataire final.
Cette partie peut transporter aussi un type spécial :
les messages d'erreurs SOAP Fault utilisés pour
signaler le type d'erreur et pour renvoyer à
l'émetteur des informations supplémentaires
indiquant les raisons de l'échec de l'appel.

SOAP Fault (1/3)
Quatre éléments standards de l’élément Fault sont définies dans la
spécification SOAP 1.1. Ils sont illustrés dans le tableau (Tab.1) suivant :
Nom élément Description
Faultcode Un code texte utilisé pour indiquer la classe de l’erreur. Voir
Tab.2 pour un listing de quatre types de fault.
Faultstring Est destiné à donner une explication de l’erreur,
compréhensible par les acteurs humains (généralement les
concepteurs et les administrateurs des sevices web.
FaultActor Est destiné à fournir des informations au sujet de ce qui a
produit l’erreur. Ceci est utile si le message SOAP travers
plusieurs nœuds, et le client a besoin de savoir le nœud qui
cause l’erreur. La source de l’erreur est indiquée au travers de
son attribut qui contient URL.
Detail Permet de signaler l’erreur de l’application en rapport avec
l’élément body. Il doit être présent si le contenu de l’élément
body ne peut pas être correctement traité.
Tab.1 : éléments standards de l’élément Fault
35
SOAP Fault (2/3)
Il existe quatre types de faultcode : Tab.2 : Faultcode SOAP
Nom élément Description

SOAPENV: Indique que l’élément l’enveloppe SOAP inclue un
VersionMismatch namespace invalide, ce qui signifie une erreur de version.
Exemple : l’espace de nom de l’élément SOAP Enveloppe
n’est pas http://schemas.xmlsoap.org/soap/envelope/.
SOAPENV: un élément de Header contenant l’attribut
MustUnderstand mustUnderstand à 1, n’a pas été compris.
SOAP‐ENV:Client Indique que la requête du client contient une erreur.
Exemple : Le client a spécifié une méthode qui n’existe pas
ou a fournit des paramètres incorrects pour une méthode
donnée.
SOAP‐ENV:Server Indique que le serveur est incapable de traiter la requête
du client.
Exemple : le service qui doit fournir les produits est
incapable de se connecter à une base de données.

SOAP Fault (3/3)
<?xml version='1.0' encoding='UTF‐8'?>

xmlns:SOAP‐ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP‐ENV:Body> ………
<SOAP‐ENV:Fault>
<faultcode xsi:type="xsd:string">SOAP‐ENV:Client</faultcode>
<faultstring xsi:type="xsd:string">
Failed to locate method (ValidateCreditCard) in class
(examplesCreditCard) at /usr/local/ActivePerl‐
5.6/lib/site_perl/5.6.0/SOAP/Lite.pm line 1555.
</faultstring>
</SOAP‐ENV:Fault>
</SOAP‐ENV:Body>
Ceci représente une erreur à la requête client, et le serveur
retourne la réponse SOAP.

Cours 04

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours 04

Transféré par

Droits d'auteur :

Formats disponibles

Masters 1 Resin, SITW,RSD,ADSI,IIEP

Les Services Web H. Meziane 1

Les Services Web H. Meziane 2

Les Services Web H. Meziane 3

Les Services Web H. Meziane 5

 une grammaire pour définir le format et la structure des messages (en

Message Requête/réponse SOAP Autre

Format Enveloppe SOAP

Transport HTTP SMTP Autre protocole

Les Services Web H. Meziane 7

Message Requête/réponse SOAP Autre

 Tous les styles d’échange reposent tous sur un seul et unique

Format Enveloppe SOAP

Les Services Web H. Meziane 8

 Le message fait l’objet d’un ensemble de convention de liaison

Transport HTTP SMTP Autre protocole

Les Services Web H. Meziane 9

Message XMl bien

SOAP Codage Autre Autre

Les Services Web H. Meziane 10

La spécification SOAP définit deux parties principales :

Les Services Web H. Meziane 11

< SOAP‐ENV : Header>

Les messages SOAP sont échangés entre l’utilisateur de

L’exemple suivant est une simple requête SOAP qui peut

Les Services Web H. Meziane 14

A l’élément ValiderCodePostal de notre requête correspond un élément

Les Services Web H. Meziane 16

Figure 1 : Style d’échange message à sens unique

Expéditeur Intermédiaire Intermédiaire Intermédiaire Destinateur

Figure 2 : Une chaîne d’acheminement

Les Services Web H. Meziane 18

Les Services Web H. Meziane 19

Les Services Web H. Meziane 20

SOAP  L’enveloppe (obligatoire) – Envelope – contient le

 L’entête (optionnel) – Header – est utile quand le

Les Services Web H. Meziane 21

 L’élément enveloppe est obligatoire est sert de conteneur aux

 Le mot clé Enveloppe est suivi d’un espace de nom indiquant la

 SOAP utilise Les namespaces pour différentier les versions. La

Les Services Web H. Meziane 22

 URI de namespace de SOAP 1.1 est http://schemas.xmlsoap.org/soap/envelope/

Les Services Web H. Meziane 23

SOAP envelope Un message SOAP comporte trois parties :

Les Services Web H. Meziane 24

 L'élément Header est optionnel et permet d'intégrer au

 Le message contiendra différentes instructions destinées à

 Header entries sont composés de deux attributs qui ont pour

Les Services Web H. Meziane 25

Les attributs dans Header entries sont :

 SOAP 1.1 utilise des entiers 1/0 pour l’attribut MustUnderstand

Les Services Web H. Meziane 26

La spécification SOAP 1.1 considère explicitement

Les Services Web H. Meziane 27

La figure 3 présente une chaîne d’acheminement avec un seul

Nice.net 1. Message A office.postalservice.com 2. Message A’ Pretty

Figure 3 : Une chaîne d’acheminement avec un seul intermédiaire.

Les Services Web H. Meziane 28

Les Services Web H. Meziane

La figure 3 présente une chaîne d’acheminement avec un seul

Nice.net 1. Message A office.postalservice.com 2. Message A’ Pretty

Figure 3 : Une chaîne d’acheminement avec un seul intermédiaire.

Les Services Web H. Meziane 31

SOAP envelope Un message SOAP comporte trois parties :