WEB

SERVICES

1 FABRICE CLARI- FABRICE.CLARI@GMAIL.COM

WEBSERVICES

XMLSOAP, WSDLRPC avec SOAPAXIS…

WEB

SERVICES

2

• Pré-requiso XMLo Espaces de noms (namespaces)o XML Schema

• Services Web : définition• SOAP• Les protocoles de communications• RPC avec SOAP • WSDL • UDDI • Un scénario• Les éditeurs• La sécurité des services web• Les faiblesses• Passé, présent, futur• L’utilisation dans l’industrie : exemple• AXIS • Les services web et la mobilités• Conclusion

Sommaire

WEB

SERVICES

3

Introduction à XML (1/4)Afin de bien comprendre le fonctionnement des services web, il est important d’avoir quelques connaissances sur le langage XML et XML Schema.

• XML est un langage balisé qui est rapidement devenu le standard pour l’échange de données ;

• Les données sont identifiées grâce à des tags (tout tag ouvert doit impérativement être fermé) ;

• A la différence de HTML, les tags XML identifient des données et non un affichage.

Exemple : <?xml version="1.0" encoding="ISO-8859-1" ?>

<album> <artiste>Jean-Jacques Goldman</artiste> <titre>Chansons pour les pieds</titre> <date_de_parution>2001</date_de_parution> <chansons> <titre piste='1'>Ensemble</titre> <titre piste='2'>Et l'on y peut rien</titre> <titre piste='3'>Une poussière</titre> </chansons> <prix euros='20' /></album>

WEB

SERVICES

4

Introduction à XML (2/4)

• Entre deux tags XML ouvert/fermé, se trouve un élément ;

• Un tag XML peut contenir d’autres tags, ce qui permet une représentation hiérarchique des données ;

• Un tag peut contenir un (voire plusieurs) attribut(s) (piste dans le tag titre de l’exemple précédent) ;

• Tous les tags ouverts doivent être fermés ;

• Un tag vide est valide (<prix euros='20' /> par exemple) ;

• Exemple de commentaires en XML : <!-- commentaire --> ;

• Un document XML commence par un prologue : <?xml version="1.0" encoding="ISO-8859-1" ?>

• Différents types de parseur XML existent : DOM (Document Object Model), qui construit un arbre en mémoire du document, et SAX (Simple API to XML) qui associe un évènement à chaque balise lue.

Astuce : pour vérifier la validité d’un document XML, vous pouvez l’ouvrir avec Internet Explorer (version supérieure ou égale à la 5.5) qui dispose d’un parseur XML. Il affichera une erreur si le document est syntaxiquement faux.

WEB

SERVICES

5

<?xml version="1.0" encoding="ISO-8859-1" ?>

<albums> <album> <artiste>Jean-Jacques Goldman</artiste> <titre>Chansons pour les pieds</titre> <date_de_parution>2001</date_de_parution> <chansons> <piste n='1'>Ensemble</piste> <piste n='2'>Et l'on y peut rien</piste> <piste n='3'>Une poussière</piste> </chansons> <prix euros='20' /> </album></albums>

Introduction à XML (3/4)La notion d’espace de noms (namespace) est très utilisée dans les services web. Les namespaces permettent :

• de qualifier de manière unique des éléments et des attributs ; • la définition de balises modulaires.

Exemple

Un magasin de disques et de livres peut caractériser son stock par deux documents XML :

Un décrivant ses disques Un décrivant ses livres

<?xml version="1.0" encoding="ISO-8859-1" ?>

<livres> <livre> <auteur>Jean-Marie Chauvet</auteur> <titre>Services Web avec SOAP, WSDL, …</titre> <date_de_parution>2002</date_de_parution> <editeur>eyrolles</editeur> <prix euros=‘39' /> </livre></livres>

Problème : la balise <titre> contient deux types d’informations.

WEB

SERVICES

6

<?xml version="1.0" encoding="ISO-8859-1" ?>

