Architectures Orientées Services

Chapitre 2 – Les Services Web

Dr. Hanen JEMAL

Année universitaire: 2023-2024
2 Plan du Chapitre

➢ Services web simple

➢ Standards pour les services web

➢ Protocole SOAP

➢ Le langage de description WSDL

➢ L'annuaire UDDI

➢ Composition des services web

➢ Standards de compositions de services

 3 Services web simples

 Service Web (selon W3C) : est un système logiciel identifié par un URI (Unified Resource
Identifier), dont les interfaces publiques et les liaisons sont définis et décris en utilisant XML.
Il peut interagir avec d’autres systèmes logiciels d’une manière prédéfinie par sa
définition, en utilisant des messages basés sur XML, acheminés par des protocoles internet.
4 Les caractéristiques des services web

• Les Services Web sont basés sur les protocoles

et les langages du Web
– HTTP, TCP/IP pour la couche réseau
– Ne nécessite pas une configuration réseau
particulière
• Ils sont décrits par XML
• Ils interagissent via des messages XML
 SOA à base des Services Web (1/2)
5
6 SOA à base des Service Web (2/2)
• Les partenaires
– Le fournisseur de services crée le service Web, puis publie son interface ainsi
que les informations d'accès au service, dans un annuaire de services Web.
– L'annuaire de services rend disponible l'interface du service ainsi que ses
informations d'accès, pour les demandeur potentiel de service.
– Le demandeur de services accède à l'annuaire de service pour effectuer une
recherche afin de trouver les services désirés. Ensuite, il se lie au fournisseur
pour invoquer le service.

• Les standards
– WSDL : Décrit les contrats des services
– SOAP : Achemine les messages entre fournisseur et demandeur de services
– Norme UDDI : spécifie la structure des annuaires de services
 Qu’est ce qu’un Service (au sens SOA) ?
7

• Partage les caractéristiques suivantes d’un objet

– Modulaire (ensemble de fonctionnalités qui font sens)
• Partage les caractéristiques suivantes d’un composant
– Boite noire (séparation interface/implémentation)
– Neutralité vis-à-vis des protocoles de transport
• Concept plus abstrait
• Est faiblement couplé (indépendant des autres services)
• Expose un petit nombre d’opérations offrant un traitement
 4 propriétés d’un service
8

• Un Service expose un Contrat

• Un Service est Autonome

Conditions Générales de Vente

Règlement Intérieur
Vos droits/Vos devoirs

• Les Frontières entre services • Les services communiquent par

sont Explicites (couplage messages
lâche)
9 Service : Contrat Standardisé (1/2)
• Contrat entre le fournisseur de service et le consommateur de
service
• Engagement qui formalise l’utilisation de service
10 Service : Contrat Standardisé (2/2)
• Un contrat de service doit être standardisé.
• Trois types de contrat sont à distinguer
– Lié à la syntaxe du service (opération, messages
d’entrée, messages de sortie, …)
– Lié à la sémantique du service (définition de
règles et de contraintes d’usage, …)
– Lié à la qualité de service (temps de réponse
attendu, procédures en cas de panne, temps de
reprise après interruption, …)
 Service : communication par messages
11

• SOA véhicule des Messages et non des objets

• Un service est une fonction qui reçoit des messages et qui les
restitue après traitement.

• Echange d’informations est en mode asynchrone

• ce mode de communication permet aux applications de traiter
les informations "au fil de l'eau", c’est à dire au fur et à
mesure de l'arrivée des données.
 Service : Autonomie
12

• Un service doit disposer

– de l’ensembles des informations nécessaires à son exécution
– ne doit dépendre d’aucun service externe (couplage lâche)
13
Standards pour les services web
XML
14 XML est un succès !
• Standard W3C
• La syntaxe XML ne contient que peu de mot clef: Simplicité
• XML est indépendant des plates-formes: Portabilité
• XML est un méta-langage, il est possible de créer ses propres balises:
Extensibilité

→Largement utilisé pour les échanges inter-applications :

interopérabilité
15 Structure de XML

• un document XML est un arbre d’éléments :

• la racine est unique
• le contenu d’un élément est :
• Des attributs
• d’autres éléments Prologue
• du texte
Racine
attribu
texte
t
Elément
 16 XML (eXtensible Markup Language)
