Cours 04 Le Protocole SOAP - PDF

Masters 1 Resin, SITW,RSD,ADSI,IIEP Laboratoire Le protocole SOAP Partie I : Echange avec un service ‐ Format du message Les Services Web H. Meziane 1 XML et Remote Procedure Call (1/2)  Dans un systèm...

Masters 1 Resin, SITW,RSD,ADSI,IIEP Laboratoire Le protocole SOAP Partie I : Echange avec un service ‐ Format du message Les Services Web H. Meziane 1 XML et Remote Procedure Call (1/2)  Dans un système d’information distribué, les applications interagissent les unes avec les autres souvent à laide du XML‐RPC1 (remote Procedure Call).  XML‐RPC est un langage XML qui permet de décrire et de déclencher des fonctions ou des procédures distantes à travers l’internet.  XML‐RPC utilise le protocole HTTP pour faire passer les messages XML du client vers le serveur en décrivant la nature des requêtes et des réponses avec un vocabulaire XML restreint. 1. RPC (Remote Procedure Call) est un protocole réseau permettant de faire des appels de procédures sur un ordinateur distant à l'aide d'un serveur d’application. Ce protocole est utilisé dans le modèle client‐serveur et permet de gérer les différents messages entre ces entités. Les Services Web H. Meziane 2 XML et Remote Procedure Call (2/2)  Le client transmet un message XML qui contient le nom de la procédure à exécuter et la valeur des paramètres de cette procédure et le serveur exécute le traitement et retourne la valeur du résultat sous forme d’un document XML indiquant si l’exécution a réussi et en précisant la (ou les) valeur(s) de retour.  À partir de la publication de XML‐RPC, l’activité autour des spécifications et des technologies qui constituent aujourd’hui l’ensemble des «services Web», s’accélère et se diversifie.  XML‐RPC est la source d’inspiration de SOAP (Simple Object Access Protocol). Le protocole SOAP est une forme de RPC mais qui est utilisé dans les services Web. Les Services Web H. Meziane 3 Protocole SOAP (Simple object Access Protocol) (1/2)  Le principale objectif du SOAP est de permettre la normalisation des échanges de données.  Le protocole SOAP définit un moyen uniforme d’échange de données encodées XML sous forme d’appels de procédure à distance RPC en utilisant HTTP comme protocole de communication, mais aussi les protocoles SMTP2 (Simple Mail Transfer Protocol ) et POP3 (Post Office Protocol ).  SOAP assure l’interoperabilité entre composants tout en restant indépendant des plates‐formes et de langage de programmation. Il repose sur deux standards, XML pour la structure des messages et HTTP pour le transport. 2. SMTP, est un protocole de communication utilisé pour transférer le courrier électronique vers les serveurs de messagerie électronique. 3. POP (protocole de bureau de poste) permet d'aller récupérer son courrier sur un serveur distant (le serveur POP). Il est nécessaire pour les personnes n'étant pas connectées en permanence à Internet afin de pouvoir consulter les mails reçus hors connexion. Les Services Web H. Meziane 4 Protocole SOAP 1.1 (2/2)  SOAP représente la pierre angulaire des architectures Web services permettant à diverse applications d’échanger facilement les services et les données.  SOAP fournit un mécanisme qui permet d’échanger de l’information structurée et typée entre applications dans un environnement réparti et décentralisé.  SOAP ne véhicule pas de modèle de programmation ou d’implémentation, mais fournit les outils nécessaires pour définir des modèles opérationnels d’échange (styles d’échange) aussi diversifiés que les systèmes de messagerie asynchrone et l’appel de procédure distante (RPC). Echange asyncrone : le client demande l’exécution d’un service sur un serveur et il poursuit son exécution sans attendre la réponse. Les Services Web H. Meziane 5 Les principes du protocole SOAP 1.1  SOAP spécifie l’utilisation de documents XML comme messages. Pour ce faire, il possède un certain nombre de traits :  une grammaire pour définir le format et la structure des messages (en termes de documents XML) ;  une convention pour désigner les agents logiciels habilités à traiter les différentes parties du message ainsi que le caractère obligatoire ou optionnel du traitement ;  une représentation codée pour véhiculer les données atomiques et structurées manipulées par les langages de programmation (style de codage) ;  un ensemble de consignes pour transporter les messages sur le protocole de transport HTTP ;  une représentation de la requête et de la réponse d’un appel de procédure distante. Les Services Web H. Meziane 6 Structure de la spécification SOAP 1.1 (1/3)  La structure SOAP 1.1 peut être organisée en plusieurs niveaux : Message Requête/réponse SOAP Autre Echange one‐Way SOAP RPC Document style d’échange Format Enveloppe SOAP Contenu Contenu littéral littéral Contenu codé Contenu XML XML Autre Autre codage autre Codage XML bien formé Schema formalisme SOAP Codage Schema SOAP SOAP Liaison Autre Liaison Sur HTTP Sur SMTP Transport HTTP SMTP Autre protocole Les Services Web H. Meziane 7 Structure de la spécification SOAP 1.1 (1/2)  Pour l’échange, la spécification prévoit pluralité de styles d’échanges possibles (One Way, requête/réponse, notification…..) Message Requête/réponse SOAP Autre Echange one‐Way SOAP RPC Document style d’échange  Tous les styles d’échange reposent tous sur un seul et unique format de message : le format XML de l’enveloppe SOAP 1.1 et de ses éléments descendants. Format Enveloppe SOAP Les Services Web H. Meziane 8 Structure de la spécification SOAP 1.1 (1/2)  Le message à format unique peut héberger un contenu littéral (du XML bien formé ou valide par rapport à des schémas XML schema,….), ou codé ( en suivant une pluralité de style de codage). Contenu Contenu littéral littéral Contenu codé Contenu XML XML Autre Autre codage autre Codage XML bien formé Schema formalisme SOAP Codage Schema  Le message fait l’objet d’un ensemble de convention de liaison (binding) avec une pluralité de protocoles de transport. SOAP SOAP Liaison Autre Liaison Sur HTTP Sur SMTP Transport HTTP SMTP Autre protocole Les Services Web H. Meziane 9 Usages de base et étendus de SOAP 1.1 Echange Format Contenu Liaison Transport Message XMl bien One Way formé SOAP (littéral) XML Soap SOAP sur HTTP Schema Document Enveloppe HTTP (littéral) SOAP SOAP Codage Autre Autre RPC SOAP liaison Protocole Autre Autre style codage d’echange Schéma Les Services Web H. Meziane 10 SOAP 1.1 et XML La spécification SOAP définit deux parties principales : Un framework de messagerie Un standard d’encodage Les Services Web H. Meziane 11 Framework de messagerie SOAP (1/5)  La spécification SOAP 1.1 définit un vocabulaire XML SOAP 1.1 pour les éléments et les attributs propres au format du message.  L’identifiant du vocabulaire XML SOAP 1.1 est associé à l’URI http://schemas.xmlsoap.org/soap/envelope/.  La déclaration du vocabulaire XML http://schemas.xmlsoap.org/soap/envelope/ est obligatoire, car elle désigne la version de SOAP revendiquée par le message.  Le préfixe associé au vocabulaire XML http://schemas.xmlsoap.org/soap/envelope/ dans SOAP1.1 est SOAP-ENV. Les Services Web H. Meziane 12 Framework de messagerie SOAP (2/5)  Le framework de messagerie SOAP requiert que le message SOAP soit composé d’une enveloppe qui contient un header et un body. L’exemple suivant présente le squelette d’un message SOAP ne contenant aucun message : Envelope est l’élément « document racine » englobant et structurant du message. < SOAP‐ENV : Header> SOAP header du message : véhicule les metadonnées du message. < SOAP‐ENV: Body> SOAP Body du message : Il contient le corps du message. 13 Les Services Web H. Meziane Framework de messagerie SOAP (3/5) Les messages SOAP sont échangés entre l’utilisateur de service et le fournisseur de service dans des enveloppes SOAP contenant une requête pour réaliser une action et une réponse contenant le résultat de cette action. Les enveloppes SOAP sont formatées XML et assez faciles à décoder. L’exemple suivant est une simple requête SOAP qui peut être envoyée via une requête HTTP à un service Web : Les Services Web H. Meziane 14 Framework de messagerie SOAP : Requête (4/5) Ce manespace est utilisé pour vérifier les incohérences de version. Sérialisation 78570 France Les éléments essentiels de l’enveloppe SOAP sont 2 paramètres codePostal et Pays. Ils sont contenus dans un élément nommé ValiderCodePostal qui est le nom de service web que nous appelons. Les autres données de l’enveloppe telle que le SOAP version et style encoding facilite l’encodage des données pour le traitement du service web. Les Services Web H. Meziane 15 Framework de messagerie SOAP : Réponse (5/5) Une réponse à cette requête peut ressembler à ceci: Oui A l’élément ValiderCodePostal de notre requête correspond un élément réponse ValiderCodePostalReponse dans le message de réponse SOAP, qui contient un simple élément valide, indiquant si le code postal est valide ou non. Les Services Web H. Meziane 16 Les bases de SOAP 1.1  Les styles d’échange proposés par SOAP 1.1 sont le message à sens unique et du type requête/réponse, avec ses deux variantes document et RPC.  Un message à sens unique SOAP 1.1 part d’un nœud expéditeur pour atteindre un nœud destinataire. Expéditeur Destinateur Réseau Figure 1 : Style d’échange message à sens unique Note : la codification orientées RPC, indique que les messages associés traitent des paramètres et des valeurs de retour (et sont donc conformes au format RPC de SOAP 1.1 : voir http://www.w3.org/TR/SOAP/#_Toc478383532), ou orientées document, c’est‐à‐dire que ces messages traitent des documents (et sont donc conformes au format standard de SOAP 1.1). Les Services Web H. Meziane 17 Chaine de message SOAP (1/3)  Un message peut être transféré directement de l’expéditeur au destinataire, ou bien transiter par un nombre illimité de nœuds intermédiaires qui forment une chaîne d’acheminement (Figue 2).  Chaque nœud intermédiaire est récepteur du message émis du nœud précédent dans la chaîne, et émetteur du message pour le nœud suivant. Dans une chaîne d’acheminement, l’expéditeur est le premier émetteur et le destinataire est le dernier récepteur.  Un Nœud intermédiaire est une application SOAP 1.1 capable de réceptionner et d’émettre des messages SOAP 1.1. Expéditeur Intermédiaire Intermédiaire Intermédiaire Destinateur 1 2 3 Figure 2 : Une chaîne d’acheminement Les Services Web H. Meziane 18 Chaine de message SOAP (2/3)  L’utilité du mécanisme de la chaîne d’acheminement est à la fois technique et fonctionnelle :  Du point de vue technique, le mécanisme normalise le rôle et la fonction du routeur applicatif.  Du point de vue fonctionnelle, les possibilités offertes par ce mécanisme sont multiples. Il permet de composer des services tiers sur la base de fonctions réparties sur la chaîne d’acheminement,  Les différents éléments d’un message SOAP 1.1 sont produits et consommés par les nœuds de la chaîne d’acheminement. Produire un élément d’un message revient à le constituer. Consommer un élément d’un message équivaut à le traiter et, pour les intermédiaires, à réémettre le message après avoir supprimé l’élément consommé. Les Services Web H. Meziane 19 Chaine de message SOAP (3/3)  L’expéditeur du message est le premier producteur du message. Le récepteur du message, qu’il soit intermédiaire ou destinataire, doit exhiber un comportement normalisé, qui peut être résumé ainsi : 1. Il doit examiner le message pour chercher les informations qui lui sont destinées. 2. Parmi les parties du message qui lui sont adressées, il y en a certaines dont la consommation de la part du nœud est obligatoire : si le nœud est « capable » d’effectuer cette consommation, il doit l’effectuer, et s’il n’en est pas « capable », il doit rejeter le message. 3. S’il s’agit d’un intermédiaire, alors il doit supprimer du message les parties qu’il consomme, et il peut ainsi produire des éléments nouveaux, posés dans les endroits du message destinés à cet effet, puis il doit émettre à nouveau le message vers le nœud suivant de la chaîne d’acheminement. Les Services Web H. Meziane 20 Structure du message SOAP  Le format de message SOAP est présenté dans la figure suivante : Un message SOAP comporte trois parties : SOAP  L’enveloppe (obligatoire) – Envelope – contient le Envelope nom du message suivi d’un domaine de nom (namespace) qui indique la version du schemas SOAP header XML SOAP supporté. Header Entry  L’entête (optionnel) – Header – est utile quand le Header Entry message doit être traiter par plusieurs intermédiaires. SOAP Body Body Entry  Le corps (obligatoire) – Body – renferme les méthodes et paramètres qui seront exécutés par Body Entry le destinataire final. Les Services Web H. Meziane 21 SOAP Enveloppe (1/2)  L’élément enveloppe est obligatoire est sert de conteneur aux autres éléments du message SOAP.  Le mot clé Enveloppe est suivi d’un espace de nom indiquant la version de SOAP utilisée et optionnellement de l’attribut encodingStyle permettant d’identifier les règles d’encodages mises en œuvre pour un message. La valeur de l’attribut est un ou plusieurs URI identifiant la règle de sérialisation ou les règles qui peuvent être utilisées pour désérialiser le message.  SOAP utilise Les namespaces pour différentier les versions. La version doit être référencée par l’élément enveloppe. Les Services Web H. Meziane 22 SOAP Enveloppe (2/2) Exemple :  URI de namespace de SOAP 1.1 est http://schemas.xmlsoap.org/soap/envelope/  URI du namespace de SOAP 1.2 est http://www.w3.org/2001/09/soap‐envelope.  …… Si une Enveloppe fait référence a un autre namespace alors on considère qu’il y a une erreur de versionning. Les Services Web H. Meziane 23 Structure du message SOAP  Le format de message SOAP est présenté dans la figure suivante : SOAP envelope Un message SOAP comporte trois parties : SOAP header  L’enveloppe (obligatoire) – Envelope – contient Header Entry le nom du message suivi d’un domaine de nom (namespace) qui indique la version du schemas XML SOAP supporté. Header Entry  L’entête (optionnel) – Header – est utile quand SOAP Body le message doit être traiter par plusieurs intermédiaires. Body Entry  Le corps (obligatoire) – Body – renferme les Body Entry méthodes et paramètres qui seront exécutés par le destinataire final. Les Services Web H. Meziane 24 SOAP Header (1/3)  L'élément Header est optionnel et permet d'intégrer au message SOAP des directives lui permettant d'externaliser certains services.  Le message contiendra différentes instructions destinées à être prises en charge par des services extérieurs (intermédiaires). Il contient un ou plusieurs sous‐éléments appelés Header entries (l’entrée de l’en‐tête).  Header entries sont composés de deux attributs qui ont pour but de déterminer comment le destinataire d'un message doit le traiter. Les Services Web H. Meziane 25 SOAP Header (2/3) Les attributs dans Header entries sont : SOAP‐ENV:actor et SOAP‐ENV:mustUnderstand  L'attribut SOAP 1.1 SOAP‐ENV:actor dans une entrée de l’en‐tête est utilisé pour désigner le consommateur de l’entrée de l’en‐tête. La valeur de l’attribut SOAP‐ENV : actor est un URI.  L’attribut SOAP 1.1 SOAP‐ENV : mustUnderstand est utilisé pour indiquer que la consommation de l’entrée de l’en‐tête par le consommateur potentiel désigné est obligatoire (valeur "1") ou facultative (valeur "0", valeur par défaut).  SOAP 1.1 utilise des entiers 1/0 pour l’attribut MustUnderstand  SOAP 1.2 utilise des valeurs boolean true/1/false/0 Les Services Web H. Meziane 26 SOAP Header (3/3) La spécification SOAP 1.1 considère explicitement que les entrées de l’en‐tête sont destinées à la mise en oeuvre de couches supérieures et transversales de la technologie des services Web, comme : la gestion des chaînes d’acheminement, la gestion des transactions, la gestion de la sécurité, etc. Cours 2 slide 10 Les Services Web H. Meziane 27 SOAP Header : Exemple (1/2) La figure 3 présente une chaîne d’acheminement avec un seul intermédiaire : nice.net veut envoyer un message à pretty.net par l’intermédiaire de office.postalservice.com. Nice.net 1. Message A office.postalservice.com 2. Message A’ Pretty Figure 3 : Une chaîne d’acheminement avec un seul intermédiaire. Les Services Web H. Meziane 28  1. parcourt l’en‐tête du message ; http://www.postalstandards.org/send 2. identifie dans l’entrée pbs:postmark la valeur de SOAP‐ENV:actor comme son http://nice.net/ propre URI ; 3. Verifie si la consommation de l’entrée de http://pretty.net/ l’en‐tête est obligatoire (valeur "1") http://pretty.net/home.asp 4. note que l’action demandée est l’envoi simple du message, désignée par l’URI : http://www.postalstandards.org/send 5. note la valeur de l’élément pbs:receiverPort ; ….. 6. ignore l’élément SOAP‐ENV:Body Les Services Web H. Meziane 29  SOAP‐ENV:mustUnderstand="1"> http://www.postalstandards.org/send http://nice.guy.net/ http://pretty.girl.net/ http://pretty.girl.net/home.asp Le message A complet émis Ciao ! par nice.guy.net à l’intention de office.postalservice.com : Les Services Web H. Meziane 30 SOAP Header : Exemple (2/2) La figure 3 présente une chaîne d’acheminement avec un seul intermédiaire : nice.net veut envoyer un message à pretty.net par l’intermédiaire de office.postalservice.com. Nice.net 1. Message A office.postalservice.com 2. Message A’ Pretty Figure 3 : Une chaîne d’acheminement avec un seul intermédiaire. Les Services Web H. Meziane 31  Le message A’ est bien emis par 6. construit un nouveau message dans lequel l’entrée pbs:postmark est http://office.postalservice.com/ modifiée : l’attribut SOAPENV:actor et l’élément 2002‐06‐30T23:59:59 pbs:action sont enlevés, en outre, http://www.postalstandards.org/send les éléments suivants : son propre URI, la date et l’heure de réception du http://nice.net/ message (à l’heure de Greenwitch,selon le format ISO 8601), le pbs:sender et pbs:receiver, sont ajoutées; http://pretty.net/ 7. envoie le nouveau message sur le http://pretty.net/home.asp port de réception http://pretty.net/home.asp. … message A’ émis par office.postalservice.com à l’intention de pretty.girl.net Les Services Web H. Meziane 32 Structure du message SOAP  Le format de message SOAP est présenté dans la figure suivante : SOAP envelope Un message SOAP comporte trois parties : SOAP header  L’enveloppe (obligatoire) – Envelope – contient Header Entry le nom du message suivi d’un domaine de nom (namespace) qui indique la version du schemas XML SOAP supporté. Header Entry  L’entête (optionnel) – Header – est utile quand SOAP Body le message doit être traiter par plusieurs intermédiaires. Body Entry  Le corps (obligatoire) – Body – renferme les Body Entry méthodes et paramètres qui seront exécutés par le destinataire final. Les Services Web H. Meziane 33 SOAP BODY L'élément SOAP Body contient les données spécifiques à l'application, c'est à dire, les méthodes et les paramètres qui seront exécutés par le destinataire final. Cette partie peut transporter aussi un type spécial : les messages d'erreurs SOAP Fault utilisés pour signaler le type d'erreur et pour renvoyer à l'émetteur des informations supplémentaires indiquant les raisons de l'échec de l'appel. Les Services Web H. Meziane 34 SOAP Fault (1/3) Quatre éléments standards de l’élément Fault sont définies dans la spécification SOAP 1.1. Ils sont illustrés dans le tableau (Tab.1) suivant : Nom élément Description Faultcode Un code texte utilisé pour indiquer la classe de l’erreur. Voir Tab.2 pour un listing de quatre types de fault. Faultstring Est destiné à donner une explication de l’erreur, compréhensible par les acteurs humains (généralement les concepteurs et les administrateurs des sevices web. FaultActor Est destiné à fournir des informations au sujet de ce qui a produit l’erreur. Ceci est utile si le message SOAP travers plusieurs nœuds, et le client a besoin de savoir le nœud qui cause l’erreur. La source de l’erreur est indiquée au travers de son attribut qui contient URL. Detail Permet de signaler l’erreur de l’application en rapport avec l’élément body. Il doit être présent si le contenu de l’élément body ne peut pas être correctement traité. Tab.1 : éléments standards de l’élément Fault 35 Les Services Web H. Meziane SOAP Fault (2/3) Il existe quatre types de faultcode : Tab.2 : Faultcode SOAP Nom élément Description SOAPENV: Indique que l’élément l’enveloppe SOAP inclue un VersionMismatch namespace invalide, ce qui signifie une erreur de version. Exemple : l’espace de nom de l’élément SOAP Enveloppe n’est pas http://schemas.xmlsoap.org/soap/envelope/. SOAPENV: un élément de Header contenant l’attribut MustUnderstand mustUnderstand à 1, n’a pas été compris. SOAP‐ENV:Client Indique que la requête du client contient une erreur. Exemple : Le client a spécifié une méthode qui n’existe pas ou a fournit des paramètres incorrects pour une méthode donnée. SOAP‐ENV:Server Indique que le serveur est incapable de traiter la requête du client. Exemple : le service qui doit fournir les produits est incapable de se connecter à une base de données. Les Services Web H. Meziane 36 SOAP Fault (3/3) ……… SOAP‐ENV:Client Failed to locate method (ValidateCreditCard) in class (examplesCreditCard) at /usr/local/ActivePerl‐ 5.6/lib/site_perl/5.6.0/SOAP/Lite.pm line 1555. Ceci représente une erreur à la requête client, et le serveur retourne la réponse SOAP. Les Services Web H. Meziane 37