Architectures orientées

services
Chapitre 3:Les technologies des web
services
Dr.Ghada Besbes
Standards des SOA
• Les standards sont un élément clé d’une SOA, ils assurent
l’interopérabilité

SOAP WSDL UDDI

W3C W3C Microsoft, IBM, HP
Simple Object Web Services Universal Description
Access Protocol Description Language Discovery and Integration

Transport Décrit le contrat Annuaire

2
Standards des SOA
• SOAP (Simple Object Access Protocol)
• Un protocole standard de communication.
• C'est l'épine dorsale du système d'interopérabilité. SOAP est un
protocole décrit en XML.
• Il se présente comme une enveloppe pouvant être signée et pouvant
contenir des données ou des pièces jointes.
• WSDL (Web Services Description Language)
• Un langage de description standard.
• C'est l'interface présentée aux utilisateurs.
• Décrit les interfaces des services
• Il indique comment utiliser le service Web et comment interagir avec
lui.
• WSDL est basé sur XML et permet de décrire de façon précise les
détails concernant le service Web tels que les protocoles, les ports
utilisés, les opérations pouvant être effectuées, les formats des
messages d'entrée et de sortie et les exceptions pouvant être 3
envoyées.
Standards des SOA
• UDDI (Universal Description, Discovery and Integration)
• Un standard pour la publication et la découverte des
informations sur les services Web
• Il fournit l'infrastructure de base pour la publication et la
découverte des services Web.
• UDDI permet aux fournisseurs de présenter leurs services Web
aux clients.
• Afin d’être découvert, un service doit être publié

4
Fonctionnement d’un web
service

5
Fonctionnement d’un web
service
Le scenario complet
1. Définition, description du service
• On doit décrire d’un point de vue informatique ce que fait le service,
la solution qu’il propose, ...
• La définition est faite en WSDL au sein du fournisseur de services
(i.e. le serveur d’applications)
2. Publication du service
• Une fois le service défini et décrit en termes de mise en œuvre, il
peut être déclaré dans un annuaire, on parle alors de publication du
service afin de le rendre accessible aux clients.
• La publication sera effectuée au sein d’un annuaire dédié UDDI.
3. Recherche du service
• Le client se connecte à un annuaire (UDDI) pour effectuer une
recherche de service. 6
Fonctionnement d’un web
service
4. Enregistrement au service web
• Une fois le service trouvé par le client, ce dernier doit
s’enregistrer auprès du fournisseur associé au service. Cet
enregistrement indique au fournisseur l’intention du client
d’utiliser le service suivant les conditions décrites dans la
publication.
5. Mise en œuvre du service
• Le client peut invoquer le service suivant les conditions
inscrites au sein de l’annuaire lors de la publication du service
web (étape 2)
7
SOA
• Le paradigme SOA : Chercher, Publier et Consommer

8
SOA
• L’approche à services est un paradigme informatique qui
propose de construire des applications à partir de services.
Ces services sont fournis par des organisations tierces et
peuvent évoluer dynamiquement .
• Cette approche repose sur trois acteurs (Fournisseur de
service, Annuaire de service et Consommateur de service) et
trois interactions (Chercher, Publier et Consommer).

9
SOA
Interactions
• La publication : Un fournisseur de service s’enregistre auprès
du registre de service pour publier sa description de service.
Un fournisseur peut avoir plusieurs types de services.
• Recherche/découverte : Le consommateur de service
interroge le registre afin de trouver les services qu’il requiert.
• Consommation/invocation et liaison : Une fois le service est
découvert, son invocation consiste à établir une liaison entre
le consommateur et le fournisseur pour permettre son
utilisation.

10
 1

XML

11
Introduction
• XML est l'abréviation de Extensible Markup Language.
• XML n'est pas un langage de programmation.
• En très gros, XML sert à stocker des données.
• XML est un langage descriptif des données
• simplement une méthode pour représenter les données.
• Celles-ci sont écrites entre des balises ou sous forme d'attributs,
et l'ensemble est écrit sous forme d'un arbre.

12
Historique
• Le développement de XML à commencé en 1996 par le XML
Working Group formé sous la conduite du world wide web
Consortium (W3C).
• Il était présidé par Jon Bosak de Sun Microsystems avec la
participation active du XML Spécial interest GROUP également
organisé par le W3C.
• La première recommandation date de février 1998.

13
Exemple

14
Objectifs
• XML sera utilisable sans difficultés sur internet
• XML soutiendra une grande variété d'applications
• Il sera facile d'écrire des programmes traitant les documents XML
• Les documents XML devraient être lisibles par l'homme et
raisonnablement clairs
• La conception de XML devrait être préparée rapidement
• La conception de XML sera formelle et concise
• Il sera facile de créer des documents XML
• XML n’est pas un langage sémantiquement figé comme peut l’être
HTML mais au contraire un langage ouvert: L’auteur d’un document
XML peut créer ses propres balises.
• Contrairement à l’usage avec HTML, on emploiera le
terme « élément » à la place des termes « balises » et « tag ». Cette
distinction met en évidence la nature plus structurée de XML par 15
rapport à HTML.
XML la syntaxe
• Un document XML est découpé en éléments structurés
hiérarchiquement.
• Un document a un élément racine appelé élément du
document.
• Un élément est composé :
• D’un nom qui spécifie son type,
• D’attributs,
• D’un contenu formé d’éléments ou de textes.
• Un texte est une chaîne de caractères.
• Un attribut a un nom et une valeur qui est une chaîne de
caractères.
• Syntaxiquement, les éléments d’un document XML sont
marqués dans le document lui-même par des paires de balises 16
ouvrantes et fermantes.
XML la syntaxe
• Tous les éléments XML doivent avoir une balise fermante:
Avec XML, il est illégal d’omettre la balise fermante.
• Avec HTML, certains éléments n’ont pas de balise fermante. Le
code suivant est correct en HTML :
<p>This is a paragraph.
<br>
• En XML tous les éléments (à l’exception du prologue) doivent
avoir des balises fermantes, comme ceci :
<p>This is a paragraph.</p>
<br />
• A la différence du HTML, les balises XML sont sensibles à la
casse.
• Tous les éléments XML doivent être correctement imbriqués. 17
XML la syntaxe
• La syntaxe pour écrire des commentaires en XML est similaire
à celle de l’HTML :
< !- - This is a comment - - >
• Tous les documents XML doivent avoir une balise racine, qui
est également le premier élément du document XML. Dans
tous les documents XML, une seule paire de balise permet de
définir l’élément racine, tous les autres éléments doivent être
imbriqués dans cet élément.
• Tous les éléments peuvent avoir des sous éléments (enfants).
• Les espaces sont définies par les caractères " " , " \t" et "\n"
dans un document XML
18
XML la syntaxe
• Un document est composé
• d’un prologue (facultatif)
• d’un arbre d’éléments (obligatoire : décrit le contenu)
• de commentaires et instructions de traitement (facultatif)

19
XML la syntaxe
• Prologue
Déclaration XML (indications au processeur)

<? xmlversion= ‘‘1.0’’ encoding=‘ISO-8859-1’ standalone=‘‘yes’’?>

• xmlversion= ‘‘1.0’’ : décrit la version utilisée

• encoding=‘ISO-8859-1’: codage de caractères utilisés dans le
document.
• Dans cet exemple, il s'agit d'un document XML dont le jeu de caractères
est l'ISO-Latin 1 (norme ISO 8859-1).
• Dans l'exemple suivant, le jeu de caractères était l'Unicode, avec
encodage UTF-8, soit la valeur par défaut.
<?xml version="1.0" encoding="UTF-8"?>
• standalone=‘‘yes’’ : le document XML est autonome; toutes les
déclarations nécessaires au document y sont incluses. 20
XML la syntaxe
• Eléments
• Les éléments gèrent la structuration des données d’un
document XML, un peu à la manière des répertoires qui
servent à l’organisation des fichiers. On peut les qualifier de
métadonnées, au sens où ils ne font pas partie réellement des
données mais servent à en désigner la nature.
• Pour décrire ce que contiennent les éléments, on parle de
modèle de contenu. On trouve:
• Rien: il n’y pas de contenu, l’élément est vide.
• Du texte
• Un ou plusieurs éléments: on peut les qualifier d’éléments fils,
l’élément les contenant étant appelé un élément parent 21
XML la syntaxe
• Pour se familiariser, prenons l’exemple suivant.

22
XML la syntaxe
• Attributs
• Un document est formé d’une hiérarchie d’éléments dénotant
la structure sémantique du contenu.
• Tout élément fils est complètement inclus dans son père.
• L’élément racine est unique et contient tous les autres
éléments.
• Un élément peut contenir d’autres éléments, des données,
des références à des entités, des sections littérales. Il peut
aussi être vide.
• Le nom de l’élément peut éventuellement être suivi
d’attributs, qui décrivent des propriétés de l’élément. Chaque
attribut a une valeur unique. 23
XML la syntaxe
• Attributs

24
XML la syntaxe
• Attributs
• Un attribut est un couple (clé,valeur) associé à la définition
d’un élément. Il est localisé dans la balise ouvrante de
l’élément. Un élément peut donc avoir de 0 à n attributs
uniques. L’attribut est complémentaire de l’élément de par
son rôle au sens où il ajoute une information à l’élément ou
bien encore le complète dans sa définition.
• On sépare les attributs par au moins un espace (blanc simple,
tabulation, retour à la ligne). Les valeurs d’attributs peuvent
figurer sur plusieurs lignes. On utilise soit les guillemets, soit
les apostrophes pour encapsuler les valeurs.
25
XML la syntaxe

• nom et prenom sont des attributs de l’élément auteur alors

que email est un attribut de l’élément contact.

