Conception et développement d'un service web pour la recherche d'objets immobiliers

Transcription

1 Université de Fribourg, Suisse Département d'informatique Bachelor en informatique de gestion Travail de Bachelor Sujet: Conception et développement d'un service web pour la recherche d'objets immobiliers Présenté par: Oscar Mora Via alla Peschiera Locarno Suisse Encadré par: Dr. Stefan Hüsemann Septembre 2007

2 A mes proches Merci pour le soutien continu ii

3 iii Résumé Dans le cadre de ce travail de Bachelor, l'auteur applique les connaissances apprises au cours de systèmes d'informations du professeur S.Hüsemann au problème de la recherche d'objets immobiliers. Ce travail s'articule en deux parties: La première partie présente les aspects théoriques des services web: dans un premier temps, l'auteur étude l'évolution des services web avant d'en présenter les technologies principales. La deuxième partie du travail est dédiée à l'analyse et la conception d'un modèle orienté service web capable de résoudre les problèmes actuels dans la recherche des objets immobiliers. Dans cette partie l'auteur développe aussi les applications qui démontrent le modèle étudié.

4 iv Remerciements Je tiens à remercier tous ceux qui ont contribué au développement de ce projet. En particulier je remercie M. Stefan Hüsemann pour la patience démontrée et pour le temps qu'il m'a consacré. Je tiens aussi à remercier mes proches pour m'avoir aidé et motivé jusqu'à la fin de mes études de bachelor. Pour la partie pratique je remercie M. Philippe Jorand de Quorum Software SA pour la documentation technique et le support. Je tiens également à remercier M. Felix Kaufmann de la Régie Estudiantine (REST).

5 v Table des matières I. Introduction Motivations Objectifs du travail Questions traitées A qui s adresse le travail?... 3 II. Les Services Web Théorie et principes des services web Qu'est-ce que un service web? Histoire des services web Le contexte L'histoire de XML L évolution des services web Technologies de base des services web Web Service Stack Extensible Markup Language Simple Object Access Protocol Web Service Description Language Universal Description Discovery and Integration Autres Standards Protocoles de package Protocoles de description Protocoles de recherche/découverte Protocoles de sécurité Protocoles de transport Protocoles de routage et workflow Langages de programmation et plateformes Sécurité Terminologie Web Service Security Le modèle de sécurité Le Security header Username Token Conclusion Théorie... 52

6 vi III. Travail pratique Introduction Le problème de la recherche d'objets immobiliers Les portails dédiés Homegate et Immoscout Fonctionnement et limites des portails dédiés Situation aux Etats-Unis et au Canada Multiple Listing Service (MLS) Real Estate Transaction Protocol (RETS) Solution proposée Modèle Fonctionnement Avantages Limites Architecture Implémentation Code-First ou Contract-First? Outils ImmoOne ImmIntegrator Démonstration Conclusion travail pratique IV. Références V. Annexes Annexe A: Interview Quorum Software Annexe B: Structure des objets dans Quorum Software Annexe C: Structure des objets dans Homegate.ch Annexe D: Code source de immone/ws/server.php Annexe E: Code Source de immintegrator/index.php Annexe F: Code Source de ClientClass.php Annexe G: Guide d'installation... 99

7 vii Liste des figures Figure II-1: Service Web [Snell 2002, p1]... 6 Figure II-2: Relation entre UDDI, WSDL et SOAP [Site 9] Figure II-3: Web Service Stack Figure II-4: Ecran de validation de XMLSpy Figure II-5: Structure de l'enveloppe SOAP [Snell p13] Figure II-6: Chemin d'un message SOAP [Snell, p23] Figure II-7: SOAP via http [Snell, p34] Figure II-8: Structure d'un document WSDL [Site 20] Figure III-1: Utilisation des différents sites web des régies immobilières Figure III-2: Utilisation d'un intégrateur ordinaire Figure III-3: Modèle de recherche orienté service web Figure III-4: Architecture de la solution Figure III-5: Fichier WSDL du service web Figure III-6: Structure base de données de ImmOne Figure III-7: Visualisation d'un objet immobilier dans ImmoOne Figure III-8: Structure du service web dans ImmoOne Figure III-9: Structure des scripts du ImmIntegrator Figure III-10: Interface de ImmIntegrator Figure III-11: Requête SOAP générée par SoapUI Figure III-12: Réponse SOAP reçu par SoapUI... 72

8 viii Liste des codes code II-1: déclaration XML code II-2: Elément simple code II-3: Elément avec attribut code II-4: Description d'un objet immobilier code II-5: XMLSchema d'un objet immobilier code II-6: Objet immobilier invalide code II-7: Exemple de requête SOAP via HTTP [Site 13] code II-8: Exemple de réponse SOAP [Site 13] code II-9: exemple de requête SOAP RPC style [site 14] code II-10: Exemple de requête avec SOAP Document style [Site 14] code II-11: Exemple d'extension d'erreur SOAP code II-12: Exemple d'erreur personnalisé SOAP code II-13: Ciblage d'un En-tête code II-14: WSDL file [Site 19] code II-15: Syntaxe et position de l'en-tête de sécurité code II-16: Syntaxe de l'élément UsernameToken code II-17: exemple avec PasswordText code II-18: exemple avec PasswordDigest code III-1: Fonction GetListing en PHP code III-2: Enregistrement de la fonction GetListing avec paramètres et types code III-3: Création des clients code III-4: Impression des résultats dans une table... 71

9 ix Liste des tableaux tableau II-1: Sous-éléments définies dans l'élément Fault tableau II-2: Erreurs standard SOAP tableau II-3: Éléments principales d'un document WSDL [Site 19] tableau II-4: Différences entre les 3 types d'annuaires UDDI [Site 23, p5] tableau II-5: Éléments et attributs relatifs à l'en-tête de sécurité [Site 35, pp 22-23] tableau II-6: Éléments et attributs relatifs le Username Token [Site 36, pp 8-9]... 48

