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)11
**fevrier
⚫ 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 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
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)18frevrier
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