Communiquer SOAP

Chapitre 2
Extrait de l'ouvrage Services Web avec SOAP, WSDL, UDDI, ebXML... de Jean-Marie Chauvet, Eyrolles, 2002.
Communiquer :
SOAP
SOAP est une spcification de communication entre services Web par
change de messages en XML au travers du Web. Simple et facile implmenter dans les serveurs Web ou dans les serveurs dapplications, SOAP
est indpendant des langages de programmation ou des systmes
dexploitation employs pour limplmentation des services Web. Les
concepteurs de SOAP ont, en effet, russi prserver la plus grande gnralit dans la reprsentation en XML des principes des protocoles de
communication. Sinspirant des gnrations prcdentes de RPC (Remote
Procedure Call) et de RPC objet (Corba, DCOM), ils se sont attachs en
formaliser la dfinition dans des documents XML changs sur le Web,
sous forme de dialogue entre le client et le serveur. SOAP repose sur XML
et sur quelques standards drivs, les NameSpaces et XML Schema, en
particulier.
Simple Object Access Protocol

SOAP est un protocole de communication entre applications fond sur
XML, visant satisfaire un double objectif : servir de protocole de
communication sur les intranets, dans une optique dintgration dapplications dentreprise, et permettre la communication entre applications et
services Web, en particulier dans un contexte dchanges interentreprises.
Conu pour sappuyer sur HTTP bien que formellement parlant on
puisse y substituer un autre protocole de transport de messages (comme
SMTP) , SOAP ne requiert pas de modification majeure aux serveurs Web
dj installs sur la Toile, tout au plus des extensions. SOAP permet
galement, grce au support de XML Schema, de sinterfacer avec des
applications prexistantes en capturant leurs structures de donnes
quelle que soit la complexit de ces dernires.
47
Services Web avec SOAP, WSDL, UDDI, ebXML
SOAP est dvelopp conjointement par Microsoft, IBM, Lotus Development (une division dIBM), DevelopMentor et UserLand Software sous les
auspices du W3C. SOAP 1.1 fit lobjet dune note soumise au W3C en mai
2000, et SOAP 1.2 dun document de travail (working draft) en juillet 2001.
Microsoft a dj, quant lui, annonc lintgration de SOAP dans la plateforme .NET, en particulier dans BizTalk Server, le fer de lance de la stratgie Internet de lditeur de Redmond.
SOAP est dfini comme un protocole lger dchange de donnes dans un
rseau de pair pair, cest--dire dcentralis. Sappuyant sur XML, SOAP
propose un mcanisme simple de reprsentation des diffrents aspects
dun message entre applications. Nimposant aucun modle de programmation spcifique, SOAP peut donc tre utilis dans tous les styles de
communication : synchrone ou asynchrone, point point ou multipoint,
intranet ou Internet.
La spcification SOAP se divise en quatre parties :
lenveloppe SOAP, qui dfinit le contexte dun message, son destinataire, son contenu et diffrentes options ;
les rgles de codage SOAP, dfinissant la reprsentation des donnes
dune application dans le corps dun message SOAP (en particulier leur
structure) ;
un protocole de RPC dfinissant la succession des requtes et des
rponses ;
la dfinition de lutilisation de HTTP comme couche de transport des
messages SOAP.
Les rgles de codage utilisent abondamment XML Schema pour dcrire la
structure des donnes constitutives des messages SOAP.
Protocoles de RPC et SOAP

SOAP se classe parmi les protocoles de communication orients objet,
reprenant les principes traditionnels de RPC (Remote Procedure Call) des
protocoles antrieurs, comme DCOM ou IIOP. SOAP ne bouleverse donc
pas larchitecture de communication ventuellement prexistante dans le
rseau de lentreprise. Bien au contraire, le rapprochement des principes
de SOAP de ceux dautres RPC facilite lintgration des diffrents protocoles et assure une excellente interoprabilit moindre cot la jonction
de lintranet et de lInternet.
Les protocoles de communication orients objet

Depuis les annes 1980, les deux protocoles de communication les plus
communment utiliss sont Sun RPC, la base du systme de gestion de
fichiers rpartis NFS, et DCE (Distributed Computing Environment), dont DEC
48
Chapitre 2 Communiquer : SOAP
fut lorigine le champion, repris par Microsoft dans DCOM. Les travaux
de lOMG, dune part, et lapport radical de COM aux produits de Microsoft, dautre part, ont produit, dans les annes 1990, des versions orientes objet de ces RPC : IIOP dans la norme Corba bien quofficiellement
la norme stipule quun protocole fond sur DCE-RPC est galement
acceptable et DCOM dans Windows NT.
Structurellement, DCOM et IIOP sont identiques. En effet, un RPC orient
objet doit imprativement contenir certaines donnes (identit des objets
et des mthodes appeles, leurs paramtres, etc.) :
Messages de requte et de rponse dans les RPC orients objet

(IIOP, DCOM, RMI)
REQUTE
RPONSE
Identit de lobjet destinataire
tat du traitement
Identit de linterface de lobjet
En-tte ventuel
Identit de la mthode de linterface
Paramtres
En-tte ventuel
Paramtres
Les identits de lobjet, de linterface, et de lopration de cette dernire,

indiquent au destinataire du message que faire de la requte ; les donnes
figurant dans le corps du message sont constitues des paramtres des
oprations, de leurs qualificatifs (in, out, ou inout) et de leur type. Les enttes de messages sont prvus pour des informations complmentaires
parfois indispensables pour la correcte excution de la requte (le
contexte transactionnel, par exemple). Dans la rponse, un code indique
ce quil est advenu de la requte au cours de son traitement par le serveur
(russite, chec, rejet) et les paramtres contiennent, le cas chant, les
donnes attendues en retour par lmetteur.
IIOP, DCOM et RMI diffrent quant la nature des informations vhicules
par ces messages mais pas sur leur structure. Dans IIOP, les objets ne
portant quune seule interface, lidentit de celle-ci est donc implicite :
cest celle de lobjet destinataire. Dans le cas de DCOM, au contraire, un
objet portant ventuellement plus dune interface, cette information
supplmentaire est indispensable. Dans IIOP, les paramtres constituant
le corps du message suivent le format CDR (Common Data Representation)
dfini dans la norme Corba ; dans DCOM, ceux-ci sont cods suivant le
format NDR (Network Data Representation) de Microsoft. De mme, les identits dobjets dans Corba sont des IOR (Interoperable Object Reference) qui
49
nont rien de commun avec le format utilis par DCOM, les OBJREF
reprsents par les UUID, des suites de 128 caractres hexadcimaux.
DCOM et IIOP sont adapts des rseaux se caractrisant par une qualit
de service homogne, une latence contrle et une administration rigoureuse. Cest plutt le cas des rseaux intranet dentreprise.
CORBA
De plus, mme si la conformit Corba assure une compatibilit minimale

entre systmes dexploitation diffrents, les produits commerciaux des diteurs
noffrent pas ncessairement le mme niveau de service, en particulier en ce qui
concerne les transactions ou la scurit.
Sur le Web, la situation est compltement diffrente : la qualit de service