Définition

 XML est un langage de balisage peu comme HTML

 XML a été conçu pour stocker et transporter des données

 XML a été conçu pour être auto-descriptif

 Exemple:
▪ Ce document est tout à fait auto-descriptif:
Il contient des informations sur l'expéditeur.
o Il a un récepteur d'informations
o Il dispose d'une rubrique
o Il a un corps de message.
▪ Mais il ne fait pas tout. XML est tout
simplement l'information enveloppé dans les
tags.
▪ Quelqu'un doit écrire un morceau de logiciel
pour envoyer, recevoir, stocker, ou l'afficher:
 17 XML (eXtensible Markup Language)
Différence entre HTML et XML

 XML et HTML ont été conçus avec des objectifs différents:

 XML a été conçu pour transporter des données - en mettant l'accent sur les données est
 HTML a été conçu pour afficher des données - en mettant l'accent sur la façon dont les
données regards
 Les balises XML ne sont pas prédéfinies comme les balises HTML
 18 XML (eXtensible Markup Language)
Structuration d’un document XML (1/2)

 Structure et éléments:
➢ Sensibilité à la casse: les
<?xml version="1.0"?> Déclaration XML (optionnel) éléments d'extrémité doivent
<contact-info> être exactement les mêmes
<nom>JEMAL</nom> Elément racine <prenom>…</prenom>.
<prenom>HANEN</prenom> (obligatoire)
<adresse> <contact-info>… ➢ Hiérarchie des éléments: Un
<rue>1256 </rue> élément XML peut contenir
</ contact-info>
<maison>12</maison> plusieurs éléments XML en tant
<codeP>3000</codeP>
que ses enfants, mais les
<ville>Sfax</ville> Elément / balise/ nœud
</adresse> éléments des enfants ne doit
<prenom>…</prenom> pas se chevaucher, c.à.d. une
<tel>(216) 123-4567</tel>
Un élément peut être vide: balise d'un élément à la fin de
</contact-info>
<element /> la hiérarchie doit avoir le
1
même nom que celui de la
balise au début.
Hiérarchie d’éléments
8
 19 XML (eXtensible Markup Language)
Structuration d’un document XML (2/2)

Attributs d’élément:
 Les attributs sont utilisés pour distinguer les éléments du même nom.
 Un attribut spécifie une propriété unique pour l'élément, en utilisant une paire nom / valeur
(entre des cotes).
 Un élément peut avoir plusieurs attributs:
<element atta="x" attb="y" …>....</element>
 Exemple élément non vide avec attributs:
<adresse ville="Sfax" codeP="3000" >Rue 1235 maison 12</adresse>
Ou élément vide avec attributs:
<adresse rue="1235" maison= "12" codeP="3000" ville="Sfax" />
20 Les espaces de noms (1/4)

<etudiant> <departement>
<id>E0000001</id> <id>D001</id>
<nom>Smith</nom> <nom>ingénieur</nom>
<prenom>John </prenom> </departement>
</etudiant>

<universite>
<departement>
<id>D001</id>
<nom>ingénieur</nom>
→Confusion sur le sens <etudiant>
des éléments id et nom <id>E0000001</id>
lors de fusion de deux <nom>Smith</nom>
documents <prenom>John </prenom>
</etudiant>
</departement>
</universite>
21 Les espaces de noms (2/4)
• Un document XML peut contenir des éléments et des attributs qui
correspondent à plusieurs domaines distincts (i.e., à plusieurs
dialectes).
• Problème : comment gérer les collisions des noms?
• Solution => Les espaces de noms (namespaces) :
• Les espaces de noms (XML namespaces) sont une recommandation du W3C
pour résoudre le problème de conflits de noms dans un document xml.
• principes :
• chaque collection est identifiée par un URI
• Chaque élément est préfixé par un nom qui identifie le nom de domaine
22

Les espaces de noms (3/4)