<magasin xmlns:magasin="http://magasin.org" xmlns:album="http://album.org" xmlns:livre="http://livre.org">

<magasin:albums> <magasin:album> <album:artiste>Jean-Jacques Goldman</album:artiste> <album:titre>Chansons pour les pieds</album:titre> <album:date_de_parution>2001</album:date_de_parution> <album:chansons> <album:piste piste='1'>Ensemble</album:piste> <album:piste piste='2'>Et l'on y peut rien</album:piste> <album:piste piste='3'>Une poussière</album:piste> </album:chansons> <album:prix euros='20' /> </magasin:album> </magasin:albums> <magasin:livres> <magasin:livre> <livre:auteur>Jean-Marie Chauvet</livre:auteur> <livre:titre>Services Web avec SOAP, WSDL, …</livre:titre> <livre:date_de_parution>2002</livre:date_de_parution> <livre:editeur>eyrolles</livre:editeur> <livre:prix euros='39' /> </magasin:livre> </magasin:livres></magasin>

Introduction à XML (4/4)L’espace de nom (xmlns) permet de créer un nom unique pour chacune des balises <titre>, en associant un identifiant unique (URI, Uniform Ressource Indentifier) à un nom.

Ces URI ne sont pas vérifiées. En général, elles pointent sur la grammaire de l’espace de noms.

WEB

SERVICES

7

Introduction à XML Schema

XML Schema précise comment représenter en XML une structure de données. A la différence des DTD, qui ne définissent que les imbrications des éléments entre eux, XML Schema définit les imbrications ainsi que les types des données (éléments et attributs).

Ainsi, le XML Schema définissant l’exemple <livre> (simplifié) est :

<xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"> <xsd:element name="livre"> <xsd:complexType> <xsd:sequence> <xsd:element name=" auteur" type="xsd:string" minoccurs="1" maxoccurs="1"/> <xsd:element name="titre" type="xsd:string"/> <xsd:element name="date_de_parution" type="xsd:string"/> <xsd:element name="editeur" type="xsd:string"/> <xsd:element name=”prix”> <xsd:complexType> <xsd:attribute name=”euros” type=”xsd:int” </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element></xsd:schema>

WEB

SERVICES

8

De multiples définitions de la notion de Web Services existent, mais sont généralement trop vagues ou trop précises.

Un groupe de travail du W3C (Web Services Architecture group, composé de multiples membres de l’industrie) en donne une définition exacte :

« A web service is a software application identified by a URI, whose interfaces and binding are capable of being defined, described, and discovered by XML artifacts, and supports direct interactions with other software applications using XML-based messages via Internet-based protocols ».

(source : http://www.w3c.org/2002/ws/arch/2/08/wd-wsa-arch-20020821.html#webservice)

• Cette définition met l’accent sur l’utilisation du langage XML, utilisé pour décrire la structure des messages échangés entre clients et serveurs de Services Web ;

• Elle ne précise pas quel protocole de transport doit être utilisé. Cependant, il doit s’agir d’un protocole utilisé sur Internet.

Web Services : une définition

WEB

SERVICES

9

Les composants d’un service web

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) ;

• un protocole pour écrire les messages ;

• un protocole de transport, afin de faire circuler les informations sur Internet.

http://www-106.ibm.com/developerworks/webservices/library/ws-best1/?dwzone=webservices#figure1

WEB

SERVICES

10

Le protocole SOAP (1/6)

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).

La grande majorité des services web utilise le protocole HTTP.

Un message SOAP est un document XMLcomposé d’une enveloppe qui contientune entête et le corps du message.

Enveloppe SOAP

En-tête SOAP(header)

Corps du message SOAP(body)

WEB

SERVICES

11

<Envelope> <Header> <Transaction>3<Transaction> </Header> <Body> <echoString> <arg0>Hello!</arg0> </echoString> </Body></Envelope>

L’enveloppe contient tout le message

Le protocole SOAP (2/6)

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

