Cours 4 :

Partie I : Echange avec un service ‐

Format du message

0- XML et Remote Procedure Call

 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 l’information (message XML) du client
vers le serveur en décrivant la nature des requêtes et des réponses avec un vocabulaire XML
restreint.
 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.
 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.

1- Protocole SOAP (Simple object Access Protocol)

 Le principal 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’interopérabilité 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.
 SMTP, est un protocole de communication utilisé pour transférer le courrier électronique vers
les serveurs de messagerie électronique.
 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.
 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 asynchrone : le client demande l’exécution d’un service sur un serveur et il poursuit son
exécution sans attendre la réponse.

2- Structure de la spécification SOAP 1.1

La structure SOAP 1.1 peut être organisée en plusieurs niveaux :

Echange, format, contenu, liaison

 Pour l’échange, la spécification prévoit pluralité de styles d’échanges possibles, qui 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.
 Le message à format unique peut héberger un contenu littéral (du XML bien formé ou valide
par rapport à des schémas XML schéma), ou codé (en suivant une pluralité de style de
codage).
 Le message fait l’objet d’un ensemble de convention de liaison (binding) avec une pluralité
de protocoles de transport.
 3- 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.

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

1. Un Framework de messagerie

La spécification SOAP 1.1 définit un vocabulaire XML SOAP 1.1 pour les éléments et les
attributs propres au format du message.

 L’identifiant du vocabulaire XML SOAP 1.1 est associé à l’URI

http://schemas.xmlsoap.org/soap/envelope/ .
 La déclaration du vocabulaire XML http://schemas.xmlsoap.org/soap/envelope
est obligatoire, car elle désigne la version de SOAP revendiquée par le message.
 Le préfixe associé au vocabulaire XML
http://schemas.xmlsoap.org/soap/envelope/ dans SOAP1.1 est SOAP-ENV.
 Le Framework de messagerie SOAP requiert que le message SOAP soit composé
d’une enveloppe qui contient un header et un body. L’exemple suivant présente le
squelette d’un message SOAP ne contenant aucun message :
 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 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.

Note :