10 x Conventions Les exemples Lorsque c'est nécessaire d expliquer des concepts à l aide d exemples de code on utilise le format suivant: <?xml version.> <code> <subelement>i am an element</subelement> </code> Ressources Externes À la fin de certains chapitres (et aussi bien à l'interne) il arrive de trouver des références à des liens externes. Ces ressources sont proposées pour étudier les aspects exclus ou qui n ont pas étés présentés en détail. Domaine Ressource 1 Ressource 2

11 I Introduction 1 I. Introduction

12 I Introduction 2 1 Motivations En tant que futur informaticien de gestion j ai tout de suite montré intérêt au monde des services web. D un coup les experts informaticiens (et pas seulement eux) ont commencé à parler de la puissance de cette technologie et quelques uns les ont même présentés comme la vraie révolution de l Internet [Site 1]! On ne sait pas encore si cette dernière affirmation est vraie, car la technologie n'est pas assez mûre [Site 2]. Il existe encore beaucoup de problèmes au niveau de la sécurité et c est surtout grâce à la communauté qui travaille constamment à l amélioration des protocoles et des standards qu on atteint des niveaux de sécurité et de stabilité toujours plus élevés. Le fait qu'ils représentent ou pas la révolution d'internet ce n'est pas relevant: les services web ont un très grand potentiel et ce n est pas un cas qu entreprises telles que Microsoft, IBM et Sun Microsystems aient investi énormément de moyens pour les développer et les faire connaître [Site 3]! Avec ce travail je veux analyser en détail ce domaine pour avoir une idée claire des avantages et désavantages que cette technologie offre dans la pratique. 2 Objectifs du travail Le but de ce travail est, dans une première partie, de présenter les aspects de base des services web et d analyser en détail les standards les plus importants pour pouvoir commencer à créer des applications orientées service. Dans la deuxième partie on passera à l action en appliquant les notions apprises au problème de la recherche d objets immobiliers. Avant de commencer avec la théorie il faut préciser que ce travail n est pas dédié à XML ou à des langages de programmation spécifiques. D autre part, pour des raisons de clarté on présentera rapidement les aspects de XML nécessaires à la compréhension des standards basés sur ce dernier.

13 I Introduction 3 3 Questions traitées Du point de vue théorique ce travail répond aux questions relatives les services web, telles que: 1. Qu'est-ce qu'un service web? 2. Quelles sont les standards utilisés dans les services web? 3. Quels sont les avantages des services web? 4. Quels sont les problèmes qui doivent encore être résolus dans le domaine des services web? 5. Comment ont-ils évolués les services web? 6. À quel point on en est avec la sécurité dans le domaine des services web? Dans la partie pratique les questions principales sont: 1. Comment peut-on améliorer la recherche d'objets immobiliers? 2. Est-ce que les services web sont l'outil adéquat? 3. Quels sont les standards d'échange dans le domaine immobilier? 4 A qui s adresse le travail? Ce document est adressé aux étudiants en informatique et en informatique de gestion qui sont intéressés au domaine des services web et aux technologies qui y sont liées. Pour cette raison tout le long du document le lecteur trouvera des exemples permettant l assimilation des notions théoriques de façon plus intuitive et chaque exemple ou partie de code peut être aussi repéré dans le cdrom. D autre part, le travail pratique s adresse principalement aux acteurs du marché immobilier qui voient dans les services web une approche intéressante pour résoudre des problèmes de caractère technique. Il faut quand même dire que cette partie est présentée comme un cas d étude et elle permet aux étudiants de fixer les connaissances théoriques apprises tout au cours de la lecture.

14 II Les Services Web 4 II. Les Services Web

15 II Les Services Web 5 1 Théorie et principes des services web Ce premier chapitre explique de façon claire les services web. Dans une première partie on répond à la question : "Qu'est-ce que c'est exactement un service web?" Après la définition et les explications nécessaires on trouve un sous-chapitre décrivant l'évolution des services web (le lecteur comprendra que l'idée en question n'est pas nouvelle!). C'est après ce voyage dans le temps que tout devient un petit peu plus technique: on verra les différentes technologies et protocoles qui permettent l'existence des services web et on analysera la façon dont ces technologies sont reliées les unes avec les autres. De plus, l étude des différents langages avec une approche "bottom-up" nous aidera à construire les connaissances nécessaires à comprendre le cas d étude Qu'est-ce que un service web? Même si cette question peut paraître très simple, il n'existe pas une réponse facile. Dans les différents sites web dédiés à ce domaine de l'informatique et dans les sources de cet ouvrage, il existe beaucoup de réponses hétérogènes. Certains auteurs clarifient les aspects théoriques, d'autres focalisent l'attention sur les différents protocoles qui en permettent l'existence et d'autres enfin proposent des définitions génériques [Iverson 2004, p1]. Il est souvent difficile d'avoir une idée claire à première vue et les différents lecteurs peuvent être désorientés par des définitions trop techniques et pleines de termes spécifiques. Par contre, il faut éviter une définition trop générique, qui peut laisser place à une incompréhension partielle du domaine en question et causer des problèmes lors d'un étude plus détaillé. Dans cette optique il est donc mieux d'éviter des termes comme SOAP, UDDI et WSDL (on en parlera après) et passer directement à une définition simple et au même temps précise. "Un service web est une interface pour une application accessible par réseau construite en utilisant des technologies standards de l'internet." [Snell 2002, p1]