Le corps (body) du message contient toutes les informations destinées au récepteur (les paramètres par exemple) ou l’élément fault si une erreur s’est produite.

L’entête (header) contient des informations non-liées à la méthode, comme par exemple l’ID de la transaction ou des informations pour la sécurité (infos du header = gestion du contexte).L’entête est facultative et les éléments qu’elle contient peuvent avoir l’attribut mustUnderstand, qui précise si le serveur est obligé de connaître et traiter l’élément.

WEB

SERVICES

12

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

Le protocole SOAP (3/6)

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.

Si une erreur se produit, la réponse contient l’élément Fault (dans le corps du message).

WEB

SERVICES

13

Le protocole SOAP (4/6)

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.

WEB

SERVICES

14

Le protocole SOAP (5/6)

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<soapenv:Body>

<ns1:echoStringResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="http://soapinterop.org/">  <return xsi:type="xsd:string">Hello!</return>   </ns1:echoStringResponse>

</soapenv:Body>

</soapenv:Envelope>

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.

WEB

SERVICES

15

Le protocole SOAP (6/6) : les headers et leurs attributs

• Les headers sont utilisés par des nœuds SOAP ;

• Il existe trois types de nœuds: envoyeur, intermédiaire et receveur final ;

• Chaque header peut avoir trois attributs : role, relay, mustUnderstand :

• role permet de définir à quel nœud le header est destiné

• relay indique si un header doit être relayé (cad transmis au nœud suivant) s’il n’est pas traité

• mustUnderstand définit si le traitement du header par le nœud est optionnel ou obligatoire

WEB

SERVICES

16

La couche de transport (1/5)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.

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 (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, …).

Ce protocole est défini par le W3C et est présenté dans une RFC (Request for Comment) : ftp://ftp.isi.edu/in-notes/rfc2616.txt.

WEB

SERVICES

17

La couche de transport (2/5) : HTTPExemple : un navigateur web souhaite obtenir la page par défaut du site

www.google.fr

Client HTTP (Internet Explorer)

Serveur Web(Apache)

Ouverture d’une socket sur le port 80 (port par défaut)

GET / HTTP/1.0

HTTP/1.0 200 OKContent-Length: 3403Server: GWS/2.0Date: Mon, 14 Oct 2002 06:31:35 GMTContent-Type: text/html

<html><head><meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"><title>Google</title><style>……

Dans le cas où toutes les requêtes HTTP doivent transiter par un serveur de cache (proxy HTTP), comme c’est le cas au MBDS, il faut ouvrir les connexions sur ce proxy (et non sur le serveur ciblé) puis demander l’URL entière.

Ex. : si un client (au MBDS), souhaite obtenir la page www.google.fr :

1. Ouverture de la socket (en TCP) sur le port 3128 de tango ;2. Envoie de la requête : GET http://www.google.fr HTTP/1.03. Le proxy se connecte à son tour à google.fr ;4. Une fois que le proxy a obtenu le résultat, il répond au client.

WEB

SERVICES

18

• 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éthodesGET Utilisé pour demander un document : GET index.html

Le corps d’une telle requête est toujours vide. Permet également de passer des paramètres au serveur, en les collant à l’URL : GET index.jsp?userLogin=toto&userPasswd=kkjuComme résultat, GET renvoie d’abord les entêtes, puis le contenu du document

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 : LINK, UNLINK, PUT, DELETE, OPTIONS, TRACE 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).

La couche de transport (3/5) : HTTP

WEB

SERVICES

19

La couche de transport (4/5) : SMTPSMTP (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.

Exemple de l’utilisation du protocole SMTP pour l’envoi d’un mail sur wanadoo.fr : - La première étape est l’ouverture d’une connexion (socket) sur le port 25 de smtp.wanadoo.fr.

WEB

SERVICES

20

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.0Content-Type: text/xml; charset=utf-8User-Agent: Axis/1.0Host: 192.168.0.1:8080Cache-Control: no-cachePragma: no-cacheSOAPAction: http://tempuri.org/echoContent-Length: 453

• puis est envoyée la requête.

La couche de transport (5/5)

Obligatoire pour requêteSOAP sur HTTP

WEB

SERVICES

21

RPC (1/2)

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).

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 à ce soucier de la couche réseau, qui est gérée par le RPC.

