Les services web: vue d'ensemble

1
Les Services Web, c'est quoi?
La technologie des services web affiche les mêmes intentions que les
architectures les plus anciennes en terme d'accès distant, comme les
moniteurs TP.

C'est la possibilité d'invoquer une fonction distante. En l'occurrence,

sur un serveur web distant puisque le protocole de base est HTTP

On dispose d'une infrastructure souple basée sur XML pour les

systèmes distribués hétérogènes

2
Les Services Web, c'est quoi?

Ils sont accessibles via le web par des protocoles bien connus

Ils sont décrits à partir de XML

Ils interagissent via XML

Ils sont localisables à partir de registres

Ils sont entièrement transversaux aux plates-formes et très

faiblement couplés

3
Les Services Web, c'est quoi?

Ils introduisent un nouveau modèle de développement basé sur ce

que l'on appelle les architectures orientées services

Une architecture orientée services se focalise sur une décomposition

plus abstraite dans la résolution des problèmes.
On parle de résolution dirigée par les services.

Un service résout un problème donné

Les services peuvent être combinés pour résoudre des problèmes de

plus en plus complexes

4
Les Services Web, c'est quoi?
Les tâches associées à la manipulation des services web sont :

Interroger un annuaire : qui fournit des choses dont on ne connaît pas forcément
la nature, le rôle ou le contenu

Négocier avec les fournisseurs potentiels de ces choses pour connaître :

Nature exacte du service fourni
Qualité/coût/etc.

Interagir avec le service du fournisseur choisi pour :

Connaître les modalités d'interaction
Introduire le service dans ma chaîne de traitements

Eventuellement composer des services

Eventuellement publier mes propres services

5
Les Services Web, c'est quoi?

L'avantage essentiel des services web concerne le fait que le client

consommateur n'a pas besoin de connaître l'identité du fournisseur du
service

Le client doit simplement exprimer son besoin

Face à un besoin, plusieurs fournisseurs de services peuvent exister

Chacun ayant des caractéristiques de coût, de performance, de fiabilité,

etc.

Le client choisit le fournisseur (le service) correspondant le mieux à ses

besoins.

6
Les usages

Les services web pour représenter des applications sophistiquées

bien délimitées et sans forte interactivité.
Par exemple, une application qui donne les données de la météo
peut être idéalement représentée par un service.

Les services web sont adaptés pour l'assemblage de composants

faiblement couplés.
Ils sont définis de façon indépendante, mais peuvent interagir.

Les services web sont adaptés à la représentation d'application

orientées messages.
Les mécanismes d'invocation asynchrone des applications orientées
messages sont en font de bonnes candidates aux services web

7
Les technologies

Les éléments techniques utilisés sont différents puisque imposés

par le Web et XML

L'architecture des Web Services repose essentiellement sur les

technologies suivantes :

SOAP - Simple Object Access Protocol

Protocole pour la communication entre Web Services

WSDL - Web Service Description Language

Langage de description de l'interface du Web Service

UDDI - Universal Description, Discovery and Integration

Annuaire pour le référencement du Web Service

8
Les technologies

Un Web Service est une application déployée sur un serveur Web