et la latence sont variables, et le rseau rsulte plus de lagrgation de
nuds et de sous-rseaux htrognes partageant la couche TCP/IP la
plus profonde que dun dveloppement disciplin. Seul un protocole
simple mais robuste peut alors saccommoder, lchelon suprieur, de
tant de variabilit : HTTP.
HTTP
DNS (Domain
Name Server) :
nuds Internet
responsables de
lidentification de
ladresse IP dune
machine daprs son
nom (URL).
linstar de DCOM et dIIOP, HTTP est une couche RPC au-dessus de TCP/
IP. Les requtes et les rponses HTTP sont traites par un serveur Web
(comme IIS de Microsoft ou comme Apache) auquel se connecte un client
HTTP, gnralement un navigateur Web. Requtes et rponses sont
composes dun en-tte et dun corps de message ; toutes sont exprimes
en texte ASCII (et non en binaire comme dans les protocoles prcdents).
Lors dun change HTTP (voir figure 2-1), le client ouvre un canal de
communication (socket) sur le port n 80 du serveur demand, charge
pour les DNS1 de trouver ladresse IP correcte. La requte et la rponse
HTTP circulent sur ce canal qui ne reste ouvert, par dfaut, que le temps
dun change. Si plusieurs requtes sont issues du mme client vers le
mme serveur cest le cas par exemple pour le tlchargement dune
page Web contenant des images stockes sous forme de fichiers spars
sur le serveur , la requte peut indiquer que le canal doit rester ouvert
par loption Keep-Alive.
Le protocole HTTP prvoit tout une srie de codes derreur (dont le
fameux code 404 illustr par la figure 2-2) ou dinformation pour renvoyer,
le cas chant, le rsultat du traitement de la requte au poste client.
Requte et rponse HTTP ont chacune leur en-tte spcifique, qualifi par
des mots-cls et leurs valeurs (voir annexe 1).
50
Figure 2-1. change HTTP entre navigateur et serveur Web.
51
Figure 2-2. change entre navigateur et serveur Web en cas derreur de traitement.
52
HTTPR
HTTPR, pour HTTP Reliable (fiable), est une proposition dIBM, datant de
juillet 2001, pour une extension du protocole HTTP visant le fiabiliser. Ce
sont des rgles supplmentaires permettant dassurer que tous les messages HTTP sont livrs leurs destinations exactement une fois et sans altration de leur contenu. En cas de dfaillance, le protocole signale le
message comme non livr. HTTPR est une extension de HTTP 1.1, hritant
donc de toutes les possibilits de cette version quant SSL, la communication au travers des pare-feu (firewalls) et des proxies.
Considrons le cas dun programme envoyant un ordre dachat un serveur
sur le rseau. En cas de dfaillance de livraison du message sans avertissement de lmetteur, lordre dachat est perdu. linverse, si le message est
livr plusieurs fois sans que le destinataire ne soit notifi de la rptition,
plusieurs ordres dachat seront effectivement passs au lieu dun. La solution classique est pour lmetteur de rpter lenvoi du message jusqu
rception dun accus de rception du destinataire. Du coup, le message
doit lui-mme contenir son identification afin que le destinataire reconnaisse les duplicatas ventuels. Cette solution reste nanmoins difficile
mettre en place dans tous les contextes de dfaillance imaginables. Le
schma habituel spare dailleurs la logique de communication de la logique de lapplication comme lillustre la figure 2-3.
Figure 2-3.
Communication
synchrone sans
fiabilit.
Dans le cas de dfaillances dans lenvoi ou dans la rception des messages, cest malgr tout aux programmes client et serveur de dcider de la
conduite suivre, surchargeant ainsi chacune des applications.
53
Figure 2-4. Communication synchrone fiable.
Dans le cas dun protocole dit fiable (voir figure 2-4), la couche de communication est munie dune forme de mmoire persistante (fichiers, bases de
donnes, etc.) laquelle elle confie une copie de chaque message entrant
et sortant, aprs leur avoir attribu un numro ou une identit unique.
Cette unicit permet de grer correctement les renvois ventuels en cas
de dfaillance de communication ou bien de procder une comparaison
avec un tat antrieur des applications lorsque les applications ellesmmes sont dfaillantes. Le protocole est tendu aux communications
asynchrones en dotant le programme client dune mmoire persistante,
conservant lidentit des messages envoys et des messages de retour
reus.
La proposition HTTPR dIBM suggre limplmentation de cette couche
supplmentaire de gestion de transport au-dessus du protocole standard
HTTP 1.1. Lmetteur de messages utilise alors la requte HTTP Post pour
transporter les informations supplmentaires, ncessaires la gestion de
la livraison des messages. La spcification prvoit que plusieurs
messages scuriss puissent tre transports dans la mme requte
HTTP de manire diminuer la frquence des changes dans le cas
dchanges importants. Des agents HTTPR de simples programmes
intermdiaires qui envoient et rceptionnent les messages, associs
une sauvegarde persistante grent alors la communication avec fiabilit
en sappuyant sur ces informations supplmentaires, ainsi que la reprise
ventuelle sur erreur de transmission ou sur dfaillance de lmetteur.
54
XML comme format neutre de reprsentation

des donnes
Lide originale apporte par SOAP est dassocier au protocole HTTP un
format neutre de reprsentation de donnes bas sur XML, remplissant le
rle jou par NDR ou par CDR dans les protocoles propritaires objet
DCOM et IIOP. En effet, tout comme NDR et CDR, XML est utilisable pour
reprsenter textuellement des structures de donnes arbitrairement
complexes. XML prsente, de plus, des avantages considrables par
rapport ses prdcesseurs : plus grande disponibilit doutils de dveloppement ou dinterprteurs facilitant son implmentation et sa
diffusion ; reprsentation textuelle, videmment plus lisible quun format
binaire ; plus grande facilit dextension ou de spcialisation, permettant
des volutions en douceur sans rcriture systmatique des programmes metteur ou destinataire. Sappuyant sur les normes NameSpaces et
XML Schema, SOAP dispose dune richesse expressive permettant
lexpression de messages entre applications et services Web, aussi
complexes soient-ils.
La structure des messages SOAP

Un message SOAP est un document XML constitu dune enveloppe
contenant un en-tte (header) facultatif et le corps (body) du message (voir
figure 2-5).
Figure 2-5. La structure

des messages SOAP.
55
Lenveloppe SOAP : <SOAP-ENV:Envelope>
Lenveloppe est la racine du document XML contenant le message SOAP,

marque par la balise <Envelope> (voir figure 2-6). La spcification
impose que tous les attributs de cette balise et de celles imbriques
soient explicitement associs un namespace, de manire supprimer
toute ambigut. Par convention, la spcification SOAP dfinit deux
namespaces frquemment utiliss :
SOAP-ENV associ lURI http://schemas.xmlsoap.org/soap/envelope pour
dfinir le namespace de lenveloppe dans la version 1.1, et http://
www.w3.org/2001/06/soap-envelope dans la version 1.2 reprise par le W3C.
SOAP-ENC associ lURI http://schemas.xmlsoap.org/soap/encoding pour la
dfinition des formats de types de donnes dans la version 1.1, et http:/
/www.w3.org/2001/06/soap-encoding dans la version 1.2.
Figure 2-6. La structure XML de lenveloppe SOAP (schma gnr avec loutil XML Spy).
Lexemple suivant montre un message SOAP que pourrait envoyer un

programme client un serveur offrant un service Web dinformation financire en ligne pour connatre la valeur dun titre :
<SOAP-ENV:Envelope
xmlns:SOAP-ENV
-"http://schemas.xmlsoap.org/soap/envelope"
SOAP-ENV :encodingStyle="http://schemas.xmlsoap.org/
ding">
<SOAP-ENV:Body>

</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
56
soap/enco-
La rponse du serveur aurait la mme structure :

<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/
envelope"
soap/encoding">
<SOAP-ENV:Body>

</SOAP-ENV:Body>
Lattribut encodingStyle, dont la valeur est un URI, spcifie quelles

conventions sont employes dans cet lment (et dans tous ceux quil
contient) pour le format des donnes. La spcification propose des
formats identifis par lURI SOAP-ENC prcdemment mentionn. A
priori, rien nexclut de faire rfrence des rgles de codage et de reprsentation des donnes diffrentes de celles proposes par la norme, mais
le cas reste exotique.
Len-tte SOAP : <SOAP-ENV:Header>

