Vous êtes sur la page 1sur 17

ARCHITECTURE ORIENTEE SERVICE

Mohamed HAMMOUDA

Année Universitaire 2017-2018

1
Les Web Services : SOAP

2
Les Web Service : Une définition

De multiples définitions de la notion de Web Services existent, mais sont


généralement trop vagues ou trop précises.

 Un service Web est un programme sollicité via Internet par


différents type de clients, permettant l’échange de données afin
que l’application appelante puisse intégrer le résultat de cet
échange à ses propres analyses. Les requêtes et les réponses
s’effectuent dans des formats ouverts (HTML, XML, JSON ou TEXT)
et transitent par Internet.

3
Les composants des Web Service

Afin de mettre en œuvre un service web, trois composants sont nécessaires :


un protocole pour décrire le service : il
permet –entre autres- d’énumérer les
méthodes disponibles, ainsi que leurs
signatures (nous étudierons plus tard
WSDL,WADL) ;

• un protocole pour écrire les messages


(SOAP) ou une architecture pour
récupérer une ressource (RestFul);

• un protocole de transport, afin de faire


circuler les informations sur Internet
(HTTP)

4
SOAP Echange de messages à travers soap

Port de connexion (URL)


Pare-feu Pare-feu
Messages
Procuration Appel Translateur
SOAP
d'interface SOAP
Application
Cliente

HTTP

RPC
local
Réponse
Parser Parser
XML Serveur
XML
d'application

CLIENT SERVEUR
5
SOAP Le protocole SOAP (1/4)

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 part 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 programmation distribuées, en suivant


le modèle RPC (Remote Procedure Call).

Soap est très pratique dans les communication Enveloppe SOAP


M2M
En-tête SOAP
Un message SOAP est un document XML (header)
composé d’une enveloppe qui contient
une entête et le corps du message. Corps du message SOAP
(body)

6
SOAP Le protocole SOAP (2/4)

Prenons l’exemple d’un message SOAP appelant une méthode echoString(string), qui prend en
paramètre une chaîne de caractères.

L’entête (header) contient des <Envelope>


informations non-liées à la
méthode, comme par exemple l’ID
<Header>
de la transaction ou des <Transaction>3<Transaction>
informations pour la sécurité.
L’entête est facultative et les </Header>
éléments qu’elle contient peuvent
avoir l’attribut mustUnderstand,
<Body>
qui précise si le serveur est obligé <echoString>
de connaître et traiter l’élément.
<arg0>Hello!</arg0>
</echoString>
</Body>
Le corps (body) du message
</Envelope>
contient toutes les informations
destinées au récepteur (les
paramètres par exemple) ou
L’enveloppe contient tout le message
l’élément fault si une erreur s’est
produite.

7
SOAP Le protocole SOAP (3/4)

Lorsque le serveur répond à la méthode echoString(string), il ajoute Response à la suite du tag


<echoString> (d’une manière générale, il rajoute Response à la suite du tag contenant le nom de
la requête.

<Envelope>
<Header>
<Transaction>3<Transaction>
</Header>
<Body>
<echoStringResponse>
<return>Hello!</return>
</echoStringResponse>
</Body>
</Envelope>

Si une erreur se produit, la réponse contient l’élément Fault (dans le corps du message).
8
SOAP Le protocole SOAP (4/4)

Une des forces de SOAP est de permettre l’inter-opérabilité entre différentes


plate-formes. 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.

Dans le cas où des données binaires devraient transiter (comme une image par
exemple), il est également possible d’envoyer un message SOAP avec
attachement et ce grâce à un message MIME (Multimedia Internet Mail
Extension).

Pour pouvoir référencer une pièce jointe depuis le corps du message SOAP, une
URI est utilisée, faisant référence à la pièce jointe.

9
SOAP La couche transport

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 le version 1.1).

Actuellement, deux couches de transport sont fréquemment utilisées (HTTP étant


le plus courant) :

• HTTP, lors d’appels synchrones ;


• SMTP, lors d’appels asynchrones.

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, …).
10
SOAP La couche transport (1/3)

• Quand un client envoie une requête, il l’envoie grâce à une méthode (GET, POST ou HEAD), suivie d’une
URI (Uniform Ressource Identifier) qui identifie la ressource demandée. Après cette URI se trouve la
version du protocole HTTP (1.0 ou 1.1) ;

• Dans les lignes suivantes se trouvent les entêtes qui précisent par exemple quels sont les documents
acceptés par client, de quel type de client il s’agit, …

• Après les entêtes se trouve le corps de la requête, rempli seulement lorsque la méthode POST est utilisée

Les méthodes
GET Utilisé pour demander un document : GET index.html

HEAD Comme GET, mais aucune information ne se trouve dans le corps du résultat.
Notamment utilisé pour voir si un document a été mis à jour.

POST Permet au client d’envoyer des données dans le corps de la requête.


