III : Services Web

 1. XML-RPC
 2. SOAP
 3. WSDL
 4. Standards WS-*

1
Qu'est quoi un services Web?
Pourquoi les services Web?
 Les services Web permettent d’interconnecter :
✓ Différentes entreprises
✓ Différents matériels
✓ Différentes applications
✓ Différents clients
o Pas uniquement des navigateurs
✓ réutilisation dans un environnement ouvert (runtime)
✓ Distribuer et intégrer des logiques métiers
✓ Vers le Web sémantique
o Pas uniquement le Web purement interactif
✓ Les services Web sont faiblement couplés
Caractéristiques:

 Réutilisable
 Indépendamment de
✓ la plate-forme (UNIX, Windows, …)
✓ l’implémentation (VB, C#, Java, …)
✓ l’architecture sous-jacente (.NET, J2EE, Axis…)
Le langage de description
d'interface WSDL
WSDL
➢ C'est un langage de définition des interfaces des
services (le contrat)
o Donc d'une grande importance
➢ Il représente la définition d'un services Web vue par le
fournisseur
➢ Il doit contenir toutes les information nécessaire au
client pour consommer le service (auto-suffisant)
➢ n'exprime pas des objet distant mais un service
Un services selon WSDL****
 La description WSDL d'un service web comprend
une définition du service, les types de données
utilisés notamment dans le cas de types
complexes, les opérations utilisables, le protocole
utilisé pour le transport et l'adresse d'appel.
 C'est un document XML qui décrit un service web
de manière indépendante de tout langage. Il
permet l'appel de ses opérations et l'exploitation
des réponses (les paramètres, le format des
messages, le protocole utilisé, ...).
Un exemple pour comprendre
Un services de compagnie aérienne:
◆ Qui permet de
● rajouter des vols
● Consulter des vols
◆ on a besoin de ce que c'est
● Vol
● Date
● Intervalle de dates (départ et retour)
● Liste de vols
Système de typage
WSDL manipule des données typées
◆ Pour cela on a choisi le système de typage
international comme (IDL sans les interface)
◆ Il utilise XSD de XML
◆ Toutefois des différences majeur avec IDL :
● Le sujet de distribution (l'objet) est lui même un type
dans IDL
● Couplage faible ou lâche
Les messages:
Décrit les noms et types d’un ensemble de champs à
transmettre
◆ Paramètres d’une invocation, valeur du retour,
message d'erreur
● Exemple
Exemple
WSDL : Les opérations
II)SOAP
Pourquoi un nouveau protocole
le besoin
◆ Le Web a besoin d’un nouveau protocole
● Multi-langages, multi-plateformes
● Respectant les formats d’échanges du Web
◆ Réponses et requêtes en XML
● Facile à implémenter sur différents protocoles de
transport
◆ RPC, HTTP ,…
● Permettant de franchir les « firewalls »
SOAP(1/9)
 Le protocole SOAP (Simple Object Access Protocol) est
devenu le standard pour décrire les messages en XML entre
services web.

 Ce dernier peut être utilisé sur différents protocoles de

transports. Les deux principaux protocoles utilisés étant
HTTP et SMTP.

 De par sa nature, SOAP permet l’inter-opérabilité entre

différents systèmes d’exploitation et différentes plate-
formes (J2EE, .NET, …).
 SOAP permet de créer des applications de type distribuées,
en suivant le modèle RPC (Remote Procedure Call).
SOAP(2/9)
 La grande majorité des services web utilise le protocole
SOAP. Un message SOAP est un document XML
composé d’une enveloppe qui contient une entête et le
corps du message.
SOAP(3/9)

 Prenons l’exemple d’un message SOAP appelant une méthode

echoString(string), qui prend en paramètre une chaîne de caractères.
SOAP(4/9)
SOAP(5/9)

 Lorsque le serveur répond à la méthode

echoString(string), il ajoute Response à la suite du tag
(d’une manière générale, il rajoute Response à la suite
du tag contenant le nom de la requête.
SOAP(6/9)
SOAP(7/9)
 Une des forces de SOAP est de permettre
l’interopérabilité entre différentes plate-forme. Il est
donc important d’avoir des règles de codage des types
de données, afin que ces dernières puissent être
encodées/décodées sans difficultés. On distingue deux
types de données :
• Les données de types simples (une chaîne de caractère
par exemple) ;
• Les types composés : structures ou tableaux.
SOAP(8/9)
 Les messages précédents présentaient SOAP sans
l’utilisation des espaces de noms, obligatoires d’après
les spécifications du protocole.
• xsi correspond au namespace des types de données
connus ;
• xsd correspond au namespace du schema du
document ;
• soapenv correspond au namespace de l’enveloppe
(utilisé pour la gestion de la version SOAP).
SOAP(9/9)
La couche de transport(1/2)
 Comme nous l’avons vu précédemment, la définition
ne définit pas une couche de transport particulière. Le
protocole SOAP quant à lui n’est pas dépendant d’un
transport particulier (dans sa version 1.0 il ne pouvait
circuler que sur HTTP ; cela a été corrigé dans la
version 1.1).
 Actuellement, deux couches de transport sont
fréquemment utilisées
• HTTP, lors d’appels synchrones ;
• SMTP, lors d’appels asynchrones.
La couche de transport(2/2)
 Les spécifications de SOAP ne précisant pas de protocole
particulier, on peut très bien imaginer invoquer des
services web grâce au protocole FTP par exemple… Le
protocole HTTP (HyperText Transfert Protocol) est l’un des
protocoles les plus utilisés sur Internet.
 La plupart des clients web (IE, …) l’utilisent pour
communiquer avec un serveur.
 Ce protocole définit le format des requêtes qu’un client
peut envoyer ainsi que les résultats qu’il peut attendre.
Chaque requête contient une URL qui contient l’identifiant
d’un objet demandé par le client (ex.: pages HTML, images,
…).
HTTP
◆ HTTP (HyperText Transfer Protocol) est devenu de facto le
protocole de communication de l’Internet
◆ HTTP est disponible sur toutes les plates-formes – très
rapidement
◆ HTTP est un protocole simple, qui ne requière que peu de
support pour fonctionner correctement
◆ HTTP est un protocole sans connexion
● Peu de paquets sont nécessaires pour échanger des
informations
◆ HTTP offre un niveau de sécurité simple et effectif
◆ HTTP est le seul protocole utilisable à travers des pare-feu
Simple Object Acess Protocol
◆ Contrairement à son nom rien d'objet dans SOAP
◆ C'est un protocole abstrait : spécification XML qui
définie un message comme un document XML
◆ Il n'impose ni un modèle d'échange (eg RPC) ni un
mécanisme de transport :
● peut être transporter par HTTP
◆ Simple car c'est un document XML en cours de
transite son interprétation est laisser au couche
applicatif
Structure d'un message
Un Message SOAP
◆ Un message SOAP
◆ un document XML
◆ Un mécanisme de Transport
◆ Un ensemble de convention pour formater &
interpréter :
● Les entêtes spécifique à l'application
● Les contenue du message
Pourquoi HTTP
◆ HTTP (HyperText Transfer Protocol) est devenu de facto le
protocole de communication de l’Internet
◆ HTTP est disponible sur toutes les plates-formes – très
rapidement
◆ HTTP est un protocole simple, qui ne requière que peu de
support pour fonctionner correctement
◆ HTTP est un protocole sans connexion
● Peu de paquets sont nécessaires pour échanger des
informations
◆ HTTP offre un niveau de sécurité simple et effectif
◆ HTTP est le seul protocole utilisable à travers des pare-feu
SMTP******
 SMTP (Simple Mail Transfer Protocol) est le principal
protocole utilisé sur Internet pour faire transiter les
emails entre deux hôtes (une passerelle peut
également être utilisée).

 SMTP utilise TCP comme couche de transport et le

port 25 par défaut.
RPC(1/6)
 Un RPC (Remote Procedure Call), est un mécanisme permettant
l’appel local d’une méthode distante : un client possède une
copie (un stub) d’un objet distant sur lequel il appelle des
méthodes.
 Côté serveur, le skeleton est un objet s’interfaçant avec le vrai
objet appelé.
• Un stub est un proxy coté client.
Différents langages de RPC existent, dont
• Corba
• DCOM
• RMI
• SunRPC
• DCE (Distributed Computing Environment)
RPC(2/6)
 Un système distribué permet de répartir des sous-
ensembles d’une architecture dans différents serveurs.
 L’avantage d’un RPC est qu’il n’y a pas de différence
entre un appel local et un appel distant.

 Il n’y a donc plus à se soucier de la couche réseau, qui

est gérée par le RPC.
RPC(3/6)
RPC(4/6)
 On constate des différences entre SOAP et les autres
protocoles :
• SOAP est le seul protocole qui ne fait pas circuler de
données binaires.
• En plus d’être lisible, cela permet le débugage ;
• SOAP peut circuler sur HTTP, ce qui lui permet de
passer les firewalls dans leurs configurations
standards.
• C’est là un de ses grands avantages.
RPC avec SOAP(5/6)
 A ses débuts, SOAP était destiné à être un protocole
fournissant un mécanisme de RPC, inter-opérable, car
utilisant XML & HTTP (il est maintenant –entre autre–
un protocole de communication entre services web par
échanges de messages XML).
 Lors d’un appel RPC, un message SOAP doit contenir :
• l’adresse du destinataire du message ;
• le nom de la méthode à exécuter ;
• les paramètres à passer à la méthode.
RPC(6/6)
 En devenant un RPC, les services web en SOAP
peuvent être vus comme un point d’entrée dans les
applications « lourdes » : par exemple, un service web
peut permettre une connexion entre un client sur
Internet et une application à base d’EJB.

 De nombreuses API (Application Programmer

Interface) permettent de créer des stubs de méthodes
exposées dans des services web.
WSDL(1/6)
 WSDL (Web Service Description Langage), est un
langage de description de services web en XML.
Il 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.
WSDL(2/6)
 A noter(1) : WSDL pourrait décrire n’importe quel
protocole de messagerie basé sur XML

 A noter (2) : les documents WSDL ne sont jamais

générés par des développeurs, mais le sont grâce à des
outils qui automatisent la tâche (par exemple, il existe
des outils qui prennent une classe Java et qui créent le
WSDL correspondant)
WSDL(3/6)
WSDL(4/6)
• Sur le slide précédent, quelques éléments n’ont pas été
présentés.
Reprenons l’élément : il définit un point de terminaison
(adresse internet plus liaison).
• Il est à noter que l’élément peut contenir plusieurs
opérations.
• A l’exemple précédent manque l’élément qui permet de
définir des types complexes (dans l’exemple ci-dessous, la
valeur renvoyée est une chaîne de caractères).
Remarque : dans la définition des messages, nous n’avons
aucune information sur le protocole de transport. Cela
reste dans la logique des web services.
WSDL(5/6)
WSDL(6/6)
WSDL : résumé des éléments d’un document
• Operation : une action particulière supportée par le
service web décrit.
En faisant l’analogie avec Java, on peut comparer une
Operation à une (méthode d’une) Interface ;
• Message : définition des types de données utilisées lors de
l’invocation (et de la réponse) d’une opération ;
• PortType : un ensemble (1..n) d’opérations ;
• Binding : lien entre un PortType et un protocole d’accès ;
• Port : définit un point d’accès (cad une URL par exemple)
pour un binding ;
• Service : contient une collection de ports.
UDDI
L’API UDDI propose deux fonctionnalités principales :
• la recherche de services (envoi de requêtes).
• la publication de services dans un annuaire UDDI ;
Les clients UDDI interrogent les serveurs (les sites
opérateurs) UDDI en envoyant des requêtes formatées en
SOAP (sur HTTP avec la méthode POST).

Les étapes sont :

1. Publication d’un service web par une société ;
2. Recherche d’un service web ;
3. Découverte d’un service web ;
4. Consommation d’un service web
LES Standards WS-*
 les services web WS-* exposent Les mêmes
fonctionnalités de service web sous la forme de
services exécutables à distance.

 Leurs spécifications reposent sur les

standards SOAP et WSDL pour transformer les
problématiques d'intégration héritées du
monde middleware en objectif d'interopérabilité.
 Nous allons présenter dans cette première partie un
aperçu de la norme WS-Security pour les services
SOAP et les différentes possibilités pour sécuriser des
services web.

 Les architectures SOA se sont généralisées petit à petit

au sein des entreprises pour construire des systèmes
capables d’offrir des fonctionnalités partagées via des
services.
 Ces services peuvent être internes et ne concerner
qu’une organisation ou être ouverts sur l’extérieur dans
le cadre d’échanges B2B.
 Dès lors que l’on propose de la valeur ajoutée ou
transporte des données dites sensibles, ces services
sont alors confrontés à des buts contradictoires :
 Exposer de l’information et la rendre facilement
accessible à un tiers (personne ou système)
 Sécuriser l’information pour la rendre uniquement
consommable par des personnes ou des systèmes
habilités à la voir et à l’utiliser.
 Au-delà du tout sécuritaire, une approche
pragmatique de la sécurité pilotée par les risques est
préférable. Rappelons les fonctions de sécurité
disponibles qui pourront s’appliquer à des services:
 Authentification : le mécanisme qui permet de
vérifier l’identité d’une personne/d’un système
 Habilitation : le droit d’accéder ou non à une
fonctionnalité, à une donnée
 Intégrité (ou signature) : la non modification d’une
donnée échangée
 Imputabilité : traçabilité des actions d’un individu
sur un système
 Confidentialité (ou chiffrement) : la non lisibilité de
la donnée par un tiers ne partageant pas un secret
Authentification
Voici un exemple de header avec un token
user name non chiffré :
Chiffrement
Voici un exemple de chiffrement du corps du
message avec un certificat X509 :
Signature
Voici un exemple de header WS-Security
avec une signature du corps du message à
base de certificat X509 :
En résumé ...
◆ Les services Web sont bâtis au-dessus de standards
 • de description (XML)
 • de transport applicatif (SOAP)
◆ Un service Web (WSDL) est une collection
 • de spécification d’opérations
 • de moyens de les invoquer
◆ Un service Web est référencé dans un annuaire (UDDI)
 • incluant des aspects opérationnels
 • et des aspects sémantiques