16 II Les Services Web 6 Bien que cette explication est très courte elle contient toutes les informations dont on a besoin pour avoir une vision plus claire des services web. Interface La Figure II-1 montre clairement le rôle d'interface qui est propre aux services web. Cette interface est placée entre l'application et l'utilisateur de façon à offrir une couche d'abstraction permettant la séparation de la plateforme et du langage de programmation du code qui invoque la fonctionnalité. Figure II-1: Service Web [Snell 2002, p1] Technologies standard Pour que les deux applications puissent communiquer il faut un langage commun, et XML est bien sûr un candidat idéal grâce à sa puissance et extensibilité. Dans le sous-chapitre 1.3 on verra quels sont les standards dérivés de XML permettant la communication entre le client et le serveur. Internet Maintenant qu'on a définit le rôle d'un service web et on sait (très superficiellement) comment les application communiquent il faut trouver un canal pour mettre en place la communication réelle. À ce propos il existe un canal très développé et expérimenté: l'internet. Plus précisément le protocole qui permet aux différents messages de voyager d'une application vers une autre est le HTTP. Mais, comme on le verra dans les chapitres suivants, ces messages peuvent être échangés en utilisant d autres protocoles (comme le SMTP par exemple). Maintenant une définition plus complète peut être exprimée. Et quelle est la meilleure si non celle du W3C? [Site 4]

17 II Les Services Web 7 A Web service is a software system identified by a URI, whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML based messages conveyed by Internet protocols. Comme on le voit donc, cette définition contient toutes les informations dont on a parlé précédemment et en ajoute des nouvelles. La définition de Snell inclue les concepts d'interface, de XML (technologies standard) et des protocoles internet. Cette nouvelle définition, cependant, ajoute le fait qu'un service web est identifié par un URI (Universal Resource Identifier) et qu'il peut être découvert par d'autres systèmes (souvent grâce aux registres UDDI et au langage WSDL dont on parlera après).

18 II Les Services Web Histoire des services web Maintenant on sait qu est-ce que un service web et on sait aussi quels sont les standards nécessaires à leur fonctionnement. Mais il est autant intéressant de connaître leur provenance pour apprendre au mieux leur potentiel et pour en prévoir l évolution. Ce sous-chapitre introduit le contexte dans lequel se trouvent les services web et parcourt les différentes étapes qui ont amené à la situation actuelle Le contexte Evidemment le contexte des services web est l Internet. C est l évolution du réseau global qui a permis la naissance de nouvelles architectures et de nouveaux langages pour les implémenter. Mais le fait le plus important dans le domaine des services web a été le changement d'une approche hommemachine, vers une approche machine-machine. Cette révolution a introduit le besoin de standardiser la description de la structure de n'importe quel document. C'est là que XML entre en jeu! L'histoire de XML Les bases de XML reviennent 30 ans à l arrière, quand le chercheur de IBM Charles Goldfarb introduisait le concept de Markup (marquage). Ce premier pas était alors connu sous le nom de GML [Site 5]. Mais il fallait quand même attendre les années 80 pour que, grâce à ISO 1, une version internationale standardisée fût présentée au monde. La version finale de ce meta-langage a été présentée en 1986 sous le nom de SGML [Site 6] (ce langage est encore utilisé). Nonobstant la standardisation, avec le web les paramètres avaient beaucoup changés, et - grâce à l adoption comme meta-langage standard par le W3C dans les années 90 HTML fit sa rentrée! Il est intéressant de noter le fait que HTML est un dérivé de SGML et que c est la simplicité par rapport à son "père" (considéré trop complexe) a en avoir rendu le standard pour la présentation des pages web. 1 International Organization for Standardization

19 II Les Services Web 9 Mais l'évolution de l'internet était très rapide et on a rapidement compris la nécessité d'un outil plus puissant, capable de fournir des fonctionnalités comme la réutilisabilité des informations ou l'échange de ces dernières entre différents systèmes hétérogènes. À ce propos tout le monde était d'accord sûr le fait que le SGML était parfait pour ces exigences, mais il fallait le rendre plus simple à apprendre, à comprendre et à l'implémenter, tout en préservant ces idées fondamentales. [Site 7] Pour répondre à ces besoins, le W3C formait en 1996 le SGML Editorial Review Board (successivement appelé XML Working Group) que, avec la participation active du SGML Working Group (successivement appelé XML Special Interest Group) travaillait au nouveau langage. Les bases de ce projet se résument en 10 objectifs: 1. XML doit pouvoir être utilisé sans difficulté sur Internet 2. XML doit soutenir une grande variété d'applications 3. XML doit être compatible avec SGML et HTML 4. Il doit être facile d'écrire des programmes traitant les documents XML 5. Le nombre d'options dans XML doit être réduit au minimum, idéalement à aucune 6. Les documents XML doivent être lisibles par l'homme et raisonnablement clairs 7. La spécification de XML doit être disponible rapidement 8. La conception de XML doit être formelle et concise 9. Il doit être facile de créer des documents XML 10. La concision dans le balisage de XML est peu importante Finalement, le 10 février 1998, les objectifs ont été tous respectés et le XML 1.0 naquit.

20 II Les Services Web L évolution des services web La naissance des services web est due à beaucoup de facteurs. Cette section résume les points les plus importants de l'article "The Past, Present and Future of Web Services" de Uche Ogbuji [Site 8]. Les applications distribuées sont nées quand la computation typique s'est déplacée des mainframes vers les réseaux des minicomputers et PC. Au début les managers IT ne devaient pas se préoccuper de la coopération entre les ordinateurs, car il n'existaient pas des connexions entre les différents mainframes, et quand il était vraiment nécessaire d'échanger des informations les EDI (Electronic Data Interchange) étaient des unités complètement séparées. L'age des minicomputers est un peu ignorée (peut être à cause de la révolution des PC, qui n'ont pas vraiment contribué aux systèmes répartis jusqu'à l'age de l'internet) mais c'est à eux qu'on doit les bases des services web. La distribution de services entre les différents minicomputers requit beaucoup d'approches différentes pour communiquer de façon soit synchrone qu'asynchrone. Le résultat est que les grandes architectures et systèmes opérationnels des ces temps (HP et Sun) ont développées des technologies de messages distribués stupéfiantes. À ce point une nouvelle génération de technologies de calcul distribuées était prête. Dans les grandes entreprises la computation était déplacée vers les différents départements (en abandonnant le centre de calcul) et l'intégration (non plus au niveau des plateformes mais au niveau du réseau) devenait donc très importante. Le secteur IT choisissait les objets comme standard de développement des applications (à cause des ses promesses sur la réutilisabilité, sur la maintenance et sur le Return On Investment). Les technologies distribuées, elles aussi, furent orientées dans ce sens. En parallèle et le Web se montraient comme les technologies distribuées les plus stables et les designers et développeurs cherchaient donc des technologies avec des caractéristiques similaires.