WEB

SERVICES

22

Code de l’appelant STUB

Réseau

Protocole réseau

Client Serveur

Protocole réseau SKELETON

Code du serveur

Service RPC Service RPC

RPC (2/2)Une architecture distribuée

Chaque RPC à son protocole de communication:• IIOP pour Corba ;• ORPC pour DCOM ;• JRMP pour RMI ;• et HTTP, SMTP, … pour SOAP !

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.

WEB

SERVICES

23

A ses débuts, SOAP était déstiné à ê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.

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. Nous étudierons en TP l’API Axis d’Apache.

RPC avec SOAP

WEB

SERVICES

24

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).

WEB

SERVICES

25

WSDL (2/3)Ci-dessous le document WSDL décrivant un WS proposant une méthode d’addition.

Décrit les messagesqui circulent

Définit comment est disponible(SOAP) la méthode et à quelle adresse

Abstraction décrivant une opération

Protocole d’accès et format des messages

<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"/> </wsdl:message> <wsdl:message name="addResponse"> <wsdl:part name="addReturn" type="xsd:int"/> </wsdl:message> <wsdl:portType name="SimpleWS"> <wsdl:operation name="add" parameterOrder="i1 i2"> <wsdl:input message="impl:addRequest" name="addRequest"/> <wsdl:output message="impl:addResponse" name="addResponse"/> </wsdl:operation> </wsdl:portType> <wsdl:binding name="SimpleWSSoapBinding" type="impl:SimpleWS"> <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>

WEB

SERVICES

26

WSDL (3/3)

• Sur le slide précédent, quelques éléments n’ont pas été présentés. Reprenons l’élément <port> : il définit un point de terminaison (adresse internet plus liaison).

<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>

• Il est à noter que l’élément <portType> peut contenir plusieurs opérations.

A l’exemple précédent manque l’élément <type> qui permet de définir des types complexes (dans l’exemple 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.

• Le logiciel XMLSpy donne une bonne vue (graphique) d’un document WSDL (ici celui du slide précédent).Une version complète d’évaluation (30 jours) est disponible sur http://www.altova.com.

WEB

SERVICES

27

UDDI (1/2)UDDI (Universal Description, Discovery and Integration) est un standard ayant pour but la création d’un annuaire distribué de services web.

Cet annuaire contient :

• 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.

WEB

SERVICES

28

UDDI (2/2)

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).

______________

Le slide suivant présente un scénario complet. 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.

WEB

SERVICES

29

UDDI + WSDL + SOAP : vue d’ensemble

ServeurUDDI

EntrepriseA

WS

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

1

L’entreprise A publie WS

2

Le serveur UDDI renvoie l’adresse de WS (plus d’autres info comme la description du service. cf plus loin)

4

EntrepriseBL’entreprise B, à la recherche d’un service du

type WS, envoie une demande de recherche au serveur UDDI

3

L’entreprise B invoque WS

5

L’entreprise A répond à B

6

WEB

SERVICES

30

Conclusions de la première partie

• 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 ;

• SOAP peut faire des RPC, mais pas que des RPC ;

• 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.

WEB

SERVICES

31

Les offres du marché

Le marché des services web est très fourni : la plupart des éditeurs proposent des kits de développement.

Le premier à proposer les services web au cœur de son architecture a été Microsoft, avec la plate-forme .NET.

Le monde Java a bien réagi bien que les spécifications J2EE de l’époque (version 1.3) ne parlaient aucunement de services web. Ils y ont été introduits dans la version 1.4.

