Chapitre 2. Communiquer : SOAP

Transcription

1 Chapitre 2 Communiquer : SOAP SOAP est une spécification de communication entre services Web par échange de messages en XML au travers du Web. Simple et facile à implémenter dans les serveurs Web ou dans les serveurs d applications, SOAP est indépendant des langages de programmation ou des systèmes d exploitation employés pour l implémentation des services Web. Les concepteurs de SOAP ont, en effet, réussi à préserver la plus grande généralité dans la représentation en XML des principes des protocoles de communication. S inspirant des générations précédentes de RPC (Remote Procedure Call) et de RPC objet (Corba, DCOM), ils se sont attachés à en formaliser la définition dans des documents XML échangés sur le Web, sous forme de dialogue entre le client et le serveur. SOAP repose sur XML et sur quelques standards dérivés, 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 d intégration d applications d entreprise, et permettre la communication entre applications et services Web, en particulier dans un contexte d échanges interentreprises. Conçu pour s appuyer 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 déjà installés sur la Toile, tout au plus des extensions. SOAP permet également, grâce au support de XML Schema, de s interfacer avec des applications préexistantes en capturant leurs structures de données quelle que soit la complexité de ces dernières. 47

2 Services Web avec SOAP, WSDL, UDDI, ebxml SOAP est développé conjointement par Microsoft, IBM, Lotus Development (une division d IBM), DevelopMentor et UserLand Software sous les auspices du W3C. SOAP 1.1 fit l objet d une note soumise au W3C en mai 2000, et SOAP 1.2 d un document de travail (working draft) en juillet Microsoft a déjà, quant à lui, annoncé l intégration de SOAP dans la plateforme.net, en particulier dans BizTalk Server, le fer de lance de la stratégie Internet de l éditeur de Redmond. SOAP est défini comme un protocole léger d échange de données dans un réseau de pair à pair, c est-à-dire décentralisé. S appuyant sur XML, SOAP propose un mécanisme simple de représentation des différents aspects d un message entre applications. N imposant aucun modèle de programmation spécifique, SOAP peut donc être utilisé dans tous les styles de communication : synchrone ou asynchrone, point à point ou multipoint, intranet ou Internet. La spécification SOAP se divise en quatre parties : l enveloppe SOAP, qui définit le contexte d un message, son destinataire, son contenu et différentes options ; les règles de codage SOAP, définissant la représentation des données d une application dans le corps d un message SOAP (en particulier leur structure) ; un protocole de RPC définissant la succession des requêtes et des réponses ; ladéfinition de l utilisation de HTTP comme couche de transport des messages SOAP. Les règles de codage utilisent abondamment XML Schema pour décrire la structure des données constitutives des messages SOAP. Protocoles de RPC et SOAP SOAP se classe parmi les protocoles de communication orientés objet, reprenant les principes traditionnels de RPC (Remote Procedure Call) des protocoles antérieurs, comme DCOM ou IIOP. SOAP ne bouleverse donc pas l architecture de communication éventuellement préexistante dans le réseau de l entreprise. Bien au contraire, le rapprochement des principes de SOAP de ceux d autres RPC facilite l intégration des différents protocoles et assure une excellente interopérabilité à moindre coût à la jonction de l intranet et de l Internet. Les protocoles de communication orientés objet Depuis les années 1980, les deux protocoles de communication les plus communément utilisés sont Sun RPC, la base du système de gestion de fichiers répartis NFS, et DCE (Distributed Computing Environment), dont DEC 48

3 Chapitre 2 Communiquer : SOAP fut à l origine le champion, repris par Microsoft dans DCOM. Les travaux de l OMG, d une part, et l apport radical de COM aux produits de Microsoft, d autre part, ont produit, dans les années 1990, des versions orientées objet de ces RPC : IIOP dans la norme Corba bien qu officiellement la norme stipule qu un 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 impérativement contenir certaines données (identité des objets et des méthodes appelées, leurs paramètres, etc.) : Messages de requête et de réponse dans les RPC orientés objet (IIOP, DCOM, RMI) REQUÊTE RÉPONSE Identité de l objet destinataire Identité de l interface de l objet Identité de la méthode de l interface État du traitement En-tête éventuel Paramètres En-tête éventuel Paramètres Les identités de l objet, de l interface, et de l opération de cette dernière, indiquent au destinataire du message que faire de la requête ; les données figurant dans le corps du message sont constituées des paramètres des opérations, de leurs qualificatifs (in, out, ou inout) et de leur type. Les entêtes de messages sont prévus pour des informations complémentaires parfois indispensables pour la correcte exécution de la requête (le contexte transactionnel, par exemple). Dans la réponse, un code indique ce qu il est advenu de la requête au cours de son traitement par le serveur (réussite, échec, rejet) et les paramètres contiennent, le cas échéant, les données attendues en retour par l émetteur. IIOP, DCOM et RMI diffèrent quant à la nature des informations véhiculées par ces messages mais pas sur leur structure. Dans IIOP, les objets ne portant qu une seule interface, l identité de celle-ci est donc implicite : c est celle de l objet destinataire. Dans le cas de DCOM, au contraire, un objet portant éventuellement plus d une interface, cette information supplémentaire est indispensable. Dans IIOP, les paramètres constituant le corps du message suivent le format CDR (Common Data Representation) défini dans la norme Corba ; dans DCOM, ceux-ci sont codés suivant le format NDR (Network Data Representation) de Microsoft. De même, les identités d objets dans Corba sont des IOR (Interoperable Object Reference) qui 49