La balise <Header> permet de passer dans le message des informations
complmentaires sur ce mme message. Cet lment est facultatif, mais,
sil est prsent, doit tre le premier dans lenveloppe SOAP du message.
Quel en est lusage ? Len-tte peut, par exemple, contenir des informations authentifiant lmetteur ou bien encore le contexte dune transaction dont le message nest quune des tapes. Pour les couches de transport (comme FTP) ne fournissant pas, lmission, dadresse de retour, on
peut aussi utiliser len-tte pour identifier lmetteur du message SOAP.
Llment Header, et les lments quil contient, peuvent tre qualifis
par lattribut mustUnderstand qui prend la valeur 0 ou 1. La valeur 1
signale que le rcepteur doit reconnatre linformation prsente dans lentte et que son traitement est obligatoire ; la valeur 0 indique que len-tte
peut tre ignor par le serveur. Ainsi est-il possible dtendre les fonctions
du serveur, par exemple, sans remettre en cause les clients.
Lexemple suivant montre un en-tte transportant une adresse de courrier
lectronique :
<SOAP-ENV:Header
<exemple:emetteur xmlns:exemple=="http://monURI"
SOAP-ENV:mustUnderstand="0">
MonNom@monDomaine.com
</exemple:emetteur>
</SOAP-ENV:Header>
57
Le serveur peut ignorer cette information sans prjudice pour le traitement du corps du message (mustUnderstand a la valeur 0). Un autre
serveur pourra, quant lui, utiliser cette information pour une trace
daudit, par exemple, de lusage dun service Web.
Un message SOAP peut avoir traverser plusieurs intermdiaires
avant datteindre son destinataire final. Dans ce cas, len-tte joue un rle
primordial : chaque arrt le long de litinraire, le serveur intermdiaire
extrait de len-tte ce qui le concerne en propre et ajoute ce qui est ncessaire au serveur intermdiaire suivant (voir figure 2-7). Les lments
concernant un serveur intermdiaire sont marqus par la prsence de
lattribut SOAP-ENV:ACTOR avec une valeur conventionnelle :
SOAP-ENV:Actor="http://schemas.xmlsoap.org/soap/actor/next"
Figure 2-7. Len-tte dans une srie de transferts successifs de messages SOAP
58
CORBA
Cette extension est une implmentation du pattern classique appel chane de

responsabilit (chain of responsibility) n 223 dans la classification originale
du dictionnaire de Design Patterns de Gamma, Helm, Johnson et Vlissides
dcouplant le client du serveur en donnant plus dun serveur la possibilit de
traiter la requte.
Le corps du message SOAP : <SOAP-ENV:Body>

Le corps du message est constitu du seul lment , contenant un
ou plusieurs sous-lments. Ces sous-lments sont les suivants :
FAULT, indiquant une erreur ou une dfaillance en rponse une
requte.
Des donnes destines au destinataire du message, un format dfini
par les rgles de codage SOAP.
Initialement, le corps de message SOAP tait conu pour passer des
appels de procdures distants, cest--dire des requtes au sens OMG du
terme (un objet, une mthode et les valeurs de ses arguments) et des
rsultats ou des messages derreur. Mais, en fait, lusage sest largi et le
corps du message est souvent utilis pour simplement passer des
donnes structures entre applications.
Dans le cas de la dfaillance (Fault), de nouveaux sous-lments sont
employs pour signaler le type de lerreur et pour renvoyer lmetteur
des informations supplmentaires indiquant la raison de lchec de
lappel. Les codes derreurs sont galement normaliss par la spcification SOAP.
Les rgles de codage des diffrents types de donnes