Tous les éditeurs du monde Java proposent leur kit pour les services web :

• Borland pour BES ;• Oracle pour 10gAS ;• BEA pour WebLogic ;• IBM pour WebSphere;• …

De nombreux projets Open Source existent également, comme par exemple l’API Axis utilisée en TP.

WEB

SERVICES

32

La sécurité des services web (1/4)A la vue du contenu des messages issus des services web, il est important de disposer de mécanisme de sécurité assurant l’authentification, l’intégrité et l’authenticité des données.

La sécurité d’un service web peut se faire à deux niveaux :

• « applicatif » : sur la couche SOAP par exemple ;

• au niveau réseau.

L’avantage de pouvoir passer les firewalls donnent aux hackers de nouveaux points d’entrée dans le système d’information de l’entreprise ; ce qui peut leur permettre par exemple de lancer une attaque de déni de service sur le serveur.

De plus, les messages étant codés en XML, les méthodes et procédures proposées par une entreprise transitent « en clair » sur le réseau, ce qui constitue une indication pour les pirates.

A la vue de l’architecture des services web, il apparaît que la problématique de sécurisation est la même que celle d’un site web car les données transitent (dans la plupart des cas) sur HTTP.

On peut donc dans un premier temps mettre les mêmes solutions de sécurité que celles utilisées pour les sites web, à savoir le protocole SSL.

WEB

SERVICES

33

Seuls le client et

le serveur peuvent

déchiffrer ces messages

La sécurité des services web (2/4)Le protocole SSL a été développé par Netscape. Permettant le cryptage des données, il est très utilisé sur Internet pour faire transiter des informations sensibles (par exemple un numéro de carte de crédit).

Il est à noter que l’organisme de normalisation IETF l’a renommé TLS.

Le protocole HTTP s’utilisant avec le protocole SSL devient HTTPS. Le port par défaut n’est plus 80 mais 443.

SSL est basé sur la cryptographie. Il fonctionne grâce à un système de clés publiques et de clés privées.

1 - Le client initialise une connexion (non cryptée, port 443 par défaut)

2- Le serveur renvoie une clé de cryptage (sa clé publique). Cette requête n’est pas cryptée.

3 – Le client génère une chaîne de 46 octets et la crypte avec la clé publique du serveur. Seul le serveur (possédant la clé privée) peut

décrypter ce message.

4 - Le serveur décrypte la chaîne de 46 octets qui est utilisée pour créer des clés de cryptage utilisées pour le reste de la session

5 - Les données transitant sont cryptées

WEB

SERVICES

34

La sécurité des services web (3/4)

SSL permet grâce aux clés publiques et privées d’encoder les messages, mais ne permet pas d’identifier le serveur.

En effet, au moment de l’initialisation du protocole SSL (étape 2) sur le slide précédent, n’importe qu’elle serveur pirate peut se faire passer pour le serveur interrogé par le client et renvoyer une clé publique.

Pour palier ce problème, les certificats ont été mis en place.

Un certificat est un objet verrouillé qui contient l’identité d’un serveur ainsi que sa clé publique. Il est encrypté avec la clé privée de l’organisme qui le délivre (comme Verisign par exemple).

Quand un client se connecte à un site, il demande à l’organisme des certificats de vérifier l’identité du serveur (grâce au certificat envoyé par le serveur).

Cela permet d’avoir avec HTTPS l’authentification ainsi que le cryptage des données.

WEB

SERVICES

35

La sécurité des services web (4/4)La sécurité des services web peut également se faire sur des couches plus basses (couches réseaux). Grâce à des règles définies sur des firewalls, on peut par exemple autoriser l’accès à un service web seulement à des clients ayant des adresses IP connues.

Certains constructeurs/éditeurs de firewalls ajoutent des règles de filtrage de messages SOAP, qui peuvent grâce à des entêtes SOAP vérifier qu’un consommateur d’un service est autorisé à y accéder.