<e:etudiant
<dep:departement
xmlns:e="http://etudiant.com">
xmlns:dep="http://departement.com">
<e:id>E0000001</e:id>
<dep:id>D001</dep:id>
<e:nom>Smith</e:nom>
<dep:nom>ingenieur</dep:nom>
<e:prenom>John </e:prenom>
</dep:departement>
</e:etudiant>
<universite xmlns:dep=http://departement.com
xmlns:e="http://etudiant.com">
<dep:departement>
<dep:id>D001</dep:id>
<dep:nom>ingenieur</dep:nom>
<e:etudiant>
<e:id>E0000001</e:id>
→on distingue les éléments et les <e:nom>Smith</e:nom>
attributs de différentes documents <e:prenom>John </e:prenom>
XML qui ont le même nom </e:etudiant>
</dep:departement>
</universite>
23 Les espaces de noms (4/4)
• Un espace de nom est déclaré à l’aide de l’attribut xmlns :
• Soit en déclarant l’espace de nom dans l’élément xmlns="URI" : définition de l’URI
associé à l’espace de noms

• Soit en associant un préfixe xmlns:préfixe="URI" : association du préfixe à l’URI

24 Exemple d’espaces de nommage classiques
• XML: http://www.w3.org/XML/1998/namespace
• Xinclude: http://www.w3.org/2001/XInclude
• Xlink: http://www.w3.org/1999/xlink
• MathML: http://www.w3.org/1998/Math/MathML
• XHTML: http://www.w3.org/1999/xhtml
• SVG: http://www.w3.org/2000/svg
• Schémas: http://www.w3.org/2001/XMLSchema
• XSLT: http://www.w3.org/1999/XSL/Transform
25 Validation des documents XML (1/2)
• Un document XML est dit valide s’il :
• est bien formé
• Il respecte la syntaxe xml
• fait référence à une DTD (Document Type Definition)ou XML schéma ;
• Validé par une une DTD ou XML schéma ;
• Respecte une grammaire et se conforme à ce qui est défini dans le XSD ou DTD associés.
26 Validation des documents XML (2/2)
• Soit par une DTD (Document Type Definition):
qui est une grammaire qui permet de définir une structure type de
document XML.
• limitées : structure simple
• Syntaxe issue de SGML (Pas XML)
• Ou par un XML schéma qui est un langage de description de format
de document XML permettant de définir la structure et le type de
contenu d'un document XML.
• syntaxe XML
• Supporte tout type des attributs
27 Validation par schéma XML
• Un document XML doit pouvoir être validé relativement à son
schéma.
• Schéma xml permet de définir la structure et les contenus des
documents.
• Typage des données
• supporter un ensemble de types primitifs.
• Permettre de créer des types de données usagers dérivés de types existants
(personne, addresse, etc).
28 Format de données pour les services
web
 XML Schema

<?xml version="1.0" encoding="UTF-8" ?>

<xsd:schema xmlns:xs=http://www.w3.org/2001/XMLSchema>
<xsd:element name="Client">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="nom" type="xs:string"/>
<xsd:element name="addresse" type="xs:string"/>
<xsd:element name="ville" type="xs:string"/>
<xsd:element name="age" type="xs:integer"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
29 Principes des schémas (1/2)
• Un schéma XML est un document XML il permet :
• Définition de types simples (Simple type).
• Définition de types complexes (Complex type).
• Déclaration d’éléments.
• Déclaration d’attributs.
 Principes des schémas (2/2)
30
31 L’utilité de xml pour les services web
• XML est utilisé pour :
• Description du contrat
• Description des messages
• Invocation des services web
• XML est indépendant des plates-formes: Portabilité
→ Assure l’interopérabilité dans des environnements applicatifs
distribués
32 Technologies (1/3)
 33 Technologies (2/3)

 WSDL (Web Services Description Language): est une grammaire XML permettant de décrire
l’interface d’utilisation d’un Web Service.
 UDDI (Universal Description Discovery and Integration): UDDI est un registre mondial conçu pour
héberger des informations sur les entreprises et leurs services de façon structurée.
 SOAP (Simple Oriented Architecture Protocol): est un protocole permettant l’invocation de
méthodes à distance par l’échange de messages XML.
 34 Technologies (3/3):
Scénario complet

 Étape 1: définition et description du service

 On doit décrire de point de vue informatique ce que fait le service, la solution qu’il propose…
 La définition est faite en WSDL par le fournisseur de services (i.e. le serveur d’applications).

 Étape 2: publication du service par le fournisseur

 Une fois le service est défini et décrit, la description WSDL peut être publiée dans un annuaire UDDI afin