26
XML la syntaxe
Attribut ou pas?
• La construction:
<replique>
<personnage attitude='assis souriant' geste='un dollar entre les mains'>Jordan
Belfort</personnage>
<texte ton='long' > Je m’appelle Jordan Belfort. L’année de mes 26 ans, à la tête de
ma propre firme de courtage, je me suis fait 49 millions de dollars, ce qui m’énerva
vraiment car ça faisait à peine un million par semaine.</texte>
</replique>
• pourrait être remplacée par :
<replique>
<personnage>Jordan Belfort</personnage>
<attitude>assis souriant</attitude>
<geste>un dollar entre les mains</geste>
<ton>long</ton>
<texte> Je m’appelle Jordan Belfort. L’année de mes 26 ans, à la tête de ma propre
firme de courtage, je me suis fait 49 millions de dollars, ce qui m’énerva vraiment 27
car ça faisait à peine un million par semaine.</ texte>
</replique>
XML la syntaxe
Attribut ou pas?
• Il faut plutôt utiliser un élément
• lorsque l’ordre est important (l’ordre des attributs est au hasard)
• lorsqu’on veut réutiliser un élément plusieurs fois (avec le même
parent)
• lorsqu’on veut (dans le futur) avoir des descendants / une
structure interne
• pour représenter un type de données (objet) plutôt que son
usage, autrement dit: une "chose" est un élément et ses
propriétés sont des "attributs"
• Il faut plutôt utiliser un attribut
• pour indiquer l’usage/type/etc. d’un élément <adresse
usage="prof"> ... </adresse>
• lorsqu'on veut imposer des valeurs par défaut dans la DTD 28
XML la syntaxe
• Ces règles de syntaxe sont à respecter impérativement:
• Le nom d’un élément ne peut commencer par un chiffre. Pas
d’espaces, pas d’apostrophe, pas de / . Premier caractère
alphabétique ou _
• Si le nom d’un élément est composé d’un seul caractère il doit
être dans la plage [a-z,A-Z] (c’est-à-dire une lettre minuscule ou
majuscule sans accent) ou _ ou :.
• Avec au moins 2 caractères, le nom d’un élément peut contenir
_, - et . plus les caractères alphanumériques
• Tous les éléments ouverts doivent être fermés.

29
XML la syntaxe
• Voici quelques conventions souvent employées dans les
documents XML :
• Employer des minuscules pour les attributs et les éléments.
• Éviter les accents dans les noms d’attributs et d’éléments pour
des raisons de compatibilité avec les outils du marché qui
proviennent souvent d’un univers anglo-saxon.
• Préférer les guillemets délimitant les valeurs d’attribut.
• Séparer les noms composés de plusieurs mots par les caractères -
, _, . ou une majuscule.
• Essayer d’être homogène dans votre document en gardant la
même convention.

30
XML la syntaxe
Un document XML est bien formé si :
• Un document XML est construit selon la structure logique :
déclaration, élément racine, arbre d’élément et d’attributs,
commentaires.
• Le document XML doit respecter les contraintes de formes,
c'est-à-dire la hiérarchie des éléments XML. Une balise
ouverte avant une deuxième se doit d’être fermée avant et
d’éviter les chevauchements d’éléments.
• Le document n’utilise pas DTD et que sa structure est
conforme à XML.

31
Exercice 1
• Considérez le document XML suivant :

<svg viewBox="0 0 100 100">

<text x="10" y="90">Bonjour</text>
<rect x="30" y="30" width="40" height="40" stroke="blue"
fill="green" />
<circle cx="50" cy="30" r="20" stroke="blue" fill="red" />
</svg>

Combien y a-t-il d'éléments ? d'éléments de type texte ?

Corrigé:
Il y a 4 éléments, 1 élément de type texte
32
 Exercice 2
Considérez le document XML suivant :
<math><mfrac><msqrt><mi>x</mi></msqrt><mn>2</mn></mfrac></math>

1. Combien y a-t-il d'éléments ? d'attributs ?d'éléments de

type texte ?
• Corrigé:
Il y a 5 éléments, 0 attribut, 2 noeuds de type texte.
2. Quels sont les fils de mfrac ? Quel est le père de mi ? Le
père de mfrac ?
• Corrigé:
Fils de mfrac : msqrt et mn. Père de mi : msqrt. Père de mfrac : 33
math.
 Exercice 2
Considérez le document XML suivant :
<math><mfrac><msqrt><mi>x</mi></msqrt><mn>2</mn></mfrac></math>

3. Représentez le document sous la forme d'un arbre.

• Corrigé:

34
Espaces de noms XML
Définition:
• Un espace de noms permet de garantir l’unicité des noms des éléments
et des attributs.
• On attache une information unique à un nom de balise.
• Les namespaces, ou domaine de noms XML, correspondent à une
collection de noms uniques identifiée par un URI (Uniform Resource
Identifier).
• Un URI représente toutes les syntaxes identifiant une ressource
internet. La ressource Internet la plus utilisée est URL (Uniform
Resource Locator).
Déclaration:
• xmlns:reseau=http://www.fsr.ac.ma/reseau
Objectifs:
• distinguer les éléments et les attributs de différentes applications XML
qui ont le même nom
• grouper les éléments et les attributs d'une même application XML pour 35
que les logiciels puissent les reconnaître
Espaces de noms XML
• Notez que l’adresse n’est utilisée que pour identifier le namespace,
elle n’est plus utilisée par le parser pour d’autres opérations. Le
seul but est de donner un nom unique au namespace.
• Toutefois, il n’est pas rare que l’URL mentionné pointe vers une
véritable page web contenant des informations sur le namespace.
• Le nom d’un namespace apparaît sous la forme d’un préfixe (par
exemple reseau) de namespaces et d’un nom local qui sont séparés
par le caractère « : ».
• Le préfixe qui pointe sur un URI (par exemple
reseau=http://www.fsr.ac.ma/reseau), sélectionne le namespace.
Cette technique garantit ainsi l’unicité des identificateurs dans le
document XML;
36
Espaces de noms XML
Exemple 1

37
Espaces de noms XML: Exemple 1

• Ambiguïté → assignation des éléments et attributs à une clé

universelle

38
Espaces de noms XML: Exemple 1

39
Espaces de noms XML: Exemple 1

40
 Espaces de noms XML
Exemple 2
• Soit un document qui donne • Un document qui donne les
la position géographique adresses réseau d’un parc
d’un parc d’ordinateurs: d’ordinateurs:
<machines> <reseau>
<machine> <equipement>
<nom>unix1</nom> <adresse>
<adresse> <IP>212.140.115.10</IP>
<batiment>12</batiment> <nom>unix1.fsr.ac.ma</nom
<bureau>R-09</bureau> >
</adresse> </adresse>
</machine> </equipement>
…. ….
41
</machines> </reseau>
Remarque: la même balise adresse n’a pas le même sens dans les deux cas.
Espaces de noms XML
Exemple 2
• Si on fusionne les 2 documents, la signification de la balise adresse
devient ambigüe:
<machines>
<machine>
<nom>unix1</nom>
<adresse>
<batiment>12</batiment>
<bureau>R-09</bureau>
</adresse>
<adresse>
<IP>212.140.115.10</IP>
<nom>unix1.fsr.ac.ma</nom>
</adresse>
</machine>
…. 42
</machines>
Espaces de noms XML
Exemple 2
• La solution est d’associer un espace de noms et un préfixe qui qualifie
les noms des éléments et des attributs de cet espace.
<?xml version="1.0" encoding="ISO-8859-1"?>
<machines>
<machine>
<nom>unix1</nom>
<adresse>
<batiment>12</batiment>
<bureau>R-09</bureau>
</adresse>
<reseau:adresse xmlns:reseau="http://www.fsr.ac.ma/reseau" >
<reseau:IP>212.140.115.10</reseau:IP>
<reseau:nom>unix1.fsr.ac.ma</reseau:nom>
</reseau:adresse>
</machine> 43
….
</machines>
Espaces de noms XML
Exemple 2
• Plusieurs espaces de noms peuvent être utilisés.
<?xml version="1.0" encoding="ISO-8859-1"?>
<local:machines
xmlns:reseau="http://www.fsr.ac.ma/reseau"
xmlns:local="http://www.fsr.ac.ma/localisation">
<local:machine>
<local:nom>unix1</local:nom>
<local:adresse>
<local:batiment>12</local:batiment>
<local:bureau>R-09</local:bureau>
</local:adresse>
<reseau:adresse>
<reseau:IP>212.140.115.10</reseau:IP>
<reseau:nom>unix1.fsr.ac.ma</reseau:nom>
</reseau:adresse>
</local:machine>
…. 44
</local:machines>
Exercice 3
On se propose de rédiger un document XML qui décrit un magasin de livres et d’albums
(musique). La structure interne du magasin (en termes d’éléments) suit ce schéma (le
symbole * indique qu’on peut avoir de 1 à n éléments):

45
• N.B : L’élément piste a un attribut « num_piste » qui indique le numéro de la piste dans
l’album. L’élément prix (album et livre) est un élément vide contenant l’attribut « dinars »
qui indique le prix.
 2

DTD

46
Validation d'un document XML
par une DTD
• Un document XML est valide si :
S’il s’agit d’un document XML bien formé, qui se conforme
également aux règles d’un Document Type Definition(DTD)

• Ce document permet de spécifier des contraintes plus

précises et propres au langage XML.

• Cette spécification d'une grammaire pour un langage et la

possibilité de tester automatiquement son respect par un
document donné, présentent les avantages suivants :
• Faciliter l'échange et la mise en commun des documents produits
par des rédacteurs différents ;
• Aider les développeurs qui conçoivent des outils automatiques 47
pour traiter les documents respectant la même DTD.
Validation d'un document XML
par une DTD
• Dans un document XML valide apparaît une déclaration du
document DTD.
• Un document DTD définit:
• le nom des éléments, leur contenu, le nombre de fois et l'ordre
d'apparition,
• les attributs éventuels et leurs valeurs par défaut,
• Les documents XML valides doivent respecter les règles
données d'une DTD.

48
Types de DTD
• La déclaration d'une DTD doit apparaître après la déclaration
XML, mais avant l’élément racine.
<!xml version="1.0" ....>
<!DOCTYPE élément_racine ....>
• La déclaration de la DTD peut contenir :
• la DTD elle-même à l'intérieur du fichier XML (DTD interne)
• une adresse URL qui indique le fichier contenant la DTD (DTD
externe).

49
DTD interne
• Dans ce cas, la spécification de la DTD arrive dans l'entête du
document XML : on trouve d'abord le mot-clef DOCTYPE suivi
de l'élément racine du document et enfin la DTD elle-même
entre crochets :

<?xml version="1.0" encoding="iso-8859-1" ?>

<!DOCTYPE cv [
.
.
.
]>
<cv>
.
.
. 50
</cv>
DTD externe
• Cette fois, la DTD est détachée dans un fichier séparé, on se
contente d'y faire référence dans l'entête du document XML.
• On retrouve le mot-clef DOCTYPE suivi de l'élément racine,
puis le mot-clef SYSTEM suivi d'une URI menant au fichier
DTD.
• À noter également que la première ligne doit faire apparaître
l'attribut standalone avec la valeur no.

<?xml version="1.0" encoding="iso-8859-1" standalone="no" ?>

<!DOCTYPE cv SYSTEM "cv.dtd">
<cv>
.
. 51
.
</cv>
Types de DTD
• Hello XML sans DTD
<?xml version="1.0"standalone="yes"?>
<hello> Hello XML ! </hello>
• Hello XML avec DTD interne
<?xml version="1.0"standalone="yes"?>
<!DOCTYPE hello [
<!ELEMENT hello (#PCDATA)> ]>
<hello> Hello XML ! </hello>
• Hello XML avec DTD externe
<?xml version="1.0" encoding="ISO-8859-1" standalone="no" ? >
<!DOCTYPE hello SYSTEM "hello.dtd"> 52
<hello> Hello XML ! </hello>
DTD externe
• lls existent deux types de DTD externes : privé ou publique.
• Les DTD privées sont accessibles uniquement en local (sur la
machine de développement ) ou sur Internet:

<!DOCTYPE CATALOGUE SYSTEM "catcd.dtd">

<!DOCTYPE CATALOGUE SYSTEM "http://www.fdr.com/dtd/catcd.dtd">

53
DTD externe
• Les DTD publiques sont disponibles pour tout le monde, étant
accessibles grâce à un URN (Uniform Ressource Name)
<!DOCTYPE ElementRacine PUBLIC "NomDeLaDTD" "URLDeLaDTD">

• Elles sont généralement utilisées lorsque la DTD est une

norme
• Le nom de la DTD appelée URN doit avoir la forme:
-//W3C//DTD catalogue //FR
• Le nom du propriétaire suivie du type de document, suivi de la
langue. C'est par exemple cas dans les documents xHTML 1.0.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 54

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Définir les éléments et leurs
contenus
• Il s'agit ici de déclarer les éléments autorisés à apparaître dans
le document, ainsi que leurs imbrications possibles. La forme
générale est la suivante :

<!ELEMENT nom_element modèle_de_contenu>

• Les noms des éléments (comme ceux des attributs) doivent

être des noms XML :
• le premier caractère est une lettre quelconque ou un _
• les caractères suivants peuvent être des lettres, des chiffres, des
tirets bas (_), des traits d'union (-) ou des points (.) ;
• il n'y a pas de limitation sur la longueur d'un nom XML.
55
Définir les éléments et leurs
contenus
Contenu purement textuel
• Si l'élément peut contenir du texte brut mais pas de nouvelles
balises, on utilisera le modèle de contenu PCDATA :

<!ELEMENT téléphone (#PCDATA)>

• Aucune balise n'est donc tolérée dans ce type de contenu.

56
Définir les éléments et leurs
contenus
Sous-éléments
Ici, on va lister les sous-éléments pouvant apparaître dans le contenu,
par exemple:
<!ELEMENT identité (prénom,nom)>
indique que l'élément identité doit contenir, dans l'ordre, un élément
prénom, un élément nom, et rien d'autre.
• Il est possible de moduler le nombre d'apparitions d'un sous-
élément en utilisant des quantifieurs après les noms d'éléments. Les
quantifieurs utilisables dans les DTD sont :
• ? : 0 ou 1 fois ;
• * : 0, 1 ou plus ;
• + : 1 ou plus.
• L'exemple suivant indique que l'élément identité doit contenir,
toujours en respectant l'ordre, un ou plusieurs éléments prénom, un
élément surnom facultatif et exactement un élément nom : 57

<!ELEMENT identité (prénom+,surnom?,nom)>

Définir les éléments et leurs
contenus
• Alternatives
• Il est également possible de définir les sous-éléments qui
peuvent apparaître de manière exclusive : si c'est l'un, ce n'est
pas les autres.
• Dans l'exemple ci-dessous, une expérience professionnelle
peut être soit un emploi, soit un stage :

<!ELEMENT expérience (stage|emploi)>

58
Définir les éléments et leurs
contenus
Combinaisons
• Il est possible de combiner les syntaxes vues précédemment:
<!ELEMENT diplôme ( (intitulé,année) | (année,compétences,stage?)+ )>

• Dans ce cas, un diplôme est :

• soit l'intitulé du diplôme et l'année d'obtention ;
• soit une suite de : année, avec les compétences acquises cette
année là, éventuellement validées par un stage.

59
Définir les éléments et leurs
contenus
• Contenu mixte
• Certains éléments ont un contenu mixte, c'est à dire qu'ils
sont composés d'une alternance, dans un ordre quelconque,
de fragments textuels et d'éléments.
• La déclaration d'un élément à contenu mixte se fait toujours
selon la syntaxe suivante, le mot clé #PCDATA étant
nécessairement en première position :

<!ELEMENT nom_élément (#PCDATA | elt1 | elt2 | ... | eltn)* >

60
Définir les éléments et leurs
contenus
• Contenu mixte
Par exemple :
<!ELEMENT paragraphe (#PCDATA | note | renvoi)*>

définit un élément paragraphe qui pourrait avoir la structure

suivante :

<paragraphe> Prendre le chemin de l'Inca<renvoi>...</renvoi> et marcher

jusqu'à la porte du Soleil<renvoi>...</renvoi>. Ne pas oublier de prendre un
foulard et de bonnes chaussures<note>...</note>. </paragraphe>

61
Définir les éléments et leurs
contenus
• Contenu vide
• Un élément peut également n'avoir aucun contenu, comme
c'est le cas par exemple de la balise br(retour à la ligne en
HTML).
• Cela se précise dans la DTD de la manière suivante :

<!ELEMENT br EMPTY>

• Une telle balise sera donc ouverte et immédiatement

refermée avec la notation suivante : <br/>.

62
Définir les éléments et leurs
contenus
• Contenu quelconque
• On termine avec la possibilité d'autoriser n'importe quel contenu à
apparaître dans un élément.

<!ELEMENT mavie ANY>

• Dans ce cas, l'élément mavie pourra contenir du texte brut mélangé

avec toute balise définie dans la DTD, dans n'importe quel ordre,
autant de fois que l'on veut.
• Ce modèle de contenu est en contradiction avec l'esprit des DTD,
qui visent plutôt à restreindre au maximum le rédacteur.
• Une utilisation cependant pratique du ANY intervient lors de la
rédaction d'une DTD alors que les documents XML sont déjà
existants: dans ce cas, on définit les éléments de plus haut niveau en
indiquant ANY pour leurs contenus, si les documents sont valides,
on reprend la DTD en affinant le contenu de chacun des éléments, 63
etc.
Définir les éléments et leurs
contenus
• Contenu quelconque
• Exemple de DTD

<!ELEMENT adresse ANY >

• Exemple de document :

<adresse><rue></rue><ville>Paris</ville></adresse>

Remarque: les éléments « rue » et « ville » doivent être déclarés

dans la DTD

64
Définir les éléments et leurs
contenus
• Définir les attributs
• La description des attributs se fait par une déclaration d'une liste
d'attributs (ATTLIST)
• La syntaxe est la suivante:
<!ATTLIST Elément Attribut Type Valeur-par-défaut>

• avec :
<!ATTLIST Elément Attribut Type #FIXED Valeur>

• FIXED signifie que l'attribut a une valeur fixe

<!ATTLIST Elément Attribut Type #REQUIRED>
• REQUIRED signifie que l'attribut est obligatoire et n'a pas de valeur 65
par défaut
Définir les éléments et leurs
contenus
• Définir les attributs
<!ATTLIST Elément Attribut Type #IMPLIED>

• IMPLIED signifie que l'attribut n'est pas obligatoire et n'a pas

de valeur par défaut
• CDATA: Type général qui permet de saisir un texte quelconque
pour un attribut de ce type.
• Remarques:
• les noms des attributs doivent être des noms XML
• l'ordre des déclarations des attributs d'un élément n'a pas
d'importance
66
Définir les éléments et leurs
contenus
• Définir les attributs
• Exemple 1:
<!ELEMENT MESSAGE (#PCDATA)>
<!ATTLIST MESSAGE LANGUE CDATA "Français">
L'élément MESSAGE contient des données textuelles et peut
contenir un attribut nommé LANGUE, sa valeur par défaut est
"Français".

67
Définir les éléments et leurs
contenus
• Définir les attributs
• Exemple 2:
• On peut, dans une même déclaration ATTLIST, définir
plusieurs attributs associés au même élément:
<!ATTLIST IMG WIDTH CDATA "100">
<!ATTLIST IMG HEIGHT CDATA "100">
• peuvent se résumer en une seule déclaration:
<!ATTLIST IMG WIDTH CDATA "100"
HEIGHT CDATA "100">

68
Définir les éléments et leurs
contenus
• Définir les attributs
• Exemple 3:
<!ATTLIST identité prénom CDATA #REQUIRED
nom CDATA #REQUIRED
surnom CDATA #IMPLIED>

• Dans ce cas, l'élément identité possède trois attributs

prénom, nom et surnom. Les deux premiers sont obligatoires
(REQUIRED) et le dernier est optionnel (IMPLIED).

69
Définir les éléments et leurs
contenus
• Définir les attributs: Enumération
• Nous pouvons limiter la liste de valeurs possibles pour un
attribut.
• On le définit comme un type énuméré.
• Exemple de déclaration d'une liste de choix d'attributs:
<!ELEMENT img EMPTY>
<!ATTLIST img format (GIF|JPEG|PNG) "GIF">
• Nous déclarons un attribut format d'un élément img.
• Cet attribut peut prendre une valeur parmi GIF, JPEG et PNG.
• La valeur par défaut est GIF.
• Remarque: ne pas mettre des guillemets dans la liste des 70
valeurs possibles.
Définir les éléments et leurs
contenus
• Définir les attributs: Enumération
• Exemple 1:

<!ELEMENT personne (nom, prenom+, tel?, email,adresse) >

<!ELEMENT nom (#PCDATA) >
<!ELEMENT prenom (#PCDATA) >
<!ELEMENT tel (#PCDATA) >
<!ELEMENT email (#PCDATA) >
<!ELEMENT adresse ANY>
<! ATTLIST personne
age CDATA #IMPLIED
genre (Masculin | Feminin ) #REQUIRED >
71
Définir les éléments et leurs
contenus
• Définir les attributs: Enumération
• Exemple 2:

<!ELEMENT auteur (#PCDATA) >

<!ATTLIST auteur
genre (Masculin | Feminin ) #REQUIRED
ville CDATA #IMPLIED>
<!ELEMENT editeur (#PCDATA) >
<!ATTLIST editeur
ville CDATA #FIXED "Tunis">

72
Limitations des DTD
Les reproches suivants sont systématiquement faits aux DTD :
• Le nombre d'apparitions d'un élément ne peut pas être contraint
précisément, puisque l'on ne dispose que des quantifieurs ?, * et +,
on aimerait pouvoir dire qu'un élément doit apparaître plus de 2
fois mais toujours moins de 5 ;
• On ne dispose pas de types pour les contenus des attributs et des
éléments (nom, date, code postal, numéro de téléphone, url,
adresse mail, etc.) ;
• On ne peut pas contraindre la forme de ces contenus (entre 5 et 20
caractères, contenant un signe @, etc. ) ;
• Le langage utilisé pour définir une DTD n'est pas un langage XML !
Pour pallier ces manques, d'autres propositions ont été faites,
permettant elles aussi de spécifier un langage XML, citons les XML 73
Schema.
Exercice
• On veut encoder un arbre généalogique dans un format XML.
La racine est gene, elle a pour fils des éléments personne. On
autorise une généalogie vide.
• L'élément personne a un attribut facultatif id et un attribut
obligatoire genre pouvant prendre au choix les valeurs h et f. Il
a un fils nom, obligatoire, contenant uniquement du texte et
un fils parents, facultatif, vide. L'élément parents possède un
attribut ref, obligatoire.
• Écrire la DTD correspondant à cette description, et insérer-là
en tant que DTD interne d'un document XML décrivant la
généalogie suivante: Bob a deux parents, Marie et Henry.
Henry a deux parents, Jean et Françoise.
75
Exercice
• On souhaite écrire un livre en utilisant le formalisme XML .
• Le livre est structuré en sections (au moins 2), en chapitres (au
moins 2) et en paragraphes (au moins 2).
• Le livre doit contenir la liste des auteurs (avec nom et
prénom).
• Les auteurs possèdent les attributs nom et prenom .
• Le livre, les sections et les chapitres possèdent l'attribut titre.
• Tous les éléments doivent posséder un titre, sauf le
paragraphe qui contient du texte.

• Créez une DTD livre.dtd qui représente l’énoncé ci-dessus.

76
 3

XML Schema

77
SCHEMAS XML
• XML Schéma est une recommandation du W3C de mai 2001
qui consiste à définir une méthodologie de description de
document XML autrement que par une DTD.
• L’approche cherche à résoudre plusieurs problèmes des DTD
dont l’épine dorsale est le fait qu’une DTD n’est pas un
document XML.
• Un XML Schéma est donc un document dont l’objectif est
similaire à une DTD mais sous forme d’un document XML.

78
SCHEMAS XML
Définition d’un xml schéma
• Un XML Schéma est un document XML qui utilise un ensemble de
balises définies au sein de la recommandation du W3C.
• L’exemple suivant illustre la mise en place d’un schema:

<?xml version="1.0" ? >

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
</xsd: schema>

• On constate dans l’exemple précédent que l’on utilise l’espace de

noms xsd dont l’URI est: http://www.w3.org/2001/XMLSchema.
• Cet espace de noms permet de distinguer les balises propres à la
recommandation XML Schéma des autres balises qui pourront être 79
utilisées.
SCHEMAS XML
Définition d’un xml schéma
• La déclaration:
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.com/name"
xmlns=" http://www.example.com/name ">
...
...
</xsd:schema>

• Signifie:
• targetNamespace: Indique que les éléments définis par ce schéma
proviennent du namespace «http://www.example.com/name». 80
• xmlns Indique que le namespace par défaut est
«http://www.example.com/name» pour les éléments sans préfixe
SCHEMAS XML
• Les fichiers schémas XML portent par convention
l’extension « .xsd » et sont constitués de définitions
d’éléments XML.
• Chaque définition est associée à un type soit simple soit
complexe :
• Les types simples caractérisent les éléments XML qui ne
peuvent contenir que du texte (texte qui peut cependant
représenter plusieurs types de données comme des
nombres, des booléens, etc.)
• Les types complexes correspondent, quant à eux, à tous les
autres éléments XML (plus généralement des éléments qui
contiennent des sous-éléments). 81
SCHEMAS XML: Les types
simples
• Les types simples sont utilisés pour la définition des éléments

• Il est également possible de restreindre les types simples en

apportant des informations supplémentaires sur le type en
question.
• La définition d’un élément de type simple respecte la syntaxe
suivante:
<element name="nom de l’élément" type="nom du type" / >

• Exemple
<element name="age" type="integer" / >

82
SCHEMAS XML: Les types
simples
• Ils existent plusieurs catégories de types simples:
• string: les chaines de caractères;
• decimal: les nombres décimaux ;
• integer: les nombres entiers
• boolean: les valeurs booléennes;
• date: les dates;
• time: les heures.

83
SCHEMAS XML: Les types
simples
Soit le document XML suivant:

<nom>Dupont</nom>
<age>25</age>

En appliquant les règles précédentes, le schéma correspondant est

obtenu:

< ?xml version="1.0" ? >

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="nom" type="xsd:string" />
<xsd:element name="age" type="xsd:integer " /> 84
</xsd:schema>
SCHEMAS XML: Les types
simples
Restreindre les types simples
• Les restrictions permettent de raffiner l’intervalle d’expression de
chaque type simple.
• Il est possible, grâce à une restriction sur le type integer, de
préciser qu’une valeur entière est comprise entre 0 et 1000.
• Pour définir une restriction, on procède de la façon suivante:

<element name="nom de l’élément" >

<simpleType>
<restriction base="nom du type restreint" >
description de la restriction
</restriction>
</simpleType>
</element> 85
SCHEMAS XML: Les types
simples
Les restrictions sur la taille d’un type
• Cette restriction permet de caractériser la taille d’un type et s’applique
essentiellement au type chaine de caractère.
• L’exemple suivant décrit l’élément adresse et précise que la taille des
données de cet élément doit être comprise entre 10 et 80 :
<xsd:element name="adresse" >
<xsd:simpleType>
<xsd :restriction base="xsd:string" >
<xsd :minlength value="10" />
<xsd :maxlength value="80" />
</xsd :restriction >
</xsd:simpleType>
</xsd:element>
• On notera qu’on peut préciser uniquement soit la taille minimale
(minlength), soit la taille maximale (maxlength).
• length: Spécifie le nombre exact de caractères. Doit être supérieur ou égal à 86
zéro
SCHEMAS XML: Les types
simples
Les restrictions sur un intervalle de valeur
• Dans ce type de restriction, on peut préciser qu’une valeur entière
est comprise entre 0 et 1000.
<xsd:element name="valeur" >
<xsd:simpleType>
< xsd :restriction base=" xsd:integer" >
< xsd:minInclusive value="0" />
< xsd:maxInclusive value="1000" />
</xsd :restriction >
</xsd:simpleType>
</xsd: element>
• On note l’utilisation de minInclusive et maxInclusive pour préciser
les bornes de l’intervalle des valeurs.
• On pourrait également utiliser minExclusive et maxExclusive pour 87
exclure de l’intervalle les valeurs des bornes.
SCHEMAS XML: Les types
simples
Les restrictions sur un ensemble de valeur
• Ce type de restriction permet d’énumérer une liste de valeurs possibles
pour un élément ou un attribut.
• L’exemple suivant définit l’élément jours et énumère les valeurs autorisées
pour ce dernier :
<xsd:element name="jours">
< xsd:simpleType>
<xsd :restriction base="xsd:string" >
<xsd :enumeration value ="lundi " />
<xsd :enumeration value ="mardi " />
<xsd :enumeration value ="mercredi " />
<xsd :enumeration value ="jeudi " />
<xsd :enumeration value ="vendredi " />
<xsd :enumeration value ="samedi " />
<xsd :enumeration value ="dimanche " /> 88
</xsd :restriction>
</xsd:simpleType>
</xsd:element>
SCHEMAS XML: Les types
complexes
• Les éléments de type complexes sont les éléments qui peuvent
contenir des sous éléments et/ou des attributs.
• Pour définir un type complexe, on utilise la syntaxe suivante:
<xsd:element name="nom de l’élément complexe" >
<xsd:complexType>
description du type complexe
</xsd:complexType>
</xsd:element>

• Remarque: Avec cette méthode, seul l'élément " nom de l’élément

complexe " peut utiliser le type complexe spécifié

89
SCHEMAS XML:Les types
complexes
Exemple:
<employee>
<firstname>John</firstname>
<lastname>Smith</lastname>
</employee>

• Un élément complexe comporte en général une séquence de sous-

éléments. Pour cette raison on utilise la déclaration sequence afin
de signifier cette caractéristique comme l’illustre le schéma suivant:
<xsd:element name="employee">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="firstname" type="xsd:string"/>
<xsd:element name="lastname" type="xsd:string"/> 90
</xsd:sequence>
</xsd:complexType>
</xsd:element>
SCHEMAS XML: Les types
complexes
• On peut séparer la définition de l’élément de celle du type
complexe:

< xsd:element name="nom de l’élément complexe" type=" nom du type" />

<xsd:complexType name=" nom du type" >
description du type complexe
</xsd:complexType>

• Ce type de notation est particulièrement intéressant si plusieurs

éléments utilisent le même type complexe.

91
SCHEMAS XML:Les types
complexes
• Exemple: L'élément "employee" peut avoir un type qui fait
référence au nom du type complexe à utiliser

<xsd:element name="employee" type="personinfo"/>

<xsd:complexType name="personinfo">
<xsd:sequence>
<xsd:element name="firstname" type="xsd:string"/>
<xsd:element name="lastname" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>

92
SCHEMAS XML:Les types
complexes
• Si on utilise cette méthode, plusieurs éléments peuvent se référer
au même type complexe, comme ceci:

<xsd:element name="employee" type="personinfo"/>

<xsd:element name="student" type="personinfo"/>
<xsd:element name="member" type="personinfo"/>

<xsd:complexType name="personinfo">
<xsd:sequence>
<xsd:element name="firstname" type="xsd:string"/>
<xsd:element name="lastname" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>

93
SCHEMAS XML: Les types
complexes
• La syntaxe pour définir un attribut est:

<xsd:attribute name="xxx" type="yyy"/>

Avec xxx est le nom de l’attribut et yyy son type

• Exemple:

<xsd:attribute name="langue" type="xsd:string"/>

• Dans cet exemple on définit l’attribut « langue » avec le type chaine

de caractères.

94
SCHEMAS XML:Les types
complexes
La syntaxe pour définir un attribut est:
• default signifie la valeur par défaut d’un attribut:

<xsd:attribute name="langue" type="xsd:string" default="EN"/>

• fixed signifie que l'attribut a une valeur fixe

<xsd:attribute name="langue" type="xsd:string" fixed="EN"/>

• use="required" signifie que l'attribut est obligatoire et n'a pas de

valeur par défaut

<xsd:attribute name="langue" type="xsd:string" use="required"/>

• Remarque: Les attributs sont optionnels par défaut. 95

SCHEMAS XML: Les types
complexes
Les indicateurs
• La déclaration sequence fait partie de la catégorie des indicateurs.
• Ils existent plusieurs autres indicateurs
• Les indicateurs d’ordre: il s’agit des balises qui définissent des sous-
éléments:
• all: tous les sous-éléments décrits dans cet indicateur sont obligatoires dans
n’importe quel ordre,
• Choice: un des éléments décrit dans cet indicateur doit être utilisé,
• Sequence: définit une liste de sous-éléments où chaque sous-élément est
obligatoire et doit suivre l’ordre défini
• Les indicateurs d’occurrence: ils sont utilisés pour définir la fréquence
avec laquelle un élément peut se produire:
• maxOccurs: spécifie le nombre maximal de fois qu'un élément peut se
produire (Pour qu’un élément apparaisse un nombre illimité de fois, on
utilise maxOccurs = "unbounded") 96
• minOccurs: spécifie le nombre minimum de fois un élément peut se produire
SCHEMAS XML: Les types
complexes
Les indicateurs
• Exemple

<xsd:element name="person">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="full_name" type="xsd:string"/>
<xsd:element name="child_name" type="xsd:string" maxOccurs="10"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>

• L'exemple indique que l'élément "child_name" peut se produire au

moins une fois (la valeur par défaut de minOccurs et maxOccurs est 97
1) et un maximum de dix fois dans l'élément «personne».
SCHEMAS XML: Les types
complexes
Les indicateurs
• Exemple
<xsd:element name="person">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="full_name" type="xsd:string"/>
<xsd:element name="child_name" type="xsd:string"
maxOccurs="10" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
• L'exemple indique que l'élément "child_name" peut se produire un
minimum de zéro et un temps maximum de dix fois dans l'élément 98
«personne».
Diviser un SCHEMA XML
• On déclare de manière globale les différents éléments qui
composent le Schéma XML, puis, dans les structures complexes, on
y fait référence.
• La déclaration d'un élément ne change pas par rapport à ce que
nous avons vu jusqu'à maintenant, qu'il s'agisse d'un élément simple
ou d'un élément complexe.
• Établir une référence est alors très simple grâce au mot clef ref :

<xsd:element ref="mon_nom" />

99
Diviser un SCHEMA XML
Exemple: décomposer l'identité d'un client:

Initialement:

<xsd:element name="identite" >

<xsd:complexType>
<xsd:sequence>
<xsd:element name="nom" type="xsd:string" ></xsd:element>
<xsd:element name="prenom" type="xsd:string"></xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
100
Diviser un SCHEMA XML
Après division:

<xsd:element name="nom" type="xsd:string" ></xsd:element>

<xsd:element name="prenom" type="xsd:string" ></xsd:element>

<xsd:element name="identite" >

<xsd:complexType>
<xsd:sequence>
<xsd:element ref="nom" ></xsd:element>
<xsd:element ref="prenom" ></xsd:element>
</xsd:sequence>
</xsd:complexType>
101
</xsd:element>
Exercice
Transposer l’arbre en DTD puis en un schéma XSD avec les
caractéristiques suivantes (le symbole * indique qu’on peut avoir
de 0 à n éléments) :
• L’élément « laboratoire » est optionnel
• Une année est une chaîne de 4 caractères
• Un livre contient exactement un titre, un prix, une année et au
moins un auteur. De plus, on associe à des éléments de ce
type l'attribut obligatoire "edition" qui précise s’il s'agit d'un
paperback ou d'une édition reliée.
• Un prix est un type vide complexe, on lui associe deux
attributs obligatoires: "valeur" et "monnaie" ("monnaie" a un
type qui dérive de "string", son champ de valeur se limite aux 102
chaînes "USD" et "EUR")
Exercice

103
 4

SOAP

104
SOAP
• SOAP (Simple Object Access Protocol) est une
recommandation du W3C (http://www.w3.org/TR/SOAP/)
• Mettre en œuvre une application qui communique via
SOAP/HTTP avec d'autres applications correspond à une partie
de l'implantation de services Web.
• un message SOAP est un document XML appelé « enveloppe».
• La déclaration d'une enveloppe SOAP comporte la définition
d'un espace de noms dont l’URI précise la version supportée
de SOAP

105
SOAP
• SOAP est un protocole de transmission de messages
• Il définit un ensemble de règles pour structurer des messages
principalement pour exécuter des dialogues requêtes-réponse
de type RPC (Remote Procedure Call)
• Il n’est pas lié à un protocole particulier mais HTTP est
populaire
• Il n’est pas non plus lié à un système d’exploitation ni à un
langage de programmation, donc, les clients et serveurs de
ces dialogues peuvent tourner sur n’importe quelle
plateforme et être écrits dans n’importe quel langage du
moment qu’ils puissent formuler et comprendre des
messages SOAP 106
SOAP
• Principe de RPC:
• Un client a une description (ou une interface) de procédures
disponibles chez un serveur distant
• Le client invoque une procédure à distance
• Le serveur exécute localement cette procédure
• Le serveur renvoie au client le résultat de la procédure.

107
SOAP
Exemple

108
SOAP
Exemple

109
SOAP
Exemple

110
SOAP
Modèle de messages
• Message SOAP: transmission d’informations d’un émetteur
vers un récepteur
• Symétrie totale: si on utilise SOAP pour implémenter un
mécanisme question/réponse, les messages ont le même
format global
• Notion de routage: un message peut passer d’un émetteur à
son récepteur final en passant par des récepteurs
intermédiaires qui peuvent modifier le message
• Notion d’erreur: le format prévoit des messages spéciaux
correspondant à la description d’une erreur
112
SOAP
• L'enveloppe est constituée de
deux parties :
• l'en-tête optionnel (header)
• le corps du message (body)
• L’enveloppe peut aussi contenir
l’élément fault (erreur) qui est un
élément facultatif défini dans le
corps SOAP et qui est utilisé pour
reporter les erreurs.

113
SOAP
• Un message SOAP valide est un document XML bien formé
• Le prologue XML peut être présent, mais, doit contenir
seulement une déclaration XML
<?xml version="1.0" encoding="UTF-8"?>
spécifiant la version de XML et l’encodage des caractères du
message XML

114
SOAP
• On peut résumer cette structure par le code suivant :
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
<soap:Header>
...
</soap:Header>
<soap:Body>
...
<soap:Fault>
...
</soap:Fault>
</soap:Body>
</soap:Envelope>

• L’attribut encodingStyle indique quelle méthode d’encodage a été 115

employée pour le message
SOAP
• L'enveloppe SOAP
• L'enveloppe SOAP sert de conteneur aux autres éléments du
message SOAP, elle est définie au début par la balise
<soap:Envelope> et se termine par la balise </soap:Envelope>.
• Les messages SOAP ne peuvent pas être envoyés en lots, autrement
dit l'enveloppe contient un seul message constitué d'un entête
facultatif (SOAP header) et d'un corps obligatoire (SOAP body).
• Toutes les balises XML associées à SOAP ont le préfixe soap (on
trouve aussi "soap-env"). L'entête est <soap:Header> et le corps
<soap:Body>.
• Deux autres espaces de noms fortement utilisés dans SOAP sont
«xsd» et «xsi».
• xsd namespace précise que les balises proviennent de la définition
de schéma XML.
• xsi namespace indique que les balises viennent d'une instance d'un 116
schéma XML.
SOAP
L'en-tête de message
• L'entête optionnel d'un message SOAP permet de véhiculer
des informations additionnelles de nature quelconque.
• L’en-tête contient des informations contextuelles
(transaction, authentification…).
• Un message SOAP peut circuler entre plusieurs intervenants.
• N'importe quel utilisateur de SOAP peut ajouter dans l'en-tête
les données qu'il souhaite.
• Tous les éléments fils de l’en-tête doivent appartenir à un
namespace

117
SOAP
• L'en-tête de message
• Exemple
<?xml version="1.0"?>

<soap:Envelope
xmlns:soap="http://www.w3.org/2003/05/soap-envelope/"
soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">

<soap:Header>
<m:Trans xmlns:m="http://www.w3schools.com/transaction/">234
</m:Trans>
</soap:Header>
...
...
</soap:Envelope> 118
SOAP
• L'en-tête de message
• Par défaut, l'application réceptrice d'un message SOAP peut ignorer
un élément de l'en-tête dans le cas par exemple où elle ne
comprend pas cet élément.
• L'application émettrice peut cependant forcer l'application
réceptrice à prendre en compte un élément en fixant l'attribut
mustUnderstand à vrai lors de la définition d'un élément de l'en-
tête.
• Si l'application réceptrice ne peut pas prendre en compte cet
élément obligatoire, alors celle-ci retournera un message d'erreur.
<soap:Header>
<sec:identity xmlns:sec="http://www.exemple.fr/security"
soap:mustUnderstand="true" >
<sec:principal>Dupont</sec:principal> 119
</sec:identity>
</soap:Header>
SOAP
Le corps du message
• Le corps d'un message SOAP est un ensemble d'éléments
XML. Il n'existe quasiment aucune restriction sur ce contenu
excepté sur le format des données qui doivent
impérativement respecter le modèle d'encodage précisé avec
la déclaration de l'enveloppe.
• L’une des caractéristiques les plus intéressantes du protocole
SOAP est sa capacité à gérer des paramètres de tout niveau de
complexité.
• Cette capacité est directement déduite du modèle des
schémas XML et consiste à traiter des types primitifs (entier,
chaîne de caractères etc..), des tableaux et structures et toute 120
combinaison de ceux-ci.
SOAP
Le corps du message
• Exemple 1:

<soap:Envelope xmlns:soap="http://www.w3c.org/2001/12/soap-envelope">
<soap:Body>
<personne>
<nom>Dupont</nom>
<prenom>Francois</prenom>
</personne>
</soap:Body>
</soap:Envelope>

121
SOAP
• Le corps du message
• Exemple 2: message 1

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body>
<m:GetPrice xmlns:m="http://www.w3schools.com/prices">
<m:Item>Apples</m:Item>
</m:GetPrice>
</soap:Body>
</soap:Envelope>
122
SOAP
• Le corps du message
• Exemple 2: message 2

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body>
<m:GetPriceResponse xmlns:m="http://www.w3schools.com/prices">
<m:Price>1.90</m:Price>
</m:GetPriceResponse>
</soap:Body>
</soap:Envelope>

123
SOAP
L'élément fault
• Afin de récupérer le plus grand nombre d'erreurs, l'approche SOAP
se base essentiellement sur le bon usage de la balise <soap:fault>
qui est contenue dans le corps SOAP.
• Cette balise est utilisée pour communiquer un problème qui a eu
lieu dans la tentative de réalisation de la demande adressée au
service Web.
• L'élément d'erreur est facultatif et figure uniquement dans les
messages de réponse, il ne peut y apparaître qu'une seule fois
• L'élément Fault permet de définir un message d'erreur qui pourrait
survenir lors du traitement d'un message SOAP. De ce fait, cet
élément est retourné à l'émetteur par le récepteur du message au
format SOAP. 124
SOAP
L'élément fault
• Cet élément comporte deux sous-éléments obligatoires :
• faultcode: cet élément précise la nature de l'erreur en indiquant un code
d'erreur; on distingue les codes d'erreur suivants :
• DataEncodingUnknown : le modèle d'encodage utilisé n'est pas
supporté,
• DTDNotSupported : le contenu du message SOAP est associé avec
DTD, ce qui n’est pas supporté,
• mustUnderstand : un élément obligatoire n'est pas reconnu,
• Receiver : le message n'a pu être traité du coté récepteur pour une
raison quelconque non liée au format du message,
• Sender : le message reçu est invalide et a donc été mal formé par
l'émetteur
• Server : indique qu'une erreur s'est produite sur le serveur, mais pas
avec le message lui-même.
• faultstring : cet élément précise un message de description pour
l'erreur. C’est la version lisible par l'homme de la balise faultcode. C'est 125
la traduction en langage naturel du code d'erreur
SOAP
L'élément fault
• Deux sous-élements optionnels de l'élément Fault offrent la
possibilité de compléter le message 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: un ensemble d'informations additionnelles de
nature quelconque

126
 SOAP
L'élément fault
• Exemple
<soap:Body>
<soap:Fault>
<!-- Identifiant de l'erreur ? défini par SOAP-->
<faultcode>soap:Server</faultcode>

<!--Description brève du message-->

<faultstring>Impossible de router le message.</faultstring>

<!-- Composant qui a généré l'erreur (URL).-->

<faultactor>http://www.monsite.com/messageDispatcher</faultactor>

<!--Message spécifique à l'application-->

<detail>
<m:error xmlns:m="http://www.monsite.com/errors"> E_NO_ROUTE </m:error> 127
</detail>
</soap:Fault>
</soap:Body>
 SOAP
• Exemple
<soap:Envelope
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:soap ="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<soap:Body>
<ns1:calculer xmlns:ns1="urn:MonService">
<param1 xsi:type="xsd:int">123</param1>
</ns1:calculer>
</soap:Body>
</soap:Envelope>
• Dans cet exemple, nous invoquons la méthode calculer avec la
valeur 123 en argument. 128
• Notez bien que cette valeur est typée grâce au type simple xsd:int.
• L’élément calculer est lié à un espace de nom qui correspond en
réalité au service traitant cette requête
 SOAP
• Exemple
<soap:Envelope
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:soap ="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<soap:Body>
<ns1:calculerResponse xmlns:ns1="urn:MonService">
<return xsi:type="xsd:int">246</return>
</ns1:calculerResponse>
</soap:Body>
</soap:Envelope>

• Le nom de la méthode est complété par le suffixe Response. 129

• L’élément return désigne la valeur résultat et est typé grâce à
un type simple xsd:int.
SOAP

130
SOAP
Exemple message input

131
SOAP
Exemple message output

132
 5

WSDL

133
Protocole WSDL
• Le langage WSDL permet de décrire des services Web à l'aide
du langage XML.

• L'utilisation du langage WSDL est de plus en plus

indispensable et est bien souvent automatisée par les outils
du marché.

• En définitive, il est rare de devoir écrire soi-même ses

descriptions WSDL mais il est, en revanche, nécessaire de
pouvoir les interpréter. En effet, il est souvent fastidieux de lire
un document WSDL et il est préférable de se doter d'un outil
pour visualiser un tel document. 134
Protocole WSDL
• WSDL décrit :
• Les informations sur les fonctions publiques du service web ;
• Les types de données utilisés durant l’échange de messages ;
• Les différents protocoles aux travers desquels le service est
accessible ; et comment y accéder ;
• Une adresse permettant de localiser le service web.
• Un document WSDL délivre un ensemble de définitions de
services Web
• Il s'agit d'un fichier qui porte par convention l'extension
«.wsdl».
• Ce document comporte plusieurs parties.
135
Protocole WSDL
Organisation d'un document WSDL
Un document WSDL est organisé de la façon suivante :
• L’espace de noms principal est
http://schemas.xmlsoap.org/wsdl/ (préfixe classique wsdl)
• La racine du document est wsdl:definitions
• Les fils de la racine sont (dans l’ordre)
• wsdl:types (facultatif): définition des types des données utilisant
un système de typage (comme XSD)
• wsdl:message (nombre quelconque): définition des messages
échangeables. Décrit les noms et types d’un ensemble de champs
à transmettre
136
Protocole WSDL
Organisation d'un document WSDL
• Les fils de la racine sont (dans l’ordre)
• wsdl:portType (nombre quelconque): définition des ensembles
d’opérations. Chaque opération a zero ou un message en entrée,
zero ou plusieurs messages de sortie ou de fautes
• wsdl:operation : c'est la description d'une action exposée dans le
port.
• wsdl:binding (nombre quelconque) : définition des bindings.
Spécifie une liaison d’un <porttype> à un protocole concret
(SOAP HTTP, MIME, …). Un porttype peut avoir plusieurs liaisons
• wsdl:service (nombre quelconque) : indique les adresses de port
de chaque liaison. C’est une collection de ports
• wsdl:port: représente un point d'accès de services défini par une 137
adresse réseau et une liaison.
Protocole WSDL

138
Protocole WSDL
Organisation d'un document WSDL
Le document WSDL peut être divisé en deux parties. Une partie pour
les descriptions abstraites, tandis que la deuxième contient les
descriptions concrètes.
1. Descriptions concrètes:
• La description concrète est composée des éléments qui sont
orientés vers le client pour le service physique.
• Les trois éléments concrets XML présents dans un WSDL sont :
• <wsdl:service>
• <wsdl:port>
• <wsdl:binding>
139
Protocole WSDL
Organisation d'un document WSDL
2. Descriptions abstraites:
• La description abstraite est composée des éléments qui sont
orientés vers la description des capacités du service Web.
• Ses éléments abstraits définissent les messages SOAP de façon
totalement indépendante de la plate-forme et de la langue.
• Cela facilite la définition d'un ensemble de services pouvant être
implémentés par différents sites Web.
• Les quatre éléments abstraits XML qui peuvent être définis dans un
WSDL sont :
• <wsdl:types>
• <wsdl:message>
• <wsdl:operation>
• <wsdl:portType> 140
 Protocole WSDL
Types de données échangées (en entrée et en sortie)

Les méthodes que le

client peut invoquer

Format des messages

Protocole de
communication

Localisation du service 141

Protocole WSDL: L'élément
definitions
• L'élément racine dans un document WSDL est
<wsdl:definitions>.
• Exemple 1: Customer:

<wsdl:definitions name="customerExemple"
targetNamespace="http://www.stevepotts.com/customer.wsdl"
xmlns:soap="http://www.schemas.xmlsoap.org/wsdl/soap/"
xmlns:wsdl="http://www.schemas.xmlsoap.org/wsdl/"
xmlns: tns=http://www.stevepotts.com/customer.xsd
xmlns:="http://www.stevepotts.com/customer.wsdl" >
…….
</wsdl:definitions>

142
Protocole WSDL: L'élément
types
• Contient les définitions de types utilisant un système de
typage (comme XSD).
• WSDL n'est pas liée exclusivement à un système de typage,
mais il utilise le XML schéma de la spécification W3C
• Décrit tous les types de données utilisés entre le client et le
serveur.
• Ces types sont l'équivalent en structures C++ ou Java à des
classes qui ne contiennent que des données et pas de
méthodes.
• Inutile si on se contente de types de base
• L’attribut targetNamespace qui définit un certain nombre
d'espaces de noms namespace auquel tous les noms déclarés
dans un élément du document WSDL appartiennent, ce qui 143
permet d'éviter les conflits de nommage.
 Protocole WSDL: L'élément
types
• Exemple 1: Customer

<wsdl:types>
<xsd:schema targetNamespace ="http://www.stevepotts.com/customer.xsd"
xmlns: xsd = "http://www.w3.org/2001/XMLSchema">
<xsd:element name ="customer">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="customer ID" type="xsd:string“
></xsd:element>
<xsd:element name="lastname" type="xsd:string" ></xsd:element>
<xsd:element name="firstname" type="xsd:string" ></xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element> 144
</xsd:schema>
</wsdl:types>
 Protocole WSDL: L'élément
types
• Exemple 2: PersonType.wsdl
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="urn:PhoneBook"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd=http://www.w3.org/2001/XMLSchema
xmlns:tns="urn:PhoneBook >
<wsdl:types>
<xsd:schema targetNamespace="urn:PhoneBook">
<xsd:complexType name="Person">
<xsd:sequence>
<xsd:element name="first" type="xsd:string"/>
<xsd:element name="last" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType> 145
</xsd:schema>
</wsdl:types>
</wsdl:definitions>
Protocole WSDL: L'élément
message
• L'élément <message> comprend la section Messages.
• Chaque message possède un nom (attribut name) et est constitué
de parties
• Si on envisage les opérations comme des fonctions, alors un
élément <message> définit les paramètres pour cette fonction.
• Permet de définir les types de données utilisées lors de l’invocation
(et de la réponse) d’une opération
• Chaque élément enfant <part> de l'élément <message> correspond
à un paramètre et possède un attribut de nom et de type, tout
comme un paramètre de fonction a un nom et un type.
• Les paramètres d'entrée sont définis dans un élément <message>
unique et séparé des paramètres de sortie, qui se trouvent dans leur
propre élément <message> 146
Protocole WSDL: L'élément
message
• Exemple 1 (customer): représente les messages correspondant à
l'ajout d'un nouveau client à un service Web.
<wsdl:message name="addCustomer">
<wsdl:part name="customerInfo" element="tns:customer">
</wsdl:part>
</wsdl:message>
<wsdl:message name="confirmationResponse">
<wsdl:part name="response" element="xsd:integer">
</wsdl:part>
</wsdl:message>
• Le message addCustomer va ajouter un nouveau client (customer)
au service Web par l'envoi d'une instance de l'élément client que
nous avons défini dans l'élément <type> dans le targetnamespace
tns.
• Le nom d'un élément <message> de sortie se termine par Response. 147
Dans cet exemple, le message de réponse est
confirmationResponse, il renvoie au client un nombre entier lui
indiquant le succès de l'opération.
Protocole WSDL: L'élément
message
• Exemple 2 (Person):

<?xml version="1.0" encoding="ISO-8859-1"?>

<wsdl:definitions xmlns:tns="urn:PhoneBook"
...>
<!-- définition des types -->
<wsdl:message name="getPhoneNumberResponse">
<wsdl:part name="getPhoneNumberReturn“ type=“xsd:integer"/>
</wsdl:message>

<wsdl:message name="getPhoneNumberRequest">
<wsdl:part name="in0" type="tns:Person"/>
</wsdl:message> 148
</wsdl:definitions>
Protocole WSDL: L'élément
operation
• C’est une action particulière supportée par le service web
décrit
• L'élément <operation> est analogue à un appel de méthode
en Java
• Seulement trois messages sont autorisés dans une opération:
1. Input Message : définit les données que le service Web
s'attend à recevoir.
2. Output Message : définit les données que le service Web
prévoit d'envoyer en réponse.
3. Fault Message : définit les messages d'erreurs qui peuvent
être retournés par le service Web.
149
 Protocole WSDL: L'élément
operation
• Plusieurs types d'opération peuvent être déclarés dans un
document WSDL :
1. Request/Response : le client envoie la demande, et le
service répond.
• Dans ce cas, une telle opération va successivement recevoir
un input (la requête en provenance de l’application cliente),
émettre un output (la réponse) et éventuellement renvoyer
une erreur.

<wsdl:operation name="opération">
<wsdl:input name="nom_optionnel"message="nom_message"/ >
<wsdl:output name="nom_optionnel"message="nom_message"/ >
<wsdl:fault name="nom_optionnel"message="nom_message"/ > 150
</wsdl:operation>
 Protocole WSDL: L'élément
operation
• Plusieurs types d'opération peuvent être déclarés dans un
document WSDL :
2. Solicit/Response : le client reçoit un message du service et
répond au service
• Ce type implique que c’est le service cible qui requiert une
réponse ;il envoie un message et attend un message
• Pour ce type d’opération, le modèle d’utilisation est l’inverse
du précèdent, à savoir que l’on va tout d’abord émettre un
message puis recevoir une réponse.
<wsdl:operation name="nom opération">
<wsdl:output name="nom_optionnel"message="nom_message"/ >
<wsdl:input name="nom_optionnel"message="nom_message"/ > 151
<wsdl:fault name="nom_optionnel"message="nom_message"/ >
</wsdl:operation>
Protocole WSDL: L'élément
operation
• Plusieurs types d'opération peuvent être déclarés dans un
document WSDL :
3. One-way : un client envoie un message au service Web,
mais ne s'attend à aucune réponse
• Ce type d’opération signifie qu’aucune réponse n’est
retournée par le service cible. Cela signifie, du point de vue du
service Web, que l’opération qu’il offre n’aura ni output, ni
fault.
• Ainsi, la syntaxe générale de description d’une opération one-
way-opération sera :

<wsdl:operation name="opération_name">
<wsdl:input name="nom_optionnel" message="nom_message"/> 152
</wsdl:operation>
Protocole WSDL: L'élément
operation
• Plusieurs types d'opération peuvent être déclarés dans un
document WSDL :
4. Notification : un service Web envoie un message au client,
mais n'attend pas de réponse.
• Dans ce cas, le service envoie un message (généralement pour
notifier un événement).
• Ce type d’opération requiert uniquement l’émission d’un
message. La syntaxe suivante est alors obtenue :

<wsdl:operation name="nom opération">

<wsdl:output name="nom_optionnel“ message= "nom_message"/ >
<wsdl:operation>
153
Protocole WSDL: L'élément
portType
• La définition des opérations offertes par un service Web est
effectuée par l’intermédiaire de la section portType.
• La section portType est une énumération de descriptions
d’opérations: un port est simplement une suite d'opérations.
• L'élément <portType> contient l'ensemble des opérations que
peut effectuer un service Web
• Chaque portType est identifié par un nom (attribut name)

154
 Protocole WSDL: L'élément
portType
• Exemple 1 (cutomer):

<wsdl:portType name ="newCustomerPortType">

<wsdl:operation name="createNewCustomer">
<wsdl:input message="addCustomer"></wsdl:input>
<wsdl:output message="confirmationResponse"></wsdl:output>
</wsdl:operation>
</wsdl:portType>

• L'élément <PortType> défini dans l'exemple est identifié par

un nom unique newCustomerPortType.
• Il contient l'opération createNewCustomer de type
Request/Response qui va ajouter un nouveau client au service 155
Web en utilisant les messages d'entrée (input) et de sortie
(output) définis précédemment dans la section message.
 Protocole WSDL: L'élément
portType
• Exemple 2 (Person):

<?xml version="1.0" encoding="ISO-8859-1"?>

<wsdl:definitions ...>
<!-- définition des types et des messages -->
<wsdl:portType name="PhoneBook" xmlns:tns="urn:PhoneBook">
<wsdl:operation name="getPhoneNumber">
<wsdl:input name="getPhoneNumberRequest"
message="tns:getPhoneNumberRequest"/>
<wsdl:output name="getPhoneNumberResponse"
message="tns:getPhoneNumberResponse"/>
</wsdl:operation>
</wsdl:portType>
156
</wsdl:definitions>
Protocole WSDL: L'élément
binding
• A ce stade de cette étude WSDL, on sait précisément définir
les opérations offertes par un service Web.
• Ces descriptions sont dites abstraites et nécessitent une
liaison avec un protocole de communication afin de devenir
concrètes.
• Plus clairement, cela signifie qu’une description WSDL
comporte une section spéciale dont l’objectif est de préciser
comment les opérations vont être traitées par un protocole
de communication. Ici le protocole de communication est le
protocole SOAP.
• Cette section doit lier chaque opération décrite dans une
partie portType avec le protocole SOAP. 157
Protocole WSDL: L'élément
binding
• L'élément <binding> permet d'obtenir les informations
nécessaires pour connecter physiquement un service Web.
• Il décrit les spécifications concrètes de la manière dont le
service sera implémenté : protocole de communication et
format des données pour les opérations et messages définis
par un portType particulier.
• L'élément <binding> a deux objectifs. Tout d'abord, il sert de
lien entre les éléments abstraits et les éléments concrets dans
le WSDL.
• Ensuite, il fournit un conteneur pour des informations telles
que le protocole et l'adresse du service Web.
158
Protocole WSDL: L'élément
binding
• Elément racine wsdl:binding, précisé par
• un attribut name : le nom du binding
• un attribut type : le type de port concerné par le binding (portType)
• wsdl:binding contient un élément wsdl:operation pour chaque
opération du type de port (attribut name pour indiquer l’opération
concernée)
• Chaque élément wsdl:operation contient des éléments définissant
le binding des messages associés (à chaque fois précisé par un
attribut name) :
• wsdl:input
• wsdl:output
• wsdl:fault
• wsdl:binding contient aussi les éléments permettant de réaliser un 159
binding vers SOAP : soap:binding
Protocole WSDL: L'élément
binding
• soap:binding : cet élément indique que la liaison sera mise à
disposition via SOAP.
• L'attribut style indique le format des messages SOAP (RPC ou
document (par défaut)), la différence entre les deux est minime.
• L’attribut transport indique le protocole utilisé pour l’échange
des messages SOAP, (en général HTTP précisé par l’URL)
• soap:operation : cet élément indique la liaison d'une
opération avec un protocole SOAP.

160
Protocole WSDL: L'élément
binding
• soap:body : cet élément fournit des détails sur la façon dont
les messages d'entrée et de sortie doivent apparaître à
l'intérieur du corps de l’enveloppe SOAP ainsi que le
namespace de l'URL d'un service particulier.
Autrement, il précise le format des messages échangés par
une opération sous forme de contraintes sur le body du
format SOAP.
• L’attribut use précise l’interprétation des messages:
• si use=encoded (classique) : l’attribut encodingStyle précise la
représentation XML et chaque partie de message est typée par
un attribut type.
• si use=literal (style document) : parties de messages brutes.
161
Protocole WSDL: L'élément
binding
• Exemple 1 (customer):
<wsdl:binding name="newCustomerBinding" type="newCustomerPortType">
<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http">
</soap:binding>
<wsdl:operation name="createNewCustomer">
<soap:operation
soapAction="http://wwww.stevepotts.com/createNewCustomer">
</soap:operation>
<wsdl:input>
<soap:body use="encoded"
namespace="http://wwww.stevepotts.com/Customer"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding">
</soap:body>
</wsdl:input>
<wsdl:output>
<soap:body use="encoded"
namespace="http://wwww.stevepotts.com/createNewCustomer"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding"> 162
</soap:body>
</wsdl:output>
</wsdl:operation>
Protocole WSDL: L'élément
binding
• Exemple 1 (customer):
• La première ligne de l'élément binding contient les attributs name et type.
• L'attribut name indique le nom identifiant la liaison binding, ici le nom de la
liaison est newCustomerBinding.
• L'attribut type permet d'établir la liaison avec un portType à travers le nom
du portType.
• Dans notre cas, cette liaison fait référence au portType
newCustomerPortType défini précédemment dans la section portType.

163
Protocole WSDL: L’élément
port
• Un port spécifie une adresse URL qui correspond à
l’implémentation du service par un fournisseur
• Définit un point d’accès (càd une URL par exemple) pour un
binding
• Un port définit un point d'accès individuel, en spécifiant une
adresse unique pour une liaison binding
• L'élément port contient deux attributs : l'attribut name et
l'attribut binding.
• L'attribut name donne un nom unique parmi tous les ports définis
dans le document WSDL.
• L’attribut binding donnant le nom du binding associé
• Un élément soap:address précise l’URI du port grâce à son 164
attribut location
 Protocole WSDL: L'élément
port
• Exemple 1 (customer):

<wsdl:port binding="newCustomerBinding" name="newCustomerPort">

<soap:address
location="http://www.stevepotts.com:1776/soap/servlet/rpcrou
ter">
</wsdl:port>

• Dans cet exemple, le nom du port est newCustomerPort.

• L'attribut binding fait référence à l'élément
bindingnewCustomerBinding défini dans la section binding du
document WSDL.
• Le port contient un élément <soap:address> qui spécifie à l'aide de
l'attribut location une URL représentant l'adresse du port.
• Dans notre exemple, l'adresse du port est : « 165
[..]www.stevepotts.com:1776/soap/servlet/rpcrouter ».
Protocole WSDL: L’élément
service
• Contient une collection de ports.
• L'élément <service> définit les ports soutenus par le service
Web.
• Il contient aussi un élément <documentation> qui fournit la
documentation lisible par l'homme.
• Pour chaque liaison supportée, un élément port est désigné
• Un élément wsdl:service portant un nom (attribut name)
contenant des éléments wsdl:port

166
 Protocole WSDL: L'élément
service
• Exemple 1 (customer):
<wsdl:service name="newCustomerService">
<documentation>Ajouter un nouveau client</documentation>
<wsdl:port binding="newCustomerBinding“ name="newCustomerPort">
<soap:address
location="http://www.stevepotts.com:1776/soap/servlet/rpcrouter">
</wsdl:port>
</wsdl:service>
• L'attribut name<wsdl:service name=[..]> donne un nom unique
parmi tous les services définis dans un document WSDL.
• Dans cet exemple, cet attribut a pour valeur newCustomerService.
• L'élément service contient le port newCustomerPort qui est associé
avec la liaison binding newCustomerBinding.
167
• NewCustomerService utilise donc le protocole SOAP, et est
accessible via l'adresse définie dans l'élément port.
 Protocole WSDL: L'élément
service
• Exemple 2 (Person):

<?xml version="1.0" encoding="ISO-8859-1"?>

<wsdl:definitions ...>
<!-- types, messages, types de port et binding -->
<wsdl:service name="PhoneBookService"
xmlns:tns="urn:PhoneBook">
<wsdl:port binding="tns:PhoneBookWSSoapBinding"
name="PhoneBookWS">
<soap:address
location="http://localhost:8080/axis/services/PhoneBookWS"/>
</wsdl:port>
</wsdl:service>
168
</wsdl:definitions>
Exemple Complet
L’élément Définition

<?xml version="1.0"?>
<definitions name="cotation"
targetNamespace="http://exemple.com/cotation.wsdl"
xmlns:tns="http://exemple.com/cotation.wsdl"
xmlns:xsd1="http://exemple.com/cotation.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">

169
Exemple Complet
L’élément Types
<types>
<schema targetNamespace="http://example.com/cotation.xsd"
xmlns="http://www.w3.org/2000/10/XMLSchema">
<element name="demandeCotationAction">
<complexType>
<sequence>
<element name="action" type="string"/>
</sequence>
</complexType>
</element>
<element name="cotationAction">
<complexType>
<sequence>
<element name="cotation" type="float"/>
</sequence>
</complexType>
</element>
</schema> 170
</types>
Exemple Complet
Interprétation de l’élément Types
• Dans cet exemple, on commence par spécifier les types utilisés grâce à
un schéma W3C.
• Ce schéma définit les éléments demandeCotationAction et
cotationAction dans l’espace de nom http://example.com/cotation.xsd
(qu’on a nommé xsd1 dans la partie définitions)
• En effet, toutes les références à ces éléments (demandeCotationAction
et cotationAction) devront être qualifiées (pour lever toute ambiguïté
dans le cas de déclarations multiples) d’où la déclaration d’un préfixe
xsd1
• Les types string et float (sans préfixe) se réfèrent au namespace par
défaut est «http://www.w3.org/2000/10/XMLSchema» qui représente
la recommandation W3C du XML Schéma
• Ils existent deux types dans cette partie:
1. demandeCotationAction qui contient un élément fils action de type
chaine de caractères
2. cotationAction qui contient un élément fils cotation de type réel 171
Exemple Complet
L’élément message
<message name="demandeCotation">
<part name="body" element="xsd1:demandeCotationAction"/>
</message>
<message name="resultatCotation">
<part name="body" element="xsd1:CotationAction"/>
</message>
Interprétation de l’élément message
• Nous avons deux messages, demandeCotation et resultatCotation,
reliés aux éléments précédents.
• Chaque élément <part> correspond à un paramètre et possède un
attribut de nom et de type
• Le message demandeCotation possède un paramètre qui s’appelle body
de type demandeCotationAction (définit dans la partie types)
• Le message resultatCotation possède un paramètre qui s’appelle body
de type CotationAction (définit dans la partie types) 172
Exemple Complet
L’élément portType
<portType name="actionPortType">
<operation name="cotation">
<input message="tns:demandeCotation"/>
<output message="tns:resultatCotation"/>
</operation>
</portType>
Interprétation de l’élément portType
• Opération de type Request/Response. Le message requête suit le
modèle demandeCotation défini dans la partie message et le
message réponse suit le modèle resultatCotation défini dans la
partie message.
• Comme nous avons un attribut targetNamespace à la racine, les
définitions globales passent dans l’espace de nom associé et le type
de port actionPortType doit donc faire des références aux messages
précédents par un préfixe tns. 173
Exemple Complet
L’élément binding
<binding name="cotationBinding" type="tns:actionPortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="cotation">
<soap:operation
soapAction="http://exemple.com/demandeCotation"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding> 174
Exemple Complet
Interprétation de l’élément binding
• Le même raisonnement pour la liaison (binding), qui avec
l’attribut type fait référence au type de port actionPortType
(tns).
• L’attribut transport indique par quel moyen les données
circulent (HTTP) alors que l’attribut style indique comment les
messages sont exploités: sous la forme de document.
• Pour l’opération cotation du portType actionPortType, on
indique sa liaison avec le protocole SOAP

175
Exemple Complet
L’élément service
<service name="actionService">
<documentation>Cotation d’une action</documentation>
<port name="actionPort" binding="tns:cotationBinding">
<soap:address location="http://exemple.com/action"/>
</port>
</service>
</definitions>
Interprétation de l’élément service
• Il reste enfin à définir le service avec une adresse d’accès via SOAP
http:// exemple.com/action en se référant à la liaison définie dans la
partie binding (cotationBinding) 176
 6

UDDI

177
UDDI
• UDDI (Universal Description, Discovery and Integration,
http://uddi.xml.org/ ) est une sorte de registre XML pour publier et
utiliser des services web sur Internet. L’idée est que, puisque
beaucoup de services sont utiles sur Internet, comme un service de
vérification des numéros de carte de crédit, des sociétés pourraient
proposer leur service à d’autres sociétés clientes.
• L'annuaire des services UDDI est un standard pour la publication et
la découverte des informations sur les services Web.
• La spécification UDDI est une initiative lancée par ARIBA, Microsoft
et IBM.
• Cette spécification n'est pas gérée par le W3C mais par le groupe
OASIS.
• La spécification UDDI vise à créer une plate-forme indépendante, un
espace de travail (framework) ouvert pour la description, la
découverte et l'intégration des services des entreprises. 178
UDDI
• L'annuaire UDDI se concentre sur le processus de découverte
de l'architecture orientée services (SOA), et utilise des
technologies standards telles que XML, SOAP et WSDL qui
permettent de simplifier la collaboration entre partenaires
dans le cadre des échanges commerciaux.
• L'accès au référentiel s'effectue de différentes manières.
• Les pages blanches comprennent la liste des entreprises qui ont
publié des services ainsi que des informations associées à ces
dernières (coordonnées, description de l'entreprise,
identifiants...).
• Les pages jaunes il s’agit d’une répartition des services en
catégories.
• Les pages vertes fournissent des informations techniques précises 179
sur les services fournis.
UDDI
• Les entreprises publient les descriptions de leurs services Web
en UDDI, sous la forme de fichiers WSDL.
• Ainsi, les clients peuvent plus facilement rechercher les
services Web dont ils ont besoin en interrogeant le registre
UDDI.
• Les clients UDDI interrogent les serveurs (les sites opérateurs)
UDDI en envoyant des requêtes formatées en SOAP
• Lorsqu'un client trouve une description de service Web qui lui
convient, il télécharge son fichier WSDL depuis le registre
UDDI
• Ensuite, à partir des informations inscrites dans le fichier
WSDL, notamment la référence vers le service Web, le client
peut invoquer le service Web et lui demande d'exécuter
180
certaines de ses fonctionnalités.
UDDI

181