Middleware Services Web, mode de fonctionnement et utilisation.

1. 23:53 185
VI. Les services web

2. Définition
 Un service Web permet à des applications et des
systèmes divers de communiquer et d’échanger
des données dans des environnements partagés
 Cette technologie permet donc à des
applications distantes de communiquer à travers
un réseau (Internet) sans tenir compte des
différences de langages de programmation et de
plates-formes
23:53 186

3. Définition
 Via un service Web, une application « A » codée
en « Java » peut communiquer avec une
application « B » codée en « C# » ou en C++
 Les requêtes et les réponses s’effectuent à l’aide
de formats ouverts tels que :
 XML, JSON, TEXT, …
 Un service Web repose le plus souvent sur le
protocole HTTP, mais celui-ci peut également
utiliser d’autres protocoles (comme par exemple
le FTP ou le SMTP)
23:53 187

4. Définition
 Pour simplifier, un service Web fournit des
interfaces qui répondent généralement à des
demandes HTTP afin de fournir des données
venant de différentes sources (base de données
ou fichiers).
23:53 188

5. Définition
 Un service Web permet à une entreprise de
communiquer avec d’autres entreprises « B2B »
et avec leurs clients « B2C » sans prendre
connaissance des systèmes d’informations se
trouvant derrière le pare-feu
23:53 189

6. Pourquoi le service web
 Il y a de milliards des utilisateurs Internet
connectés
 Les ventes des objets en lignes se multiplient
 Les objets du quotidien deviennent de plus en
plus connectés
 Le « Big Data » n’arrête pas de s’enrichir et les
demandes de services n’arrêtent pas
d’augmenter
 le « Big Data » ou volumes massifs de données est
le terme apparu suite à l’explosion des données
hébergées sur les serveurs ces dernières années
23:53 190

7. Pourquoi le service web
 Les données proviennent de nombreuses
sources :
 des capteurs GPS des véhicules, des réseaux
sociaux, des vidéos publiées en lignes ou encore des
objets connectés
 La plus grande partie des données numériques
mondiales ont été créées au cours de ces
dernières années
 De plus, l’utilisateur devient de plus en plus
exigeant et les entreprises doivent répondre à
ses demandes pour le satisfaire
23:53 191

8. Pourquoi le service web
 Un supermarché par exemple ne peut plus se
contenter d’une grande surface de vente vers
laquelle les clients se déplacent ;
 Un supermarché doit avoir un site Internet
 doit proposer un service de commande en ligne «
B2C »,
 doit échanger des informations avec d’autres
entreprises « B2B »
 Les services proposés fonctionnent dans des