Les rgles de codage font appel des balises dfinies dans le second
namespace propre SOAP (http://schemas.xmlsoap.org/soap/encoding/). Il est
galement possible de spcifier des namespaces de substitution, propres
lutilisateur, pour dfinir ou redfinir ces balises de codage de donnes
en rponse des besoins particuliers. Toutes les valeurs des donnes
dune requte ou dune rponse suivent la srie de rgles suivantes :
Les valeurs dites simples (comme les entiers ou les chanes de caractres)
apparaissent directement entre les balises.
Font lobjet dun traitement particulier les valeurs dites composes, constitues de champs qualifis dun nom, dun numro dordre, ou des
deux. Cette qualification est appele un accesseur. On dfinit les structures,
des valeurs composes dont les accesseurs sont tous des noms, et les
tableaux, des valeurs composes dont les accesseurs sont tous des
numros dordre.
Les lments reprsentant ces valeurs sont dits inclus ou indpendants. Un
lment inclus dans une structure compose reprsente directement la
valeur du champ considr de la structure. Mais la valeur du champ peut
59
galement tre un pointeur vers un lment, dit alors indpendant. Un

lment indpendant est une valeur qui peut tre ainsi partage par
plusieurs lments dans le corps dun mme message.
Bien que ce nen soit pas le seul usage possible, SOAP est principalement
employ pour transporter entre services Web des requtes et le rsultat
de leur excution un usage qui trouve aussi son champ dapplication
dans lintgration dapplications dentreprises. Comme dans un
middleware, une requte SOAP contient alors le nom dune mthode ou
dune fonction invoque sur le site Web distant avec lensemble de ses
paramtres. La rponse SOAP contient, quant elle, le rsultat de lexcution de cette fonction ou un code derreur signalant une dfaillance. Ainsi,
dans lusage courant de SOAP, il est relativement simple de mettre en
correspondance les messages mis et reus avec les objets et le
programme implmentant tel ou tel service Web.
Reprenons lexemple (classique) dune opration sur un compte bancaire
dfini, par exemple, par la mthode Java suivante sur le serveur :
package banque
public void operation{
public int compte;
public float montant ;
}
Une instance particulire de cette classe apparatrait alors dans le corps

dun message sous la forme de la structure SOAP suivante :
<t:operation xmlns:t="http://monServeur/banque">
<compte>125612</compte>
<montant>250.75</montant>
</t:operation>
dans laquelle les accesseurs sont les noms Compte et Montant utiliss comme balises. Une transaction dbit-crdit, peine plus complexe,
serait de la mme manire reprsente dans un message sous la structure
SOAP suivante :
<t:transaction xmlns:t="http://monServeur/banque">
<credit>
</credit>
<debit>
</debit>
</t:transaction>
60
La classe Java correspondante tant :

package banque
public class transaction{
public operation credit;
public operation debit;
Une fois ces structures dfinies, lappel dune mthode Java sur ces oprations se droule suivant le schma de la figure 2-8.
Les finesses supplmentaires se greffant ces rgles gnrales telles
que la reprsentation en SOAP de la nullit ou de labsence de certains
champs dune valeur compose, font appel des mcanismes standardiss de reprsentation des donnes complexes, traits par la norme
XML Schema. Cest aussi le cas dans la situation o la valeur dun champ
dune structure se trouve tre une instance dun sous-type du type prvu
(dans le cas que nous exposons, il suffit dimaginer par exemple une
sous-classe de la classe Operation contenant des champs
supplmentaires : ces derniers doivent alors figurer galement dans le
message SOAP).
Enfin, pour illustrer lusage des pointeurs lintrieur dun message SOAP,
ajoutons notre scnario bancaire une seconde transaction dbit-crdit
faisant circuler le mme montant entre trois comptes. La reprsentation
nave venant naturellement lesprit est la suivante :
<t:double-transaction xmlns :t="http://monServeur/banque">
<transaction-B-vers-C>
<credit>
</credit>
<debit>
</debit>
</transaction-B-vers-C>
<transaction-A-vers-B>
<credit>
</credit>
<debit>
</debit>
</transaction-A-vers-B>
</t:double-transaction>
Cette reprsentation ne capture pas le fait que le compte B, intermdiaire,

est le mme dans les deux transactions, la premire fois au dbit, la
61
62
Figure 2-8. Structure du programme traitant les messages
SOAP sur le serveur
seconde au crdit. Il faudrait, en quelque sorte, factoriser la structure

commune : cest prcisment le rle des lments indpendants. On utilisera donc plutt la reprsentation SOAP suivante :
<t:double-transaction xmlns:t="http://monServeur/banque">
<transaction-B-vers-C>
<credit>
</credit>
<debit href="#id1" />
</transaction-B-vers-C>
<transaction-A-vers-B>
<credit href="#id1" />
<debit>
</debit>
</transaction-A-vers-B>
</t:double-transaction>
<t:operation soap:id="id1" xmlns:t="http://monServeur/
banque">
</t:operation>
Ici, le compte intermdiaire fait lobjet dune dfinition part laquelle la

transaction principale fait rfrence par le truchement de lidentifiant id1.
Notons au passage que la valeur dun accesseur peut tre soit une constante (comme dans <montant>250.75</montant>), soit un URI agissant comme un pointeur (comme dans lexpression <debit
href="#id1"/>). Dans ce dernier cas, plusieurs valeurs composes
peuvent alors faire rfrence au mme lment indpendant lintrieur
dun message SOAP.
Pour conclure, nous donnons lexemple dun tableau et de sa reprsentation dans un message SOAP. Le tableau suivant, dfini dans lIDL de
DCOM, dcrit un ensemble de points :
struct POINTLIST{
long cElem;
[size_is(cElem)] POINT points[];
};
Il sera reprsent dans un message SOAP, pour un jeu donn de valeurs,

sous la forme dun tableau SOAP :
<t:POINTLIST xmlns:"uri-de-POINTLIST">
<cElem>3</cElem>
<points xsd:type="t:POINT[3]">
<POINT><x>3</x><y>4</y></POINT>
63
</points>
</t:POINTLIST>
Lattribut xsd dans llment points fait rfrence la norme XML

Schema. Il permet de stipuler le type, au sens de la structure de donnes,
du champ reprsent par llment points. Dans lexemple, ce schma
est suppos dfini dans lURI du namespace spcifi dans la balise de
llment t:POINTLIST.
SOAP avec pices jointes

Dans le cas o le message comporte des donnes binaires ne se prtant
pas une reprsentation textuelle, un mcanisme standard dinclusion du
message SOAP dans un message MIME composite (multipart/related
message) permet de prserver les rgles de traitement du message SOAP.
Cest le cas dans le scnario de la relation entre compagnies dassurances
dans lequel formulaires signs et photos de dgts doivent tre changs
(voir figure 2-9), ou bien dans celui dune collaboration dans le secteur du
btiment, dans lequel des dessins darchitecte doivent circuler. La plupart
des images transmises sur Internet, par exemple, sont soit au format GIF,
soit au format JPEG : elles constituent un message MIME dun type particulier. La spcification MIME (RFC 2387) prcise comment mler dans un
mme message diffrents types de donnes, sous le type particulier
multipart/related.
Les rgles de construction dun message SOAP avec pices jointes sont
les suivantes :
Le message SOAP proprement parler apparat le premier dans le message MIME, et donc le type figurant dans len-tte multipart/
relatedest celui des messages SOAP :text/xml
Les autres lments du message MIME doivent prsenter un en-tte
MIME comportant soit lattribut Content-ID, soit lattribut ContentLocation pour pouvoir tre identifis sans ambigut.
Le traitement du message SOAP se fait suivant les rgles habituelles
spcifies dans la norme.
64
Figure 2-9. Dclaration de dgt pour lassurance : message SOAP avec

fac-simil du formulaire sign en pice jointe
Les rfrences aux pices jointes dans le message SOAP

Pour quon puisse faire rfrence des pices jointes depuis len-tte ou
depuis le corps dun message SOAP, on utilise une astuce des rgles de
codage des messages SOAP. La norme SOAP 1.2 permet la valeur dun
accesseur dtre une rfrence plutt quune constante (entier, chane de
caractres). La rfrence est alors exprime par un URI. Pour le cas
prsent, la norme SOAP avec pices jointes utilise ce degr de libert et
stipule simplement des conventions de construction dURI qui pointent
vers les pices jointes au message MIME encapsulant le message SOAP.
Chaque partie du message multipart/related est identifi par un URI
auquel le message SOAP peut faire librement rfrence :
Si lattribut Content-Location est prsent et contient un URI absolu
(voir figure 2-10), celui-ci est utilis comme identifiant de la partie
MIME en question (le plus simple).
Si ce mme attribut est prsent mais contient un URI relatif (voir figure
2-11, page 67), lURI absolu est constitu en rfrence au plus proche
contenant MIME qualifi par un Content-Location absolu ou en
65
rfrence au dfaut thismessage:/ en cas dabsence dune telle

racine (pour les pices jointes complexes ou imbriques).
Si lattribut Content-ID est prsent, il existe une mthode normalise
de construction dun URI partir de sa valeur (RFC 2111).
Figure 2-10. Rfrences des pices jointes dans un message SOAP : URI absolu
Notons quun message SOAP peut parfaitement ne pas faire rfrence aux
pices jointes groupes avec lui dans le mme message MIME. De mme,
la rsolution effective des URI dun message SOAP faisant rfrence des
pices jointes nest pas ncessairement du ressort de linterprteur SOAP
lui-mme : en fonction du traitement du message, ces rfrences seront
rsolues ou non par le service Web sollicit.
SOAP avec pices jointes induit quelques changements mineurs dans les
requtes suivant le protocole de transport auquel on fait appel, HTTP ou
SMTP, par exemple. Dans le premier cas, lattribut Content-Type:
Multipart/Related apparat dans len-tte HTTP lexclusion de tous
les attributs HTTP redondants avec ceux de MIME (comme ContentTransfer-Encoding, par exemple). Dans le second cas, les en-ttes
SMTP et MIME sont simplement fusionns : il ny a pas de redondance.
66
Figure 2-11. Rfrences des pices jointes dans un message SOAP : URI relatif
Limportance de SOAP avec pices jointes pour les services mtier est
indiscutable. Le consortium ebXML, par exemple, a abandonn son
protocole de messagerie propritaire pour adopter SOAP ds que ce
dernier protocole a permis lattachement de pices jointes. SOAP avec
pices jointes contribue la gnralisation de ladoption de SOAP comme
service de communication entre services et applications Web.
Le routage des messages SOAP : WS-Routing

Dans les applications base de workflow et dans lautomatisation des
processus mtier, le routage des messages, cest--dire la dtermination
des chemins de diffusion des messages, est essentiel. En effet, lintgrit
des donnes et le bon aboutissement des processus reposent au bout du
compte sur le bon ordre de la transmission des messages et de la rmission ventuelle de ceux qui se sont gars. Microsoft, promoteur actif
67
de la spcification SOAP, sest attaqu la dfinition dun mcanisme

gnral de routage utilisable dans ce cas. Dabord connu sous le nom de
SOAP-RP (SOAP Routing Protocol), la spcification a t affine et publie
pour recueillir les commentaires ventuels en octobre 2001 sous le nom
WS-Routing (Web Services Routing Protocol).
WS-Routing est un protocole fond sur SOAP, dfinissant lchange de
messages unidirectionnel entre un metteur et un rcepteur au travers
dun certain nombre dintermdiaires. De plus, WS-Routing construit
automatiquement un chemin de retour pour les rponses du rcepteur
lmetteur originel. Ainsi, grce WS-Routing il est possible dtablir
toutes sortes de modes de communication par messages SOAP : point
point, requte/rponse, accuss de rception et notifications de
dfaillance. WS-Routing rajoute simplement des informations dans un
en-tte inclus dans lenveloppe SOAP, ce qui rend ce protocole relativement indpendant de la couche de transport choisie pour la transmission
des messages eux-mmes (TCP, UDP et HTTP). Grce cette possibilit de
construction des chemins de retour, il devient alors possible de corrler
divers messages changs entre serveurs. La corrlation de messages et
WS-Routing, mis en uvre dans BizTalk, par exemple, sont des dispositifs
essentiels pour ladministration des processus mtier et linterprtation
des traces daudit dans les phases de dveloppement et de test.
Le modle de routage des messages de WS-Routing

Dans le protocole SOAP, lattribut
permet dindiquer le
destinataire final de telle ou telle partie du message, mais rien ne permet
a priori dexpliciter la squence dintermdiaires au travers desquels le
message doit passer avant datteindre ce destinataire. WS-Routing est
conu pour pallier cette difficult et fournir automatiquement les informations ncessaires pour corrler les changes de messages entre les
nuds de traitement SOAP. La spcification WS-Routing dfinit une
terminologie, prsente dans le tableau rsum suivant :
Le protocole dfinit les oprations suivantes :
Lmetteur initial indique dans un en-tte WS-Routing le destinataire
final du message ainsi que des intermdiaires WS-Routing ventuels
qui dfinissent le chemin WS-Routing.
Le message est transmis au premier nud WS-Routing indiqu ; si
celui-ci est un intermdiaire, il relaie le message au nud suivant du
chemin WS-Routing.
68
Terme
Commentaire
En-tte WS-Routing
En-tte SOAP utilis pour conserver linformation de

routage, associ au namespace http://schemas.xmlsoap.org/rp
Message WS-Routing
Message SOAP contenant un en-tte WS-Routing.
Dfaillance WS-Routing
Notification de dfaillance SOAP contenant un en-tte

WS-Routing.
metteur/rcepteur WS-Routing
Application crant ou recevant un message WS-Routing

li un protocole de transport donn.
Chemins WS-Routing
Le chemin et le chemin de retour WS-Routing sont constitus de la squence (et de la mme en ordre inverse)
des metteurs et des rcepteurs WS-Routing au travers
desquels circule un message WS-Routing.
Chemin de retour WS-Routing
Ce chemin est construit automatiquement par le protocole lors de la transmission initiale de lmetteur au
rcepteur. Ce chemin est ventuellement utilis pour
faire parvenir lmetteur les rponses du rcepteur.
Intermdiaire WS-Routing
Un nud jouant la fois le rle dmetteur et de rcepteur WS-Routing.
Proxy WS-Routing
Intermdiaire WS-Routing jouant un rle explicite dans

la transmission des messages WS-Routing.
Tunnel WS-Routing
Intermdiaire WS-Routing jouant un rle de relais entre

deux canaux de communications sans participer explicitement la transmission des messages SOAP.
Gateway WS-Routing
Un destinataire final WS-Routing assurant la traduction

de SOAP vers un autre protocole (par exemple, la
traduction dun message SOAP en un flux de commandes Telnet).
certaines conditions, un intermdiaire WS-Routing peut ajouter dynamiquement de nouveaux intermdiaires au chemin de routage. Le
chemin na donc pas ncessairement tre compltement connu au
moment de lmission des messages.
Enfin, lintermdiaire peut ventuellement ajouter des informations
permettant de reconstituer un chemin de retour des messages SOAP,
tablissant ainsi une communication point point bi-directionnelle
entre metteur et rcepteurs originels.
Cette communication bi-directionnelle permise par WS-Routing est indpendante de la couche de transport physique retenue pour lchange des
messages. La spcification nimpose pas de choix et propose, par exem-
69
ple, des liaisons WS-Routing pour TCP (qui est bi-directionnel) et pour
UDP (qui nest pas bi-directionnel).
Le rle des intermdiaires WS-Routing est finalement de permettre
laccs aux informations relatives la transmission des messages SOAP
et de faciliter le franchissement de barrires spcifiques de communications (pare-feu, protocoles spcifiques de transport, etc.). Les informations de transmission de messages SOAP sont utiles des applications
dadministration, par exemple, ainsi ventuellement qu des applications complmentaires assurant des services de scurit, daudit, de chiffrement ou dauthentification et de collaboration reposant sur lexamen
des itinraires suivis par les messages changs dans un rseau SOAP.
Cest dans ces derniers cas quun intermdiaire WS-Routing peut tre
amen ajouter un intermdiaire WS-Routing dynamiquement. Nous
retrouvons ici le pattern dinterposition de services, dont lusage est gnral
dans les serveurs dapplications avec la notion de composant logiciel et
de conteneur. Ainsi, par exemple, lauthentification de la communication
entre un metteur et un rcepteur SOAP peut simplement tre assure par
un intermdiaire WS-Routing qui ajoute systmatiquement aux chemins
WS-Routing sur lequel il se trouve, un dtour par un autre intermdiaire
WS-Routing charg de la vrification de lidentit de lmetteur. Ainsi les
messages sont automatiquement authentifis sans que lmetteur ou le
destinataire naient eux-mmes appeler explicitement le service
dauthentification.
Les gateways WS-Routing assurent la traduction entre le protocole vhiculant les messages SOAP et des protocoles extrieurs, spcifiques. Comme
un connecteur, le gateway transpose les messages dun protocole de transport lautre et, en retour, traduit (du mieux quil est possible si lquivalence nest pas parfaite) les codes derreurs et de dfaillance du protocole
externe.
Les balises de WS-Routing

WS-Routing dfinit de nouveaux lments, tout dabord pour dsigner les
nuds de routage le long du chemin :
Balise WS-Routing
Dfinition
to
URI du destinataire final du message.
from
URI de lmetteur du message
via
URI dun intermdiaire (impos) sur le chemin.
70
Le chemin et le chemin de retour sont marqus par de nouveaux

lments :
Balise WS-Routing
Dfinition
fwd
Squence dlments via ordonnant la liste des intermdiaires WS-Routing traverser.
rev
Squence, inverse de la prcdente, dlments via indiquant le chemin de retour.
Lexemple suivant montre un message minimal sans intermdiaire et sans

chemin de retour :
<S:Envelope
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header>
<m:path xmlns:m="http://schemas.xmlsoap.org/rp/">
<m:action>http://www.notification.org/update
</m: action>
<m:to>soap://notification.com/some/endpoint</m:to>
<m:id>uuid:20020802-1403-4351-b623-5dsf35sgs5d6
</m:id>
</m:path>
</S:Header>
<S:Body>
Le corps du message SOAP
</S:Body>
</S:Envelope>
Seul llment to est prsent dans len-tte WS-Routing indiquant ici une
communication directe avec le destinataire.
Dans le second exemple, un message est mis par A vers C via un intermdiaire WS-Routing B. Le message issu de A vers B est le suivant (avec un
chemin de retour initialement vide) :
<S:Envelope
<S:Header>
<m:action>http://www.im.org/chat</m:action>
<m:to>soap://C.com/some/endpoint</m:to>
<m:fwd>
<m:via>soap://B.com</m:via>
</m:fwd>
<m:rev>
<m:via/>
</m:rev>
71
<m:from>mailto:chauvet@eyrolles.com</m:from>
</m:id>
</m:path>
</S:Header>
<S:Body>
</S:Body>
</S:Envelope>
Le message ensuite mis de B vers C aprs traitement du prcdent est

alors :
<S:Envelope
<S:Header>
<m:action>http://www.im.org/chat</m:action>
<m:to>soap://C.com/some/endpoint</m:to>
<m:fwd>
</m:fwd>
<m:rev>
<m:via/>
<m:via m:vid="cid:122326@B.com"/>
</m:rev>
<m:from> mailto:chauvet@eyrolles.com </m:from>
</m:id>
</m:path>
</S:Header>
<S:Body>
</S:Body>
</S:Envelope>
Cette fois, llment rev est automatiquement renseign par le traitement au nud B.De plus, B a ajout et renseign lattribut vid dans
llment rev, qui est lidentit du canal de communication ayant reu le
message en provenance de A. Le cas chant, B pourra ainsi ractiver ce
canal pour faire parvenir A des rponses ventuelles de C, ou dintermdiaires en aval de B. WS-Routing assure ainsi la complte indpendance
des diffrents segments sur le chemin initial et le chemin de retour. Des
protocoles de transport peuvent, par exemple, lier A et B, dune part, et B
et C, dautre part, sans remettre en cause ni lapplication mettrice ni le
destinataire du message.
Pour assurer la corrlation des messages, llment id contient lidentit
unique de chaque message en circulation. Le nouvel lment relatesTo
permet de faire rfrence lidentit dun autre message dans len-tte
WS-Routing. Ainsi, par exemple, une rponse circulant de C vers A, arrive-
72
rait dabord au nud intermdiaire B sous la forme du message SOAP

suivant :
<S:Envelope
<S:Header>
<m:action>http://www.im.org/update</m:action>
<m:fwd>
<m:via/>
<m:via m:vid="cid:122326@B.com"/>
</m:fwd>
<m:rev>
<m:via>soap://C.com/rev/endpoint2;up=udp
</m:via>
</m:rev>
<m:from>mailto:billg@microsoft.com</m:from>
<m:id>uuid:9fshs8fj-sffg-r5ts-adfg9kd84jd9mjdld43</m:id>
<m:relatesTo>
uuid:20020802-1403-4351-b623-5dsf35sgs5d6
</m:relatesTo>
</m:path>
</S:Header>
<S:Body>
</S:Body>
</S:Envelope>
Dans ce message, llment fwd est construit partir du contenu de

llment rev des messages initiaux. Llment relatesTo indique, en
rfrence, quel message originel cette rponse correspond.
Enfin, WS-Routing dfinit galement des codes derreur en cas de dfaillance.
Ces codes apparaissent dans llment fault de SOAP le cas chant. Le
tableau suivant rsume les diffrentes dfaillances et leurs codes :
Liaisons WS-Routing vers les protocoles de transport

La spcification dcrit comment lier WS-Routing aux protocoles de transport TCP, UDP et HTTP. Il est galement possible de dvelopper des
liaisons des protocoles de transport spcifiques autres que ceux prsents dans ce projet de norme.
Les liaisons TCP et UDP utilisent un mcanisme dencapsulation propos
par Microsoft lIETF en fvrier 2002 : DIME (Direct Internet Message Encapsulation). DIME est un format binaire lger de message permettant
dencapsuler plusieurs parties de natures et de types diffrents dans le
mme message. En caricaturant, il sagit dune version lgre de MIME, le
mcanisme dencapsulation du courrier lectronique. Chaque partie est
identifie par un nom, un type, une taille et un numro dordre, chacun de
73
ces identifiants tant compatible avec les quivalents MIME. Dans larchitecture de services Web de Microsoft, DIME permet dencapsuler un
message SOAP avec ses pices jointes sous une forme moins lourde
traiter que dans le cas du codage MIME.
Code derreur WS-Routing
Signification
Dfaillance lmission
700 Invalid WS-Routing Header
En-tte invalide.
701 WS-Routing Header Required
Absence den-tte WS-Routing.
710 End-point Not Found
Destinataire introuvable.
711 End-point Gone
Destinataire devenu inactif (et pas dalternative de

reroutage).
712 End-point Not Supported
Destinataire incapable de traiter les en-ttes WSRouting.
713 End-point Invalid
Destinataire invalide (en gnral, erreur de syntaxe

dans lURI).
720 Alternative End-point Found
Destinataire de substitution identifi.
730 End-point Too Long
LURI du destinataire est trop longue pour tre traite par le destinataire WS-Routing.
731 Message Too Large
Message trop lourd.
740 Message Time-out
Dpassement des dlais de traitement attendus

par le destinataire.
750 Message Loop Detected
Dtection dune boucle dans le chemin de routage.
751 Reverse Path Unavailable
Impossibilit de construire le chemin de retour.
Dfaillance la rception
800 Unknown Routing Fault
Dfaillance dorigine inconnue !
810 Element Not Implemented
En-tte contenant un lment non conforme au

schma WS-Routing.
811 Service Unavailable
Le traitement des messages WS-Routing ne

rpond pas.
812 Service Too Busy
Le traitement des messages WS-Routing bloque

les ressources du destinataire, empchant le traitement de nouveaux messages.
820 End-point Not Reachable
Le destinataire ne peut tre atteint.
74
Dans le cas de WS-Routing, le message DIME est obligatoirement constitu du message WS-Routing lui-mme, en premire partie, et des pices
jointes ventuelles dans les parties suivantes. Par convention, lidentifiant
de la premire partie du message DIME est lURI du destinataire suivant
sur le chemin, extrait du message WS-Routing. Cette convention permet
de router le message directement sans que le nud intermdiaire nait
interprter la totalit du message SOAP et de len-tte WS-Routing. Il ny
a alors pas de dgradation de performance dans la transmission des
messages.
Ainsi encapsul, le message est prt tre transport par TCP, qui est un
protocole bi-directionnel, et par UDP, qui ne lest pas. Dans le premier cas,
les lments rev sont facultatifs, la couche de transport TCP se chargeant
elle-mme du calcul du chemin de retour. Dans le second cas, les datagrammes UDP ntant pas bi-directionnels, les lments rev sont obligatoires et renseigns par le traitement aux tapes intermdiaires le long du
chemin. En ce qui concerne HTTP, WS-Routing est entirement compatible avec la liaison SOAP HTTP.
SOAP transport par HTTP

La spcification SOAP met en avant HTTP (plutt que dautres protocoles
de transport comme SMTP, FTP, POP3 ou NNTP) comme protocole privilgi de transport des messages SOAP. Les premires versions de SOAP
sintressaient essentiellement au RPC au travers du Web, do la vocation premire de SOAP : du RPC sur HTTP. Larrive de nouveaux acteurs
comme IBM dans le groupe de spcification de SOAP conduisit enrichir
lambition de SOAP et lon vit une premire dmonstration de SOAP sur
SMTP, par exemple.
Le modle requte/rponse de SOAP sadapte parfaitement au modle
requte HTTP/rponse HTTP. Le message SOAP vient naturellement
simbriquer dans les requtes et les rponses HTTP (voir figure 2-12),
bnficiant de toute la gestion et du routage dcentralis du protocole du
Web.
La requte SOAP HTTP

La spcification nutilise que les requtes HTTP de type Post pour transporter les requtes SOAP (sans raison particulire autre que la simplicit,
dans ce cas, du passage de donnes de lmetteur vers le destinataire). Un
attribut supplmentaire doit, par contre, tre utilis dans len-tte HTTP
de la requte, pour se manifester auprs du destinataire SOAP du
message. Rappelons, en effet, que les serveurs SOAP et les serveurs Web
(HTTP) ne sont pas physiquement lis et un serveur Web donn peut, par
75
exemple, hberger plusieurs services Web et autant de destinataires

SOAP. Cet attribut supplmentaire, SOAPAction, a pour valeur un URI
sans format spcifique dont linterprtation est la charge du destinataire
de la requte, comme dans lexemple suivant :
Figure 2-12. Le message SOAP

inclus dans une requte ou une
rponse HTTP
POST http://www.serveurBoursier.fr HTTP/1.1

Content-type: text/xml ; charset="utf-8"
Content-length: mcdu
SOAPAction: http://uneUriCompriseDuDestinataire#infos
<SOAP-ENV:Envelope
envelope"
soap/encoding">
<SOAP-ENV:Body>
</SOAP-ENV:Body>
76
La rponse SOAP HTTP

Pour les rponses, SOAP suit la smantique des codes de retour HTTP. Si
la rponse HTTP porte un code de type 2xx, le message SOAP a t reu,
compris et trait correctement. Dans le cas contraire, SOAP utilise
conventionnellement le code 500 (Internal Server Error), et la balise Body
doit alors contenir llment Fault indiquant la nature de lerreur. La
rponse la requte de la section prcdente serait donc (en cas de
succs) :
HTTP/1.1 200 OK
Content-type: text/xml ; charset="utf-8"
Content-length: mcdu
<SOAP-ENV:Envelope
envelope"
soap/encoding">
<SOAP-ENV:Body>

</SOAP-ENV:Body>
SOAP sur HTTPR

Lusage de HTTPR permet lenvoi et la rception fiable de messages SOAP,
et, par consquent, une communication fiable entre services Web. Dans ce
scnario, la proposition dIBM est de faire passer lattribut SOAPAction
dans len-tte HTTPR, qui contient dj les identifiants uniques et lhorodatage des messages, sous le nouveau nom app-soap-action. Ainsi, la
requte SOAP HTTP prcdente devient la requte SOAP HTTPR suivante :
POST http://www.serveurBoursier.fr HTTP/1.1
Transfer-Encoding: chunked
...
request: PUSH HTTPR/1.0
transactionid: 1
message-size: nnn
target-uri: "httpr://www.serveurBoursier.fr"
content-type: text/xml; charset="utf-8"
reply-uri: "httpr://www.serveurBoursier.fr"
message-id: "fg8[t7[E]#]"
correlation-id: "6cf6[C]#5cd6[D]#cd5/f5[a]/4[a]/
g4[a]fd5[A]#cd4td4#"
put-time: 2001-02-15T11:12:12Z
app-soap-action: http://electrocommerce.org/abc#MyMessage
77
<SOAP-ENV:Envelope
envelope"
soap/encoding">
<SOAP-ENV:Body>
</SOAP-ENV:Body>
Len-tte spcifique HTTPR sintercale avant le message SOAP. Il contient

lidentit, lhorodatage et le nom de laction HTTPR (ici PUSH, simplement
pour indiquer la transmission dune requte). On y trouve galement des
identifiants uniques (transactionid, message-id et correlation-id) permettant en cas de dfaillance de grer ltat du dialogue
entre les deux parties.
Scnario de dcouverte dynamique des services Web

La comparaison avec la structure des requtes des protocoles de communication objet propritaires claire les similarits entre SOAP et les RPC
objet :
Requte Corba, DCOM ou RMI
Requte SOAP
Identit de lobjet destinataire

POST /URIobjet http/1.1
Identit de linterface de lobjet
Identit de la mthode de linterface
SOAPAction
En-tte ventuel
Balise SOAP:Header
Paramtres
Balise SOAP:Body
La requte ne spcifie pas comment passer de la combinaison de lURI de

lobjet destinataire et de la valeur de lattribut SOAPAction au code
excutable, charg de traiter le message. Comme dans les spcifications
Corba, cette dtermination est laisse au choix de limplmentation du
serveur SOAP. Ainsi certains serveurs SOAP vont-ils utiliser le nom de la
classe Java excuter comme URI, avec la mthode comme valeur de
SOAPAction ; dautres, conservant ltat de lobjet entre deux requtes
SOAP, utiliseront soit des cookies, soit une convention de codage dans lURI
pour sauvegarder ltat de lobjet destinataire. Toute la flexibilit de
lusage de SOAP comme protocole de communication entre services Web
repose sur ces degrs de libert dans linterprtation des en-ttes et du
contenu des messages.
78
Dans le scnario dusage des services Web, dit de dcouverte des

services , lapplication Web doit initialement dcouvrir les URI des
services disponibles pour formuler correctement les requtes SOAP
appropries (voir figure 2-13).
Figure 2-13. Les tapes du protocole de dcouverte des services Web.
Ce protocole de dcouverte suppose que lon ait prtabli, dune part, des
annuaires consignant en un endroit public la correspondance entre URL
et services et, dautre part, une description de ces services qui les rend lisibles par lapplication client (voir figure 2-14). Annuaires et descriptions de
services font lobjet de normalisations en XML (UDDI et WSDL1, respectivement) indispensables lutilisation de SOAP dans larchitecture de
services Web.
CORBA
Dans la norme Corba, il est prcis que lORB dispose dun annuaire interne permettant de dterminer sans ambigut ladresse IP du serveur et le code excutable de lobjet Corba charg de traiter une requte. Le choix de la technique
dimplmentation de cet annuaire interne est laiss libre aux diteurs de logiciels. En gnral, les compilateurs IDL se chargent dactualiser cet annuaire pendant la phase de dveloppement. Cet annuaire est diffrent de ceux fournis par
les CorbaServices de plus haut niveau, Naming et Trader Services.
DCOM
Dans larchitecture de composants logiciels DCOM de Microsoft, le registre joue

prcisment le rle de cet annuaire. Chacune des entres du registre comporte
toutes les informations ncessaires lexcution dune mthode dun objet
DCOM.
79
Les standards
WSDL (Web Services
Description
Language) et UDDI
(Universal Description, Discovery and
Integration) sont
dcrits respectivement aux chapitres 3
et 4.
Figure 2-14. Les tapes du protocole de dcouverte des services Web avec un annuaire UDDI externe.
SOAP employ pour lappel

une procdure distante
Lun des objectifs des concepteurs de SOAP tait de fournir un mcanisme
universel dappel de procdure distant (RPC). cette fin, la norme, aprs
avoir insist sur la gnralit des messages SOAP, propose un certain
nombre de conventions pour lusage de SOAP comme vhicule dinvocation de procdures distantes. Ces conventions sont videmment conformes aux rgles de codage SOAP prcdemment dcrites et sappliquent
quel que soit le protocole de transport choisi (HTTP, HTTPR, SMTP).
Pour servir dappel une procdure distante, le message SOAP doit contenir linformation suivante :
ladresse URI du destinataire SOAP du message ;
le nom de la procdure ou de la mthode excuter ;
la signature ventuelle de la mthode ;
80
les paramtres passer en entre la procdure ;

des donnes supplmentaires facultatives.
Le corps dun message SOAP RPC

Les invocations et les rsultats de lexcution sont transports dans le
corps du message SOAP (sous la balise <Body>), suivant les conventions
suivantes :
Une invocation est reprsente par une donne de type struct de
mme nom.
Il y a un accesseur pour chaque paramtre [in] ou [in/out] nomm
daprs le nom du paramtre reprsent, et ce dans le mme ordre que
dans la signature de la mthode.
Un rsultat est aussi reprsent par une donne de type struct.
Il y a un accesseur pour le rsultat et pour chaque paramtre [out] ou
[in/out], galement nomms lidentique et dans le mme ordre que
dans la signature.
Une dfaillance est reprsente par une balise SOAP <Fault>.
Par convention, lexistence dun rsultat dnote le succs de lexcution
de la procdure, la prsence de la balise <Fault>, son chec. Il est donc
illgal davoir la fois un rsultat et une balise <Fault> dans la mme
rponse SOAP RPC.
Len-tte dun message SOAP RPC

Il est possible dutiliser len-tte, de toute manire facultatif, dun
message SOAP pour passer des donnes complmentaires lors de linvocation. Ces donnes ne font, en gnral, pas partie de la signature de la
mthode mais peuvent nanmoins se rvler indispensables la bonne
excution de la procdure appele (un contexte de transaction, par exemple).
Ainsi, lappel de la procdure distante DetailsValeursCours se
prsenterait sous la forme suivante (ici avec le protocole de transport
HTTP) :
POST /StockQuote HTTP/1.1
Host: www.serveurWebBoursier.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "http://example.org/2001/06/titres"
<env:Envelope xmlns:env="http://www.w3.org/2001/06/
soap-envelope" >
<env:Body>
<m:DetailsValeursCours
env:encodingStyle="http://www.w3.org/2001/06/
soap-encoding"
81
xmlns:m="http://example.org/2001/06/titres" >
<Symbole>BLZE</Symbole>
<Compagnie>Blaze Software Corp.</Compagnie>
<Prix>34.1</Prix>
</m: DetailsValeursCours >
</env:Body>
</env:Envelope>
dont lquivalent dans un langage de programmation comme Java serait :

Mthode :
PrixEtVolume DetailsValeursCours( String Symbole,
String Compagnie, float prix)
Appel :
DetailsValeursCours( "BLZE", "Blaze Software Corp.",
34.1 )
Le rsultat serait reprsent par la rponse SOAP suivante, toujours avec
le protocole de transport HTTP :
HTTP/1.1 200 OK
<env:Envelope
xmlns:env="http://www.w3.org/2001/06/soap-envelope" >
<env:Body>
<m: DetailsValeursCoursResponse
env:encodingStyle="http://www.w3.org/2001/06/
soap-encoding"
xmlns:m="http://example.org/2001/06/titres" >
<PrixEtVolume>
<Dernier>34.5</Dernier>
<Volume>10000</Volume>
</ PrixEtVolume >
</m: DetailsValeursCoursResponse >
</env:Body>
</env:Envelope>
Dans le cas dune dfaillance, on aurait un message SOAP du type :

HTTP/1.1 500 Internal Server Error
<env:Envelope xmlns:env="http://www.w3.org/2001/06/
soap-envelope" >
<env:Body>
<env:Fault>
<faultcode>env:Server</faultcode>
<faultstring>Server Error</faultstring>
<detail>
<e:myfaultdetails
xmlns:e="http://example.org/2001/06/faults" >
<message>Le serveur boursier Web na pas
fonctionn</message>
82
<errorcode>1001</errorcode>
</e:myfaultdetails>
</detail>
</env:Fault>
</env:Body>
</env:Envelope>
SOAP : la couche de communication

des services Web
SOAP se contente de spcifier un contenu XML aux documents HTTP, utilisable dans un protocole de communication fond sur lchange de messages entre une application et un service Web ou entre services Web. SOAP
est indpendant du contenu des messages proprement parler et laisse
la responsabilit de linterprtation de ces messages aux couches suprieures des protocoles de communication.
Cette versatilit permet demployer SOAP diverses tches dintgration dapplications. lintrieur du rseau intranet de lentreprise,
SOAP peut ventuellement se substituer aux couches de transport des
middleware propritaires (Corba, DCOM, RMI) et faciliter lintgration
de progiciels acquis et installs sparment, par exemple, par diffrents dpartements de lentreprise. Ainsi, alors que la plupart des
grands diteurs de progiciels travaillent sur la publication des fonctions de leurs applications laide de XML Schema, le besoin dun hub
capable de transmettre et de router les messages SOAP se fait sentir.
Cest ce quon appelle un serveur dintgration, connect au rseau local
de lentreprise et orchestrant le ballet des messages SOAP entre progiciels.
Vis-vis de lextrieur, SOAP et ses spcifications sont utiliss pour
communiquer avec les annuaires et les services Web ou applications Web
externes. Ce rle peut dailleurs tre confi au serveur dintgration luimme, correctement scuris par un pare-feu, ou encore un serveur
Web, comme Apache ou IIS, dot dun moteur XML pour le traitement des
messages.
SOAP apparat donc comme ce quon fait de plus universel et de plus flexible comme contenant dans une couche basse de communication entre
applications ou services Web. De plus, linterprtation des URI identifiant
metteurs et destinataires, tant laisse libre, cela permet de mettre bout
bout SOAP et des protocoles de communication de middleware non
fonds sur le Web.
83
SOAP apparat comme un standard de facto, de nombreux fournisseurs et

diteurs de logiciels en fournissant aujourdhui des implmentations
commerciales. Cette spcification a t retenue par le W3C dans le cadre,
plus large, d'un groupe de travail sur lutilisation dXML pour lchange et
le transport de donnes, baptis XML Protocol.
84

Communiquer SOAP

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Communiquer SOAP

Uploaded by

Copyright:

Available Formats

Chapitre 2

Simple Object Access Protocol

Services Web avec SOAP, WSDL, UDDI, ebXML

Protocoles de RPC et SOAP

Les protocoles de communication orients objet

Chapitre 2 Communiquer : SOAP

Messages de requte et de rponse dans les RPC orients objet

Identit de lobjet destinataire

Identit de linterface de lobjet

Identit de la mthode de linterface

Les identits de lobjet, de linterface, et de lopration de cette dernire,

Services Web avec SOAP, WSDL, UDDI, ebXML

De plus, mme si la conformit Corba assure une compatibilit minimale

Sur le Web, la situation est compltement diffrente : la qualit de service

Chapitre 2 Communiquer : SOAP

Figure 2-1. change HTTP entre navigateur et serveur Web.

Services Web avec SOAP, WSDL, UDDI, ebXML

Chapitre 2 Communiquer : SOAP

Services Web avec SOAP, WSDL, UDDI, ebXML

Figure 2-4. Communication synchrone fiable.

Chapitre 2 Communiquer : SOAP

XML comme format neutre de reprsentation

La structure des messages SOAP

Figure 2-5. La structure

Services Web avec SOAP, WSDL, UDDI, ebXML

Lenveloppe SOAP : <SOAP-ENV:Envelope>

Lenveloppe est la racine du document XML contenant le message SOAP,

Lexemple suivant montre un message SOAP que pourrait envoyer un

Chapitre 2 Communiquer : SOAP

La rponse du serveur aurait la mme structure :

Lattribut encodingStyle, dont la valeur est un URI, spcifie quelles

Len-tte SOAP : <SOAP-ENV:Header>

Services Web avec SOAP, WSDL, UDDI, ebXML

Chapitre 2 Communiquer : SOAP

Cette extension est une implmentation du pattern classique appel chane de

Le corps du message SOAP : <SOAP-ENV:Body>

Les rgles de codage des diffrents types de donnes

Services Web avec SOAP, WSDL, UDDI, ebXML

galement tre un pointeur vers un lment, dit alors indpendant. Un

Une instance particulire de cette classe apparatrait alors dans le corps

Chapitre 2 Communiquer : SOAP

La classe Java correspondante tant :

Cette reprsentation ne capture pas le fait que le compte B, intermdiaire,

Services Web avec SOAP, WSDL, UDDI, ebXML

Chapitre 2 Communiquer : SOAP

seconde au crdit. Il faudrait, en quelque sorte, factoriser la structure

Ici, le compte intermdiaire fait lobjet dune dfinition part laquelle la

Il sera reprsent dans un message SOAP, pour un jeu donn de valeurs,

Services Web avec SOAP, WSDL, UDDI, ebXML

Lattribut xsd dans llment points fait rfrence la norme XML

SOAP avec pices jointes

Chapitre 2 Communiquer : SOAP

Figure 2-9. Dclaration de dgt pour lassurance : message SOAP avec

Les rfrences aux pices jointes dans le message SOAP

Services Web avec SOAP, WSDL, UDDI, ebXML

rfrence au dfaut thismessage:/ en cas dabsence dune telle

Chapitre 2 Communiquer : SOAP

Le routage des messages SOAP : WS-Routing

Services Web avec SOAP, WSDL, UDDI, ebXML

de la spcification SOAP, sest attaqu la dfinition dun mcanisme

Le modle de routage des messages de WS-Routing

Chapitre 2 Communiquer : SOAP

En-tte SOAP utilis pour conserver linformation de

Message SOAP contenant un en-tte WS-Routing.