(serveur d'objets).

Supporter des Web Services apporte une interopérabilité

certaine et une grande flexibilité puisqu'il s'agit de coopération
entre objets distants par le biais du Web (TCP/IP - HTTP).

9
Les technologies

Pile de protocole

Document XML décrivant le service afin de

WSDL
rendre la solution des Web Services générique

Protocole basé sur le standard XML pour

SOAP
l'échange de données structurées entre des
applications réseaux

Couche réseau
HTTP
(HyperText Transfer Protocol)

Couches de base permettant l'interopérabilité des Web

Services

10
Les technologies
■Afin d'être découvert, un service doit être publié.
■Au dessus de ces trois couches de base viennent se

greffer deux couches UDDI :

Découverte de services UDDI

Publication de services UDDI

■On publie notre service via le document WSDL auprès

de notre annuaire UDDI.

■Une application cliente peut découvrir et accéder à notre

service lors de son exécution via un annuaire UDDI.

11
Le protocole SOAP

Rôle
Assure les appels de procédures à distance au dessus d'un protocole
de transport

Fonctionnement côté Client

Ouverture d'une connexion HTTP
Requête SOAP est un document XML décrivant :
une méthode à invoquer sur une machine distante
les paramètres de la méthode

Fonctionnement côté Serveur SOAP

Récupère la requête
Exécute la méthode avec les paramètres
Renvoie une réponse SOAP (document XML) au client

12
Le protocole SOAP

Service Requestor Service Provider

Demandeur de service Fournisseur de service

Requête SOAP
Serveur SOAP
Client HTTP dispatcheur
TOMCAT
Réponse SOAP

réseau implémentation

13
Le langage WSDL

Une interface qui cache le détail de l'implémentation du service,

permettant une utilisation indépendante :
de la plate-forme utilisée
du langage utilisé

Le fichier WSDL est au format XML et regroupe toutes les

informations nécessaires pour interagir avec le Web Service :
les méthodes
les paramètres et valeurs retournées
le protocole de transport utilisé
la localisation du service

Documents WSDL, générés par les outils de développement

favorisent une intégration rapide du service

14
Le langage WSDL

2 types de documents WSDL :

le document WSDL décrivant l'interface du service
le document WSDL décrivant l'implémentation du service

Documents indispensables au déploiement de Web Services

Publication et recherche de services au sein de l'annuaire UDDI se

font via ces 2 types de document WSDL

Pour l'accès à un service particulier, un client se voit retourné l'URL du

fichier WSDL décrivant l'implémentation du service.
Seul l'emplacement de ce fichier WSDL est indiqué puisque ce dernier
référence l'autre document WSDL décrivant l'interface de mise en
œuvre du service.

15
Annuaire UDDI

Rôle
Spécification pour la définition d'un service de registre

Fournisseur
Déclaration du fournisseur
Enregistrement de ses Web Services disponibles

Client
Requête de recherche de Web Services (SOAP)
Mise en relation avec le Web Service d'un fournisseur

16
Le fournisseur de services

publication Annuaire UDDI

WSDL
description
Service Description du service
Provider

déploiement serveur web Servlet

SOAP

implémentation

17
SOAP

18
SOAP, c'est quoi?

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ête-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, théoriquement, les clients et serveurs de
ces dialogues peuvent tourner sur n'importe quelle plate-forme et
être écrits dans n'importe quel langage du moment qu'ils puissent
formuler et comprendre des messages SOAP.

19
SOAP, c'est quoi?

Pour comprendre, imaginons une base de données très simple

d'une entreprise, comprenant une table spécifiant :
le numéro de référence,
le nom,
le numéro de téléphone des employés.

On désire mettre en place un service qui permet à d'autres

systèmes de la compagnie de consulter ces données.

Le service retourne un nom et un numéro de téléphone (un tableau

de chaînes de caractères à deux éléments) pour un numéro de
référence d'employé donné (un entier).

Voici la signature Java de ce service :

String[] getEmployeeDetails ( int employeeNumber );

20
SOAP, c'est quoi?

L'approche SOAP consiste :

à encapsuler la logique de requête de la base de données du service
(i.e. implémentation), dans une méthode Java par exemple
puis démarrer un thread qui écoute les requêtes adressées à ce
service (un écouteur ou listener), ces requêtes étant formulées dans
un format SOAP et contenant le nom du service et les paramètres
requis.
Le listener décode la requête SOAP entrante et la transforme en un
appel de la méthode vers l'objet concerné.
Il récupère le résultat de l'appel de la méthode, l'encode dans un
message SOAP (la réponse) et le renvoie au demandeur.

Cela donne:

21
Les points forts

Protocole de communication entre applications

Basé sur XML et les namespaces.

Communication par le Web (HTTP / SMTP / …)

Indépendant de la plateforme (windows, unix, mac, …)

Simple et extensible

22
Les principes

Permet d'envoyer des messages XML entre deux machines.

Les messages sont « emballés » dans une enveloppe SOAP

L'enveloppe SOAP est une grammaire prédéfinie

La grammaire du message dépend de l'application

Enveloppe repose sur Le message est

une grammaire SOAP dépendant de
identique pour tous les l'application puisqu'il
messages indique la méthode et
les paramètres

23
Les principes

Modèle pour le RPC :

Message Request invoque une méthode d'un objet distant
Message Response renvoie le résultat de son exécution

Encodage de types de données des langages de programmation,

comme :
Tableaux,
Enregistrements,
…

A noter que cela est hérité du modèle des schémas XML qui
permettent la représentation de structures de données
arbitrairement complexes (arbres, pointeurs, ...)

24
Les principes

Utilisable avec des protocoles :

Synchrones : HTTP,
Asynchrones : SMTP, JMS, …

Gestion des erreurs (SOAP Fault)

Entêtes (SOAP Header) :

utilisation de méta-données pour un ou plusieurs destinataires du
message qui peuvent chacun modifier les entêtes (audit, suivi, etc.).

Une spec du w3c (SOAP 1.2)

plus de modularité
mais aussi plus de complexité.

25
Les messages SOAP: présentation

<soap:Envelope
xmlns:soap=http://www.w3.org/2001/12/soap-envelope
soap:encodingStyle=http://www.w3.org/2001/12/soap-encoding>

<soap:Header>
…
</soap:Header>

<soap:Body>
…
<soap:Fault>
…
</soap:Fault>
</soap:Body>
</soap:Envelope>

26
Les messages SOAP: présentation

Un message SOAP valide est un document XML correctement formé.

Le prologue XML peut être présent, mais dans ce cas, ne doit contenir
qu'une déclaration XML (c-à-d. qu'il ne doit contenir ni référence à un
DTD, ni instruction XML).

