Les Web Services en 60 diapos chrono !

<Web Services/><Web Services/>
Olivier Le Goaër
olivier.legoaer@univ-pau.fr

Plan de la formation
 Appel de procédure
● Locale/distante, synchrone/asynchrone
 World Wide Web
● Principes techniques du Web
 Formats d’échange textuels
● XML et JSON
 Vers la notion de Web Service
● Web APIs, Service-oriented Architecture (SOA)
 Web Service de type SOAP et REST

Appel de procédureAppel de procédure

Appel de procédure locale
 Appel (ou invocation) de fonctions/procédures
● Rôle appelant-appelés (caller-callee)
function A() {
//something to do
}
function B(x) {
x++;
A(); //appel de A()
}
function C(y) {
A();
B(y);
}
Code compilé sur une
seule et même machine
=
Espace d'adressage unique

Appel synchrone/asynchrone
 Synchrone : l'appelant est bloqué dans l'attente
de la terminaison de l'appelé
 Asynchrone : l'appelant poursuit son exécution
même si l'appelé n'a pas terminé. Néanmoins, il
pourra en être averti en retour (callback).
function A() {
//something to do
}
function B(x) {
A(); //appel synchrone de A()
foo(); //instruction qui doit attendre que A() termine
}

Signature de procédure
 Juste ce qu'il faut savoir pour appeler une
procédure correctement
● Les détails de l'implémentation ne rentrent pas en ligne
de compte
● Nom + paramètres attendus + type de retour éventuel
 Un ensemble de signatures forme une interface
de programmation
● API : Application Programming Interface
function getStockPrice(String stockName) : Float
function distGmaps(String villeDepart, String villeArrivee) : Float

Informatique répartie
 Systèmes répartis
● Programmes indépendants sur des machines distinctes
et communiquant par échange de messages,
généralement asynchrones
● Apparaît à un utilisateur comme un système unique et
cohérent
 Programmation répartie
● Interface Description Langage (IDL) : liste de signatures
– Permet de compiler un code qui fait appel (à travers le
réseau) à du code pourtant situé sur une autre machine
● Multi-langage : un code écrit en Java doit idéalement
pouvoir appeler un code écrit en Python, etc.

Appel de procédure distante
 Appel de fonctions/procédures
● Espaces d'adressage différents !
 Passage des paramètres et valeurs retours
sous forme de messages
● Technique du "marshalling" ou "serialization"
function C(y) {
//appels distants
machine2::A();
z = machine2::B(y);
}
function A() {
//something to do
}
function B(x) {
A(); //appel de A() local
return x++;
}
y
Machine1 (caller)
Machine2 (callee)
x++

Technologies historiques
 La solution Corba (Common Object Request
Broker Architecture)
● La couche ORB se charge d'acheminer les appels
– Utilise une description IDL
 L'utilisation de RPC (Remote procedure call) ou
RMI (Remote Method Invocation)
● Talon client (stub), talon serveur (skeleton)
– Générés à partir d'une description IDL

Appel distant : synthèse
Appelant
(le client)
Appelant
(le client)
Appelé
(le serveur)
Appelé
(le serveur)
réseau
getStockPrice("IBM")
34.5
??
?
??
?

Appel distant : synthèse
Appelant
(le client)
Appelant
(le client)
Appelé
(le serveur)
Appelé
(le serveur)
Talon coté client
(stub)
Talon coté serveur
(skeleton)
Protocole de
communication
Protocole de
communication
réseau
ORB/IIOP
Interface
écrite en
« IDL »
Compilateur IDL

Technologie Web Service
 L'utilisation de Web Services (WS)