de la rendre accessible aux clients.

 Étape 3: recherche du service par un client

 Le client se connecte sur un annuaire UDDI pour effectuer une recherche de services.

 Étape 4: invocation du service par le client

 Une fois le service trouvé par le client, ce dernier peut invoquer le service suivant les conditions inscrites
au sein de la description WSDL trouvée.
35
Protocole SOAP
Chapitre2 – services web
 36
SOAP - Service Oriented Architecture Protocol

 Acronyme initialement pour Simple Object Access Protocol, changé dans sa version
1.2 vers Service Oriented Architecture Protocol
 Un message SOAP
 Permet la transmission d’un message au format XML
 Va d’un nœud émetteur vers un nœud receveur
 Peut éventuellement passer par des nœuds intermédiaires (autres services intermédiaires)
 SOAP s’appuie sur :
 XML et XML Schema pour la représentation des messages
 Les protocoles internet classiques pour la transmission des messages
 HTTP, SMTP, FTP…
37 Présentation du SOAP
• SOAP est le protocole standard pour décrire les messages en
XML avec services web.

• Définit un ensemble de règles pour structurer des messages

• Peut être utilisé sur diférents protocoles de transports.

– Principalement HTTP et SMTP

• Permet l’interopérabilité indépendamment des diférents

systèmes d’exploitation.
38 L’échange de messages
39 Les messages SOAP
• Messages XML encapsulés dans une
enveloppe SOAP
• L'intérieur du message dépend de style et
format des messages
– RPC ou document
– Encodé ou litéral
• Types de données hérités de XML Schema
 40
Modèles d’échange des messages (1/2)

input input

Client Service Client Service

in-only
Le consommateur envoie un message au
fournisseur qui change uniquement son statut
fault
Robust In-only
Même chose que in-only si le statut du service change.
Si une erreur est générée, une faute est envoyée

fault

Client Service Client Service

output output

out-only Robust out-only

Le contraire de in-only, principalement une Même chose que le out-only, sauf que ça peut
notification d’évènement provoquer un message d’erreur
 41
Modèles d’échange des messages (2/2)

(1) input input

Client Service Client Service

(2) output (?) output
(2’) fault fault

in-out in-optional-out
Équivalent à requête/réponse : le consommateur initie la Un échange à deux directions standard où une réponse du
requête, le fournisseur répond par un message ou une erreur. fournisseur est optionnelle.

(2’) fault fault

(2) input (?) input

Client Service Client Service

(1) output output
out-in Out-optional-in
Contraire de in-out : le fournisseur initie l’échange. Contraire de in-optional-out.
42 Comment fonctionne SOAP ?
• L’intérieur de message est encapsulé dans des enveloppes
• À réception côté serveur elle est ”désencapsulée”
• Le serveur extrait les données
• Puis appelle la méthode spécifiée avec les paramètres fournis
• Idem pour le retour, les paramètres sont encapsulés dans un
message SOAP à destination du client
 Structure d’un Document SOAP
43

Protocole de
transport: ex. HTTP

Définit le doc Optionnelle:

XML comme Stockage des
un message informations
SOAP spécifiques à la
transaction.
Utile surtout, quand
Contenant des le message doit
données à être traité par
transporter plusieurs
intermédiaires.

Facultatif: Reporter les erreurs

44 Structure d’un message SOAP (1/2)
•Un message SOAP est un document XML composé d’une
enveloppe qui contient une entête et un corps du message.

SOAP ENVELOPPE
 Envelope
SOAP HEADER
🞑 Contenant un message,
🞑 Élément racine XML, HEADER ENTRY
 Header (optionnel)
🞑 Ex : Numéros de session.
SOASO
P AEN
P VBEOLDOYPE
 Body (obligatoire)
🞑 Ex : nom des méthodes,
nom des paramètres, BODY ENTRY
valeurs de paramètres

4
4
45 Structure d’un message SOAP (2/2)

<SOAP-ENV :Envelope>
<SOAP-ENV :Header>
... entête...
</SOAP-ENV :Header>
<SOAP-ENV :Body>
... Corps du message...
</SOAP-ENV :Body>
</SOAP-ENV :Envelope>
4
5
46
L’enveloppe d’un message SOAP
• L’enveloppe: Élément obligatoire dans un message SOAP
– Il permet de spécifier la version de SOAP utilisée et l’espace de
nommage http://www.w3.org/2003/05/soap-envelope
– Il permet aussi de spécifier les règles d’encodage utilisés par le
message