21 II Les Services Web 11 Aux portes du nouveau millenium les bases pour une nouvelle technologie de systèmes repartis étaient prêtes. Cette nouvelle technologie était basée sur les besoins des systèmes d'information et sur les expériences des technologies des réseaux: Il fallait supporter les opérations reparties à l'intérieur des applications et les services génériques entre applications. Il fallait supporter les échanges à l'intérieur de l'entreprise et ceux entre différentes entreprises; tout en respectant le concept de "cross-platform". La nouvelle technologie devait utiliser les standards de l'internet. Elle devait supporter à plein la scalabilité Elle devait supporter à plein l'internationalisation. Elle devait être "Fault-tolerant". Les développeurs et les managers devaient avoir un très riche support des différents revendeurs. Il devait être possible d'échanger facilement messages simples et messages complexes dans un environnement sécurisé (où nécessaire). La première entreprise à encadrer ces besoins était HP et elle commençait au début des années 90 à travailler sur ces problèmes. En 1999, elle lançait sur le marché e-speak, qui peut être considérée la première technologie orienté service (elle utilisait HTTP et XML). Une autre entreprise qui a lancé un produit très important est Useland avec son XML-RPC. Cette technologie était très simple, mais c'est justement cette simplicité (trop de limitations) qu'en a limité son usage à la seule communauté Open Source. En 1999 arrivait aussi SOAP, qui permettait un échange de messages beaucoup plus complet que les autres. Maintenant les services web sont en traîne d'évoluer dans toutes les directions et on voit aussi des standards s'affirmant et d'autres disparaître.

22 II Les Services Web Technologies de base des services web Les services web existent fondamentalement grâce à XML. Le extensible Markup Language est la colle qui permet la communication entre les différentes applications écrites dans différents langages de programmation. C'est grâce à XML que des standards comme UDDI, WSDL et SOAP (pour en citer quelques uns seulement) sont nés. Cette section présente brièvement l'architecture des services web et le Web Service Stack. Dans un deuxième temps on a un aperçu de XML et on analyse dans les détails SOAP. WSDL et UDDI seront montrés rapidement Web Service Stack Les services web se composent d'une collection de standards que l'on regroupe sous le nom de Web Service Stack. Les principaux protocoles qui formaient la spécification initiale des services web sont: Simple Object Access Protocol (SOAP) définit les messages qui contiennent la requête et la réponse d un service. Il est indépendant de n importe quel moyen de transmission. Web Service Description Language (WSDL) décrit un service web et la forme du message SOAP nécessaire pour effectuer les requêtes. Universal Discovery, Description and Integration (UDDI) c est le résultat d une coopération entre plusieurs entreprises avec le but de fournir un outil d organisation et de recherche pour les services web. Ces protocoles sont maintenant universellement acceptés et sont donc des standards de facto. La Figure II-2 montre l interaction des trois technologies.

23 II Les Services Web 13 Figure II-2: Relation entre UDDI, WSDL et SOAP [Site 9] Pour comprendre cette image imaginons qu'un informaticien veut développer un système d'informations boursières. Dans ce système il veut montrer l'évolution de certaines actions. Tout ce qu'il doit faire c'est utiliser UDDI pour interroger un registre qui lui permet de trouver un fournisseur de tel service Quand la recherche est terminée, l'informaticien pourra connaître la structure des messages SOAP nécessaires pour l'utilisation du service grâce à la description WSDL donnée par le fournisseur. Ces trois standards ont permis le développement initial des services web et ils ont incités beaucoup d entreprises à leur utilisation. Cependant, à cause des problèmes de sécurité et de fiabilité, du besoin croissant de décrire et implémenter nouveaux et plus complexes scénarios de business, plusieurs autres standards ont été proposés. Certains se sont affirmés, d autres sont disparus et d autres encore ont étés réunis pour en augmenter leur puissance. [Site 9] La situation est en évolution continue et il existe différentes vues de la pile (quoique elles se ressemblent toutes). La Figure II-3 montre la vision de la pile des protocoles actuels donnée par le W3C [Site 10]

24 II Les Services Web 14 Figure II-3: Web Service Stack Tout en bas on trouve les protocoles nécessaires à la transmission de messages dans le réseau (HTTP, SMTP, FTP, etc.). En vert on voit les technologies de base qui permettent l'existence des standards qui se trouvent au niveau supérieur (XML sur toutes). Basés sur les technologies décrites en vert, on trouve dans l'ordre les standards pour la construction et l'échange des messages (SOAP), ceux pour la description des services web (WSDL) et enfin ceux nécessaires pour les processus liés aux services web (Recherche, agrégation, etc.). Tout autour de cette pile centrale se trouvent les standards concernant la sécurité ou la gestion. Ces standards sont en effet logiquement placés à tous les niveaux pour avoir différents dégrées de sécurité. Comme déjà dit au début de cet ouvrage, on ne va pas décrire tous les protocoles et standards (cela serait assez long). L'attention sera dédiée a ceux nécessaires pour le fonctionnement de base des services web (UDDI, WSDL, SOAP). De plus, le chapitre 2 présentera la couche de la sécurité. Les prochaines sections présentent les principaux standards cités en précédence avec une approche "bottom-up". C'est-à-dire qu'on commence par étudier les technologies de base qui permettent de comprendre les autres standards de plus haute niveau.