4 Services Web avec SOAP, WSDL, UDDI, ebxml n ont rien de commun avec le format utilisé par DCOM, les OBJREF représentés par les UUID, des suites de 128 caractères hexadécimaux. DCOM et IIOP sont adaptés à des réseaux se caractérisant par une qualité de service homogène, une latence contrôlée et une administration rigoureuse. C est plutôt le cas des réseaux intranet d entreprise. CORBA De plus, même si la conformité à Corba assure une compatibilité minimale entre systèmes d exploitation différents, les produits commerciaux des éditeurs n offrent pas nécessairement le même niveau de service, en particulier en ce qui concerne les transactions ou la sécurité. Sur le Web, la situation est complètement différente : la qualité de service et la latence sont variables, et le réseau résulte plus de l agrégation de nœuds et de sous-réseaux hétérogènes partageant la couche TCP/IP la plus profonde que d un développement discipliné. Seul un protocole simple mais robuste peut alors s accommoder, à l échelon supérieur, de tant de variabilité : HTTP. HTTP DNS (Domain Name Server) : nœuds Internet responsables de l identification de l adresse IP d une machine d après son nom (URL). À l instar de DCOM et d IIOP, HTTP est une couche RPC au-dessus de TCP/ IP. Les requêtes et les réponses HTTP sont traitées par un serveur Web (comme IIS de Microsoft ou comme Apache) auquel se connecte un client HTTP, généralement un navigateur Web. Requêtes et réponses sont composées d un en-tête et d un corps de message ; toutes sont exprimées en texte ASCII (et non en binaire comme dans les protocoles précédents). Lors d un é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 DNS 1 de trouver l adresse IP correcte. La requête et la réponse HTTP circulent sur ce canal qui ne reste ouvert, par défaut, que le temps d un échange. Si plusieurs requêtes sont issues du même client vers le même serveur c est le cas par exemple pour le téléchargement d une page Web contenant des images stockées sous forme de fichiers séparés sur le serveur, la requête peut indiquer que le canal doit rester ouvert par l option Keep-Alive. Le protocole HTTP prévoit tout une série de codes d erreur (dont le fameux code 404 illustré par la figure 2-2) ou d information pour renvoyer, le cas échéant, le résultat du traitement de la requête au poste client. Requête et réponse HTTP ont chacune leur en-tête spécifique, qualifié par des mots-clés et leurs valeurs (voir annexe 1). 50

5 Chapitre 2 Communiquer : SOAP Figure 2-1. Échange HTTP entre navigateur et serveur Web. 51

6 Services Web avec SOAP, WSDL, UDDI, ebxml Figure 2-2. Échange entre navigateur et serveur Web en cas d erreur de traitement. 52

7 Chapitre 2 Communiquer : SOAP HTTPR HTTPR, pour HTTP Reliable (fiable), est une proposition d IBM, datant de juillet 2001, pour une extension du protocole HTTP visant à le fiabiliser. Ce sont des règles supplémentaires permettant d assurer que tous les messages HTTP sont livrés à leurs destinations exactement une fois et sans altération de leur contenu. En cas de défaillance, le protocole signale le message comme non livré. HTTPR est une extension de HTTP 1.1, héritant donc de toutes les possibilités de cette version quant à SSL, à la communication au travers des pare-feu (firewalls) et des proxies. Considérons le cas d un programme envoyant un ordre d achat à un serveur sur le réseau. En cas de défaillance de livraison du message sans avertissement de l émetteur, l ordre d achat est perdu. À l inverse, si le message est livré plusieurs fois sans que le destinataire ne soit notifié de la répétition, plusieurs ordres d achat seront effectivement passés au lieu d un. La solution classique est pour l émetteur de répéter l envoi du message jusqu à réception d un accusé de réception du destinataire. Du coup, le message doit lui-même contenir son identification afin que le destinataire reconnaisse les duplicatas éventuels. Cette solution reste néanmoins difficile à mettre en place dans tous les contextes de défaillance imaginables. Le schéma habituel sépare d ailleurs la logique de communication de la logique de l application comme l illustre la figure 2-3. Figure 2-3. Communication synchrone sans fiabilité. Dans le cas de défaillances dans l envoi ou dans la réception des messages, c est malgré tout aux programmes client et serveur de décider de la conduite à suivre, surchargeant ainsi chacune des applications. 53

8 Services Web avec SOAP, WSDL, UDDI, ebxml Figure 2-4. Communication synchrone fiable. Dans le cas d un protocole dit fiable (voir figure 2-4), la couche de communication est munie d une forme de mémoire persistante (fichiers, bases de données, etc.) à laquelle elle confie une copie de chaque message entrant et sortant, après leur avoir attribué un numéro ou une identité unique. Cette unicité permet de gérer correctement les renvois éventuels en cas de défaillance de communication ou bien de procéder à une comparaison avec un état antérieur des applications lorsque les applications ellesmêmes sont défaillantes. Le protocole est étendu aux communications asynchrones en dotant le programme client d une mémoire persistante, conservant l identité des messages envoyés et des messages de retour reçus. La proposition HTTPR d IBM suggère l implémentation de cette couche supplémentaire de gestion de transport au-dessus du protocole standard HTTP 1.1. L émetteur de messages utilise alors la requête HTTP Post pour transporter les informations supplémentaires, nécessaires à la gestion de la livraison des messages. La spécification prévoit que plusieurs «messages sécurisés» puissent être transportés dans la même requête HTTP de manière à diminuer la fréquence des échanges dans le cas d échanges importants. Des «agents HTTPR» de simples programmes intermédiaires qui envoient et réceptionnent les messages, associés à une sauvegarde persistante gèrent alors la communication avec fiabilité en s appuyant sur ces informations supplémentaires, ainsi que la reprise éventuelle sur erreur de transmission ou sur défaillance de l émetteur. 54