Le message doit utiliser l'enveloppe SOAP et les namespaces

d'encodage SOAP, et doit avoir la forme suivante:
Une déclaration XML (optionnelle)
Une Enveloppe SOAP (l'élément racine) qui est composée de :
Une En-tête SOAP (optionnel)
Un Corps SOAP

27
Les messages SOAP: exemple

Un dialogue RPC encodé par SOAP contient un message de requête

et un message de réponse.

Considérons la méthode d'un service simple qui double la valeur

d'un entier donné dont voici la signature Java :

int doubleAnInteger ( int numberToDouble );

28
Les messages SOAP: exemple

Voici un exemple de requête SOAP sur un service définissant la

méthode décrite précédemment :

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

<SOAP-ENV:Envelope
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<ns1:doubleAnInteger
xmlns:ns1="urn:MySoapServices">
<param1 xsi:type="xsd:int">123</param1>
</ns1:doubleAnInteger>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

29
Les messages SOAP: exemple

Voici un exemple de réponse SOAP sur un service définissant la méthode

décrite précédemment :

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

<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<ns1:doubleAnIntegerResponse
xmlns:ns1="urn:MySoapServices"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<return xsi:type="xsd:int">246</return>
</ns1:doubleAnIntegerResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

30
Les messages SOAP: le prologue

Le prologue XML contient 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.

31
Les messages SOAP: l'enveloppe

La balise de l'Enveloppe SOAP ‹SOAP-ENV:Envelope ... > dans le

message de requête spécifie tout d'abord le style d'encodage.
Cette balise est optionnelle comme c'est le cas dans le message
de réponse.

L'Enveloppe SOAP contient également des définitions de

namespaces.
Les identifiants des namespaces sont standards et la
spécification SOAP demande à ce que ces namespaces soient
définis correctement ou pas du tout (c-à-d qu'un message SOAP
dans lequel manquent des définitions de namespaces est correct
et peut être exploité mais un message contenant des définitions
incorrectes, c-à-d non standards, est mauvais et refusé).

32
Les messages SOAP: l'entête

Il n'y a pas de tag header (en-tête) SOAP dans cet exemple.

Les en-têtes SOAP sont optionnelles et sont typiquement utilisées

pour transmettre des données d'authentification ou de gestion de
session.

A noter que l'authentification et la gestion de session sont en

dehors du cadre du protocole SOAP, même si les concepteurs de
SOAP autorisent une certaine flexibilité dans la transmission de
messages SOAP, de telle façon que les personnes qui les
implémentent puissent inclure de telles informations.

33
Le messages SOAP: le corps

La balise SOAP Body (le corps) ‹SOAP-ENV:Body> encapsule une unique

balise de méthode qui porte le nom de la méthode elle-même
‹ns1:doubleAnInteger ... > (ou, le même nom suivi du mot
"Response" dans le cas du message de réponse).

La balise de la méthode reçoit typiquement le namespace

correspondant au nom du service, dans notre cas urn:MySoapServices
pour assurer l'unicité (un service web, qui peut contenir n'importe
quel nombre de méthodes nommées différemment, a un nom de
service unique à l'URL sur laquelle il est accessible)

34
Les messages SOAP: le corps

La balise de méthode encapsule à son tour n'importe quel nombre de

paramètres comme par exemple la balise ‹param1 ... >

Les noms des balises de paramètres peuvent être de n'importe quel

nom qui peut être autogénérés ou défini explicitement

Dans le message de réponse, il n'y a qu'une seule balise de paramètre

(représentant la valeur de retour de la méthode).
Elle porte le nom ‹return>

35
Les messages SOAP: compléments

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 toutes
combinaisons de ceux-ci.

Voyons pour finir, à quoi ressemblent les dialogues SOAP pour des
méthodes avec des types de paramètres et de retour complexes.

36
Les messages SOAP: compléments

Dans les transparents suivants, nous donnons le dialogue résultant

de l'appel de la version initiale de getEmployeeDetails comme
décrite précédemment.

Dans cette version, le client envoie un entier (l'identification de

l'employé) et reçoit un tableau de chaînes de caractères à deux
éléments contenant :
le nom de l'employé
et le numéro de téléphone

Dans la balise ‹return> du message de réponse, nous avons le type

de la structure complexe (le tableau de chaines), à savoir :
xsi:type="ns2:Array" ns2:arrayType="xsd:string[2]"

37
Les messages SOAP: compléments
Voici un exemple de requête SOAP pour notre nouveau service :

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

<SOAP-ENV:Envelope
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<ns1:getEmployeeDetails
xmlns:ns1="urn:MySoapServices">
<param1 xsi:type="xsd:int">1016577</param1>
</ns1:getEmployeeDetails>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

38
Les messages SOAP: compléments
Voici un exemple de requête SOAP pour notre nouveau service :
<?xml version="1.0" encoding="UTF-8" ?>
<SOAP-ENV:Envelope
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<ns1:getEmployeeDetailsResponse
xmlns:ns1="urn:MySoapServices"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<return
xmlns:ns2="http://schemas.xmlsoap.org/soap/encoding/"
xsi:type="ns2:Array"
ns2:arrayType="xsd:string[2]">
<item xsi:type="xsd:string">Bill Posters</item>
<item xsi:type="xsd:string">+1-212-7370194</item>
</return>
</ns1:getEmployeeDetailsResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

39
Style RPC ou DOC

Style RPC
Appels de procédures distants
Paramètres proches des types des langages de programmation
Degré élevé d'automatisation

Style DOC
Echanges de messages conformes à des schémas arbitraires (Ex:
Demande d'achat).
Plus d'expressivité
Encouragé par .Net

40
Synchrone ou Asynchrone

Aujourd'hui : beaucoup de services synchrones,

au dessus d'HTTP.
Pas de garanties de service (timeout ?)

Plus robuste : Echanges asynchrones

SMTP, JMS, …
Garanties de service (Exactly Once)

41
Architecture technique côté client

Les messages envoyés au serveur seront des requêtes SOAP-XML

enveloppées dans des requêtes HTTP.

De même, les réponses du serveur sont des réponses HTTP qui

renferment des réponses SOAP-XML.

Du côté client, pour ne pas prendre en charge la sérialisation

SOAP et l'encodage HTTP, nous utilisons un package SOAP
spécifique.

Nous invoquons ensuite le service, simplement en invoquant la

méthode appropriée du package SOAP (typiquement en spécifiant
l'URL du service, le nom du service et tous les paramètres requis).
Le premier travail d'un package est de sérialiser l' invocation de
ce service en requête SOAP. Il doit ensuite encoder ce message
dans une requête HTTP et l'envoyer à l'URL spécifiée.

42
Architecture technique côté client

Nous verrons la façon dont le serveur traite la requête, mais pour

l'heure, il nous renvoie le message encodé HTTP contenant la
réponse SOAP.

Nous nous reposons sur le même package SOAP pour exécuter

l'inverse de ce qui fut fait au stade de la requête, c'est-à-dire
que le package décode le message HTTP et extrait le message
SOAP, ensuite désérialise le message SOAP et obtient la valeur
de retour de l'appel de la méthode.
Cette valeur de retour trouvée est ensuite passée comme valeur
de retour à l'invocation originale de la méthode par le code
client.

43