25 II Les Services Web Extensible Markup Language Tout le monde a déjà entendu parler de XML. C'était le candidat numéro 1 pour être la technologie la plus appréciée durant les années 90 et elle l'est encore aujourd'hui [Myer 2005, p1]. Mais qu'est-ce que c'est exactement? Qu'est-ce que rend XML tellement spécial? Et, pourquoi est-il à la base des services web? Ce chapitre traitera de façon superficielle le langage. Dans une première partie on verra l'utilisation de XML pour décrire des documents, et dans une deuxième partie on verra son utilisation dans la description d'autres langages (dialectes) en affrontant les concepts de validité et de well-formedness. Définition "XML est un méta-langage permettant de marquer la structure de documents texte de manière arborescente en insérant des balises dans le corps des documents". [Site 11] C'est-à-dire qu'avec XML il est possible de décrire n'importe quelle structure de document en créant des balises personnalisées. Structure d'un document XML Un document XML est composé fondamentalement d'une déclaration XML, d'un élément racine (contenant tous les autres éléments) et des différents éléments et attributs. La déclaration XML Pour signaler qu'un document est décrit en utilisant XML il est nécessaire d'écrire la ligne suivant juste au début du document: <?xml version="1.0"?> code II-1: déclaration XML Grâce à cette indication n'importe quel dispositif sait qu'il est en traîne de lire un document XML.

26 II Les Services Web 16 Eléments Un élément consiste en une balise d'ouverture, ses attributs, le contenu et une balise de fermeture. Il n'y a pas de restrictions dans la définition d'éléments. Il faut quant même se rappeler qu'un élément doit avoir une balise de fermeture identique à celle d'ouverture (sauf pour le '/'). Voilà un exemple d'élément simple: Attributs <myelement>je suis un élément</myelement> code II-2: Elément simple Les attributs sont utilisés pour ajouter des informations sûr les éléments. Il n'existe pas une règle pour décider quelle information est un attribut et quelle est un élément. Une "règle" utilisée souvent est: "Si le contenu est grand, alors c'est un élément, sinon c'est un attribut". Mais il faut se rappeler: C'est le développeur qui décide son propre langage ou structure! Par exemple l'élément précèdent pourrait être modifié de la façon suivante pour en définir la langue (dans ce cas français): <myelement lang="fr">je suis un élément</myelement> code II-3: Elément avec attribut Le code II-4 est la description possible d'un objet immobilier utilisant les éléments et les attributs qu'on vient d'étudier. <?xml version="1.0"?> <object type="house" mode="sell"> <title>une belle maison</title> <address> <street>avenue du Silo 34</street> <zip>1020</zip> <city>renens</zip> <area>vd</area> <country>switzerland</country> </address> <price currency="chf"> </price> </object> code II-4: Description d'un objet immobilier Dans cette simplification l'élément <object> (élément racine) se réfère à l'objet immobilier qu'on est en traîne de décrire. Cet objet a deux attributs (type et mode) lesquels indiquent le type d'objet (maison, appartement) et la modalité du contrat (en vente, à louer). D'après on trouve les éléments fils <title>,

27 II Les Services Web 17 <address> et <price>. Grâce à la logique arborescente des documents XML l'élément <address> (élément complexe) peut avoir d'autres éléments fils (<street>, <zip>, etc.). XML pour décrire des dialectes XML n'est pas limité à décrire la structure des documents. En effet, on l'utilise aussi pour définir d'autres langages (dialectes), chacun avec ses propres règles. Même (X)HTML a été définit avec XML et il doit donc respecter de règles définies par le W3C. Jusqu'ici on n'a pas traité la validité ou le concept de "Well-formedness" (bien formé). Pour continuer dans l'étude de XML ces concepts doivent êtres clarifiés. Well-formedness Un document XML doit être bien formé. C'est-à-dire qu'il doit respecter les règles de syntaxe du langage. Il est, par exemple, obligatoire qu'un document ait un élément racine (contenant tous les autres éléments). De plus les attributs doivent êtres contenus entre guillemets (attribut="valeur"). Ils existent différentes règles à suivre pour respecter le principe de wellformedness mais elles ne seront pas traitées dans ce texte pour des raisons d'espace. À la fin de ce chapitre le lecteur trouvera les références nécessaires pour étudier à fond ces règles. Validité et validation La validité d'un document est vérifiée par rapport aux règles spécifiées soit dans un DTD (Document Type Definition) ou dans un XMLSchema. Le DTD est le vieux système de validation (on l'utilise encore) mais maintenant beaucoup des gens préfèrent les XMLSchemas car avec eux on a un contrôle plus profond sur les éléments. Dans une optique très superficielle le fonctionnement est le suivant:

28 II Les Services Web 18 Le XMLSchema définit certaines règles (comme, par exemple, "l'élément <object> doit avoir l'attribut mode, lequel peut avoir seulement les valeurs "rent" ou "sell". Le code II-5 définit un schéma pour les objets immobiliers. <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" elementformdefault="qualified" attributeformdefault="unqualified"> <xs:element name="object"> <xs:annotation> <xs:documentation>a real estate object</xs:documentation> </xs:annotation> <xs:complextype> <xs:all> <xs:element name="title"/> <xs:element name="address"> <xs:complextype> <xs:sequence> <xs:element name="street"/> <xs:element name="zip"/> <xs:element name="city"/> <xs:element name="area"/> <xs:element name="country"/> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="price"> <xs:complextype> <xs:attribute name="currency" type="xs:string" use="required" fixed="chf"/> </xs:complextype> </xs:element> </xs:all> <xs:attribute name="type" use="required"> <xs:simpletype> <xs:restriction base="xs:string"> <xs:enumeration value="house"/> <xs:enumeration value="apartment"/> </xs:restriction> </xs:simpletype> </xs:attribute> <xs:attribute name="mode" use="required"> <xs:simpletype> <xs:restriction base="xs:string"> <xs:enumeration value="sell"/> <xs:enumeration value="rent"/> </xs:restriction> </xs:simpletype> </xs:attribute> </xs:complextype> </xs:element> </xs:schema> code II-5: XMLSchema d'un objet immobilier

29 II Les Services Web 19 Une fois le schéma défini il est possible de valider un document. Pour valider un document par rapport à une grammaire (XMLSchema) il faut utiliser un parseur validant en lui fournissant soit le document XML soit une référence au schéma. Le code II-6 est un document invalide car l'attribut "mode" a une valeur autre que "rent" ou "sell". <?xml version="1.0" encoding="utf-8"?> <object xmlns:xsi=" xsi:nonamespaceschemalocation="myobjectschema.xsd" type="house" mode="rent_for_holidays"> <title>une maison de vacances</title> <address> <street>via alla Peschiera 1</street> <zip>6600</zip> <city>locarno</city> <area>ti</area> <country>switzerland</country> </address> <price currency="chf">2000</price> </object> code II-6: Objet immobilier invalide Grâce à l'exemple il est claire qu'on a ajouté deux nouveaux attributs à l'objet immobilier: xmlns:xsi indique la modalité avec laquelle on indique le schéma XML et l'attribut xsi: nonamespaceschemalocation indique le nom et le chemin du schéma. La Figure II-4 est l'écran de validation de l'outil Altova XMLSpy 2 Figure II-4: Ecran de validation de XMLSpy 2

30 II Les Services Web 20 Une fonctionnalité désirée de la création de nouveaux dialectes est la possibilité d'utiliser éléments définis dans des grammaires différentes. Cette caractéristique permet donc d'utiliser le travail d'autres personnes en évitant de recréer la roue! Evidemment l'utilisation d'éléments dérivantes des plusieurs grammaires pose les problèmes suivants: 1. au niveau de la validation d'un document, quel est le schéma à utiliser? 2. il est possible que deux grammaires utilisent le même nom pour éléments différents comment résoudre cette ambiguïté? La solution à ces problèmes sont les namespaces (espaces de nommage). Les Namespaces Les espaces de nommage XML (namespace) offrent une méthode simple pour qualifier les noms des éléments et des attributs utilisés dans des documents XML, en associant ceux-ci avec des espaces de nommage désignés par des références d'uri 3. Le chapitre qu'on vient de terminer n'est pas exhaustif. Pour continuer aisément la lecture de cet ouvrage (surtout pour la partie pratique) le lecteur est invité à étudier à fond l'xml (spécialement les espaces de nommage) et les XMLSchemas en utilisant les sources proposées. Ressources Externes Well- Formedness XMLSchema Namespaces

31 II Les Services Web Simple Object Access Protocol Définition SOAP est un protocole léger destiné à l'échange d'informations structurées dans un environnement décentralisé, distribué. Il utilise des technologies XML pour définir une structure d'échange de messages fournissant une construction de messages pouvant être échangés sur divers protocoles sous-jacents. La structure a été conçue pour être indépendante de tout modèle de programmation et autres sémantiques spécifiques d'implémentation. [Site 12] Plus en détail, la spécification du SOAP ne définit rien d'autre qu'une enveloppe contenant les informations à transmettre, et un set de règles pour la transformation des types des données spécifiques aux applications et aux plates-formes en représentation XML. SOAP est une application de XML et, de plus, il est fortement basé sûr d'autres standards XML comme XML Schema et les XML namespaces. Les messages SOAP Un message SOAP est constitué d'une enveloppe contenant deux parties: le Header(en-tête) (optionnel) le Body(corps) (obligatoire). La Figure II-5 montre la structure d'une enveloppe SOAP. Figure II-5: Structure de l'enveloppe SOAP [Snell p13]

32 II Les Services Web 22 Le SOAP namespace La syntaxe à utiliser pour les messages SOAP est définie dans les deux namespaces suivantes: Enveloppe: Sérialisation: Un exemple SOAP Le code II-7 est une requête SOAP envoyée via HTTP pour obtenir des informations sûr le prix d'une action auprès d'un service d'information boursière. POST /StockQuote HTTP/1.1 Host: Content-Type: text/xml; charset="utf-8" Content-Length: nnnn: SOAPAction: Some-URI" <SOAP-ENV:Envelope xmlns:soap-env=" SOAP-ENV:encodingStyle=" <SOAP-ENV:Body> <m:getlasttradeprice xmlns:m="some-uri"> <symbol>dis</symbol> </m:getlasttradeprice> </SOAP-ENV:Body> </SOAP-ENV:Envelope> code II-7: Exemple de requête SOAP via HTTP [Site 13] Le code II-8, par contre, est la réponse générée qui est envoyé au client. HTTP/ OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn <SOAP-ENV:Envelope xmlns:soap-env=" SOAP-ENV:encodingStyle=" <SOAP-ENV:Body> <m:getlasttradepriceresponse xmlns:m="some-uri"> <Price>34.5</Price> </m:getlasttradepriceresponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> code II-8: Exemple de réponse SOAP [Site 13]

33 II Les Services Web 23 Le modèle d'échange des messages SOAP Les messages SOAP sont normalement des transmissions en une seule direction, envoyées par un émetteur vers un destinataire. Mais, comme l'exemple précédente le montre, on implémente souvent un système de requête/réponse. Il existe deux façons d'implémenter le système de requête/réponse: le RPC style et le Document style. Au début SOAP supportait seulement le style RPC mais à partir de la version 1.0 les deux sont supportés. RPC Style Le style "RPC" (Remote Procedure Call) prévoit un message SOAP contenant le nom de la méthode qu'on veut utiliser avec une liste de paramètres. Quand le message arrive au serveur, la requête est transformée en méthode et une réponse contenant l'output est générée. Le style "RPC" est "tightly coupled" car le message est lié à la définition de la méthode! Le code II-9 montre une requête SOAP RPC style qui appelle la méthode GetStockQuote avec le parametre Symbol = ORCL. <SOAP-ENV:Envelope...> <SOAP-ENV:Body> <m:getstockquote xmlns:m="urn:xmethods:example"> <m:symbol>orcl</m:symbol> </m:getstockquote> </SOAP-ENV:Body> </SOAP-ENV:Envelope> code II-9: exemple de requête SOAP RPC style [site 14] Document Style Les service web avec style "Document" sont "loosely coupled". C'est à dire que le client envoie la requête et les paramètres au service dans un document XML. La structure de ce document n'est pas lié à la méthode et à ses paramètres. C'est l'application (le service) qui s'occupe de lire le document XML et appeler la méthode désirée. Le WS-I (Web Service Interoperability Organization) conseille l'utilisation du style "Document".

34 II Les Services Web 24 Le code II-10 montre la même requête que celle du code II-9 mais en style "Document". <SOAP-ENV:Envelope...> <SOAP-ENV:Body> <StockQuoteRequest symbol="orcl"/> </SOAP-ENV:Body> </SOAP-ENV:Envelope> code II-10: Exemple de requête avec SOAP Document style [Site 14] Une application SOAP doit être capable de traiter le message SOAP suivant ces trois actions (en cet ordre): 1. identifier toutes les parties du message destinées à cette application 2. vérifier que toutes les parties nécessaires (identifiées dans l'étape 1) soient supportées par l'application et traitées correctement. dans le cas contraire l'application doit rejeter le message (quoique il est possible d'ignorer les parties optionnelles identifiés dans l'étape 1 sans compromettre l'échange message/réponse). 3. dans le cas que l'application SOAP ne soit pas le destinataire final, il faut éliminer toutes les parties identifiées dans l'étape 1 avant de passer le message au destinataire suivant. L'attribut MustUnderstand Quand une application envoie un message à une autre, il est implicite que le destinataire soit capable de traiter le message. Cela n'est pourtant pas vrai pour les en-têtes: un destinataire ne doit pas forcement comprendre l'en-tête pour traiter correctement le message. Si l'expéditeur requière la compréhension d'un bloque Header il doit ajouter l'attribut MustUnderstand = "true" au bloque. Dans le cas où le destinataire trouve ce flag et il ne comprend pas l'en-tête il doit rejeter tout le message. Cet attribut assure donc la compréhension de toute l'enveloppe SOAP. Comme on a déjà dit, un message SOAP est composé de l'enveloppe (obligatoire), l'en-tête (optionnel) et le corps (obligatoire). Voyons-les un peu plus en détail.

35 II Les Services Web 25 L'enveloppe SOAP L'enveloppe est la couche externe d'un message SOAP. Elle doit obligatoirement contenir un élément Body. Dans le cas où l'enveloppe contient aussi un élément Header, elle ne peut pas en contenir plus qu'un et il doit être le premier fils de l'élément enveloppe (placé avant le corps). L'en-tête SOAP L'en-tête peut contenir plusieurs éléments, à condition qu'ils soient tous valides et qualifiés avec les espaces de nommage. Chaque élément contenu dans l'entête s'appelle header block (bloque d'en-tête). Les bloques d'en-tête servent à communiquer informations contextuelles relevantes pour le traitement du message. Un exemple peut être un bloque qui contient information sur l'authentification, sur le routage ou, comme montré dans le chapitre Le Security header2.2.2, sur la sécurité. Le corps SOAP L'élément Body contient l'information échangée. Cet élément peut avoir plusieurs fils et, comme pour l'en-tête, il faut seulement que chaque fils soit un élément XML bien formé, valide, qualifié avec un espace de nommage et il ne doit pas faire référence aux DTDs. SOAP Fault (les erreurs) L'élément SOAP Fault est utilisé pour transmettre informations sur les erreurs et/ou le statut de l'application. Quand il est présent, il doit se trouver à l'intérieur du corps du message, et ne peut apparaître plus qu'une fois. Le tableau II-1 résume les sous-éléments définies dans l'élément Fault.