Utile pour envoyer des formulaires, des documents, poster des messages dans les newsgroups… Cette méthode est
celle qui convient le mieux à SOAP

• D’autre méthodes existent : PUT, DELETE mais sont rarement utilisées ;

• La réponse du serveur contient le statut de la réponse, les entêtes puis le corps de la réponse (par
exemple le contenu d’un document HTML ;

• Différents statuts existent. Les principaux sont : 200 (ok), 400 (mauvaise requête), 403 (client non
autorisé), 404 (document inexistant), 500 (erreur d’exécution –sur le serveur). 11
SOAP La couche transport (2/3)

Exemple d’envoi d’un message SOAP au dessus de HTTP

Le message ne contient aucune information le liant à la couche de transport.


Concernant le protocole HTTP, l’ajout d’un attribut SOAPAction:uneURI permet au
destinataire (le serveur HTTP) de savoir qu’il reçoit une requête SOAP. La valeur
est une uri qui n’est pas vérifiée.

Pour un envoi via HTTP:

• ouverture d’une socket sur le port du serveur (80 par défaut) ;


• puis :

POST /axis/services/echo HTTP/1.0


Content-Type: text/xml; charset=utf-8
User-Agent: Axis/1.0
Host: 192.168.0.1:8080 Obligatoire pour requête
Cache-Control: no-cache SOAP sur HTTP
Pragma: no-cache
SOAPAction: http://tempuri.org/echo
Content-Length: 453

• puis est envoyée la requête. 12


SOAP WSDL (1/3)

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.

A noter : 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).13
SOAP La couche transport (3/3)
Ci-dessous le document WSDL décrivant un WS proposant une méthode d’addition.
<wsdl:definitions targetNamespace="http://192.168.0.12:8080/axis/SimpleWS.jws"/>
<wsdl:message name="addRequest">
<wsdl:part name="i1" type="xsd:int"/>
<wsdl:part name="i2" type="xsd:int"/> Décrit les messages
</wsdl:message> qui circulent
< <wsdl:portType name="SimpleWS">
<wsdl:operation name="add" parameterOrder="i1 i2">
Abstraction décrivant une opération
<wsdl:input message="impl:addRequest" name="addRequest"/>
<wsdl:output message="impl:addResponse" name="addResponse"/>
</wsdl:operation>
</wsdl:portType>
Protocole d’accès et format des
<wsdl:binding name="SimpleWSSoapBinding" type="impl:SimpleWS">
messages
<wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="add">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="addRequest">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://192.168.0.12:8080/axis/SimpleWS.jws" use="encoded"/>
</wsdl:input>
<wsdl:output name="addResponse">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://192.168.0.12:8080/axis/SimpleWS.jws" use="encoded"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="SimpleWSService">
<wsdl:port binding="impl:SimpleWSSoapBinding" name="SimpleWS">
<wsdlsoap:address location="http://192.168.0.12:8080/axis/SimpleWS.jws"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
Définit comment est disponible
(SOAP) la méthode et à quelle adresse

14
SOAP Le UDDI

UDDI (Universal Description, Discovery and Integration) est un standard


ayant pour but la création d’un annuaire distribué de services web.

• les pages blanches : informations générales sur une société (nom,


description, adresse) ;

• les pages jaunes : classement des types de services ;

• les pages vertes ou roses : informations sur les modes d’exploitation du


service.

L’UDDI Business Registry est une implémentation complète des spécifications


UDDI. Lancée en mai 2001 par Microsoft et IBM, elle permet maintenant à
quiconque d’y chercher des informations et aux sociétés de s’enregistrer.

UDDI repose sur une architecture distribuée comparable à celle des


serveurs DNS.
En guise d’exemple :
• http://uddi.microsoft.com ;
• http://www.ibm.com/services/uddi.
15
SOAP SOA : Architecture globale

1 L’entreprise A
développe et déploie
un service web (WS)

Entreprise WS L’entreprise A
A
répond à B
6

5
L’entreprise B
invoque WS
2
L’entreprise A
publie WS

Entreprise
L’entreprise B, à la recherche d’un service du B
type WS, envoie une demande de recherche
au serveur UDDI
3

4
Le serveur UDDI renvoie l’adresse
de WS (plus d’autres info comme la
description du service. cf plus loin)
Serveur
UDDI 16
SOAP SOAP : Conclusion

 Trop souvent on lit « web services = SOAP ». C’est faux !


Web service = XML + (HTTP|SMTP|FTP|…)

 Les services web permettent de mettre en place des services faiblement


couplés (loosely coupled), rendant la communication entre deux plate-
formes incompatibles possible.

 SOAP est indépendant de la couche de transport ;

 Cependant, SOAP est devenu de facto le standard des services web ;

 WSDL sert à décrire des services web ;

 UDDI est un annuaire qui répertorie les sociétés et les services web
qu’elles proposent ; UDDI est basé sur une architecture distribuée.
17

Vous aimerez peut-être aussi