La codification orientées RPC, indique que les messages associés traitent des paramètres et
des valeurs de retour (et sont donc conformes au format RPC de SOAP 1.1 : voir
http://www.w3.org/TR/SOAP/#_Toc478383532 ), ou orientées document, c’est‐à‐dire que ces
messages traitent des documents (et sont donc conformes au format standard de SOAP 1.1).

Chaine de message SOAP

 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.

 L’utilité du mécanisme de la chaîne d’acheminement est à la fois technique et fonctionnelle :

o Du point de vue technique, le mécanisme normalise le rôle et la fonction du routeur
applicatif.
o Du point de vue fonctionnel, les possibilités offertes par ce mécanisme sont multiples. Il
permet de composer des services tiers sur la base de fonctions réparties sur la chaîne
d’acheminement.
 Les différents éléments d’un message SOAP 1.1 sont produits et consommés par les nœuds de la
chaîne d’acheminement. Produire un élément d’un message revient à le constituer. Consommer un
élément d’un message équivaut à le traiter et, pour les intermédiaires, à réémettre le message après
avoir supprimé l’élément consommé.
  L’expéditeur du message est le premier producteur du message. Le récepteur du message, qu’il soit
intermédiaire ou destinataire, doit exhiber un comportement normalisé, qui peut être résumé ainsi :
1. Il doit examiner le message pour chercher les informations qui lui sont destinées.
2. Parmi les parties du message qui lui sont adressées, il y en a certaines dont la
consommation de la part du nœud est obligatoire : si le nœud est « capable » d’effectuer
cette consommation, il doit l’effectuer, et s’il n’en est pas « capable », il doit rejeter le
message.
3. S’il s’agit d’un intermédiaire, alors il doit supprimer du message les parties qu’il
consomme, et il peut ainsi produire des éléments nouveaux, posés dans les endroits du
message destinés à cet effet, puis il doit émettre à nouveau le message vers le nœud
suivant de la chaîne d’acheminement.

Structure du message SOAP

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

1. SOAP Enveloppe
 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.
2. SOAP Header
 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 d'un espace de nom, d'un nom local et de deux attributs qui ont pour
but de déterminer comment le destinataire d'un message doit le traiter.
 Les attributs dans Header entries sont :
SOAP‐ENV:actor et SOAP‐ENV:mustUnderstand
1. 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.
2. 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.
 3. 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.

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 :

Il existe quatre types de faultcode :

 2. Un standard d’encodage

 Les services Web sont mis en œuvre par des programmes écrits à l’aide de différents langages de
programmation. Ces langages manipulent des données atomiques comme les entiers, les flottants,
les dates, etc., mais aussi des structures de données plus complexes, formées par composition
récursive de données atomiques.
 Les données manipulées par les langages de programmation (Java, C# ou C++,....) sont toujours
typées, où chaque variable doit déclarer son type dans le texte du programme.
 SOAP 1.1 est censé mettre en œuvre un mécanisme d’échange indépendant des choix
d’implémentation des applications, et notamment des langages de programmation.
 Mécanisme d’échange repose sur des messages au format XML dotés d’une structure prédéfinie
(enveloppe, en‐tête, corps, etc.).

Pour faciliter l’intégration de ce mécanisme d’échange avec les applications, il

est nécessaire de définir des représentations et codage dans les messages SOAP,
des données manipulées par ces langages et applications et de mettre en œuvre les
règles associées d’encodage et de décodage.

 SOAP 1.1 appelle ces représentations et les règles d’encodage/décodage associées, des styles de
codage, encodingstyle.
 À partir de la disponibilité d’un style de codage, des outils d’aide au développement de services
Web peuvent générer automatiquement la chaîne des traitements, depuis la production du
message SOAP de la part de l’émetteur, jusqu’à la consommation du message de la part du
récepteur.
 L’objectif de encoding style est de permettre au développeur applicatif de continuer à travailler
dans la représentation de données propre au langage de programmation qu’il utilise, sans se poser
de questions au sujet du format et du codage des données dans le message SOAP.

Trois stratégies sont possibles pour la représentation des données typées dans les messages SOAP :

1. Représentation littérale :

 Avec la représentation littérale, il n’y a pas de codage des données : le contenu XML du message
SOAP (corps, entrée de l’en‐tête) est la donnée véhiculée par le message.
 Le producteur du message a la responsabilité de constituer un fragment XML bien formé et
éventuellement valide et de le placer à la bonne position dans le message (comme descendant
direct du corps ou comme une entrée de l’en‐tête).
 Le consommateur doit analyser le contenu du message en utilisant des outils standards
disponibles dans plusieurs langages de programmation, comme les analyseurs SAX et DOM. Il
peut, par ailleurs, valider le message par rapport a un Schéma XML.
 Deux applications qui s’échangent des messages SOAP 1.1 en représentation littérale manipulent
directement des fragments de documents XML.
 2. Représentation codée explicite :

 En représentation codée explicite, il existe un accord entre les applications qui participent à
l’échange. Cet accord définit un style de codage, à savoir une correspondance entre, d’un côté, les
arbres d’éléments et les données‐caractères XML du message SOAP 1.1, et de l’autre, les types
atomiques et structurés manipulés par les langages des applications participantes.
 La référence au style de codage est explicite dans le message.
 L’outil permettant d’indiquer le style de codage dans le message SOAP 1.1 est l’attribut
SOAP‐ENV:encodingStyle, dont la valeur est une URI .
 La déclaration SOAP‐ENV:encodingStyle="URI" indique que le style de codage identifié par
URI est en vigueur dans la partie du message couverte par la portée de la déclaration.

La spécification SOAP 1.1 précise que le style de codage SOAP 1.1 pour le codage explicite est identifié par
l’URI: http://schemas.xmlsoap.org/soap/encoding/ et que les messages qui adoptent ce style de codage
devraient le revendiquer explicitement par la déclaration :

SOAP‐ENV:encodingStyle = http://schemas.xmlsoap.org/soap/encoding/

L’attribut encodingStyle est indiqué soit dans SOAP‐ENV: Envelope avec l’espace de nom indiquant la
version de SOAP utilisée ou dans SOAP‐ENV:Body.

3. Représentation codée Implicite :

 En représentation codée implicite, les données sont codées dans le message selon un style de
codage, mais celui‐ci reste implicite, car le message ne véhicule aucune revendication explicite sur la
présence d’un codage dans le message et aucune référence aux règles correspondantes
d’encodage/décodage.
 Dans un message SOAP 1.1, cela se traduit par l’absence de la déclaration
SOAP‐ENV:encodingStyle ou par la présence de déclarations de type :
SOAP‐ENV:encodingStyle=""
 Le typage implicite correspond au renvoi, par le vocabulaire XML, à un schéma XML Schema, qui
contient la définition de l’élément et de son type.

Le modèle de données du style de codage SOAP 1.1

 La spécification SOAP 1.1 désigne les données codées dans un message sous le terme de valeurs.
 Une valeur peut être une valeur simple, en correspondance avec les données atomiques, ou bien une
valeur composite (en correspondance avec les données structurées).
 Une valeur est toujours représentée dans un message SOAP (en‐tête, corps, erreur) comme le
contenu d’un élément XML.
 Une valeur simple est représentée par les données‐ caractères du contenu d’un élément « feuille »,
qui n’a pas de sous‐éléments. Une valeur simple est toujours typée.
Les valeurs et les types simples

 Le style de codage SOAP s’appuie sur le système de typage de données atomiques proposé par la
spécification XML Schema.
 L’espace du nom associé aux types de données de schéma XML, XML Schema Datatypes (XSD),
est comme suit :

xmlns:xsd=’http://www.w3.org/2001/XMLSchema’

Il fournit les types courants comme : strings, floats, doubles, et integers.

Les types simples proposés par la spécification XSD sont listés dans le tableau 1.
Typage d’une valeur simple

 SOAP 1.1 impose l’annotation du typage des valeurs simples dans le message et propose deux
approches pour désigner les types :
 Le typage implicite, qui correspond au renvoi, par le vocabulaire XML, à un schéma XML
Schema, qui contient la définition de l’élément et de son type.

 Le typage explicite
Le type peut aussi être directement désigné via l’attribut xsi:type :

<ens:accountcode xsi:type="xs:string">0000123456A</ens:accountcode>

Le style de codage SOAP 1.1 admet des accesseurs polymorphes (dans le même message), à savoir
la réutilisation des accesseurs pour plusieurs données de types différents.

La spécification SOAP 1.1 impose dans ce cas l’utilisation de xsi:type sur chaque occurrence de
l’accesseur en question.

Exemple :

<ens:cost xsi:type="xs:decimal">29.95</ens:cost> ou xsi:type="xsd:decimal">

<ens:cost xsi:type="xs:float">29.95</ens:cost>

<ens:cost xsi:type="xs:double">29.95</ens:cost>

Rappel :

http://www.w3.org/2001/XMLSchema‐instance : cet espace de noms définit des attributs qui

peuvent être utilisés dans tout document XML (type, nullschemaLocation et
noNamespaceSchemaLocation). Pour simplifier, on utilisera systématiquement le préfixe xsi: pour
référencer cet espace de noms.
Typage d’une valeur composée

 L’encodage SOAP définit les types composés suivants :

 Arrays (Tableaux) désigne un tableau dont les éléments sont de même types. La position
ordinale de chacun des membres dans le tableau le différencie des autres.

SOAP arrays possède un ensemble de règles spécifiques, qui exigent qu’on spécifie l’élément type et
la dimension du array :

 Les tableaux ont un type particulier marqué par leur attribut xsi:type, qui est
SOAP‐ENC:Array. Les éléments qui possèdent l’attribut xsi:type=SOAP‐ENC:Array
sont déclarés en tant que tableau d’encodage SOAP.
 Le type des membres du tableau est déclaré au moyen d’un autre attribut
SOAP‐ENC:arrayType. Cet attribut indique le type (datatype) et la taille du tableau.
  Structs (enregistrement) qui désigne une valeur composée dans laquelle le nom d’accesseur
seul permet de différencier les valeurs de membres, chaque accesseur ayant un unique nom.

Par contraste avec array, struct contient des valeurs multiples, mais chaque élément est spécifié
avec un unique élément accesseur.

Exemple :

Considérons un item dans un catalogue de produit. Dans ce cas, struct peut contenir un nom
de produit, un prix et sa description. Cette structure est représentée dans un message SOAP comme
suit :
 4- La spécification SOAP définit aussi un mécanisme RPC

I. Invocation de services d’objets distants via SOAP RPC

La spécification SOAP RPC décrit la possibilité d’utiliser le protocole SOAP pour invoquer les
procédures sur réception du message SOAP. Les différentes étapes d’invocation d’objets distants avec
SOAP sont les suivantes :

 Connexion du client vers le serveur

 Demande d’un document via une méthode GET
 Renvoi du document, erreur ou information sur le document
 Déconnexion

5- SOAP

II. Invocation détaillée de services d’objets distants via SOAP RPC

1. Le programme client SOAP crée un document XML contenant les informations nécessaires pour
invoquer les services d’un objet distant. Le document XML est incorporé dans une enveloppe SOAP
avant d’être transmis sous forme de requête POST HTTP (méthode Post est utilisée lorsqu'une
requête modifie la ressource).
2. Le message est transmis via une connexion HTTP standard vers le serveur SOAP.
3. Le serveur SOAP reçoit le message, analyse sa cohérence et l’aiguille vers l’objet concerné.
4. L’objet effectue le traitement demandé et renvoie le résultat au serveur SOAP qui l’encapsule avant
de le renvoyer au client.
5. Le résultat est renvoyé au client à travers un document SOAP encapsulé dans un en‐tête de réponse
HTTP.
6. Le SOAP client reçoit les résultats, ouvre l’enveloppe SOAP et envoie le résultat au demandeur
initial.
III. Méthodes d’Invocations de services

1. GET : Méthode la plus courante pour demander une ressource. Une requête GET est sans effet sur la
ressource, il doit être possible de répéter la requête sans effet.
2. HEAD : Méthode ne demande que des informations sur la ressource, sans demander la ressource
elle‐même.
3. POST : Cette méthode doit être utilisée lorsqu'une requête modifie la ressource.
4. CONNECT : Cette méthode permet d'utiliser un proxy comme un tunnel de communication.
5. PUT : Cette méthode permet d'ajouter une ressource sur le serveur.
6. DELETE : Cette méthode permet de supprimer une ressource du serveur.
7. TRACE : Cette méthode demande au serveur de retourner ce qu'il a reçu, dans le but de tester et
d'effectuer un diagnostic sur la connexion.
8. OPTIONS : Cette méthode permet d'obtenir les options de communication d'une ressource ou du
serveur en général.