<?xml version="1.0"?>
< SOAP-ENV:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-
envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<SOAP-ENV :Body>
!!Contenu de la requête!!
</ SOAP-ENV:Body>
</SOAP-ENV :Envelope>

4
6
47 Exemple d’enveloppe SOAP

L'identificateur d'espace de noms pour les éléments

et les attributs de cet enveloppe est défini
dans http://schemas.xmlsoap.org/soap/envelope/

L'enveloppe contient un seul message constitué d'un entête

facultatif (SOAP header) et d'un corps obligatoire (SOAP body).
 48 Header - Entête SOAP (1/2)

 Paramètres annexes du message:

Informations authentifiant l’émetteur.
Informations liées aux transactions si le message doit passer par
plusieurs intermédiaires SOAP.

 Par exemple, l'élément d'en-tête peut être utilisé pour spécifier une
signature numérique pour les services protégés par mot de passe. De
même, il peut être utilisé pour spécifier un numéro de compte pour les
services SOAP pay-per-use.
49 L’entête d’un message SOAP
• L’en-tête est défini par la balise <SOAP-ENV:Header>
• L’élément peut être facultatif
• il contient des métadonnées pour l'exécution du service et qui peuvent être
interprétées (ou non) par le serveur
– L’en-tête d’un message SOAP est utilisé pour transmettre des informations
supplémentaires sur ce même message :
• Transactions,
• sessions,
• Actor,
• L’attribut mustUnderstand
–Si absent ou = 0
» l’élément est optionnel pour l’application réceptrice
–Si =1
»l’élément doit être compris de l’application réceptrice. Sinon le
traitement du message par le récepteur doit échouer.
 50 Header - Entête SOAP (2/2)

 Constitué d’un ou plusieurs éléments, ayant chacun un identificateur

et un espace de nom.
 Trois attributs associés à un élément peuvent être utilisés :
 soap:mustUnderstand : cet attribut prend la valeur 1 (si le récepteur doit
reconnaître l'information présente dans l'en-tête) ou 0 (sinon).
 soap:actor : sert à indiquer le destinataire SOAP auquel un bloc d'en-tête SOAP
particulier est destiné.
 soap:relay : est utilisé pour indiquer si un bloc d'en-tête SOAP ciblé sur un
récepteur SOAP doit être réacheminé (relayé) s'il n'est pas traité.
51 Exemple d’entête SOAP

<soap:Header>
<!- - Elément User: à destination du nœud RightsManager - ->
<m:User xmlns:m="http://www.monsite.com/rights"
soap:actor="http://www.monsite.com/rights/RightsManager">
Admin
</m:User>
<!- - Elément Lang: à destination du nœud suivant- ->
<m:Lang xmlns:m="http://www.monsite.com/lang/"
soap:actor="http:Llschemas.xmlsoap.org/soap/next"
soap:mustUnderstand= "0"
FR
</m:Lang>
<!- - Elément Session: à destination du nœud final - ->
<m:Session xmlns:m="http://www.monsite.com/session/"
soap:mustUnderstand= "1" >
12AE3C
</m:Session>
</soap:Header>
52 Corps SOAP (Body)

 Endroit où les données XML spécifiques à l’application, et qui doivent être

échangées, sont placées.
 L’élément Body est obligatoire, mais peut être vide.
 Il peut contenir plusieurs fils (appelés des entrées), qui peuvent être:
 Données spécifiques à l’application: information échangée dans le service web
représentée par une méthode et ses arguments (requête) ou une ou plusieurs valeurs
(réponses)
 Message de faute : utilisé en cas d’erreur.
 Un message SOAP contient des données ou un message de faute, mais pas les
deux à la fois.
 Exemple de corps d’un Message SOAP
53 (Request)
 54 Fautes SOAP: Message d'erreur SOAP

 Définit entre une balise <soap:fault> ouvrante et fermante qui peut

contenir 4 autres balises:
 faultcode : contient un code indiquant la nature du problème.
 faultstring : c'est la traduction en langage naturel du code d'erreur.
 faultactor : indique le service qui a généré l'erreur. Cela est important lorsqu'une