Des protocoles spécifiques sont en cours d’élaboration. Microsoft a proposé au W3C le protocole WS-Security qui permet l’identification des utilisateurs, l’intégrité des messages SOAP ainsi que le chiffrement des données. WS-Security est basé sur XML Signature (authenticité de l’utilisateur) et de XML Encryption (encodage des données).

Un exemple avec le protocole WS-Security (source : http://msdn.microsoft.com)

WEB

SERVICES

36

Les faiblesses des services web

• Les protocoles HTTP et TCP ne proposent pas de qualité de services ;

• Le protocole HTTP ne permet pas de savoir si une requête a bien été transmise au serveur, s’il a répondu, …

• Le protocole HTTPR (HTTP Reliable), proposé par IBM, garantit que les messages sont bien acheminés en renvoyant un accusé de réception ;

• Une solution à ces problèmes : disposer d’une ligne louée entre les deux points où des messages SOAP circulent. Cette solution fonctionne très bien, mais est coûteuse et ne met pas en valeur les avantages des services web ;

• Les solutions de sécurités propres aux services web sont immatures.

WEB

SERVICES

37

Services web : passé, présent, futur

2001 2002 2003 2004 2005 2006 2007

Marché ouvertRéférencement et fourniture de services électroniques dans un annuaire global.

Partenaires de confiance externeServices web utilisés par une entreprise pour s’engager avec des partenaires externes de confiance.

Premier usage

Entrée en vigueur

Approche définitivement acceptéeSources:Gartner Group & 01 Informatique

Applications internesServices web utilisés pour intégrer les applications internes.

Décollage prévu…

WEB

SERVICES

38

Les services web dans l’industrie

e-Travel, une business entity d’Amadeus (250 personnes dans le monde), a choisi d’utiliser des web services.

« Nous avons proposé une implémentation SOAP de nos serveurs de données, pour répondre à la demande des compagnies aériennes qui ne voulaient pas de notre habillage graphique ». Denis Lacroix, Directeur R&D e-Travel (Décision Micro & Réseau, n° 254).

Dans cette architecture, e-Travel n’utilise pas de standard de sécurité spécifiquement lié aux services web, mais le protocole SSL pour encoder le flux de données.

e-Travel propose à ses clients la possibilité d’interroger son back-end grâce à des requêtes SOAP, dont une description XML Schema est fournie.

WEB

SERVICES

39

AXIS

• Axis est une API Java (Open Source) servant à créer et à consommer des services web;

• AXIS = Apache eXtensible Interaction System

• Site web : http://ws.apache.org/axis ;

• Supporte SOAP 1.1 et 1.2 partiellement ;

• Pas de support d’UDDI ;

• S’utilise avec n’importe quel serveur d’application J2EE (propose même un serveur HTTP pour fonctionner en mode stand-alone) ;

• Propose deux outils WSDL2Java et Java2WSDL permettant le mapping entre des services web et des classes Java, et vice-versa ;

• Dispose d’un outil de monitoring de requêtes ;

• Propose un méchanisme ulttra-simple de création de services web ;

• AXIS est l’API que nous allons utiliser pendant les TPs.

WEB

SERVICES

40

AXIS : invocation dynamique d’un service web• AXIS implémente la spécification JAX-RPC

WEB

SERVICES

41

AXIS : utilisation de WSDL2Java

WSDL2Java permet de représenter un service côté client. A la différente de l’invocation dynamique, cela permet de :

• passer les arguments à la place de tableaux d’objets (cf exemple précédent) ;• avoir en retour l’objet attendu et non un objet « Object » à caster…

WSDL2Java génère :

Nom de la balise XML dans le document WSDL

Classe générée

<type> nom-type.java<porttype> nom-port.java

<binding> nom-portBindingStub.java<service> port-nameService.java

WEB

SERVICES

42

AXIS : utilisation de WSDL2JavaRelations entre les fichiers générés par WSDL2Java et séquence d’utilisation :

source : http://www.ociweb.com/javasig/knowledgebase/2002Sep/Axis.pdf

WEB

SERVICES

43

Un peu de sécurité dans la pratique (1/2)

Quels sont les attaques auxquelles un service web est exposé :

• Deni de service ;• Interception et manipulation des messages ;• Requête du client falsifiée ;• Réponse du serveur falsifiée ;• Tentative de lectures/écritures sur le système de fichiers du serveur.

-> Ces attaques ne sont pas spécifiques aux services web mais aux serveurs web !

A ces attaques, se rajoutent les attaques propres aux données XML :

• Envois de très gros documents XML (assimilée à un déni de service) ;• Déclarations d’entités récursives dans les headers XML ;• Déclarations d’entités pointant sur un fichier local.

source : documentation d’Axis

WEB

SERVICES

44

Un peu de sécurité dans la pratique (2/2)

Quelques options pour sécuriser un service web :

• Authentifier les clients (avec HTTPS par exemple) ;

• Ecrire du code sûr ;

• Recompiler Axis avec le simple nécessaire à l’exécution du service ;

• Renommer les outils exposés afin que personne ne sache que vous utilisez Axis (ou une autre API) ;

• Désactiver la génération automatique des fichiers WSDL ;

• Filtrer les accès via les adresses IP ;

• Logger les accès ;

• Lancer le serveur web et Axis avec des droits réduits ;

• ...

WEB

SERVICES

45

La mobilité et les services web (1/2)

De nombreuses solutions permettent d’invoquer des services web depuis des clients mobiles (PDA PocketPC/Linux, téléphones J2ME).

Avec un OS Microsoft :

• .NET CF : la version pour terminaux mobiles de l’environnement d’exécution (runtime) de .NET intègre les API pour invoquer des services web ;

• PocketSOAP : client open source SOAP, disponible sous la forme d’un objet COM (également disponible pour win32) ;

En faisant du Java :

• J2ME Web Service API (JSR 172) : http://developers.sun.com/techtopics/mobility/apis/articles/wsa ;

• Oracle J2ME Web Service : cf slide suivant.

PS : ce n’est pas une liste exhaustive !

WEB

SERVICES

46

La mobilité et les services web (2/2)

Service webService webProxyProxy

L’approche d’Oracle pour la consommation de services web depuis des applications J2ME :

exemple d’appel d’un service web « Addition »

SOAP/HTTPadd 3 4

7

Un proxy se charge de la communication avec le service web afin d’en cacher la complexité au client J2ME. Ce proxy doit être généré pendant le développement de l’application (depuis JDeveloper, IDE d’Oracle) ;

Le terminal mobile n’envoie donc que la chaîne de caractères « add 3 4 », ce qui lui évite de faire du traitement XML (coûteux).

WEB

SERVICES

47

Sujet URLServices Web avec SOAP, WSDl, UDDI, ebXML, …

http://www.amazon.fr/exec/obidos/ASIN/2212110472/171-1062886-285386939 € sur Amazon.fr

WebService(définition)

http://www-106.ibm.com/developerworks/webservices/library/ws-best1/?dwzone=webservices

Architecture des WebServices, d’après le W3C

http://www.w3c.org/2002/ws/arch/2/08/wd-wsa-arch-20020821.html

Design d’un document XML (choix attribut/élément)

http://java.sun.com/xml/jaxp/dist/1.1/docs/tutorial/overview/4_design.html

XML, le livre blanc http://www.application-servers.com/livresblancs/xml/ (nécessite la création d’un compte sur le site)

* http://www.google.fr ; http://groups.google.fr Les services web chez

Sunhttp://java.sun.com/webservices

Les services web chez Microsoft

http://www.microsoft.com/webservices

XML : des bases de données aux services

web

Auteur: Georges Gardarin – Editions Dunod

Présentation d’Axis http://www.ociweb.com/javasig/knowledgebase/2002Sep/Axis.pdf(par Mark Volkmann)

Ressources