9 Chapitre 2 Communiquer : SOAP XML comme format neutre de représentation des données L idée originale apportée par SOAP est d associer au protocole HTTP un format neutre de représentation de données basé sur XML, remplissant le rôle joué par NDR ou par CDR dans les protocoles propriétaires objet DCOM et IIOP. En effet, tout comme NDR et CDR, XML est utilisable pour représenter textuellement des structures de données arbitrairement complexes. XML présente, de plus, des avantages considérables par rapport à ses prédécesseurs : plus grande disponibilité d outils de développement ou d interpréteurs facilitant son implémentation et sa diffusion ; représentation textuelle, évidemment plus lisible qu un format binaire ; plus grande facilité d extension ou de spécialisation, permettant des évolutions «en douceur» sans récriture systématique des programmes émetteur ou destinataire. S appuyant sur les normes NameSpaces et XML Schema, SOAP dispose d une richesse expressive permettant l expression de messages entre applications et services Web, aussi complexes soient-ils. La structure des messages SOAP Un message SOAP est un document XML constitué d une enveloppe contenant un en-tête (header) facultatif et le corps (body) du message (voir figure 2-5). Figure 2-5. La structure des messages SOAP. 55

10 Services Web avec SOAP, WSDL, UDDI, ebxml L enveloppe SOAP : <SOAP-ENV:Envelope> L enveloppe est la racine du document XML contenant le message SOAP, marquée par la balise <Envelope> (voir figure 2-6). La spécification impose que tous les attributs de cette balise et de celles imbriquées soient explicitement associés à un namespace, de manière à supprimer toute ambiguïté. Par convention, la spécification SOAP définit deux namespaces fréquemment utilisés : SOAP-ENV associé à l URI pour définir le namespace de l enveloppe dans la version 1.1, et à dans la version 1.2 reprise par le W3C. SOAP-ENC associé à l URI pour la définition des formats de types de données dans la version 1.1, et à / dans la version 1.2. Figure 2-6. La structure XML de l enveloppe SOAP (schéma généré avec l outil XML Spy). L exemple suivant montre un message SOAP que pourrait envoyer un programme client à un serveur offrant un service Web d information financière en ligne pour connaître la valeur d un titre : soap/enco- <SOAP-ENV:Envelope xmlns:soap-env -" SOAP-ENV :encodingstyle=" ding"> <SOAP-ENV:Body> <!-- Requête de la valeur d un titre --> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 56

11 Chapitre 2 Communiquer : SOAP La réponse du serveur aurait la même structure : <SOAP-ENV:Envelope xmlns:soap-env=" envelope" SOAP-ENV :encodingstyle=" soap/encoding"> <SOAP-ENV:Body> <!-- Valeur du titre --> </SOAP-ENV:Body> </SOAP-ENV:Envelope> L attribut encodingstyle, dont la valeur est un URI, spécifie quelles conventions sont employées dans cet élément (et dans tous ceux qu il contient) pour le format des données. La spécification propose des formats identifiés par l URI SOAP-ENC précédemment mentionné. A priori, rien n exclut de faire référence à des règles de codage et de représentation des données différentes de celles proposées par la norme, mais le cas reste exotique. L en-tête SOAP : <SOAP-ENV:Header> La balise <Header> permet de passer dans le message des informations complémentaires sur ce même message. Cet élément est facultatif, mais, s il est présent, doit être le premier dans l enveloppe SOAP du message. Quel en est l usage? L en-tête peut, par exemple, contenir des informations authentifiant l émetteur ou bien encore le contexte d une transaction dont le message n est qu une des étapes. Pour les couches de transport (comme FTP) ne fournissant pas, à l émission, d adresse de retour, on peut aussi utiliser l en-tête pour identifier l émetteur du message SOAP. L élément Header, et les éléments qu il contient, peuvent être qualifiés par l attribut mustunderstand qui prend la valeur 0 ou 1. La valeur 1 signale que le récepteur doit reconnaître l information présente dans l entête et que son traitement est obligatoire ; la valeur 0 indique que l en-tête peut être ignoré par le serveur. Ainsi est-il possible d étendre les fonctions du serveur, par exemple, sans remettre en cause les clients. L exemple suivant montre un en-tête transportant une adresse de courrier électronique : <SOAP-ENV:Header <exemple:emetteur xmlns:exemple==" SOAP-ENV:mustUnderstand="0"> MonNom@monDomaine.com </exemple:emetteur> </SOAP-ENV:Header> 57

12 Services Web avec SOAP, WSDL, UDDI, ebxml Le serveur peut ignorer cette information sans préjudice pour le traitement du corps du message (mustunderstand a la valeur 0). Un autre serveur pourra, quant à lui, utiliser cette information pour une trace d audit, par exemple, de l usage d un service Web. Un message SOAP peut avoir à «traverser» plusieurs intermédiaires avant d atteindre son destinataire final. Dans ce cas, l en-tête joue un rôle primordial : à chaque arrêt le long de l itinéraire, le serveur intermédiaire extrait de l en-tête ce qui le concerne en propre et ajoute ce qui est nécessaire au serveur intermédiaire suivant (voir figure 2-7). Les éléments concernant un serveur intermédiaire sont marqués par la présence de l attribut SOAP-ENV:ACTOR avec une valeur conventionnelle : SOAP-ENV:Actor=" Figure 2-7. L en-tête dans une série de transferts successifs de messages SOAP 58

