1 / 47

F ABRICE C LARI - FABRICE.CLARI@GMAIL.COM

W EB S ERVICES XML SOAP, WSDL RPC avec SOAP AXIS …. F ABRICE C LARI - FABRICE.CLARI@GMAIL.COM. Sommaire. Pré-requis XML Espaces de noms ( namespaces ) XML Schema Services Web : définition SOAP Les protocoles de communications RPC avec SOAP WSDL UDDI Un scénario

candy
Télécharger la présentation

F ABRICE C LARI - FABRICE.CLARI@GMAIL.COM

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. WEBSERVICES XML SOAP, WSDL RPC avec SOAP AXIS … FABRICE CLARI- FABRICE.CLARI@GMAIL.COM

  2. Sommaire • Pré-requis • XML • Espaces de noms (namespaces) • 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

  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>

  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.

  5. Introduction à XML (3/4) Problème : la balise <titre> contient deux types d’informations. • 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 disquesUn décrivant ses livres <?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> <?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>

  6. Introduction à XML (4/4) Ces URI ne sont pas vérifiées. En général, elles pointent sur la grammaire de l’espace de noms. 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. <?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>

  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>

  8. Web Services : une définition • De multiples définitions de la notion de Web Servicesexistent, 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.

  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

  10. Le protocole SOAP (1/6) Enveloppe SOAP En-tête SOAP (header) Corps du message SOAP (body) 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 XML composé d’une enveloppe qui contient une entête et le corps du message.

  11. Le protocole SOAP (2/6) <Envelope> <Header> <Transaction>3<Transaction> </Header> <Body> <echoString> <arg0>Hello!</arg0> </echoString> </Body> </Envelope> 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. 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’enveloppe contient tout le message Prenons l’exemple d’un message SOAP appelant une méthode echoString(string), qui prend en paramètre une chaîne de caractères.

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

  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.

  14. Le protocole SOAP (5/6) • 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. <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>

  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

  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.

  17. La couche de transport (2/5) : HTTP Exemple : un navigateur web souhaite obtenir la page par défaut du site www.google.fr Serveur Web (Apache) Client HTTP (Internet Explorer) Ouverture d’une socket sur le port 80 (port par défaut) GET / HTTP/1.0 HTTP/1.0 200 OK Content-Length: 3403 Server: GWS/2.0 Date: Mon, 14 Oct 2002 06:31:35 GMT Content-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 : • Ouverture de la socket (en TCP) sur le port 3128 de tango ; • Envoie de la requête : GET http://www.google.fr HTTP/1.0 • Le proxy se connecte à son tour à google.fr ; • Une fois que le proxy a obtenu le résultat, il répond au client.

  18. La couche de transport (3/5) : HTTP • 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 • 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).

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

  20. La couche de transport (5/5) • 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 • Cache-Control: no-cache • Pragma: no-cache • SOAPAction: http://tempuri.org/echo • Content-Length: 453 • puis est envoyée la requête. Obligatoire pour requête SOAP sur HTTP

  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.

  22. RPC (2/2) Service RPC Service RPC Réseau Code de l’appelant STUB Protocole réseau Protocole réseau SKELETON Code du serveur • Chaque RPC à son protocole de communication: • IIOP pour Corba ; • ORPC pour DCOM ; • JRMP pour RMI ; • et HTTP, SMTP, … pour SOAP ! Serveur Client Une architecture distribuée • 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.

  23. RPC avec SOAP • 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.

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

  25. WSDL (2/3) Décrit les messages qui circulent Abstraction décrivant une opération Protocole d’accès et format des messages Définit comment est disponible (SOAP) la méthode et à quelle adresse 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"/> </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>

  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.

  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.

  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 : • Publication d’un service web par une société ; • Recherche d’un service web ; • Découverte d’un service web ; • Consommation d’un service web.

  29. UDDI + WSDL + SOAP : vue d’ensemble Entreprise A 1 L’entreprise A développe et déploie un service web (WS) WS L’entreprise A répond à B 6 5 Entreprise B L’entreprise B invoque WS 2 L’entreprise A publie WS L’entreprise B, à la recherche d’un service du 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

  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.

  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.

  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.

  33. La sécurité des services web (2/4) 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. Seuls le client et le serveur peuvent déchiffrer ces messages 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 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.

  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.

  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)

  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.

  37. Services web : passé, présent, futur 2002 2003 2004 2005 2006 2007 2001 Applications internes Services web utilisés pour intégrer les applications internes. Partenaires de confiance externe Services web utilisés par une entreprise pour s’engager avec des partenaires externes de confiance. Marché ouvert Référencement et fourniture de services électroniques dans un annuaire global. Premier usage Entrée en vigueur Décollage prévu… Approche définitivement acceptée Sources: Gartner Group & 01 Informatique

  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.

  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.

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

  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 :

  42. AXIS : utilisation de WSDL2Java Relations entre les fichiers générés par WSDL2Java et séquence d’utilisation : source : http://www.ociweb.com/javasig/knowledgebase/2002Sep/Axis.pdf

  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

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

  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 !

  46. La mobilité et les services web (2/2) L’approche d’Oracle pour la consommation de services web depuis des applications J2ME : exemple d’appel d’un service web « Addition » Proxy Service web add 3 4 SOAP/HTTP 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).

  47. Ressources

More Related