● XML-RPC, JSON-RPC, SOAP, ...
– Repose sur une description WSDL (≈ IDL)
● REST
– Repose (pour l'instant) sur une interface unifiée
● Description WADL proposée par le W3C en 2009
 Idée : réutiliser l'infrastructure World Wide Web
● Les procédures distantes sont des URLs
– Architecture client (appelant)/serveur(appelé)
– Le protocole de communication HTTP a fait ses preuves
● Reste à s'accorder sur les messages échangés...

En route pour les WS...
Machine2::getStockPrice("IBM")Machine2::getStockPrice("IBM")
Http://128.45.67.10:80/getStockPrice?stockName=IBM
http://www.example.org/getStockPrice?stockName=IBM
Noms de domaines

WWW : rétrospective
 1989 : les travaux Tim Berners-Lee et son
équipe au CERN (Suisse) débouchent sur le
langage HTML et le protocole HTTP.
 1993 : NCSA (National Center for
Supercomputing Applications) lance le
navigateur graphique Mozaïc qui est gratuit
 Depuis 1994, le W3C (World Wide Web
Consortium) standardise un ensemble de
technologies reliées au Web
● HTML, CSS, XML, SOAP, ...

Architecture client/serveur
 C'est toujours le client qui est à l'initiative de la
connexion au serveur ("maître/esclave").
Serveur Web
www.twitter.com
Serveur Web
www.twitter.com
Client Web : Chrome
Requête http
Réponse http
Exécution sur le serveur
(ASP, PHP, JSP, ...)
Execution sur le client
(HTML, CSS, JavaScript, ...)
1
3
24

Anatomie d'une URL
 Uniform Resource Locator
● http://host:[port]/path/resource#signet
 Données additionnelles (a.k.a paramètres)
● /resource?param1=value1&param2=value2&...
 Règles de bonne formation
● Pas d'espaces, pas d'accents (cf. encodage)
 Exemples familiers
● http://www.univ-pau.fr:80/fr/index.html
● https://www.meteofrance.com/previsions?ville=pau

Le protocole HTTP
 Le protocole HTTP (HyperText Transfer
Protocol) permet d'encapsuler des données qui
transitent entre un client et un serveur Web
Client
Serveur
Web
Requête HTTP(1)
Réponse HTTP(2)
Interprète les ressources Héberge des ressources

Mode déconnecté
 HTTP fonctionne en mode déconnecté
1. Le serveur Web reçoit une demande de connexion de la part d’un
client Web;
2. Après l'établissement de la connexion, le client envoie une
requête HTTP qui demande une ressource particulière;
3. Le serveur Web renvoie vers le client la ressource via un flux
HTTP;
4. Le serveur interrompt la connexion avec le client
AVANTAGES INCONVENIENTS
 le serveur Web peut supporter un
grand nombre de clients
 portabilité du client
 l’établissement d’une connexion est coûteux en
temps
 grande consommation de bande passante
 impossible de maintenir un contexte (stateless)

Format des requêtes HTTP
GET /docu.html HTTP/1.0
Accept: text/html
Accept: image/gif
User-Agent: Mozilla/4.7
* une ligne blanche *
POST /script HTTP/1.0
Accept: text/html
Accept: image/gif
Content-Length: 24
name1=value1&
name2=value2
Méthode
Ressource Version
Corps
entête

Méthodes et entêtes des requêtes
 Méthodes de la requête
● GET : demander quelque chose (une ressource) et envoi de données
● HEAD : demander les informations concernant l’entête d’un document
● POST : envoi de données à une ressource (typiquement un script)
● ...
 Entête de la requête
● Accept : Accepte une liste de types MIME (Multipurpose Internet Mail Extension)
● Accept-Encoding : Une liste de méthodes de codage MIME
● User-Agent : un identificateur du client
● Authorization : login password (faible au niveau sécurité)
● ...

Passage de paramètres
 Par la méthode GET
● les paramètres sont directement inclus dans l'URL
● une séquence de paires clé=valeur, séparées par une
esperluette (&) :
– /script?name=Le+Goaer&surname=Olivier&...
 Par la méthode POST
● les paramètres sont encapsulés dans le corps de la
requête HTTP
● les données peuvent même prendre une forme libre,
tant que le serveur sait comment les traiter

Méthode GET ou POST ?
 Confidentialité des données
● GET : les paramètres sont visibles dans l'URL
● POST : les paramètres ne sont pas visibles
 Volume des données
● GET : les URLs ont une limite de caractères
– 255 sur les vieux serveurs, + de 8000 aujourd'hui
● POST : aucune limitation du volume des données

HTTP/1.0 200 OK
Date:Wed, 02Feb97 23:04:12 GMT
Server: Apache/1.3.6
Last-modified: Mon,15Nov96 23:33:16 GMT
Content-type:text/html
Content-length: 2345
<html><head><title> …
</body></html>
Type
de serveur
Code status
Corps
Format des réponses HTTP

Entêtes et corps des réponses
 Entêtes de réponse
● Server: type de serveur
● Date: la date de traitement de la requête
● Content-Type: le type MIME de la ressource renvoyée
● Content-length: la taille en octets de la ressource renvoyée
● ...
 Corps de la réponse
● Un seul objet par réponse
● Du texte dans le cas d'un document XML ou JSON, des
octets dans le cas d'une image ou d'un son, etc.

Code de réponses des serveurs
 La première ligne de la réponse d'un serveur
donne
● la version du protocole HTTP utilisé
● un code d'état sur 3 chiffres
● une description du résultat
CODES D'ETATS
100--199 Message informatif
200--299 Requête du client accomplie avec succès
300--399 Requête du client redirigée, d'autres actions sont nécessaires
400--499 Requête du client incomplète (ex: 404: non trouvé )
500--599 Erreurs du serveur

Exemple de communication
Accept: image/gif, image/jpeg
Accept-language:en-us
Accept-Encoding: gzip, deflate
HTTP/1.1 200 OK
Date: Mon, 06 Jan 2014 13:45:24 GMT
Server:Apache/1.3.6 (Unix)
Last Modified: Fri, O4 oct 2015 14:08:23 GMT
Content-Length:458
Content-type:text/html
<html>
<head>
<title>The New York Times</title>
</head>
<body> … </body>
</html>
CLIENT SERVEUR
Requête (1)
Réponse (2)
GET /featured/ HTTP/1.1

Formats d'échangeFormats d'échange
textuelstextuels

Formats d'échange
 Formats textuels
● Human-readable
● Portable (à l'encodage de caractère près)
 Aisément manipulable à l'aide de « Parsers »
● Parsers DOM et SAX pour XML
– Expressions Xpath, XQuery
● Parsers JSON
 APIs de parsing disponibles dans quasiment
tous les langages de programmation

XML (eXtensible Markup Language)
 Est un « méta » langage
● En soit, il n'exprime rien, mais sert à en définir d'autre
 Concepts
● Eléments (a.k.a balises) et attributs
● Imbrication des éléments, sans chevauchement
 Importance du schéma (anciennement DTD)
● Fige le vocabulaire et les imbrications possibles
● Engendre de-facto un langage
– html, xml soap, wsdl, kml, svg, mathml...

XML : exemple
<?xml version="1.0" encoding="UTF-8"?>
<users>
<user data-id="101">
<nom>Zorro</nom>
<metier>Danseur</metier>
</user>
<nom>Hulk</nom>
<metier>Footballeur</metier>
</user>
<nom>Zidane</nom>
<metier>Star</metier>
</user>
<nom>Batman</nom>
<metier>Veterinaire</metier>
</user>
</users>

JSON (JavaScript Object Notation)
 Absence de schéma (schemaless)
● JSON est un meta-langage : chacun fait ce qu'il veut !
 Concepts simples
● Stockage sous la forme key:value
● Valeur de 2 types
– Object {}
– Array []

JSON : exemple
{
users: [
{ id: 101, nom: "Zorro", metier: "Danseur" },
{ id: 102, nom: "Hulk", metier: "Footballeur" },
{ id: 103, nom: "Zidane", metier: "Star" },
{ id: 104, nom: "Batman", metier: "Veterinaire" }
]
}

Vers la notion deVers la notion de
Web ServiceWeb Service

Intéropérabilité entre SI
Protocole standard
Requête métier
normalisée
1
Réponse métier
normalisée
5
Passerelle
Services
2
4
Traitement
métier
3
SI Agence
de voyage Fram
SI Air France
partie opaque
(neutralité technologique)
SI Mercure

Service + Web = Service Web
Protocole http
Requête http
JSON/XML
1
Réponse http
JSON/XML
5
Passerelle
Web Services
2
4
Traitement
métier
3
CLIENT
SERVEUR WEB
partie opaque
(PHP, ASP, JSP, Node.js, ...)

Deux Webs co-existent désormais
 Resources destinées à être consommées par
un humain : le « Web des documents »
● Le client est un navigateur → Pages Web
● S'adressent à monsieur tout le monde
 Resources destinées à être consommées par
une machine : le « Web des services »
● Le client est un programme → Services Web
● S'adressent aux développeurs
 Une même information peut être fournie par
ces 2 biais, selon le bon vouloir du fournisseur

Exemple d'une info financière
https://fr.finance.yahoo.com/ Page Web (l'information est noyée)
http://download.finance.yahoo.com/d/quotes.csv?s=EURUSD=X&f=l1 Service Web
(information brute)

API Open Data
 Philosophie d'ouverture et d'intéropérabilité
● Exemple : construire des applications "mashup"
 Jeux de données librement téléchargables via
le site web du fournisseur
● Cas des pages web (ne nous intéresse pas ici)
● Formats d'export CSV, EXCEL, ...
 Jeux de données accessibles via des APIs Web
● Liste des signatures des procédures appelables
● Des procédures distantes souvent limitées (read-only)
– Exportations de données situées en base

Open Data : quelques exemples
Gouvernement
www.data.gouv.fr
Gouvernement
www.data.gouv.fr
Vie locale
opendata.agglo-pau.fr,
opendata.paris.fr, ...
Vie locale
opendata.agglo-pau.fr,
opendata.paris.fr, ...
Cartographie
API Google Maps (payant),
API OpenStreetMap, ...
Cartographie
API Google Maps (payant),
API OpenStreetMap, ...
Transports
data.sncf.com,
developer.airfranceklm.com
Transports
data.sncf.com,
developer.airfranceklm.com
......

Exemple de l'entreprise Garmin

Exemple de PrestaShop (Backoffice)

Contrôles au niveau de l'API
 Contrôle d'accès
● Permet au fournisseur d'authentifier et d'autoriser (ou
non) un consommateur via un identifiant unique
● Souvent un simple paramètre ("APIkey", "token", ...)
supplémentaire au moment de l'appel
– http://provider/service?key=HD454DSJH9
 Contrôle d'usage
● Basé sur le contrôle d'accès ci-dessus, et permet au
fournisseur de fixer des quotas (ex: max 15 requêtes
http/jour)
 Contrôle = monétisation des services !

Métaphore du service
 Un fournisseur de service
● Le serveur (l'appelé) propose une offre de service
 Un consommateur de service
● Le client (l'appelant) est en demande d'un service
 Un annuaire (ou registre) de service
● Le client découvre les services existants
 Une négociation entre les 2 parties
● Si les termes du "contrat" conviennent (tarif, qualité,
quantité, etc.), l'appel de procédure a lieu

Architecture orientée service (SOA)
Consommateur
de service(s)
Consommateur
de service(s)
Fournisseur
de service(s)
Fournisseur
de service(s)
Offre/contrat
de service
Annuaire public
de service(s)
Annuaire public
de service(s)
appel(s) de service(s)
publication
demande
+
Orchestration
de service

Web Service de typeWeb Service de type
SOAP et RESTSOAP et REST

Simple Object Access Protocol
 Protocole de transport
● HTTP quasi-unanimement (rarement SMTP, FTP, ...)
 Format d'échange
● XML SOAP
 Description des services
● WSDL (Web Services Description Language)
 Annuaire
● UDDI (Universal Description Discovery and Integration)
Technologies
standardisées
par le W3C

Architecture orientée service (SOA)
Consommateur
de service(s)
Consommateur
de service(s)
Fournisseur
de service(s)
Fournisseur
de service(s)
WSDL
Annuaire
de service(s)
Annuaire
de service(s) UDDI
getStockPrice("IBM")
publication
demande
SOAP
http://www.example.org/InStock

Message xml SOAP
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2003/05/soap-envelope/"
soap:encodingStyle=
"http://www.w3.org/2003/05/soap-encoding">
<soap:Header>
...
</soap:Header>
<soap:Body>
...
<soap:Fault>
...
</soap:Fault>
</soap:Body>
</soap:Envelope>

Requête SOAP
Spécifique au
domaine métier
(décrit par WSDL)
POST /InStock HTTP/1.1
Host: www.example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: 250
<soap:Envelope
soap:encodingStyle="http://www.w3.org/2003/05/soap-
encoding">
<soap:Body xmlns:m="http://www.example.org/stock">
<m:GetStockPrice>
<m:StockName>IBM</m:StockName>
</m:GetStockPrice>
</soap:Body>
</soap:Envelope>
http

Réponse SOAP
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: 200
<soap:Envelope
soap:encodingStyle="http://www.w3.org/2003/05/soap-
encoding">
<soap:Body xmlns:m="http://www.example.org/stock">
<m:GetStockPriceResponse>
<m:Price>34.5</m:Price>
</m:GetStockPriceResponse>
</soap:Body>
</soap:Envelope>
http

Exemple avec un client KSOAP
 API client SOAP pour Android (Java)
String METHOD_NAME = "getStockPrice";
String NAMESPACE = "http://www.example.org/";
String SOAP_ACTION = "http://www.example.org/InStock/";
String URL = "http://www.example.org/stock"; //WSDL
SoapObject request = new SoapObject(NAMESPACE, METHOD_NAME);
request.addProperty("StockName", "IBM");
SoapSerializationEnvelope envelope = new
SoapSerializationEnvelope(SoapEnvelope.VER11);
envelope.dotNet = true;
envelope.setOutputSoapObject(request);
HttpTransportSE androidHttpTransport = new HttpTransportSE(URL);
androidHttpTransport.call(SOAP_ACTION, envelope);
SoapObject response = (SoapObject)envelope.getResponse();
//ici manipulation de l'objet résultat
Float valueStock = (Float) response.getProperty("price");

REpresentational State Transfer
 HTTP définit quatre (principaux) verbes pour la
manipulation des ressources
● GET : récupérer l’état de la ressource
● PUT : attribuer l’état de la ressource
● DELETE : supprimer la ressource
● POST : fournir des données à la ressource
 HTTP définit 40 codes de statut, répartis en
cinq catégories
 Tout cela est bien suffisant pour faire du RPC !
« CRUD »
Create
Read
Update
Delete

Requête et réponse REST
GET /InStock/IBM/ HTTP/1.1
GET /InStock/stockPrice?stockName=IBM HTTP/1.1
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 32
{ price: 34.5, currency: "USD" }
Ou bien...

Exemple avec un client Ajax
 Asynchronous JavaScript and XML (AJAX)
var req = new XMLHttpRequest(); //API cliente unique
//methode http GET
req.open('GET', 'http://www.exemple.org/InStock/IBM/', true);
req.onreadystatechange = function (aEvt) { //callback
if (req.readyState == 4) {
if(req.status == 200) { //code retour serveur OK
var resp = JSON.parse(req.responseText); //parsing JSON
window.alert(resp.price & ' ' & resp.currency);
}
}
};
req.send(); //envoie la requête au serveur

SOAP versus REST (1/2)
 Le degré de liaison entre le client et le serveur
● Fort avec SOAP
– APIs client spécifiques, pas forcément disponibles
● Faible avec REST
– API client unique (un simple client http), disponible dans
tous les langages de programmation
 La sémantique
● SOAP met l'accent sur les opérations/procédures
– HTTP est réduit à une simple couche de transport
● REST met l'accent sur une interface unifiée
– Verbes HTTP, code de retours HTTP, etc.

SOAP versus REST (2/2)
 Soap reste complexe à mettre en oeuvre
● WSDL demeure une technologie intéressante
– Services auto-décrits. Interface versus implémentation
– APIs clients générées à partir de cette description
● Le concept d'annuaire UDDI a fait un flop
● Profusion d’extensions (WS-Policy, WS-Security, WS-
Trust, etc.)
 Le style REST brille par sa simplicité
● Ce concept d'interface unifiée a fait ses preuves dans
d'autres domaines de l'informatique (ex: fichiers Unix)

L'avenir du Web Service : HATEOAS
 Hypermedia As The Engine Of Application State
● Point culminant du style REST
 S'approprier HTTP
● Créer ses propres verbes d'action métier HTTP
● Créer ses propres codes de retour métier HTTP
 Exploiter le concept de lien hypermédia
● Le retour des procédures appelées peut inclure des
URLs qui à leur tour peuvent être appelées, et ainsi de
suite...
● Autre façon de réaliser des orchestrations de services

Les Web Services en 60 diapos chrono !

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Les Web Services en 60 diapos chrono !

Similar a Les Web Services en 60 diapos chrono ! (20)

Más de Olivier Le Goaër

Más de Olivier Le Goaër (6)

Les Web Services en 60 diapos chrono !