chaîne de services a été utilisée pour traiter la demande.
 detail : cet élément doit contenir autant d'informations que possible sur l'état du
serveur à l'instant de l'apparition de l'erreur. Il contient souvent des valeurs de
variables au moment de l'échec.
 55 Styles de messages SOAP (1/2)

 SOAP supporte deux styles de communication:

 RPC (Remote Procedure Call)
 Document (ou message)
 Le style RPC est parfaitement structuré alors que le type
Document n'a pas de structure imposée mais son contenu peut
être facilement validé grâce à un schéma XML.
 Avec le style document, il est donc possible de structurer
librement le corps du message grâce au schéma XML.
56 Styles de messages SOAP (2/2)

➢ RPC:
public int add(int num1, int num2)
➢ Document:
soapenv:body>
<
public Document add(Document operation)
<ns:add>
<soapenv:body>
<num1 xsi:type=“xsd:int”>
<ns:operation>
10
<add>10</add>
</num1>
<add>8</add>
<num2
xsi:type=“xsd:int”>8</num2> </ns:operation>
</ns:add> </soapenv:body>
</soapenv:body>
 57 Encodage des messages SOAP

 Les règles d'encodage (Encoding rules) précisent les mécanismes de

sérialisation des données dans un message.
 Il existe deux types :
 Encoded : les paramètres d'entrée de la requête et les données de la
réponse sont encodés selon un langage XML spécifique à SOAP sans
utiliser des schémas XML
 Literal : les données n'ont pas besoin d'être encodées de façon
particulière : elles sont directement encodées en utilisant des schémas
XML.
 58 Style des messages SOAP

 Le style et le type d'encodage permettent de définir comment les données seront

représentées, sérialisées et désérialisées dans les requêtes et les réponses.
 La combinaison du style et du type d'encodage peut prendre plusieurs valeurs :
 RPC/Encoded: c'est le premier format historiquement proposé par SOAP mais son utilisation
est de moins en moins fréquente
 RPC/Literal
 Document/Literal
 Le style et le type d'encodage sont précisés dans le WSDL.
 L'appel du service web doit obligatoirement se faire dans le style précisé dans le
WSDL puisque celui-ci détermine le format des messages échangés.
59 Les formats des messages SOAP
• Les format des messages SOAP sont précisé dans les bindings du WSDL
– Attribut style (RPC ou document)
– Attribut use (encoded ou literal )
60 Les messages encodés
• Le type d'encodage Encoded utilise un ensemble de
règles reposant sur les types de données des schémas
XML pour encoder les données
<?xml version="1.0" encoding="UTF-8" ?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd=http://www.w3.org/2001/XMLSchema
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<ns0:additionner
xmlns:ns0="http://axis.test.com"
soapenv:encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/" >
<valeur1 xsi:type="xsd:int">10</valeur1>
<valeur2 xsi:type="xsd:int">20</valeur2>
</ns0:additionner>
</soapenv:Body>
</soapenv:Envelope> 19
61 Les messages littérales
• les données n'ont pas besoin d'être encodées d’une façon particulière : elles
sont directement encodées en XML selon un schéma défini dans le WSDL
• Les informations concernant les type sont éliminées.

<soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ws="http://ws.test.com/">
<soapenv:Body>
<ws:additionner>
<ws:valeursAddition>
<valeur1>20</valeur1>
<valeur2>30</valeur2>
</ws:valeursAddition>
</ws:additionner>
</soapenv:Body>
</soapenv:Envelope>
62 Le style RPC vs le style Document
• Remote procedure call : (RPC) permet
l'invocation d'opérations
– Le corps du document contient obligatoirement le
nom de la méthode invoquée et les données
correspondent aux arguments de cette méthode.

• Document: Le corps du message Soap peut

contenir n’importe quel document XML.

6
2
63 Le style RPC d’un message SOAP
• Les messages
contiennent le nom de
l'opération
• La requête/Réponse est
modélisée comme une
structure dont le nœud
le plus externe est le
nom de l'opération et
les nœuds contenus
sont les paramètres
6
3
64 Le style document d’un message SOAP
• Les messages ne
contiennent pas le nom
de l'opération
• Le contenu du corps de
l'enveloppe peut être
validé puisque tous les
éléments sont définis
dans un schéma