environnements hétérogènes (l’utilisateur peut
disposer (tablette, smartphone, laptop, ou PC).
23:53 192

9. Pourquoi le service web
 Le service Web est une solution a toutes ces
exigences :
 Il intègre une architecture adaptative et est basé
sur un système de communication ouvert
(interopérabilité, information accessible et
interprétable par d’autres systèmes informatiques)
 De plus, le problème de ressources est également
résolu étant donné que le client ne fait aucun
traitement complexe, il se contente de lire et
afficher les informations transmises. Les traitements
sont décentralisés sur le serveur qui gère le service
23:53 193

10. Pourquoi le service web
 Les anciennes architectures distribuées telles
que CORBA, DCOM et RMI ont adopté un style
pour distribuer de l’information entre clients,
fournisseurs et partenaires
 Ces technologies n’ont pas connu un énorme
succès en raison de la diversité des plates-
formes utilisées par les clients
 De plus, elles ne sont pas adaptées à Internet, car
elles ont du mal à traverser les pare-feux
 L’inconvénient majeur est qu’ils ont une architecture
fortement couplée (une modification côté serveur,
entraine une modification côté client)
23:53 194

11. Pourquoi le service web
 A contrario, un service Web permet d’avoir des
applications faiblement couplées ce qui favorise
son utilisation et sa maintenance
23:53 195

12.  Les opérations ou actions associées au modèle
de services Web comprennent:
 Publier : Une fois développé le service Web est
considéré comme publié. La publication comprend
l'inscription dans le référentiel de services approprié.
 Rechercher : Une application agissant en tant que
consommateur de services devra trouver le
fournisseur de services approprié à l'aide d'un
référentiel de services.
Opérations ou actions
associées

13.  Les opérations ou actions associées au modèle
de services Web comprennent:
 Lier : Une fois le service identifié, le consommateur
de service le liera, ce qui implique de localiser son
emplacement spécifique sur le réseau, de contacter
le fournisseur de services et d'appeler son service.
 Demande de service / Réponse : Pour appeler un
service Web, le consommateur de service émettra
une demande de service. Une fois terminé, le
fournisseur de services fournira une réponse de
service.
Opérations ou actions
associées

14. WorkFlows Pour WS

15.  Le flux de communications du modèle des
Services Web :
1. L'étape 1: Un utilisateur fait une demande. Par
exemple, supposons qu'un utilisateur a accédé à
une page Web avec un panneau qui affiche la
météo locale. Le serveur qui héberge la page Web
n'a pas ces informations météorologiques
stockées localement; au lieu de cela, pour
l'afficher, il dépend d'un service publié externe. Ce
serveur Web, qui héberge la page Web locale,
dans ce contexte, devient un consommateur de
services.
WorkFlows Pour WS

16.  Le flux de communications du modèle des
Services Web :
2. L'étape 2: ce consommateur de service émet une
demande de service vers un autre serveur Web
qui héberge une base de données, ou un
référentiel de services, des conditions
météorologiques actuelles et des prévisions.
3. L'étape3 : la demande de service Web est
conditionnée en tant que document XML et
envoyée sur Internet à l'aide de la messagerie
SOAP via le protocole de transport HTTP (find).
L'ordinateur distant assume désormais le rôle de
fournisseur de services.
WorkFlows Pour WS

17.  Le flux de communications du modèle des
Services Web :
3. L'étape 4: ce fournisseur de services accepte la
demande de service Web de l'utilisateur.
4. L’étape 5: le service interroge sa base de données
et la conditionne au format XML (liaison) en tant
que réponse de service.
5. L'étape 6: l'application d'origine reçoit la réponse
et présente ses informations à l'utilisateur.
WorkFlows Pour WS

18.  Les services Web fonctionnant ensemble de
sont soumis a des accords et des contrats
entre des individus ou des organisations.
 Les accords doivent être déterminés à l'avance
(par exemple a quel prix les services Web sont
consommés.
 Certains services Web peuvent être gratuits et
accessibles au public pour tout demandeur,
mais l'authentification et la sécurité des
utilisateurs peuvent devoir être ajoutées aux
services.
WorkFlows Pour WS

19.  Les composants qui composent les services Web
sont des normes développées par l'organisme
qui régit le Web le Consortium (W3C) –
 Un fournisseur de services : Le service peut impliquer
l'exécution d'une tâche de calcul ou le renvoi d'une
information demandée à partir d'un référentiel.
 Un consommateur de services est une
application logicielle qui lance une demande
 Un référentiel de services fournit des
descriptions des services disponibles dans un
domaine donné. Permet aux prestataires de
services d'enregistrer les services.
23:53 203
WorkFlows Pour WS

20. Fonctionnement
 Fonctionnement et démarche côté client
1. Prendre connaissance des interfaces que le
service Web propose ;
2. Construire la requête ;
3. Envoyer la requête (HTTP le plus souvent) ;
4. Récupérer et interpréter les données
retournées (JSON, XML ou TEXT) ;
5. Traiter les données (calculer, afficher).
23:53 204

21. Fonctionnement
 Fonctionnement et démarche côté serveur
1. Définir les interfaces publiques ;
2. Récupérer les requêtes du client ;
3. Traduire la requête et effectuer le traitement ;
4. Envoyer la réponse normalisée dans un format
standard (JSON, XML ou TEXT).
23:53 205

22. Technologies utilisées
 Il existe plusieurs modèles de mise en œuvre
pour les services Web, mais les deux plus
dominants sont SOAP et REST.
 Tous deux s’appuyant sur le protocole HTTP
23:53 206

23. Technologies utilisées
23:53 207

24. Le protocole HTTP
 Permet au client de récupérer des documents
statiques du serveur (HTML, PDF, Images, …)
ou dynamique (contenu généré dynamiquement
au moment de la requête (PHP, JSP, ASP, …)
 Son fonctionnement très simple (en HTTP/1.0)
1. Le client se connecte au serveur (Créer un socket)
2. Le client demande au serveur un document:
Requête HTTP
3. Le serveur renvoi au client le document
(status=200) ou d’une erreur (status=404) quand le
document n’existe pas
4. Deconnexion
23:53 208

25. La connexion
23:53 209
Serveur HTTP
Client HTTP
doc.html
:Socket
IPS=
Port=80
:Socket
Port=80
accept()
doc.html
:Socket
IPC=
Port=80
Connexion
GET /doc.html
POST /script.php
Réponse HTTP
Status=200
Déconnexion

26. La connexion
 Méthodes du protocole HTTP : Une requête
HTTP est utilisée en utilisant les méthodes
suivantes :
 GET : Pour récupérer le contenu d’un document
 POST : Pour soumettre des formulaires (envoyer
dans la requête des données saisie par l’utilisateur)
 PUT : Pour envoyer un fichier
 DELETE : demander au serveur de supprimer un
document
 HEAD : récupérer les informations sur un document
(type, capacité, date de dernière modification, …)
23:53 210

27. Le client envoie la requête : Méthode POST
23:53 211
POST/Nom_Script HTTP/1.0
Accept: text/html
Accept-Language: fr
User-Agent: Mozzila/4.0
Login=Value1& pass=Value2
& Var3=Value3
*****saut de ligne *****
Entête de la requête
Corps de la requête

28. Le serveur retourne la réponse
23:53 212
HTTP/1.0 200 OK
Date : Wed, 05Feb02 15:02:01 GMT
Server : Apache/1.3.24
Last-Modified: Wed02Octb01 24:05:01GMT
Content-Type: text/html
Content-legnth : 4205
<HTML><HEAD>
…..
</BODY></HTML>
*****saut de ligne *****
Entête de la requête
Corps de la requête
Ligne de Status
Date du serveur
Nom du serveur
Dernière modification
Type de contenu
Sa taille
Le fichier que le
client va afficher

29. Le client envoie la requête : Méthode GET
23:53 213
GET/Nom_Script?login=val1&pass=vla2&… HTTP/1.0
Accept: text/html
Accept-Language: fr
User-Agent: Mozzila/4.0
*****saut de ligne *****
Entête de la requête
Corps de la requête est vide

30. Mise en œuvre Web Services
23:53 214
<?xml version=1.0 encoding=UTF-8>
<Envelope>
<Header/>
<Body>
<conversion>
<montant>12 </montant>
</conversion>
</Body>
</Envelope>
<?xml version=1.0 encoding=UTF-8>
<Envelope>
<Body>
<conversionResponse>
<return>132 </return>
</conversionResponse>
</Body>
</Envelope>
Serveur HTTP
BanqueService
HTTP
+conversion(double mt):double
+Compte getCompte()
+List<Compte> getCompte()
HTTP
jaxWS
jaxB
-code : int
-solde : double
Compte
Requête HTTP
Réponse HTTP
Client
PHP
.NET
java
cobol

31. Concepts des web services
 Le web services s’articulent autour des trois
concepts :
 SOAP : Simple Object Access Protocol
 WSDL : Web Service Description Language
 UDDI : Universal Description, Discovery and
Integration
23:53 215

32. Concepts des web services
23:53 216

33. Concepts des web services
23:53 217
1. Le client envoie une requête à l’annuaire
de Service pour trouver le service Web dont il
a besoin
2. L’annuaire cherche pour le client, trouve le
service Web approprié et renvoie une réponse
au client en lui indiquant quel serveur détient
ce qu’il recherche
3. Le client envoie une deuxième requête au
serveur pour obtenir le contrat de
normalisation de ses données

34. Concepts des web services
23:53 218
4. Le serveur envoie sa réponse sous la forme
établie par WSDL en langage XML.
5. Le client peut maintenant rédiger sa requête
pour traiter les données dont il a besoin.
6. Le serveur fait les calculs nécessaires suite à
la requête du client, et renvoie sa réponse
sous la même forme normalisée.

35.  Un protocole d'échange inter-applications
indépendant de toute plate-forme basé sur le
langage XML
 Un appel de service SOAP est un flux ASCII
encadré dans les balises XML et transporté dans
le protocole HTTP
 Il utilise principalement HTTP / HTTPS comme
protocole de communication sous-jacent
 SOAP a été conçu pour traiter le transport et la
messagerie pour les grands environnements
distribués
23:53 219
SOAP : Simple Object Access Protocol

36. SOAP : Simple Object Access Protocol
 Le protocole SOAP permet d’appeler une
méthode RPC et d’envoyer des messages aux
machines distantes via le protocole ce HTTP
23:53 220

37. SOAP : Simple Object Access Protocol
 SOAP permet aux systèmes objets distribués de
solliciter et d’obtenir des services rendus par
d’autres objets. il est moins lourd à mettre en
œuvre que d’autres protocoles
 Par rapport à tous les protocoles de RPC, SOAP
est inter opérable, ainsi il est indépendant des
plates-formes et langages de programmation
 L’autre avantage réside dans le déploiement des
applications. Sur Internet, il est désagréable
d’utiliser autre chose que HTTP à cause des
Firewalls, qui doivent êtres reconfigurés
23:53 221

38. SOAP : Simple Object Access Protocol
 Il définit comment organiser les informations à
l'aide de XML afin qu'elles puissent être
échangées entre machines.
 Cependant, SOAP n'a pas connaissance de la
sémantique des messages transmis.
 Du point de vue de la communication, SOAP est
un protocole de communication sans état et
unidirectionnel.
 La communication entre deux parties doit être
encodée en SOAP et tout schéma de communication
complexe entre les parties impliqué doit être mis en
œuvre par le système sous-jacent.
23:53 222

39. Message SOAP
 Le message SOAP est un document XML
contenant les composants ci-dessous:
 Un élément Envelope : Identifie le document XML en
tant que message SOAP. C’est la partie contenant le
message SOAP et est utilisé pour encapsuler tous
les détails dans le message SOAP. Il s'agit de
l'élément racine du message SOAP.
 Un élément d'en-tête : Peut contenir des
informations d'authentification qui peuvent être
utilisées par l'application appelante. Par défaut, le
message SOAP peut contenir des paramètres qui
peuvent être des simples chaînes et des nombres,
mais aussi un type d'objet complexe
23:53 223

40. Message SOAP
 L'élément Body contient les informations d'appel
et de réponse, en d'autres termes, les données
XML comprenant le message envoyé ou reçu
 En outre, un message SOAP généré du côté du
service, peut contenir un élément fault en cas
d'échec
23:53 224

41. Message SOAP
23:53 225

42. Structure document SOAP
23:53 226

43. Requête SOAP avec POST
23:53 227
POST/Nom_Script HTTP/1.0
Accept: application/html
Accept-Language: fr
*****saut de ligne *****
Entête de la requête
Corps de la requête SOAP
<SOAP-ENV:Envelope xmlns SOAP-ENV=“http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header>
<SOAP-ENV:Body>
<conversion xmlns=“http://bk/test">
<montant xmlns=““> 12 <montant>
</conversion>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

44. Réponse SOAP
23:53 228
*****saut de ligne *****
Entête de la requête
Corps de la réponse
<?xml version=“1.0“?>
<SOAP-ENV:Envelope xmlns SOAP-ENV=“http://schemas.xmlsoap.org/soap/envelope”/
xmlns xsd=“http://www.w3org/2001/XMLSchema” xmlns:ns1=“http://bk/test “>
<SOAP-ENV:Body>
<ns1:conversionReponse>
<return>132.0<return>
</ns1:conversionReponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
HTTP/1.0 200 OK
Date : Wed, 05Feb02 15:02:01 GMT
Server : Apache/1.3.24
Mime-version 1.0
Last-Modified: Wed02Octb01 24:05:01GMT
Content-Type: text/html
Content-legnth : 4205

45. POST /InStock HTTP/1.1 Host: www.example.org Content−Type:
application/soap+xml; charset=utf−8 Content−Length: nnn
<?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 xmlns:m="http://www.example.org/weather">
<m:GetTemperature>
<m:CityName>Innsbruck</m:CityName>
</m:GetTemperature>
</soap:Body>
</soap:Envelope>
Un message SOAP est défini pour le namespace XML
http://schemas.xmlsoap.org/soap/envelope/
Message SOAP(Requête)

46. HTTP/1.1 200 OK Content−Type: application/soap+xml; charset=utf−8
Content−Length: nnn
<?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 xmlns:m="http://www.example.org/services/weather">
<m:GetTemperatureResponse>
<m:Temperature>10</m:Temperature>
</m:GetTemperatureResponse>
</soap:Body>
</soap:Envelope>
Message SOAP(Réponse)

47. <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<soap:Fault>
<faultcode>soap:Server</faultcode>
<faultstring>Internal server error</faultstring>
</soap:Fault>
</soap:Body>
</soap:Envelope>
Message SOAP(Fault)

48. WSDL : Web Service Description Language
 WSDL est un langage de description basé sur
XML pour les services Web.
 Donne la description au format XML des web
services en précisant les méthodes pouvant être
invoquées, leurs signatures et le point d’accés
(URL, port, etc.)
23:53 232

49.  Un service est défini comme un ensemble de
points de terminaison ou de ports réseau.
Deux niveaux de description de service sont
identifiés dans WSDL.
1. Tout d'abord, un niveau d'interface abstrait fournit
des détails sur les types, les opérations et les
interfaces du service.
2. Ensuite, des protocoles réseau et des points de
terminaison concrets spécifient comment et où le
service peut être consulté
WSDL : Web Service Description Language

50. WSDL : Web Service Description Language

51. WSDL : Web Service Description Language
 Au niveau de l'interface abstraite, les types sont définis
en termes de schémas XML
 Les types sont utilisés pour définir des messages qui
représentent des données échangées entre les
fournisseurs de services et les demandeurs de services
 Les messages sont regroupés en opérations, chaque
opération étant constituée d'un ou plusieurs messages.
 Les opérations spécifient également l'ordre dans lequel
les messages sont envoyés ou reçus, en suivant des
modèles d'échange de messages prédéfinis:
 "In-Out", "Out-Only", "Robust-In-Only", "In-Optional-Out"
 Enfin, l'interface regroupe plus d'opérations
23:53 235

52. WSDL : Web Service Description Language
 Dans WSDL, une opération représente un
simple échange de messages qui suit un modèle
d'échange de messages spécifique (MEP).
 Le plus simple des MPEs, «In-Only», permet
d'envoyer un seul message d'application au service
 «Out-Only» symétriquement permet d'envoyer un
seul message par le service à son client.
 Un peu plus utile est le MEP «Robust-In-Only», qui
autorise également un seul message d'application
entrant, mais en cas de problème, le service peut
répondre avec un message d'erreur.
23:53 236

53. WSDL : Web Service Description Language
 Dans WSDL, une opération représente un
simple échange de messages qui suit un modèle
d'échange de messages spécifique (MEP).
 Le MEP le plus courant est peut-être «In-Out», qui
autorise un message d'application entrant suivi soit
d'un message d'application sortant, soit d'un
message d'erreur sortant.
 Enfin, utilisé dans les systèmes de messagerie est
«In-Optional-Out» où un seul message d'application
entrant peut être suivi soit d'un message sortant
d'erreur, soit d'un message sortant normal, qui à
son tour peut être suivi d'un message d'erreur
23:53 237

54. WSDL : Web Service Description Language
 Afin de communiquer avec un service Web
décrit par une interface abstraite, un client doit
savoir comment les messages XML sont
sérialisés sur le réseau et où exactement ils
doivent être envoyés.
 Dans WSDL, la sérialisation des messages en
ligne est décrite dans une liaison, puis une
construction de service énumère un certain
nombre d'adresses de point de terminaison
concrètes.
23:53 238

55. WSDL : Web Service Description Language
 Une liaison suit généralement la structure d'une
interface et spécifie les détails de sérialisation
nécessaires.
 La spécification WSDL contient deux
spécifications de liaison prédéfinies, une pour
SOAP (sur HTTP) et une pour HTTP simple.
 Ces liaisons spécifient comment un message
XML abstrait est incorporé dans une enveloppe
de message SOAP ou dans un message HTTP, et
comment les modèles d'échange de messages
sont réalisés dans SOAP ou HTTP
23:53 239

56. WSDL : Web Service Description Language
 Dans SOAP chaque erreur doit avoir un code
d'erreur avec deux options principales,
l'expéditeur ou le destinataire, indiquant qui a
un problème
23:53 240

57.  <?xml version='1.0' encoding='UTF-8'?>
 <definitions
 xmlns="http://schemas.xmlsoap.org/wsdl/"
 xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
 xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"
 xmlns:tns="http://www.mymeteo.com/webservices/meteo"
 xmlns:xs="http://www.w3.org/2001/XMLSchema"
 xmlns:ns1="http://www.mymeteo.com/meteo"
 targetNamespace="http://www.mymeteo.com/webservices/meteo"
 name="MeteoService"
 >
WSDL : Espaces des noms

58.  <!-- Les types de données au format XML schema -->
 <types>
 <xs:schema version="1.0"
targetNamespace="http://www.mymeteo.com/meteo"
 elementFormDefault="qualified">
 <xs:complexType name="temperature">
 <xs:sequence>
 <xs:element name="valeur" type="xs:double"/>
 <xs:element name="unite" type="xs:string"/>
 </xs:sequence>
 </xs:complexType>
WSDL : Les types

59.  <xs:complexType name="lieu">
 <xs:sequence>
 <xs:element name="ville" type="xs:string"/>
 </xs:sequence>
 </xs:complexType>
 <xs:complexType name="releve">
 <xs:sequence>
 <xs:element name="temperature" type="ns1:temperature"/>
 <xs:element name="lieu" type="ns1:lieu"/>
 </xs:sequence>
 </xs:complexType>
 <xs:element name="lieu" type="ns1:lieu"/>
 <xs:element name="releve" type="ns1:releve"/>
 </xs:schema>
 </types>
WSDL : Les types (suite)

60.  <!--
 La description de tous les messages possibles.
 Un message est défini par un ensemble de parties (une partie pour le body
 et une partie par en-tête)
 -->
 <message name="releveMeteo">
 <part name="partLieu" element="ns1:lieu"/>
 </message>
 <message name="releveMeteoResponse">
 <part name="partReleve" element="ns1:releve"/>
 </message>
WSDL : Les messages

61.  <!--
 Description des interfaces (indépendantes de SOAP)
 Une interface est composée d'un ensemble d'opérations.
 Chaque opération est définie par les messages en entrée et en sortie.
 -->
 <portType name="MeteoService">
 <operation name="releveMeteo">
 <input

wsam:Action="http://www.mymeteo.com/webservices/meteo/MeteoService/releveMeteoReq
uest"
 message="tns:releveMeteo"/>
 <output

wsam:Action="http://www.mymeteo.com/webservices/meteo/MeteoService/releveMeteoRes
ponse"
 message="tns:releveMeteoResponse"/>
 </operation>
 </portType>
WSDL : Les interfaces

62.  <!-- Liaison des interfaces avec le protocole SOAP -->
 <binding name="MeteoServicePortBinding" type="tns:MeteoService">
 <soap:binding transport="http://schemas.xmlsoap.org/soap/http"
style="document"/>
 <operation name="releveMeteo">
 <soap:operation soapAction=""/>
 <input>
 <soap:body use="literal"/>
 </input>
 <output>
 <soap:body use="literal"/>
 </output>
 </operation>
 </binding>
WSDL : Les liaisons

63.  <!--
 Localisation du service
 Dans le cas d'un binding SOAP avec un transport HTTP, on trouve ici l'URL du
service.
 -->
 <service name="MeteoService">
 <port name="MeteoServicePort" binding="tns:MeteoServicePortBinding">
 <soap:address location="http://www.mymeteo.com/ws/meteo"/>
 </port>
 </service>
 </definitions>
WSDL : Localisation des services

64. UDDI (Universal Description, Discovery and Integration)
 Normalise une solution d’annuaire distribué de
web services, permettant a la fois la publication
et l’exploitation (recherche) de web services
 UDDI se comporte lui-même comme un web
service dont les méthodes sont appelées via le
protocole SOAP
 d'une part, UDDI fournit un mécanisme
permettant aux fournisseurs de services
d'enregistrer leurs services Web et, d'autre part,
aux consommateurs de services de les trouver.
23:53 248

65. UDDI (Universal Description, Discovery and Integration)
 UDDI définit un modèle de données standard et
des registres de services API forWeb.
 Le modèle de données est utilisé pour stocker
dans le registre des informations sur les
entreprises ou les fournisseurs de services, les
services offerts par ces entreprises ainsi que des
informations techniques sur ces services sous
forme de descriptions WSDL.
 Il existe cinq types de structure de données
définis dans le cadre du modèle de données:
23:53 249

66. Universal Description, Discovery and
Integration Protocol (UDDI)
 L'entité commerciale, businessEntity, décrit une
entreprise ou une entité de fourniture de services en
termes de nom, de description et de type d'entreprise
exercée
 Une entité commerciale fournit généralement un ou
plusieurs services liés à l'entité commerciale via la
structure de données businessService.
 Le businessService contient des informations sur le
service fourni par une entité commerciale, y compris le
nom, la description et les informations sur la façon
d'accéder aux services dans le cadre de l'élément
bindingTemplate.

67.  Le bindingTemplate fournit des informations détaillées
sur un service, y compris une adresse de point d'entrée
pour accéder au service
 Le tModel est la partie du modèle de données utilisée de
manière intensive pour la recherche. Il collecte les
informations identifiant de manière unique la
spécification du service.
 Un annuaire UDDI est accessible à l'aide d'API UDDI.
Cette API fournit des moyens pour publier des services,
accéder et interroger le registre, par programme.
Universal Description, Discovery and
Integration Protocol (UDDI)

68. UDDI : Exemple
 <businessEntity businessKey="uuid:EAE4D5A8−CFF4−4501−55AD−E702126866A0"
 operator="http://www.example.org/weather"
 authorizedName="John Doe">
 <name> Compagnie de services Météo</name>
 <description> Nous vous fournissons des informations météo </description>
 <contacts>
 <contact useType="general info">
 <description>Informations Générales</description>
 <personName>John Doe</personName>
 <phone> +(43) 444−1111 </phone>
 <email>jdoe@weather.com</email>
 </contact>
 </contacts>
 <businessServices> ...</businessServices>
 </businessEntity>

69. <businessServices>
<businessService
serviceKey="uuid:D6F1B765−BDB3−4837−828D−8284301E5A2A"
businessKey="uuid:BA744ED0−3EE7−91D3−DC23−11E035229C6
4">
<name>WeatherWebService</name>
<description>Service Web Méteo</description>
<bindingTemplates>
...
</bindingTemplates>
<categoryBag />
</businessService
</businessServices>
UDDI : Exemple

70. Illustration Par Un Exemple Plus Large
• Imaginez une «agence de voyage virtuelle» (VTA) qui est un service d'utilisateur final fournissant
des services de tourisme électronique aux clients.
• Ces services peuvent couvrir toutes sortes de services d'information liés au tourisme - des
informations sur les événements et les sites touristiques d'une région aux services qui prennent en
charge la réservation en ligne de vols, d'hôtels, de locations de voitures, etc.
• Les partenaires des VTA sont intégrés via une intégration B2B classique.
• En un mot, l'application VTA fournit les fonctionnalités suivantes: les clients utilisent le service
VTA comme point d'entrée pour leurs demandes.
• Ces services destinés aux utilisateurs finaux sont agrégés par la VTA en invoquant et en combinant
les services Web proposés par plusieurs prestataires de services touristiques.
• Pour faciliter cela, il peut y avoir un contrat dit «parapluie» entre les fournisseurs de services et la
VTA pour réglementer l'utilisation et l'attribution des services Web.

71. Illustration Par Un Exemple Plus Large

72. Illustration Par Un Exemple Plus Large
• Prenons l'exemple d'une
entreprise hôtelière imaginaire,
appelée «The Blue Hotel», qui
permet à ses clients de vérifier la
disponibilité des chambres à
l'aide du service Web
«BlueHotelService». La
représentation WSDL de ce
service est
<?xml version="1.0" encoding="utf−8" ?>
<description
xmlns="http://www.w3.org/ns/wsdl"
targetNamespace=
"http://www.bluehotel.com/wsdl/BlueHotelService"
xmlns:tns=
"http://www.bluehotel.com/wsdl/BlueHotelService"
xmlns:bhns =
"http://www.bluehotel.com/schemas/BlueHotelService"
xmlns:wsoap= "http://www.w3.org/ns/wsdl/soap"
xmlns:soap="http://www.w3.org/2003/05/soap−envelope"
xmlns:wsdlx= "http://www.w3.org/ns/wsdl−extensions">

73. Illustration Par Un Exemple
Plus Large: WSDL
<documentation> This document describes the Blue Hotel Web service. </documentation>
<types>
<xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.bluehotel.com/schemas/BlueHotelService"
xmlns="http://www.bluehotel.com/schemas/BlueHotelService">
<xs:element name="checkAvailability" type="tCheckAvailability"/>
<xs:complexType>
<xs:sequence>
<xs:element name="checkInDate" type="xs:date"/>
<xs:element name="checkOutDate" type="xs:date"/>
<xs:element name="roomType" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="checkAvailabilityResponse"
type="tCheckAvailabilityResponse"/>
<xs:complexType>
<xs:sequence>
<xs:element name="roomType" type="xs:string"/>
<xs:element name="rateType" type="xs:string"/>
<xs:element name="rate" type="xs:double"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="invalidDataError" type="xs:string"/>
</xs:schema>
</types>

74. Illustration Par Un Exemple Plus Large :
WSDL
</types>
<interface name = "BlueServiceInterface" >
<fault name = "invalidDataFault"
element = "bhns:invalidDataError"/>
<operation name="opCheckAvailability"
pattern="http://www.w3.org/ns/wsdl/in−out"
style="http://www.w3.org/ns/wsdl/style/iri"
wsdlx:safe = "true">
<input messageLabel="In"
element="bhns:checkAvailability" />
<output messageLabel="Out"
element="bhns:checkAvailabilityResponse" />
<outfault ref="tns:invalidDataFault" messageLabel="Out"/>
</operation>
</interface>
<binding name="BlueServiceSOAPBinding"
interface="tns:BlueServiceInterface"
type="http://www.w3.org/ns/wsdl/soap"
wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/">
<fault ref="tns:invalidDataFault"
wsoap:code="soap:Sender"/>
<operation ref="tns:opCheckAvailability"
wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap−response"/>
</binding>
<service name="BlueService"
interface="tns:BlueServiceInterface">
<endpoint name="reservationEndpoint"
binding="tns:BlueServiceSOAPBinding"
address ="http://www.bluehotel.com/BlueService"/>
</service>
</description>

75. Illustration Par Un Exemple Plus Large
• Une fois le «BlueHotelService» mis en place, la société Blue
Hotel doit enregistrer le service auprès d'un registre UDDI.
De cette manière, les clients potentiels peuvent interroger le
registre et trouver des informations pertinentes sur le registre
UDDI contient un ensemble de structures de données dédiées
à «BlueHotelService», une fois ce service inscrit au registre.

76. <businessEntity
businessKey="uuid:3AE4D5A8−CFF4−4501−55AD−E702126866A0
"
operator="http://www.bluehotel.com/"
authorizedName="George Blue">
<name>Blue Hotel</name>
<description>
The Blue Hotel, one of the best in town
</description>
<contacts>
<contact useType="general info">
<description>General Information</description>
<personName>George Blue</personName>
<phone> +(43) 555−222 </phone>
<email>gblue@bluehotel.com</email>
</contact>
</contacts>
<businessServices>
...
</businessServices>
</businessEntity>
Illustration Par Un Exemple Plus Large
• L'entité commerciale,
businessEntity, de
la société «Blue Hotel»
est

77. <bindingTemplate
bindingKey="uuid:36F1B765−BDB3−4837−828D−8284301E5A2A"
serviceKey="uuid:40E6D5A8−3E16−4f01−99DA−035229685A40">
<description xml:lang="en">SOAP binding for
Blue Hotel service</description>
<accessPoint
URLType="http">http://www.bluehotel.com/hotel:80/soap</accessPoint
>
<tModelInstanceDetails>
<tModelInstanceInfo
tModelKey="uuid:AE1B645F−CF2F−491f−811A−4868705F5904" />
</tModelInstanceDetails>
</bindingTemplate>
</bindingTemplates>
Illustration Par Un Exemple Plus Large
• L'élément bindingTemplate
associé au service Blue Hotel
est

78. Illustration Par Un Exemple Plus Large
• L'élément tModel
associé au service Blue
Hotel est
<tModel
tModelKey="uddi:WE1B6Q5F−CF2F−491f−811A
−4868705F5904"
operator="http://www.bluehotel.com/hotel"
authorizedName="George Blue">
<name>BlueHotelInterface Port Type</name>
<description>
An interface for the Blue Hotel service
</description>
<overviewDoc>
<overviewURL>
http://www.bluehotel.com/services/BlueHotelServi
ce.wsdl
</overviewURL>
</overviewDoc>
</tModel>

79. Illustration Par Un Exemple Plus Large
• Une simple interaction entre VTA et le Blue Hotel Service
comprend :
• l'émission d'une demande de vérification de la disponibilité
d'un type de chambre spécifique pour un intervalle de temps
donné
• et une réponse générée par le Blue Hotel Service contenant
des informations sur le type de chambre, le type de tarif et le
tarif réel de la chambre.

80. Illustration Par Un Exemple Plus Large
POST /InStock HTTP/1.1 Host: www.example.org Content−Type:
application/soap+xml; charset=utf−8 Content−Length: nnn
<?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 xmlns:bhns=
"http://www.bluehotel.com/wsdl/BlueHotelService">
<bhns:checkAvailability>
<bhns:checkInDate>2009−03−24</bhns:checkInDate>
<bhns:checkOutDate>2009−03−30</bhns:checkOutDate>
<bhns:roomType>Single</bhns:roomType>
</bhns:checkAvailability>
</soap:Body>
</soap:Envelope>

81. Illustration Par Un Exemple Plus Large
HTTP/1.1 200 OK Content−Type: application/soap+xml;
charset=utf−8
Content−Length: nnn
<?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 xmlns:bhns=
"http://www.bluehotel.com/wsdl/BlueHotelService">
<bhns:checkAvailabilityResponse>
<bhns:roomType>Single</bhns:roomType>
<bhns:rateType>Discount</bhns:rateType>
<bhns:rate>150.50</bhns:rate>
</bhns:checkAvailabilityResponse>
</soap:Body>
</soap:Envelope>

82.  JAX-WS (Java API for XML Web Services) repose sur
JAX-RPC (Java API for XML based RPC) qui permet de
développer des services web en java
 JAX-WS s’appui sur l’API JAXB 2.0 (Java Architecture for
XML Binding) en ce qui concerne la correspondance
entre document xml et objets java
 JAXB 2.0 permet de mapper des objets java dans un
document xml et vice versa
 Il permet aussi de générer des classes java à partir de
schéma xml et vice versa
Mise en œuvre avec Java : JAX-WS

83.  JAX-WS/JAXB
Mise en œuvre avec Java : JAX-WS

84.  Il existe 2 styles de services web reposant sur SOAP : le
Style Document et le Style RPC
 En plus du style, il existe deux types d'encodages :
Encoded et Literal
 Le style RPC est parfaitement structuré
 Alors que Le type Document n'a pas de structure
imposée
 son contenu est validé grâce à un schéma
Mise en œuvre avec Java : JAX-WS

85.  Dans le style RPC, le corps du message (tag
<soap:body>) contient un élément qui est le nom de
l'opération du service
 Cet élément contient un élément fils pour chaque
paramètre
 Dans le style Document, le corps du message (tag
<soap:body>) contient directement un document xml
dont tous les composants doivent être décrits dans un
ou plusieurs schémas XML
 Le moteur Soap est alors responsable du mapping entre le
contenu du message et les objets du serveur.
Mise en œuvre avec Java : JAX-WS

86.  JAX-WS fournit un ensemble d’annotations
pour mapper (sérialiser) la correspondance
JAVA-WSDL
 Il suffit pour cela d’annoter directement les
classes java qui représentent le web service
 Dans l’exemple suivant, une classe java utilise
les annotations JAX-WS qui vont permettre de
générer le document WSDL. Le document
WSDL est auto généré par le serveur
d’application au moment de déploiement
Mise en œuvre avec Java : JAX-WS

87. Exemple d’une classe annotée avec
Java : JAX-WS

88. Quelques annotations JAXB
Description
Annotation
Associer une classe ou une énumération a un
élément XML
@XmlRootElement
Associer un espace de nommage a un
package
@XmlSchema
Marque une entité pour ne pas être mappée
dans le document XML
@XmlTransient
Convertir une propriété en un attribut dans le
document XML
@XmlAttribute
Convertir une propriété en un élément dans
le document XML
@XmlElement
Préciser comment un champ ou une propriété
est sérialisé
@XmlAccessorType
Associer un prefixe d’un espace de nommage
a un URI
@XmlNs

89.  Le client qui doit consommer le web service a
besoin d’un proxy
 Pour générer le proxy (stub), il existe
plusieurs possibilités :
 Jax-RPC Artefacts, Jax-WS Artefacts, Apache CXF,
Oracle Proxy Artefacts, Axis 1.x Artefacts, …
 Ces outils sont intégrés également dans le testeur
SOAPUI, Oxygen, …
 Jax-ws (wsimport.exe) intégré dans java : Peut être
utilisé en ligne de commande: il suffit de préciser à
wsimport.exe l’adresse du web service
(localhost:8585/)
Exposé le web service

90.  Dans SOAPUI, il faut indiqué le chemin où on trouve wsimport
Exposé le web service

91.  On doit indiquer l’adresse du web service
(http://localhost:8585/BanqueWS?wsdl) et le chemin ou il faut
générer les class (Source Directory): choisir le chemin ou se trouve le
fichier Client.java). Et les bycode sont placés dans le dossier Target
Directory)
Exposé le web service

92.  Comment développer un service web avec JAX-WS
1. Créer le service
 Développer le service web
 Déployer le service web
 Un serveur HTTP
 Un conteneur WS (JaxWS, AXIS, CXF, …)
2. Tester le web service avec un analyseur SOAP, SOAPUI
3. Créer le Client
 Un Client java
 Un Client .Net
 Un Client PHP
 …
Résumé

93. Exemple d’application

94. Exemple d’application

95. Exemple d’application

96. Merci de votre Attention
23:53 280