36 II Les Services Web 26 Elément Faultcode Faultstring Faultactor Detail Description C'est une valeur générée algorithmiquement qui identifie le type d'erreur. Cette valeur doit être qualifié dans l'xml namespace. C'est une explication "humaine" de l'erreur C'est l'identificateur unique du noeud où l'erreur est arrivé Est utilisé pour exprimer des détails spécifiques à l'application sur la nature de l'erreur et où c'est il produit. Cet élément doit être présente si l'erreur est généré à cause d'un problème lié au corps du message. Dans le cas d'un erreur lié à d'autres aspects du traitement du message, il n'est pas obligatoire. tableau II-1: Sous-éléments définies dans l'élément Fault Codes erreurs standards SOAP Ils existent 4 types standard d'erreur (faultcodes) appartenant à l'espace de nommage Le tableau II-2 les montre avec une description. Erreur VersionMismatch MustUnderstand Server Client Description L'enveloppe SOAP est en train d'utiliser une version invalide de l'espace de nom pour l'élément enveloppe. Un bloque en-tête contenant le flag mustunderstand="true" n'a pas été compris Un erreur non pas lié au processus de traitement du message est arrivé L'erreur est causé par le message. C'est-à-dire que le message est mal formé (mauvaise utilisation des règles de codage), ou que les informations contenues sont fausses tableau II-2: Erreurs standard SOAP