6
4
65
Le langage de description WSDL
Chapitre 2 - Services Web
66 C’est quoi le WSDL?

• WSDL= Web Service Description Language

• Langage de définition des contrats des Web Services
• Basé entièrement sur XML
• Objectif :
– décrit d’une manière abstraite et indépendante du
langage de programmation, l’ensemble des
fonctionnalités offertes par un service
– Permet de décharger les utilisateurs des détails
techniques de réalisation d’un appel

6
6
 67 WSDL - Web Services Description Language

 Un document WSDL se compose d'un ensemble d'éléments décrivant:

 le protocole de communication (SOAP RPC ou SOAP orienté message)

 la localisation du service

 les types de données utilisés par le service,

 le format de messages requis pour communiquer avec ce service

 les méthodes, les paramètres et se qu’il retourne

 les liaisons SOAP associées à chaque message.

68 Structure d’un fichier WSDL
• Format XML de description de
services Web

• Une description WSDL :

1. Décrit les opérations d’un service web
(méthodes, types des paramètres)
→ description abstraite

2. Décrit les aspects techniques

d’implantation d’un service web (quel
est le protocole utilisé, quel est le
l’adresse du service)
Cette description sert à se connecter
concrètement à un service web.
→ description concrète

6
8
 Structure du fichier WSDL
69 <definitions>
<types>
définition des types........
</types>
<message>
définition des messages ....
</message>
<portType>
définition des ports (opérations et messages).......
</portType>
<binding>
Les protocoles de communication utilisés par le web-service
</binding>
<service>
Une adresse physique où accéder au service.
</service>
</definitions>
-4-
70 Elément <definitions> (1/2)
• Il contient les namespaces faisant référence aux types des élements utilisés dans le document.

o wsdl : http://schemas.xmlsoap.org/wsdl/WSDL
namespace pour le framework WSDL.
o soap : http://schemas.xmlsoap.org/wsdl/soap/WSDL
namespace pour le binding WSDL SOAP.
o http : http://schemas.xmlsoap.org/wsdl/http/WSDL
namespace pour le binding WSDL HTTP GET & POST.
o mime : http://schemas.xmlsoap.org/wsdl/mime/ WSDL
namespace pour le binding WSDL MIME.
o soapenc : http://schemas.xmlsoap.org/soap/encoding/
namespace d’encodage SOAP 1.1.
o soapenv : http://schemas.xmlsoap.org/soap/envelope/
namespace de définition de l’enveloppe SOAP 1.1.
o xsi : http://www.w3.org/2000/10/XMLSchema-instance
namespace d’instance XSD.
o xsd : http://www.w3.org/2000/10/XMLSchema
namespace de schéma XSD .
o tns : “this namespace” (tns) référence le document courant par convention.

7
0
71 Elément <definitions> (2/2)
L’entête d’un document WSDL comporte des références à
différents espaces de nommage (namespace) identifiés par
une URL et un préfixe:
72 Eléments d’un document WSDL

 Types
 PortTypes
 Messages

 Binding
 Service
 Port
 Opération
 73 WSDL : Types

 Définitions des types de données <types>

<xsd:schema xmlns:xs=http://www.w3.org/2001/XMLSchema>
 Utilisés pour décrire les messages <xsd:element name="Client">
<xsd:complexType>
échangés <xsd:sequence>
<xsd:element name="nom" type="xs:string"/>
 Utilisent les schémas XML comme <xsd:element name="addresse" type="xs:string"/>
<xsd:element name="ville" type="xs:string"/>
type canonique <xsd:element name="age" type="xs:integer"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
 Exemples: </types>
74 Elément <Types>

• Types : Permet la définition des types complexes. Il utilise généralement

la grammaire XSD car cette dernière supporte un grand nombre de type
de données.