13 Chapitre 2 Communiquer : SOAP CORBA Cette extension est une implémentation du pattern classique appelé «chaîne de responsabilité» (chain of responsibility) n 223 dans la classification originale du dictionnaire de Design Patterns de Gamma, Helm, Johnson et Vlissides découplant le client du serveur en donnant à plus d un serveur la possibilité de traiter la requête. Le corps du message SOAP : <SOAP-ENV:Body> Le corps du message est constitué du seul élément, contenant un ou plusieurs sous-éléments. Ces sous-éléments sont les suivants : FAULT, indiquant une erreur ou une défaillance en réponse à une requête. Des données destinées au destinataire du message, à un format défini par les règles de codage SOAP. Initialement, le corps de message SOAP était conçu pour passer des appels de procédures distants, c est-à-dire des requêtes au sens OMG du terme (un objet, une méthode et les valeurs de ses arguments) et des résultats ou des messages d erreur. Mais, en fait, l usage s est élargi et le corps du message est souvent utilisé pour simplement passer des données structurées entre applications. Dans le cas de la défaillance (Fault), de nouveaux sous-éléments sont employés pour signaler le type de l erreur et pour renvoyer à l émetteur des informations supplémentaires indiquant la raison de l échec de l appel. Les codes d erreurs sont également normalisés par la spécification SOAP. Les règles de codage des différents types de données Les règles de codage font appel à des balises définies dans le second namespace propre à SOAP ( Il est également possible de spécifier des namespaces de substitution, propres à l utilisateur, pour définir ou redéfinir ces balises de codage de données en réponse à des besoins particuliers. Toutes les valeurs des données d une requête ou d une réponse suivent la série de règles suivantes : Les valeurs dites simples (comme les entiers ou les chaînes de caractères) apparaissent directement entre les balises. Font l objet d un traitement particulier les valeurs dites composées, constituées de champs qualifiés d un nom, d un numéro d ordre, ou des deux. Cette qualification est appelée un accesseur. On définit les structures, des valeurs composées dont les accesseurs sont tous des noms, et les tableaux, des valeurs composées dont les accesseurs sont tous des numéros d ordre. Les éléments représentant ces valeurs sont dits inclus ou indépendants. Un élément inclus dans une structure composée représente directement la valeur du champ considéré de la structure. Mais la valeur du champ peut 59

14 Services Web avec SOAP, WSDL, UDDI, ebxml également être un pointeur vers un élément, dit alors indépendant. Un élément indépendant est une valeur qui peut être ainsi partagée par plusieurs éléments dans le corps d un même message. Bien que ce n en soit pas le seul usage possible, SOAP est principalement employé pour transporter entre services Web des requêtes et le résultat de leur exécution un usage qui trouve aussi son champ d application dans l intégration d applications d entreprises. Comme dans un middleware, une requête SOAP contient alors le nom d une méthode ou d une fonction invoquée sur le site Web distant avec l ensemble de ses paramètres. La réponse SOAP contient, quant à elle, le résultat de l exécution de cette fonction ou un code d erreur signalant une défaillance. Ainsi, dans l usage courant de SOAP, il est relativement simple de mettre en correspondance les messages émis et reçus avec les objets et le programme implémentant tel ou tel service Web. Reprenons l exemple (classique) d une opération sur un compte bancaire défini, par exemple, par la méthode Java suivante sur le serveur : package banque public void operation{ public int compte; public float montant ; } Une instance particulière de cette classe apparaîtrait alors dans le corps d un message sous la forme de la structure SOAP suivante : <t:operation xmlns:t=" <compte>125612</compte> <montant>250.75</montant> </t:operation> dans laquelle les accesseurs sont les noms Compte et Montant utilisés comme balises. Une transaction débit-crédit, à peine plus complexe, serait de la même manière représentée dans un message sous la structure SOAP suivante : <t:transaction xmlns:t=" <credit> <compte>125612</compte> <montant>250.75</montant> </credit> <debit> <compte>125760</compte> <montant>250.75</montant> </debit> </t:transaction> 60

15 Chapitre 2 Communiquer : SOAP La classe Java correspondante étant : package banque public class transaction{ public operation credit; public operation debit; } Une fois ces structures définies, l appel d une méthode Java sur ces opérations se déroule suivant le schéma de la figure 2-8. Les finesses supplémentaires se greffant à ces règles générales telles que la représentation en SOAP de la nullité ou de l absence de certains champs d une valeur composée, font appel à des mécanismes standardisés de représentation des données complexes, traités par la norme XML Schema. C est aussi le cas dans la situation où la valeur d un champ d une structure se trouve être une instance d un sous-type du type prévu (dans le cas que nous exposons, il suffit d imaginer par exemple une sous-classe de la classe Operation contenant des champs supplémentaires : ces derniers doivent alors figurer également dans le message SOAP). Enfin, pour illustrer l usage des pointeurs à l intérieur d un message SOAP, ajoutons à notre scénario bancaire une seconde transaction débit-crédit faisant circuler le même montant entre trois comptes. La représentation «naïve» venant naturellement à l esprit est la suivante : <t:double-transaction xmlns :t=" <transaction-b-vers-c> <credit> <compte>125612</compte> <montant>250.75</montant> </credit> <debit> <compte>125760</compte> <montant>250.75</montant> </debit> </transaction-b-vers-c> <transaction-a-vers-b> <credit> <compte>125760</compte> <montant>250.75</montant> </credit> <debit> <compte>125900</compte> <montant>250.75</montant> </debit> </transaction-a-vers-b> </t:double-transaction> Cette représentation ne capture pas le fait que le compte B, intermédiaire, est le même dans les deux transactions, la première fois au débit, la 61

16 Services Web avec SOAP, WSDL, UDDI, ebxml Figure 2-8. Structure du programme traitant les messages SOAP sur le serveur 62

17 Chapitre 2 Communiquer : SOAP seconde au crédit. Il faudrait, en quelque sorte, factoriser la structure commune : c est précisément le rôle des éléments indépendants. On utilisera donc plutôt la représentation SOAP suivante : <t:double-transaction xmlns:t=" <transaction-b-vers-c> <credit> <compte>125612</compte> <montant>250.75</montant> </credit> <debit href="#id1" /> </transaction-b-vers-c> <transaction-a-vers-b> <credit href="#id1" /> <debit> <compte>125900</compte> <montant>250.75</montant> </debit> </transaction-a-vers-b> </t:double-transaction> <t:operation soap:id="id1" xmlns:t=" banque"> <compte>125760</compte> <montant>250.75</montant> </t:operation> Ici, le compte intermédiaire fait l objet d une définition à part à laquelle la transaction principale fait référence par le truchement de l identifiant id1. Notons au passage que la valeur d un accesseur peut être soit une constante (comme dans <montant>250.75</montant>), soit un URI agissant comme un pointeur (comme dans l expression <debit href="#id1"/>). Dans ce dernier cas, plusieurs valeurs composées peuvent alors faire référence au même élément indépendant à l intérieur d un message SOAP. Pour conclure, nous donnons l exemple d un tableau et de sa représentation dans un message SOAP. Le tableau suivant, défini dans l IDL de DCOM, décrit un ensemble de points : struct POINTLIST{ long celem; [size_is(celem)] POINT points[]; }; Il sera représenté dans un message SOAP, pour un jeu donné de valeurs, sous la forme d un 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

18 Services Web avec SOAP, WSDL, UDDI, ebxml <POINT><x>5</x><y>6</y></POINT> <POINT><x>7</x><y>8</y></POINT> </points> </t:pointlist> L attribut xsd dans l élément points fait référence à la norme XML Schema. Il permet de stipuler le type, au sens de la structure de données, du champ représenté par l élément points. Dans l exemple, ce schéma est supposé défini dans l URI du namespace spécifié dans la balise de l élément t:pointlist. SOAP avec pièces jointes Dans le cas où le message comporte des données binaires ne se prêtant pas à une représentation textuelle, un mécanisme standard d inclusion du message SOAP dans un message MIME composite (multipart/related message) permet de préserver les règles de traitement du message SOAP. C est le cas dans le scénario de la relation entre compagnies d assurances dans lequel formulaires signés et photos de dégâts doivent être échangés (voir figure 2-9), ou bien dans celui d une collaboration dans le secteur du bâtiment, dans lequel des dessins d architecte 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 d un type particulier. La spécification MIME (RFC 2387) précise comment mêler dans un même message différents types de données, sous le type particulier multipart/related. Les règles de construction d un message SOAP avec pièces jointes sont les suivantes : Le message SOAP à proprement parler apparaît le premier dans le message MIME, et donc le type figurant dans l en-tête multipart/ related est celui des messages SOAP : text/xml Les autres éléments du message MIME doivent présenter un en-tête MIME comportant soit l attribut Content-ID, soit l attribut Content- Location pour pouvoir être identifiés sans ambiguïté. Le traitement du message SOAP se fait suivant les règles habituelles spécifiées dans la norme. 64

19 Chapitre 2 Communiquer : SOAP Figure 2-9. Déclaration de dégât pour l assurance : message SOAP avec fac-similé du formulaire signé en pièce jointe Les références aux pièces jointes dans le message SOAP Pour qu on puisse faire référence à des pièces jointes depuis l en-tête ou depuis le corps d un message SOAP, on utilise une astuce des règles de codage des messages SOAP. La norme SOAP 1.2 permet à la valeur d un accesseur d être une référence plutôt qu une constante (entier, chaîne de caractères ). La référence est alors exprimée par un URI. Pour le cas présent, la norme SOAP avec pièces jointes utilise ce degré de liberté et stipule simplement des conventions de construction d URI qui pointent vers les pièces 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 référence : Si l attribut Content-Location est présent 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 même attribut est présent mais contient un URI relatif (voir figure 2-11, page 67), l URI absolu est constitué en référence au plus proche contenant MIME qualifié par un Content-Location absolu ou en 65

20 Services Web avec SOAP, WSDL, UDDI, ebxml référence au défaut «thismessage:/» en cas d absence d une telle racine (pour les pièces jointes complexes ou imbriquées). Si l attribut Content-ID est présent, il existe une méthode normalisée de construction d un URI à partir de sa valeur (RFC 2111). Figure Références à des pièces jointes dans un message SOAP : URI absolu Notons qu un message SOAP peut parfaitement ne pas faire référence aux pièces jointes groupées avec lui dans le même message MIME. De même, la résolution effective des URI d un message SOAP faisant référence à des pièces jointes n est pas nécessairement du ressort de l interpréteur SOAP lui-même : en fonction du traitement du message, ces références seront résolues ou non par le service Web sollicité. SOAP avec pièces jointes induit quelques changements mineurs dans les requêtes suivant le protocole de transport auquel on fait appel, HTTP ou SMTP, par exemple. Dans le premier cas, l attribut Content-Type: Multipart/Related apparaît dans l en-tête HTTP à l exclusion de tous les attributs HTTP redondants avec ceux de MIME (comme Content- Transfer-Encoding, par exemple). Dans le second cas, les en-têtes SMTP et MIME sont simplement fusionnés : il n y a pas de redondance. 66

21 Chapitre 2 Communiquer : SOAP Figure Références à des pièces jointes dans un message SOAP : URI relatif L importance de SOAP avec pièces jointes pour les services métier est indiscutable. Le consortium ebxml, par exemple, a abandonné son protocole de messagerie «propriétaire» pour adopter SOAP dès que ce dernier protocole a permis l attachement de pièces jointes. SOAP avec pièces jointes contribue à la généralisation de l adoption 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 l automatisation des processus métier, le routage des messages, c est-à-dire la détermination des chemins de diffusion des messages, est essentiel. En effet, l intégrité des données et le bon aboutissement des processus reposent au bout du compte sur le bon ordre de la transmission des messages et de la réémission éventuelle de ceux qui se sont égarés. Microsoft, promoteur actif 67

22 Services Web avec SOAP, WSDL, UDDI, ebxml de la spécification SOAP, s est attaqué à la définition d un mécanisme général de routage utilisable dans ce cas. D abord connu sous le nom de SOAP-RP (SOAP Routing Protocol), la spécification a été affinée et publiée 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, définissant l échange de messages unidirectionnel entre un émetteur et un récepteur au travers d un certain nombre d intermédiaires. De plus, WS-Routing construit automatiquement un chemin de retour pour les réponses du récepteur à l émetteur originel. Ainsi, grâce à WS-Routing il est possible d établir toutes sortes de modes de communication par messages SOAP : point à point, requête/réponse, accusés de réception et notifications de défaillance. WS-Routing rajoute simplement des informations dans un en-tête inclus dans l enveloppe SOAP, ce qui rend ce protocole relativement indépendant de la couche de transport choisie pour la transmission des messages eux-mêmes (TCP, UDP et HTTP). Grâce à cette possibilité de construction des chemins de retour, il devient alors possible de corréler divers messages échangés entre serveurs. La corrélation de messages et WS-Routing, mis en œuvre dans BizTalk, par exemple, sont des dispositifs essentiels pour l administration des processus métier et l interprétation des traces d audit dans les phases de développement et de test. Le modèle de routage des messages de WS-Routing Dans le protocole SOAP, l attribut permet d indiquer le destinataire final de telle ou telle partie du message, mais rien ne permet a priori d expliciter la séquence d intermédiaires au travers desquels le message doit passer avant d atteindre ce destinataire. WS-Routing est conçu pour pallier cette difficulté et fournir automatiquement les informations nécessaires pour corréler les échanges de messages entre les nœuds de traitement SOAP. La spécification WS-Routing définit une terminologie, présentée dans le tableau résumé suivant : Le protocole définit les opérations suivantes : L émetteur initial indique dans un en-tête WS-Routing le destinataire final du message ainsi que des intermédiaires WS-Routing éventuels qui définissent le chemin WS-Routing. Le message est transmis au premier nœud WS-Routing indiqué ; si celui-ci est un intermédiaire, il relaie le message au nœud suivant du chemin WS-Routing. 68

23 Chapitre 2 Communiquer : SOAP Terme En-tête WS-Routing Message WS-Routing Défaillance WS-Routing Émetteur/récepteur WS-Routing Chemins WS-Routing Commentaire En-tête SOAP utilisé pour conserver l information de routage, associé au namespace Message SOAP contenant un en-tête WS-Routing. Notification de défaillance SOAP contenant un en-tête WS-Routing. Application créant ou recevant un message WS-Routing lié à un protocole de transport donné. Le chemin et le chemin de retour WS-Routing sont constitués de la séquence (et de la même en ordre inverse) des émetteurs et des récepteurs WS-Routing au travers desquels circule un message WS-Routing. Chemin de retour WS-Routing Intermédiaire WS-Routing Proxy WS-Routing Tunnel WS-Routing Gateway WS-Routing Ce chemin est construit automatiquement par le protocole lors de la transmission initiale de l émetteur au récepteur. Ce chemin est éventuellement utilisé pour faire parvenir à l émetteur les réponses du récepteur. Un nœud jouant à la fois le rôle d émetteur et de récepteur WS-Routing. Intermédiaire WS-Routing jouant un rôle explicite dans la transmission des messages WS-Routing. Intermédiaire WS-Routing jouant un rôle de relais entre deux canaux de communications sans participer explicitement à la transmission des messages SOAP. Un destinataire final WS-Routing assurant la traduction de SOAP vers un autre protocole (par exemple, la traduction d un message SOAP en un flux de commandes Telnet). À certaines conditions, un intermédiaire WS-Routing peut ajouter dynamiquement de nouveaux intermédiaires au chemin de routage. Le chemin n a donc pas nécessairement à être complètement connu au moment de l émission des messages. Enfin, l intermédiaire 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 récepteurs originels. Cette communication bi-directionnelle permise par WS-Routing est indépendante de la couche de transport physique retenue pour l échange des messages. La spécification n impose pas de choix et propose, par exem- 69

24 Services Web avec SOAP, WSDL, UDDI, ebxml ple, des liaisons WS-Routing pour TCP (qui est bi-directionnel) et pour UDP (qui n est pas bi-directionnel). Le rôle des intermédiaires WS-Routing est finalement de permettre l accès aux informations relatives à la transmission des messages SOAP et de faciliter le franchissement de barrières spécifiques de communications (pare-feu, protocoles spécifiques de transport, etc.). Les informations de transmission de messages SOAP sont utiles à des applications d administration, par exemple, ainsi éventuellement qu à des applications complémentaires assurant des services de sécurité, d audit, de chiffrement ou d authentification et de collaboration reposant sur l examen des itinéraires suivis par les messages échangés dans un réseau SOAP. C est dans ces derniers cas qu un intermédiaire WS-Routing peut être amené à ajouter un intermédiaire WS-Routing dynamiquement. Nous retrouvons ici le pattern d interposition de services, dont l usage est général dans les serveurs d applications avec la notion de composant logiciel et de conteneur. Ainsi, par exemple, l authentification de la communication entre un émetteur et un récepteur SOAP peut simplement être assurée par un intermédiaire WS-Routing qui ajoute systématiquement aux chemins WS-Routing sur lequel il se trouve, un détour par un autre intermédiaire WS-Routing chargé de la vérification de l identité de l émetteur. Ainsi les messages sont automatiquement authentifiés sans que l émetteur ou le destinataire n aient eux-mêmes à appeler explicitement le service d authentification. Les gateways WS-Routing assurent la traduction entre le protocole véhiculant les messages SOAP et des protocoles extérieurs, spécifiques. Comme un connecteur, le gateway transpose les messages d un protocole de transport à l autre et, en retour, traduit (du mieux qu il est possible si l équivalence n est pas parfaite) les codes d erreurs et de défaillance du protocole externe. Les balises de WS-Routing WS-Routing définit de nouveaux éléments, tout d abord pour désigner les nœuds de routage le long du chemin : Balise WS-Routing to from via Définition URI du destinataire final du message. URI de l émetteur du message URI d un intermédiaire (imposé) sur le chemin. 70

25 Chapitre 2 Communiquer : SOAP Le chemin et le chemin de retour sont marqués par de nouveaux éléments : Balise WS-Routing fwd rev Définition Séquence d éléments via ordonnant la liste des intermédiaires WS-Routing à traverser. Séquence, inverse de la précédente, d éléments via indiquant le chemin de retour. L exemple suivant montre un message minimal sans intermédiaire et sans chemin de retour : <S:Envelope xmlns:s=" <S:Header> <m:path xmlns:m=" <m:action> </m: action> <m:to>soap://notification.com/some/endpoint</m:to> <m:id>uuid: b623-5dsf35sgs5d6 </m:id> </m:path> </S:Header> <S:Body> Le corps du message SOAP </S:Body> </S:Envelope> Seul l élément to est présent dans l en-tête WS-Routing indiquant ici une communication directe avec le destinataire. Dans le second exemple, un message est émis par A vers C via un intermédiaire WS-Routing B. Le message issu de A vers B est le suivant (avec un chemin de retour initialement vide) : <S:Envelope xmlns:s=" <S:Header> <m:path xmlns:m=" <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

26 Services Web avec SOAP, WSDL, UDDI, ebxml <m:id>uuid: b623-5dsf35sgs5d6 </m:id> </m:path> </S:Header> <S:Body> Le corps du message SOAP </S:Body> </S:Envelope> Le message ensuite émis de B vers C après traitement du précédent est alors : <S:Envelope xmlns:s=" <S:Header> <m:path xmlns:m=" <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>uuid: b623-5dsf35sgs5d6 </m:id> </m:path> </S:Header> <S:Body> Le corps du message SOAP </S:Body> </S:Envelope> Cette fois, l élément rev est automatiquement renseigné par le traitement au nœud B.De plus, B a ajouté et renseigné l attribut vid dans l élément rev, qui est l identité du canal de communication ayant reçu le message en provenance de A. Le cas échéant, B pourra ainsi réactiver ce canal pour faire parvenir à A des réponses éventuelles de C, ou d intermédiaires en aval de B. WS-Routing assure ainsi la complète indépendance des différents segments sur le chemin initial et le chemin de retour. Des protocoles de transport peuvent, par exemple, lier A et B, d une part, et B et C, d autre part, sans remettre en cause ni l application émettrice ni le destinataire du message. Pour assurer la corrélation des messages, l élément id contient l identité unique de chaque message en circulation. Le nouvel élément relatesto permet de faire référence à l identité d un autre message dans l en-tête WS-Routing. Ainsi, par exemple, une réponse circulant de C vers A, arrive- 72

27 Chapitre 2 Communiquer : SOAP rait d abord au nœud intermédiaire B sous la forme du message SOAP suivant : <S:Envelope xmlns:s=" <S:Header> <m:path xmlns:m=" <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-adfg- 9kd84jd9mjdld43</m:id> <m:relatesto> uuid: b623-5dsf35sgs5d6 </m:relatesto> </m:path> </S:Header> <S:Body> Le corps du message SOAP </S:Body> </S:Envelope> Dans ce message, l élément fwd est construit à partir du contenu de l élément rev des messages initiaux. L élément relatesto indique, en référence, à quel message originel cette réponse correspond. Enfin, WS-Routing définit également des codes d erreur en cas de défaillance. Ces codes apparaissent dans l élément fault de SOAP le cas échéant. Le tableau suivant résume les différentes défaillances et leurs codes : Liaisons WS-Routing vers les protocoles de transport La spécification décrit comment lier WS-Routing aux protocoles de transport TCP, UDP et HTTP. Il est également possible de développer des liaisons à des protocoles de transport spécifiques autres que ceux présentés dans ce projet de norme. Les liaisons TCP et UDP utilisent un mécanisme d encapsulation proposé par Microsoft à l IETF en février 2002 : DIME (Direct Internet Message Encapsulation). DIME est un format binaire «léger» de message permettant d encapsuler plusieurs parties de natures et de types différents dans le même message. En caricaturant, il s agit d une version légère de MIME, le mécanisme d encapsulation du courrier électronique. Chaque partie est identifiée par un nom, un type, une taille et un numéro d ordre, chacun de 73

28 Services Web avec SOAP, WSDL, UDDI, ebxml ces identifiants étant compatible avec les équivalents MIME. Dans l architecture de services Web de Microsoft, DIME permet d encapsuler un message SOAP avec ses pièces jointes sous une forme moins lourde à traiter que dans le cas du codage MIME. Code d erreur WS-Routing Signification Défaillance à l émission 700 Invalid WS-Routing Header En-tête invalide. 701 WS-Routing Header Required Absence d en-tête WS-Routing. 710 End-point Not Found Destinataire introuvable. 711 End-point Gone Destinataire devenu inactif (et pas d alternative de reroutage). 712 End-point Not Supported Destinataire incapable de traiter les en-têtes WS- Routing. 713 End-point Invalid Destinataire invalide (en général, erreur de syntaxe dans l URI). 720 Alternative End-point Found Destinataire de substitution identifié. 730 End-point Too Long L URI du destinataire est trop longue pour être traitée par le destinataire WS-Routing. 731 Message Too Large Message trop lourd. 740 Message Time-out Dépassement des délais de traitement attendus par le destinataire. 750 Message Loop Detected Détection d une boucle dans le chemin de routage. 751 Reverse Path Unavailable Impossibilité de construire le chemin de retour. Défaillance à la réception 800 Unknown Routing Fault Défaillance d origine inconnue! 810 Element Not Implemented En-tête contenant un élément non conforme au schéma WS-Routing. 811 Service Unavailable Le traitement des messages WS-Routing ne répond pas. 812 Service Too Busy Le traitement des messages WS-Routing bloque les ressources du destinataire, empêchant le traitement de nouveaux messages. 820 End-point Not Reachable Le destinataire ne peut être atteint. 74

29 Chapitre 2 Communiquer : SOAP Dans le cas de WS-Routing, le message DIME est obligatoirement constitué du message WS-Routing lui-même, en première partie, et des pièces jointes éventuelles dans les parties suivantes. Par convention, l identifiant de la première partie du message DIME est l URI du destinataire suivant sur le chemin, extrait du message WS-Routing. Cette convention permet de router le message directement sans que le nœud intermédiaire n ait à interpréter la totalité du message SOAP et de l en-tête WS-Routing. Il n y a alors pas de dégradation de performance dans la transmission des messages. Ainsi encapsulé, le message est prêt à être transporté par TCP, qui est un protocole bi-directionnel, et par UDP, qui ne l est pas. Dans le premier cas, les éléments rev sont facultatifs, la couche de transport TCP se chargeant elle-même du calcul du chemin de retour. Dans le second cas, les datagrammes UDP n étant pas bi-directionnels, les éléments rev sont obligatoires et renseignés par le traitement aux étapes intermédiaires le long du chemin. En ce qui concerne HTTP, WS-Routing est entièrement compatible avec la liaison SOAP HTTP. SOAP transporté par HTTP La spécification SOAP met en avant HTTP (plutôt que d autres protocoles de transport comme SMTP, FTP, POP3 ou NNTP) comme protocole privilégié de transport des messages SOAP. Les premières versions de SOAP s intéressaient essentiellement au RPC au travers du Web, d où la vocation première de SOAP : du RPC sur HTTP. L arrivée de nouveaux acteurs comme IBM dans le groupe de spécification de SOAP conduisit à enrichir l ambition de SOAP et l on vit une première démonstration de SOAP sur SMTP, par exemple. Le modèle requête/réponse de SOAP s adapte parfaitement au modèle requête HTTP/réponse HTTP. Le message SOAP vient «naturellement» s imbriquer dans les requêtes et les réponses HTTP (voir figure 2-12), bénéficiant de toute la gestion et du routage décentralisé du protocole du Web. La requête SOAP HTTP La spécification n utilise que les requêtes HTTP de type Post pour transporter les requêtes SOAP (sans raison particulière autre que la simplicité, dans ce cas, du passage de données de l émetteur vers le destinataire). Un attribut supplémentaire doit, par contre, être utilisé dans l en-tête HTTP de la requête, pour se manifester auprès du destinataire SOAP du message. Rappelons, en effet, que les serveurs SOAP et les serveurs Web (HTTP) ne sont pas physiquement liés et un serveur Web donné peut, par 75

30 Services Web avec SOAP, WSDL, UDDI, ebxml exemple, héberger plusieurs services Web et autant de destinataires SOAP. Cet attribut supplémentaire, SOAPAction, a pour valeur un URI sans format spécifique dont l interprétation est à la charge du destinataire de la requête, comme dans l exemple suivant : Figure Le message SOAP inclus dans une requête ou une réponse HTTP POST HTTP/1.1 Content-type: text/xml ; charset="utf-8" Content-length: mcdu SOAPAction: <SOAP-ENV:Envelope xmlns:soap-env=" envelope" SOAP-ENV :encodingstyle=" soap/encoding"> <SOAP-ENV:Body> <!-- Requête de la valeur d un titre --> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 76

31 Chapitre 2 Communiquer : SOAP La réponse SOAP HTTP Pour les réponses, SOAP suit la sémantique des codes de retour HTTP. Si la réponse HTTP porte un code de type 2xx, le message SOAP a été reçu, compris et traité correctement. Dans le cas contraire, SOAP utilise conventionnellement le code 500 (Internal Server Error), et la balise Body doit alors contenir l élément Fault indiquant la nature de l erreur. La réponse à la requête de la section précédente serait donc (en cas de succès) : HTTP/ OK Content-type: text/xml ; charset="utf-8" Content-length: mcdu <SOAP-ENV:Envelope xmlns:soap-env=" envelope" SOAP-ENV :encodingstyle=" soap/encoding"> <SOAP-ENV:Body> <!-- Valeur du titre --> </SOAP-ENV:Body> </SOAP-ENV:Envelope> SOAP sur HTTPR L usage de HTTPR permet l envoi et la réception fiable de messages SOAP, et, par conséquent, une communication fiable entre services Web. Dans ce scénario, la proposition d IBM est de faire passer l attribut SOAPAction dans l en-tête HTTPR, qui contient déjà les identifiants uniques et l horodatage des messages, sous le nouveau nom app-soap-action. Ainsi, la requête SOAP HTTP précédente devient la requête SOAP HTTPR suivante : POST HTTP/1.1 Transfer-Encoding: chunked... request: PUSH HTTPR/1.0 transactionid: 1 message-size: nnn target-uri: "httpr:// content-type: text/xml; charset="utf-8" reply-uri: "httpr:// message-id: "fg8[té7[e]#]" correlation-id: "é6cf6[c]#é5cd6[d]#cd5/f5[a]/ç4[a]/ g4[a]fd5[a]#cd4td4#" put-time: T11:12:12Z app-soap-action: 77