37 II Les Services Web 27 Ces codes sont extensibles (comme le code II-11 le démontre) et on peut donc spécifier plus en détail les types d'erreurs. Pour étendre un type il faut utiliser le point "." (cette notation implique que la partie à droite est plus détaillée que celle à gauche). <s:envelope xmlns:s=" "> <s:body> <s:fault> <faultcode>client.authentication</faultcode> <faultstring> Invalid credentials </faultstring> <faultactor> <details> <!-- application specific details --> </details> </s:fault> </s:body> </s:envelope> code II-11: Exemple d'extension d'erreur SOAP Erreurs personnalisés Il est aussi possible de définir un set d'erreurs personnalisés, dans le cas où l'extension des types standard ne soit pas suffisante. La seule requête est qu'ils soient définis correctement dans un espace de nommage. Le code II-12 montre un erreur personnalisé. <s:envelope xmlns:s=" "> <s:body> <s:fault xmlns:xyz="urn:mycustomfaults"> <faultcode>xyz:customfault</faultcode> <faultstring> My custom error </faultstring> </s:fault> </s:body> </s:envelope> code II-12: Exemple d'erreur personnalisé SOAP Il faut quand même être attentifs dans l'exploitation de cette possibilité: en tant que personnalisés, ces erreurs ne peuvent pas être interprétés par tous les clients et certains ne pourront pas se comporter de façon intelligente face à un tel erreur! De plus, l'extensibilité des types standard, rend les erreurs personnalisés inutiles dans la plus part des cas.

38 II Les Services Web 28 Acteurs et message paths Un message SOAP voyage essentiellement en une seule direction (de l'expéditeur vers le destinataire), mais il est possible que le message passe par divers intermédiaires avant d'arriver à destination. Ces intermédiaires peuvent chacun faire quelque chose avec le message avant de l'envoyer envers les autres acteurs. Un intermédiaire SOAP et principalement un service web qui ajoute de la valeur ou des fonctionnalités à la transaction entre l'expéditeur et le destinataire. L'ensemble d'intermédiaires à travers lesquels le message passe est appelé message path (chemin du message) et chaque intermédiaire est un acteur. La construction d'une message path n'est pas couverte par la spécification SOAP. Il existent diverses extensions SOAP, comme le Microsoft's SOAP Routing Protocol (WS-Routing), qui s'occupent de cette problématique. Ce que SOAP spécifie est un mécanisme pour identifier quelles parties du messages sont destinées à quels acteurs. Ce mécanisme est connue comme "Targeting" (ciblage) et agisse seulement sur les en-tête et non pas sur le corps du message. Pour destiner un en-tête à un acteur il faut utiliser l'attribut spéciale "actor", dont la valeur est un identifient unique de l'intermédiaire auquel l'en-tête est destiné. Cet identifiant peut être le URL où l'acteur se trouve (mais aussi quelque chose plus générique). Les intermédiaires qui ne s'identifient pas avec l'attribut "actor" doivent ignorer le header. Voyons maintenant un exemple [Snell 2002, p23]: Imaginons qu'un revendeur reçoit une grande commande d'un client par le biais de son service web. Pour être sûr qu'il s'agisse d'une vrai commande provenant du client et non pas de quelqu'un d'autre le revendeur a établi un partenariat avec des tiers qui offrent un service de validation de signatures numériques. Le service fonctionne en vérifiant la validité de l'en-tête contenant la signature numérique.

39 II Les Services Web 29 Quand le client envoie la commande au revendeur, le message est routé à travers le service de validation, lequel validera la signature contenue dans l'entête et ajoutera un autre header qui contient l'information concernant la validité ou invalidité de la signature. La Figure II-6 montre la transaction Figure II-6: Chemin d'un message SOAP [Snell, p23] Pour que la vérification soit effectuée il est nécessaire que le service des tiers soit capable de comprendre quel est l'en-tête qui contient la signature. Cela est accompli en ciblant l'en-tête avec la signature au service de vérification, comme dans le code II-13. <s:envelope xmlns:s=" "> <s:header> <x:signature actor="uri:signatureverifier"> </x:signature> </s:header> <s:body> <abc:purchaseorder> </abc:purchaseorder> </s:body> </s:envelope> code II-13: Ciblage d'un En-tête Le transport des messages SOAP Comme déjà dit dans ce chapitre, dans le Web Services Stack, SOAP est placé au dessus des couches de transport. En tant que protocole de package il ne doit pas se préoccuper des protocoles de transport qui seront utilisés pour l'échange des messages. Cette particularité rend SOAP extrêmement flexible et en permet l'utilisation en n'importe quelle situation ou structure de réseau. Comme exemple de cette flexibilité, SOAP::Lite l'implémentation de service web SOAP basée sur Perl, écrite par Pavel Kulchenko supporte la capacité

40 II Les Services Web 30 d'échanger messages SOAP via http, FTP, TCP, SMTP, POP3, MQSeries et Jabber [Snell 2002, p34]. SOAP via HTTP À cause de sa profonde présence dans l'internet, HTTP est le moyen de transport le plus utilisé pour l'échange des messages SOAP. Il est tellement important, que même la spécification SOAP le traite de manière spéciale, en fournissant des détails sur la sémantique du modèle d'échange SOAP en relation à HTTP [Site 15]. SOAP et HTTP sont une couple naturelle parce que HTTP est un protocole basé sur le système requête/réponse et reflète parfaitement le concept du modèle SOAP RPC. Le fonctionnement est montré à l'aide de la Figure II-7. Figure II-7: SOAP via http [Snell, p34] La requête SOAP est envoyée au serveur au moyen d'une requête HTTP et le serveur rend la réponse en utilisant une réponse HTTP. Bien que cette couple fonctionne très bien, il faut dire qu'elle ne reflète pas forcément le modèle asynchrone qu'on veut atteindre pour avoir un "loosecoupling" avec le style "Document"