7
4
75 Élement <operation>
• Chaque opération est essentiellement définie par ses messages
• Trois types d'opération selon
le séquencement et la nature
des messages:
– Requête/réponse
(ex: "Quel prix ?" ; "150€" )
– Notification (sortie) :
(ex: "Délai dépassé, transaction
abandonnée" )
– Sollicitation (entrée)
(ex: "Annulation de transaction" )
7
5
76 Elément <portype> (1/2)

• Ensemble d’opérations
– Groupes de messages à envoyer/recevoir
• Fonctionnalité proche des interfaces Java

• portType (name, operation(name,(input msg, output

msg)))
– A chaque portType sont associées des opérations,
correspondant aux méthodes.
– Pour chaque méthode, on définit le message d’entrée
et/ou de sortie
7
6
77 Elément <portype> (1/2)

• Ensemble d’opérations
– Groupes de messages à envoyer/recevoir

• portType (name, operation(name,(input msg,

output msg)))
– A chaque portType sont associées des opérations,
correspondant aux méthodes.
– Pour chaque méthode, on définit le message
d’entrée et/ou de sortie
7
7
78 Elément <portype> (2/2)
79
WSDL : Operations & Port Type

 Operations:  Port Type:

o Description abstraite d’une action o Collection d’opérations
o Fait référence à un message d’entrée o Définition abstraite d’un service
et/ou de sortie
 80
WSDL : Messages
 Messages:
o Définitions abstraites des messages échangés et de leurs paramètres
o Chaque opérations définies dans le document WSDL posséde un message request portant le même
nom que l’opération et un message réponse:
o Exemple:
81 Elément <message> (1/2)

• Les messages décrivent les noms et types d’un ensemble de

champs à transmettre. Peuvent-être comparés aux paramètres d'un
appel de procédure.

• Message(name, (part()))
– Deux types de message Input et Output.
– Peut être composé de plusieurs parties (Parts) correspondant
aux paramètres passés aux fonctions.
• Part(nom, type)
– Il peut être défini comme un type ( simple ou complexe)
– L’ordre des « parts » dépend de la signature de la méthode

8
1
82 Elément <message> (2/2)
 83 WSDL : Binding

 Binding:
o Protocole de transport, ex:
SOAP 1.1 over HTTP
o Style du service (RPC ou
Document)
o Format de données concrets
pour un port type (litteral ou
encoded)

o URI de chaque port type (défini

par attribut namespace)
84 Elément <binding> (1/3)

• Séparation entre la définition abstraite du service et

la manière de la consommer
• Chaque <portType> peut avoir plusieurs <binding>
• C'est un élément qui définit les détails techniques
nécessaire pour consommer le service:
– Style de consommation des opérations
– L'encodage des messages requête & réponse.
– En général:
• SOAP
• HTTP

8
4
85 Elément <binding> (2/3)
• Binding(name, type, (soap:binding, style, transport),(operation(soap:operation,
soap:action (input(soap:boby, encodingStyle, namespace, use),
output(soap:boby, encodingStyle, namespace, use))
– Nom de binding
– Le type permet de spécifier le portType( classe) auquel on fait référence
– soap :binding permet de déterminer le protocole d’invocation utilisé
– Style: permet de préciser si le message( body de soap) contient des données ou
un document xml
– Transport spécifie le protocole d’invocation.
– soap:action précise le contenu de l’entête du message d’invocation SOAP
– soap:body précise la forme des « messages parts » présents dans le corps du
message SOAP.
– Use est utilisé pour spécifier la forme des données, un namespace (encoded) ou
des paramètres (literal)

8
5
86 Elément <binding> (3/3)
 87 WSDL : Port & Service

 Port:
o Définit une extrémité de communication unique
o Adresse de l’extrémité pour le binding
o URL (pour HTTP), email (pour SMTP)
 Service : collection de ports
o Pour chaque protocole de transport supporté, il existe un seul port relative à un
binding.
o Fournit aussi la documentation lisible par l'homme
88 Elément <service>

• Permet de spécifier l’url où envoyer les messages

d’invocation.
• Service(name, port(name, binding, :address(location)) )
– Port spécifie l’adresse (URI) à laquelle un service peut être
invoqué.
• L’élément binding permet d’associer le nom du port au binding du
fichier wsdl.
– soap:address spécifie l’adresse du service

8
8
89 WSDL : structure

• Description de l’interface du service :

▪ Types : description des données (de paramètres) utilisées
dans les messages
Messages : description structurée des données échangées
Opérations : description abstraite des actions supportées par un service.
Type de port : ensemble d’opérations abstraites supportées par
un ou plusieurs services Web

▪ Binding : un protocole concret et une spécification de

format de données pour un type de port particulier.

8
9
90 WSDL
91 Représentation types de données
en XSD
92
L’annuaire UDDI
Chapitre 2 – Services Web