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"

41 II Les Services Web Web Service Description Language La section 1.3.3, étant dédiée au protocole SOAP, fournisse les bases nécessaires pour implémenter un système d'échange des messages en utilisant les moyens de transport déjà existantes (comme le HTTP ou le SMTP). Dans une situation hypothétique, on pourrait développer une application digne d'être mise à disposition du monde entier par le biais des services web. Tout ce qu'on devrait faire serait d'expliquer au gens comment utiliser ce service. On devrait leur dire quel est son but, quels sont les méthodes à disposition et sous quelle forme les résultats leur seraient envoyés. De plus, on devrait aussi leur expliquer quels sont les messages d'erreur et leur origine. Fournir toutes ces informations personnellement serait infaisable pour tous les possibles utilisateurs. Donc Il faut un système capable de fournir les explications nécessaires à tous les clients potentielles. C'est pour résoudre cette problématique que le WSDL (Web Service Description Language) entre en jeu. Ce protocole fournit les outils nécessaires à décrire de façon assez complète les services web. Le but de cette section n'est pas d'expliquer le fonctionnement du protocole au niveau technique, mais plutôt d'en montrer très rapidement les propriétés les plus importantes. Définition WSDL est un "format XML définit par le groupe W3C. Il permet de décrire les différents services d'un réseau en tant que des fournisseurs accessibles à travers l'utilisation de messages. Ces messages contiennent des informations orientées soit document, soit procédure". [Site 16] Histoire Le WSDL 1.1 a été présenté comme note au W3C en mars 2001 par Ariba, IBM et Miscrosoft. Le but était celui de décrire les services pour le W3C XML Activity

42 II Les Services Web 32 on XML Protocols. En juillet 2002, la première version Working Draft WSDL 1.2 a été distribuée [Site 17]. En juin 2007 la version WSDL 2.0 est devenue une recommandation W3C [Site 18] La structure des documents WSDL 1.0 Un document WSDL est composé de 4 éléments principales. Le tableau II-3 montre chaque élément avec une brève description. Élément <porttype> Description Ceci est l'élément le plus important d'un document WSDL. Il décrit un service web, les opérations qui peuvent êtres exécutées et les messages échangés. On peut comparer cet élément à une librairie de fonctions ou à une classe dans les langages de programmation communs. <message> <types> <bindings> <definitions> <service> Cet élément définit les données d'une opération. Chaque message peut être composé de plusieurs parties et chaque partie peut être comparée à un attribut d'un fonction dans les un langage de programmation commun. Il définit les types de données utilisées par le service web. Pour des raisons de convivialité avec les différentes plateformes, WSDL utilise la syntaxe des XMLSchemas pour définir les types. Définit les protocoles de communications utilisées pour chacun <porttypes> C'est l'élément racine d'un document WSDL Contient l'adresse où on trouve le service. tableau II-3: Éléments principales d'un document WSDL [Site 19]

43 II Les Services Web 33 La Figure II-8 montre la structure d'un document WSDL et le code II-14 est un document WSDL très simple. Figure II-8: Structure d'un document WSDL [Site 20] <definitions> <message name="gettermrequest"> <part name="term" type="xs:string"/> </message> <message name="gettermresponse"> <part name="value" type="xs:string"/> </message> <porttype name="glossaryterms"> <operation name="getterm"> <input message="gettermrequest"/> <output message="gettermresponse"/> </operation> </porttype> </definitions> code II-14: WSDL file [Site 19] Ressources Externes spécification Tutorial

44 II Les Services Web Universal Description Discovery and Integration Une fois qu'une application est développée, que le système de requête/réponse est implanté grâce à SOAP et qu'on est capable de le décrire à l'aide de WSDL, ce qui reste à faire est permettre aux possibles utilisateurs de trouver le service web dans le lieu chaotique que c'est l'internet. Pour ce faire, dans ce chapitre on étudiera UDDI, car c'est un des projets qui accomplissent au mieux cette tache. Définition "UDDI Est une norme basée sur XML, poussée par une quarantaine de sociétés, qui doit permettre de définir, de trouver et d'utiliser des service web facilement" [Site 21]. UDDI est une des spécifications centrales des services web. Il est interrogé en utilisant SOAP et fournisse accès aux documents WSDL qui décrivent les différents services. Malheureusement en réalité personne l'utilise! Histoire Le projet UDDI a commencé en octobre 2000 par une collaboration entre Microsoft, Ariba et IBM. Au cours de temps d'autres entreprises s'y sont jointes comme Sun Microsystems, Oracle, HP et SAP. En 2005 la version UDDI V3.2 a été approuvée comme OASIS Standard. À ce moment, le OASIS UDDI Spec TC travail sur l'amélioration de la sécurité, de la fidélité et de la sémantique. De plus, on cherche d'aligner le plus possible UDDI à l'architecture des services web et aux autres standards [Site 22].

45 II Les Services Web 35 L'enregistrement L'enregistrement UDDI consiste en trois composants: Pages blanches: comprennent la liste des entreprises ainsi que des informations associées à ces dernières. On y retrouve donc des informations comme le nom de l'entreprise, ses coordonnées, la description de l'entreprise, mais également l'ensemble de ses identifiants. Pages jaunes: recensent les services web de chacune des entreprises sous le standard WSDL Pages vertes: fournissent des informations techniques précises sur les services fournis. Ces informations concernent les descriptions de services et d'information de liaison ou encore les processus métiers associés. La consultation Il existe trois types d'annuaires UDDI: l'annuaire privé à l'entreprise (avec accès restreints), l'annuaire publique et l'annuaire semi-privé. Le tableau II-4 montre les différences entre les trois types:

46 II Les Services Web 36 Type Description Analogie web exemple Publique Les outils administratives peuvent êtres sécurisés, mais la consultation est essentiellement libre. Les données peuvent êtres échangés avec d'autres registres Website Xmethods 4 Privé Se trouve derrière un firewall, Intranet IBM isolé du réseau publique. Soit les WebSphere outils administratives que la UDDI consultation sont sécurisés. Les Registry 5 données ne sont pas échangés avec d'autres registres Semi-privé C'est un annuaire fournit à Extranet Trading l'intérieur d'un environnement partner contrôlé. C'est-à-dire que network seulement les partenaires ont accès aux différents outils. Les données peuvent être échangés avec d'autres annuaires auxquels on fait confiance. tableau II-4: Différences entre les 3 types d'annuaires UDDI [Site 23, p5] Une entreprise peut choisir de créer plusieurs registres de façon à séparer les informations internes de ces accessibles au publique (on parle toujours d'informations relatives aux services). Jusqu'au 12 janvier 2006 l'annuaire publique par excellence était le UDDI Business Registry (UBR). C'était un annuaire publique et libre, géré en concomitance par IBM, Microsoft, NTT Communications et SAP. Tout le monde p.html

47 II Les Services Web 37 était libre de publier des informations à n'importe quel noeud UBR et d'y faire des requêtes. À partir du 12 janvier 2006 le UBR à été abandonné à cause de la standardisation en 2005 de la version UDDI V3.2 parce que les entreprises qui le géraient on défini les buts du projet comme achevés. Quel que soit le type d'annuaire, pour lancer une requête on utilise des messages SOAP. L'utilisation d'uddi est en dehors des buts de ce document. Pour le lecteur qui veut approfondir ce domaine les ressources externes sont un bon point de départ. Ressources Externes Spécification UDDI V3.0.2 Tutorial 0,289142,sid26_gci916789,00.html

48 II Les Services Web Autres Standards Les sections précédentes traitaient les technologies et protocoles les plus utilisés et standardisées. Cependant, il en existent beaucoup plus, et ce chapitre les présente rapidement divisés par catégorie. Chaque standard ou protocole présenté est suivi par une ressource (pour ce qui sont intéressés). La liste suivante est surtout extraite de [Snell 2002, pp ] car c'est une des sources les plus complètes Protocoles de package XML-RPC C'est la manifestation originale du SOAP idée par Dave Winer de Userland Software. Ce simple protocole était beaucoup utilisé dans la communauté open source (mais il est désormais un protocole abandonné). Jabber Jabber est un protocole de transport et de package qui peut être utilisé dans un système peer-to-peer asynchrone Protocoles de description DAML-S Le DARPA Agent Markup Language Ontology for web services est un projet de recherche académique pour décrire sémantiquement les services web.

49 II Les Services Web 39 RDF Le Resource Description Framework (RDF) est un modèle de graphe destiné à décrire de façon formelle les ressources Web et leurs métadonnées, de façon à permettre le traitement automatique de telles descriptions. Développé par le W3C, RDF est le langage de base du Web sémantique. Une des syntaxes (sérialisation) de ce langage est RDF/XML [Site 24]. Il y a eu certains discussions sûr la possibilité de décrire les services web très facilement avec RDF. Beaucoup d'exemples ont été développés, et il existe aussi une version modifié de WSDL conforme à la syntaxe RDF Protocoles de recherche/découverte WS-Inspection Le Web Service Inspection Language fournit un indice XML pour trouver les services disponibles à un certain endroit dans le réseau. ebxml Registry Fait partie du projet ebxml et le but c'est de définir un model standard pour rechercher et trouver les services web purement business. Cet approche est différente mais non pas incompatible avec UDDI. Il inclut beaucoup plus d' informations que UDDI Protocoles de sécurité XML Digital Signatures C'est un effort commun du W3C et du IETF pour définir une méthode standard de représentation des signatures numériques en XML.

50 II Les Services Web 40 XML Encryption C'est un effort du W3C pour définir une méthode standard de cryptage des contus XML et de représenter des données cryptés sous la forme de XML. SAML Le Security Assertions Markup Language est un standard informatique définissant un protocole pour échanger des informations liées à la sécurité. Basé sur le langage XML. SAML a été développé par OASIS [Site 25]. XKMS Le XML Key Management Service est une spéciation pour implémenter une infrastructure de management des clés publiques basée sur les services web Protocoles de transport Reliable HTTP (HTTPr) C'est une version du protocole http proposé par IBM capable d'assurer la fiabilité des échanges des messages Protocoles de routage et workflow WS-Routing C'est un mécanisme proposé par microsoft pour définir le chemin d'un message SOAP parmi différents intermédiaires.

51 II Les Services Web 41 WS-Address C'est un mécanisme de routage pensé pour surclasser le WS-Routing Langages de programmation et plateformes JAXP Le Java API for XML Parsing est l'effort de la Java Community Process (jcp) de standardiser les API XML en Java. JAX-RPC Le Java API for XML RPC est l'effort du JCP pour standardiser les API Java pour utiliser les services web. SimpleXML SimpleXML est une des deux nouvelles extensions de PHP 5 consacrées à XML, et présente une approche du traitement des fichiers XML mettant en avant la simplicité d'utilisation [Site 26]. Il existent bien sur d'autres protocoles et technologies, et la liste montrée n'est rien d'autre qu'une sélection parmi les multitudes qu'on trouve. L'exclusion d'un protocole de cette liste n'est en aucun cas à interpréter comme un jugement sur sa validité.

52 II Les Services Web 42 2 Sécurité Le concept de sécurité est primordial quand on parle des systèmes en réseau. Il existe diverses manières de protéger les donnés. On passe de l'accès limité (login, intranets, etc.) à l'utilisation de méthodes de cryptage ou de signature de documents numériques. Ce chapitre répond à la question sur la sécurité qu'on s'est posé au début de cet ouvrage. L'idée à la base des ces services web est l'échange d'informations permettant d'améliorer les processus des chaque partenaire. La nature de ces informations est très variable, mais il arrive souvent qu'on s'échange informations confidentielles (numéros des cartes de crédit, données personnels, données business, etc.). Vue cette nature, il est très important de protéger ces données de toute modification et accès interdit. Un exemple de ce besoin de protection peut être une compagnie aérienne qui offre un service web permettant la réservation des places pour ses vols. Cette compagnie doit être certaine que seulement les partenaires autorisés puissent utiliser le service de façon à éviter des problèmes de nature économique dans le cas de fausses réservations. Un autre cas, beaucoup plus intéressant, est le cas des services web qui valident les cartes de crédit. Dans ce cas, il est strictement nécessaire d'interdire à un tiers de lire et/ou modifier les informations qui voyagent dans le web (on parle de sécurité end-to-end). Avec les exemples montrés, on comprends donc la nécessité d'ajouter la couche "Sécurité" au Web Services Stack étudié dans le chapitre Ce chapitre étudie le concept de sécurité et on analysera en détail la spécification OASIS Web Service Security (WSS). De plus, on étudiera la théorie et l'utilisation du Username Token.

53 II Les Services Web Terminologie Le domaine de la sécurité est assez complexe, et avant de commencer son étude il est très important de connaître la terminologie. Ce sous-chapitre présente quelques définitions. Confidentialité La confidentialité a été définie par l'organisation internationale de normalisation (ISO) comme "le fait de s'assurer que l'information n'est seulement accessible qu'à ceux dont l'accès est autorisé", et est une des pierres angulaires de la sécurité de l'information. La confidentialité est l'une des raisons d'être des cryptosystèmes, rendus possibles dans la pratique par les techniques de la cryptographie moderne [Site 27]. Intégrité De manière générale, l'intégrité des données désigne l'état de données qui, lors de leur traitement, de leur conservation ou de leur transmission, ne subissent aucune altération ou destruction volontaire ou accidentelle, et conservent un format permettant leur utilisation [Site 28]. Clé de chiffrement Une clé est un paramètre utilisé en entrée d'une opération cryptographique (chiffrement, déchiffrement, scellement, signature numérique, vérification de signature). Une clé de chiffrement peut être symétrique (cryptographie symétrique) ou asymétrique (cryptographie asymétrique) : dans le premier cas, la même clé sert à chiffrer et à déchiffrer ; dans le second cas on utilise deux clés différentes, la clé de chiffrement est publique alors que celle servant au déchiffrement est gardée secrète (la clé secrète, ou clé privée, ne peut pas se déduire de la clé publique) [Site 29].

54 II Les Services Web 44 Cryptographie La cryptographie est une des disciplines de la cryptologie s'attachant à protéger des messages (assurant confidentialité, authenticité et intégrité) en s'aidant souvent de secrets ou clés [Site 30]. Security Token (Marque de sécurité) Un Security token contient les informations sur l'identité et la sécurité. Il est utilisé pour autoriser l'accès à documents et ressources [Site 31]. Signature numérique Est un mécanisme permettant d'authentifier l'auteur d'un document électronique et de garantir son intégrité, par analogie avec la signature manuscrite d'un document papier [Site 32].

55 II Les Services Web Web Service Security Originellement développé par IBM, Microsoft, VeriSign et Forum Systems et, à ce moment, conduit par le comité OASIS-OPEN, le protocole Web Service Security (WS-Security) permet d'appliquer de la sécurité aux services web. La première spécification (WS-Security 1.0) a été lancée le 19 avril 2004 et le 17 février 2006 le comité a lancé la version 1.1 [Site 33]. Définition La spécification Web Service Security (WS-Security) propose un set standard d'extensions SOAP qui peuvent être utilisées dans le développement de services web sécurisés de façon à implémenter l'intégrité et la confidentialité des messages échangés [Site 34]. Le WS-Security propose aussi, un mécanisme général pour associer des tokens aux messages. Cependant il n'est pas nécessaire d'utiliser un type de token spécifique. En effet, WS-Security a été structuré de façon à être extensible (c'est-à-dire qu'il supporte des formats de token multiples) pour permettre différents mécanismes d'authentification et sécurisation. De plus, WS-Security décrit comment encoder tokens de sécurité binaires et comment les attacher aux messages SOAP. Parmi les tokens décrits on trouve: Username tokens X.509 tokens SAML tokens REL Tokens Kerberos tokens D'ailleurs, l'intégrité des messages est assurée en combinant les signatures XML et les security tokens. De cette façon on peut assurer que les messages ont été envoyés par un expéditeur approprié et ils n'ont pas étés modifiés durant l'échange.

56 II Les Services Web Le modèle de sécurité Le WS-Security spécifie un modèle de sécurité des messages en termes d'une combinaison de security tokens et des signatures numériques avec le but de protéger les messages SOAP. Principalement il est fondamental qu'aucune modification ne soit pas faite sans qu'on la détecte (intégrité) et que les messages soient lisibles exclusivement aux destinataires prévus (confidentialité)! L'intégrité des messages est garantie par l'utilisation des XML Signatures (XMLSIG) en combinaison avec les security tokens de façon à détecter les modifications. Ce modèle permet aussi l'utilisation de plusieurs signatures par différents acteurs. De plus, l'extensibilité du mécanisme d'intégrité permet l'utilisation de formats de signature autres que le XMLSIG. La confidentialité des messages se base sûr l'utilisation de XML Encryption (XMLENC) en conjonction avec les security tokens de façon à rendre différentes parties du message confidentielles. Comme pour les signatures, il est possible d'utiliser d'autres processus cryptographiques en dehors du XMLENC Le Security header Le security header (<wsse:security>)permet d'ajouter informations de sécurité à un message SOAP. Cet élément a les attributs optionnels "actor" et "role" et ils sont utilisés pour adresser l'en-tête à un destinataire spécifique (si le message passe à travers plusieurs intermédiaires). Le code II-15 montre la syntaxe et la position de l'en-tête de sécurité <s11:envelope> <s11:header> <wsse:security s11:actor=" " s11:mustunderstand=" ">.</wsse:security> </s11:header> </s11:envelope> code II-15: Syntaxe et position de l'en-tête de sécurité

57 II Les Services Web 47 Le tableau II-5 est un extrait de ce présenté dans la spécification OASIS et montre les éléments et attributs relatifs à l'en-tête de sécurité avec leur signification et d'autres détails. Autres info. /wsse:security L'en-tête permettant d'envoyer informations de sécurité Cet attribut permet l'identification d'un acteur spécifique Optionnel Cet attribut est utilisé pour indiquer si un élément doit être forcement traité au non. True (Vrai) signifie "traitement forcé" La non utilisation implique valeur = false /wsse:security/@{any} Ceci est un mécanisme permettant l'addition d'autres attributs, basés sur des schémas. Attributs non reconnus devraient causer un erreur tableau II-5: Éléments et attributs relatifs à l'en-tête de sécurité [Site 35, pp 22-23] À l'intérieur de l'en-tête de sécurité on trouve éléments tels que les security tokens et les signatures. Il faut se rappeler que l'en-tête peut contenir n'importe quel type de token ou de signature Username Token Comme on a déjà vue dans les chapitres précédents, le WS-Security header permet l'utilisation de plusieurs security tokens. Cette section traite le Username token (le plus simple) pour comprendre le mécanisme de fonctionnement. Plus tard, nous regarderons superficiellement les autres tokens de façon à en savoir un peu plus sûr les possibilités existantes. Le Username token permet de soumettre un nom d'utilisateur et, éventuellement, un mot de passe. Le code II-16 en montre la syntaxe et le tableau II-6 est montre les éléments et les attributs relatifs au Username Token.

58 II Les Services Web 48 <S11:Envelope xmlns:s11="..." xmlns:wsse="..."> <S11:Header>... <wsse:security> <wsse:usernametoken wsu:id=" "> <wsse:username> </wsse:username> </wsse:usernametoken> </wsse:security>... </S11:Header>... </S11:Envelope> code II-16: Syntaxe de l'élément UsernameToken Autres info. /wsse:usernametoken/wsse:password Cet élément est utilisé pour fournir un mot de passe (ou un équivalent, comme le hash). Il est recommandé que cet élément soit utilisé seulement avec un canal sécurisé, tel que le HTTP/S, ou que le token lui-même soit crypté. Cet attribut spécifie le type de mot de passe utilisé. Optionnel Ceci est un mécanisme permettant l'addition d'autres attributs, basés sur des schémas. /wsse:usernametoken/wsse:nonce Valeur aléatoire crypté Optionnel Spécifie le type de Nonce. Si cet attribut n'est pas spécifié, la valeur par défaut est Base64 Optionnel /wsse:usernametoken/wsu:created Spécifie un timestamp pour indiquer le temps de création d'un Optionnel message tableau II-6: Éléments et attributs relatifs le Username Token [Site 36, pp 8-9]

59 II Les Services Web 49 L'élément <wsse:password> En couple avec l'élément <wsse:username> il est aussi possible de spécifier un élément <wsse:password>. Le types de mots de passe peuvent être librement choisis (derived password, S/KEY, etc.) mais on trouve souvent le type PasswordText ou PasswordDigest. Evidemment si on utilise un mot de passe du type PasswordText l'information sera en texte plain (lisible). Dans le cas de PasswordDigest, au contraire, l'information contenue est un Digest, c'est-à-dire un équivalent du mot de passe originale (par exemple le hash). Les mots de passe du type PasswordDigest sont définies comme étant le résultat du codage en Base64[XML-Schema] du valeur de hash SHA-1 du mot de passe codé UTF8. Il est quand même important de noter que si la PasswrodDigest n'est pas envoyée par le biais d'un canal sécurisé, elle n'offre pas une sécurité plus élevée qu'un mot de passe PasswordText. Les éléments <wsse:nonce> et <wsse:created> Une des attaques les plus simples à mettre en œuvre est le "Replay Attack". Cet attaque consiste à intercepter une information génuine et la répéter pour s'authentifier auprès d'un service [Site 37]. Les points suivantes montrent le fonctionnement de cet attaque: 1) Bob Envoie une requête ad Alicia en lui communicant sa PasswordDigest. 2) Cleancy intercepte la communication 3) Alicia donne accès à la ressource à Bob parce que le mot de passe c'est correcte. 4) Bob ferme la communication avec Alicia 5) Cleancy retransmet la PasswordDigest de Bob à Alicia. Il s'approprie donc de l'identité de Bob 6) Alicia n'a aucun élément pour comprendre ce qui est en traîne d'arriver et donne accès à Cleancy.

60 II Les Services Web 50 Les éléments <Nonce> et <Created> sont utilisés pour protéger le service de ce type d'attaque. Un Nonce est un numéro généré avec un algorithme aléatoire. Ce numéro doit être collé à chaque message envoyé de façon à ce que le serveur puisse détecter les nombres déjà utilisés et donc rejeter un message déjà arrivé. Le problème est que le serveur doit avoir une liste des Nonces déjà utilisés consumant ainsi des ressources. Pour diminuer les ressources destinées à ce contrôle, l'émetteur doit coller au message l'élément Created. Cet élément n'est rien d'autre qu'un timestamp généré au moment de la création du message. En combinant le Nonce et le Timestamp (Created) le serveur peut retenir seulement les dernières nonces arrivés (on défini une limite de temps soit par exemple 5 minutes) et diminuer donc les ressources utilisées. Quand on utilise ces deux éléments il faut les inclure dans le PasswordDigest de la façon suivante: PasswordDigest = Base64(SHA-1(nonce + created + password) Le code II-17 est un exemple avec PasswordText et le code II-18 en est un avec PasswordDigest. <S11:Envelope xmlns:s11="..." xmlns:wsse="..."> <S11:Header>... <wsse:security> <wsse:usernametoken> <wsse:username>bob</wsse:username>.<wsse:password>bobpassword</wsse:password> </wsse:usernametoken> </wsse:security>... </S11:Header>... </S11:Envelope> code II-17: exemple avec PasswordText

61 II Les Services Web 51 Erreurs <S11:Envelope xmlns:s11="..." xmlns:wsse="..."> <S11:Header>... <wsse:security> <wsse:usernametoken> <wsse:username>bob</wsse:username>.<wsse:password Type=" #PasswordDigest"> weyi3nxd8ljmnvksckfv8t3rghh3rw== </wsse:password>.<wsse:nonce>wscqanjceac4mqobe07saq==</wsse:nonce>.<wsu:created> t01:24:32z</wsu:created> </wsse:usernametoken> </wsse:security>... </S11:Header>... </S11:Envelope> code II-18: exemple avec PasswordDigest Les implémentations devraient utiliser le set d'erreurs définis dans la spécification WSS:SOAP Message Security pour augmenter l'interopérabilité. S'il est vraiment nécessaire d'utiliser des codes d'erreur personnalisés il faut qu'ils soient définies dans des espaces de noms privés. En tout cas, quand on utilise des messages d'erreur personnalisés, il faut être attentifs à ne pas fournir des vulnérabilités facilitant les attaques! Les autres tokens compatibles avec la WS-Security sont très bien documentés et une fois compris le fonctionnement du security token il est assez simple d'apprendre à utiliser les autres. Ressources Externes Liste des spécifications pour les différents tokens

62 II Les Services Web 52 3 Conclusion Théorie Les technologies Les services web sont des technologies en évolution continue. Aujourd'hui certaines des ces technologies se sont imposées comme des standards et elles sont presque globalement adoptées. D'autres par contre sont destinées à disparaître. La jungle des technologies est pleine de nouveaux protocoles et le temps seulement pourra nous dire lesquels formeront les services web du futur. Le développement Les développeurs ont toujours plus d'environnements qui simplifient leur travail dans le domaine des services web. Par exemple, ils existent maintenant des éditeurs visuels qui permettent une génération très simple des documents WSDL ou des prototypes de service web 6. De plus, il est toujours plus simple de transformer une application normale en un service web (l'environnement Microsoft.Net Framework est un des outils les plus avancés en ce sens). La sécurité Au niveau de la sécurité on a fait des progrès énormes, mais ce domaine est encore trop chaotique. Il faut quand même dire qu'un des points forts des services web est l'utilisation des technologies standard de l'internet. Cela permet d'atteindre des niveaux de sécurité acceptables en utilisant technologies mûres comme le HTTPS, SSL, SSH ou VPN. Le business C'est déjà longtemps que les grandes entreprises ont compris les potentialités des services web (maintenant on voit aussi entreprises plus petites s'intéresser à ce domaine), mais la plus grande partie des services web qu'on trouve dans le réseau, sont assez simples. Je ne veux pas dire que les services web existants sont presque inutiles, mais dans le futur, on devrait voir des grands réseaux de services avec des capacités beaucoup plus intéressantes. 6 Par exemple Altova MissionKit

63 III Travail pratique 53 III. Travail pratique

64 III Travail pratique 54 1 Introduction Dans la section précédente on a étudié les différents standards nécessaires au développement des services web. Cette section est dédiée aux services web dans la pratique et dans les chapitres qui suivent nous allons appliquer les connaissances apprises au développement d'un outil de recherche d'objets immobiliers basé sur les services web. Dans le deuxième chapitre on présente le problème central de ce travail et dans le troisième on analyse la situation aux Etats-Unis (car la réalité nordaméricaine est plus avancée de celle suisse dans l'utilisation des nouvelles technologies du web). Après cette analyse on passe vraiment au projet pratique et le chapitre 4 est dédié à l'architecture et à l'implémentation de notre solution. Finalement le chapitre 5 regroupe l'évaluation du projet et les considérations personnelles. 2 Le problème de la recherche d'objets immobiliers Au moment actuel, quand une personne recherche un objet immobilier (appartement, maison, etc.) les processus à suivre sont deux 7 : 1. Utiliser les différents sites web des régies 2. Utiliser un portail dédié qui regroupe les objets des différentes régies dans une seule base de données À l'aide de la Figure III-1 on voit que dans le premier cas l'utilisateur exécute différentes requêtes dans les différents sites web des régies. Cela dit, il est claire que l'utilisateur doit tout d'abord connaître l'endroit où les sites se trouvent et il doit aussi apprendre à utiliser les différentes interfaces proposées. 7 Evidemment on parle ici de l'utilisation des technologies de l'internet.

65 III Travail pratique 55 Figure III-1: Utilisation des différents sites web des régies immobilières La Figure III-2 montre l'interaction avec un site dédié. On voit toute de suite les bénéfices d'une telle approche: l'utilisateur n'a qu'à exécuter une requête dans le site web dédié en ayant comme résultat tous les objets des régies partenaires. Figure III-2: Utilisation d'un intégrateur ordinaire

66 III Travail pratique 56 À la situation actuelle ce deuxième modèle est le meilleur, mais il faut quand même dire qu'il a des limites et des problèmes structurels assez évidents. Le chapitre 2.1 présente en détail ce modèle Les portails dédiés Ce sous-chapitre est divisé en deux parties. La première présente les deux principaux portails dédiés en Suisse et la deuxième explique leur fonctionnement avant de mettre en évidence les problèmes existants Homegate et Immoscout24 En Suisse les deux acteurs principales sont Immoscout24.ch et Homegate.ch. Ces deux portails présentent un nombre très grand d'annonces immobilières. Immoscout24.ch 8 ImmoScout24 est la plus importante place de marché électronique de Suisse pour les logements, les immeubles commerciaux et de vacances. Ce site propose quotidiennement plus de offres on-line. ImmoScout24 est une plate-forme du groupe Scout24, leader incontesté du réseau suisse des places de marché on-line [Site 38]. homegate.ch 9 Cette entreprise est une filiale de la Banque Cantonale de Zurich. Elle a été fondée le 1er mars 2001 et son siège est à Adliswil, tout près de Zurich [Site 39]. Avec, chaque mois, environ 2.2 million de visites de plus de 650'000 visiteurs, homegate.ch fait partie des entreprises en ligne qui ont la plus vaste audience [Site 40]

67 III Travail pratique Fonctionnement et limites des portails dédiés Le fonctionnement des portails dédiés est plus ou moins le suivant: Le portail a différents partenaires. Chaque partenaire peut insérer des annonces directement dans le système du portail ou préparer (à une intervalle précise) un fichier texte (généralement XML) contenant tous les objets présents dans la propre base de données. Plusieurs fois par jour le portail prend les fichiers et sauvegarde les informations dans sa base de données [Annexe A]. Même si pour l'utilisateur il existe beaucoup d'avantages, ce modèle présente certains erreurs conceptuels: Tout d'abord il faut noter que la même information est répétée: les objets d'une régie partenaire sont contenus dans deux au plusieurs bases de données (dans le cas qu'une régie soit partenaire avec plusieurs portails). De plus, il y a le risque que l'information transmise à l'utilisateur soit obsolète (que se passe-t-il si l'utilisateur reçoit le prix d'un objet et malheureusement ce prix a changé depuis la dernière mise à jour?). Finalement dans une analyse globale du système (régies + portails) l'utilisation de mémoire et de ressources est doublée à cause de la répétition des informations. Le prochain chapitre analyse la réalité des Etats-Unis et du canada et présente un standard d'échange, développé par les associations du marché immobilier de ces pays pour résoudre des problèmes similaires à ceux mise en évidence dans ce chapitre.

68 III Travail pratique 58 3 Situation aux Etats-Unis et au Canada En Amérique du nord il existe des services réunissant les objets immobiliers provenant de plusieurs parties du continent. Ces services s'appellent Multiple Listing Services et ils sont comparables aux sites (bien plus petits) présentés pour la Suisse Multiple Listing Service (MLS) Définition Selon wikipedia le Multiple Listing Service c'est une base de données permettant de montrer les objets immobiliers en vente dans une certaine région. Parmi les objets on trouve ceux mis en vente par les agents immobilières affiliés à ce particulier MLS ou appartenant à la National Associtation of Realtors (NAR) ou à la Canadian Real Estate Association (CREA) [Site 41]. Ce type de service est très utilisé aux Etats-Unis et en Canada, mais on commence à en voir la présence aussi en Europe. Le but d'un MLS est de simplifier la recherche d'objets immobiliers dans une certaine région en augmentant la productivité des agents immobiliers. Toutefois grâce au développement de l'internet et donc grâce à un accès plus simple aux informations, il existe maintenant plus de 800 MLS (seulement aux Etats-Unis) et il faut donc trouver une solution pour consolider toutes les informations [Site 42]. C'est pour consolider les informations provenant de plusieurs MLS que le Real Estate Standards Organization (RESO) a développé le RETS Real Estate Transaction Protocol (RETS) Définition Selon Wikipedia RETS a été créé pour surmonter les difficultés présentées par l'existence d'un grand nombre d'organismes (MLS, agents immobiliers, clients) désirant partager et distribuer les informations immobilières. RETS satisfait ce

69 III Travail pratique 59 besoin en fournissant une norme commune pour l'échange des données immobilières. Beaucoup de MLS emploient le protocole RETS [Site 43]. À Ce moment la version 2 de RETS est devenue un standard. RETS et XML La première version de RETS utilisait partiellement XML et les technologies dérivantes. Mais les standards de base de RETS2 (standardisé en 2006) sont SOAP, WSDL, XML et XMLSchema. Pour ce que concerne la sécurité, RETS2 utilise WS-Security et plus en détail, SOAP Message Security, Username Token Profile, X.509 Certificate Token Profile, et SAML Token Profiles. RETS2 et UDDI La NAR (National Association of Realtors) a décidé d'exclure UDDI des standards liés à RETS2 car les services offerts par ce standard sont normalement fournis après accords contractuels. C'est-à-dire que personne peut chercher un MLS RETS-compliant et l'utiliser librement. Considérations personnelles RETS2 est un pas énorme dans le développement d'un langage commun entre les différents acteurs immobiliers. Les technologies des base des services web sont valables et RETS2 en est la preuve. Malheureusement RETS est trop lié au marché nord-américaine et surtout aux objets en vente seulement. Il faudrait développer un standard plus général, capable de représenter aussi les autres objets. L'outil développé dans le cadre de ce projet n'utilise pas RETS car il est trop complexe pour les objectifs préfixés.

70 III Travail pratique 60 4 Solution proposée Pour résoudre les problèmes existants dans les modèles actuels on propose une solution alternative aux portails dédiés. La solution proposée est la conception d'une interface commune permettant l'échange des informations sur les objets immobiliers en utilisant les services web. Le chapitre 4.1 présente l'architecture du modèle. On commence par son fonctionnement pour passer aux avantages et limites. Dans le chapitre 4.2 le lecteur verra l'architecture des applications développées pour démontrer le fonctionnement du modèle. Finalement le chapitre 4.3 est dédié à l'implémentation Modèle La Figure III-3 présente le modèle orienté service web. Dans ce modèle les régies implémentent une interface avec des méthodes prédéfinies de façon à ce que l'intégrateur puisse définir un client capable d'appeler ces méthodes pour retrouver les objets respectant certains critères de recherche. Figure III-3: Modèle de recherche orienté service web

71 III Travail pratique Fonctionnement L'utilisateur doit envoyer sa requête à l'intégrateur seulement. Ce dernier construit des requêtes SOAP et les envoie aux différents services web des régies. Finalement les régies exécutent les requêtes dans leur bases de données privées et envoient une réponse SOAP à l'intégrateur. Une fois que toutes les réponses arrivent, l'intégrateur présente les résultats sous forme d'html Avantages Ce modèle permet d'éviter des problèmes de redondance (les informations des objets sont contenues dans les bases de données privées des régies) et les informations présentées à l'utilisateur sont toujours à jour. Un autre avantage est que l'intégrateur ne doit pas remplir aucune base de données privée en lisant à intervalles régulières les documents des régies (il épargne des ressources). De plus, en respectant la logique des services web, chaque régie peut choisir l'architecture qu'elle préfère (la seule chose à respecter c'est l'interface prédéfinie). Dans cette optique on peut avoir par exemple un service web implémenté en Perl, un autre en Java et l'intégrateur en PHP ou.net! Limites Ce modèle est quand même simplifié car les but du projet étaient d'implémenter l'interface et l'intégrateur seulement. À cause de cela, on ne voit donc pas un registre et l'intégrateur ne peut donc pas chercher des nouvelles régies implémentant l'interface. De plus, par rapport aux portails dédiés, il est important de noter que le temps pour transmettre le résultats à l'utilisateur sera majeur, car il est beaucoup plus rapide d'exécuter une requête SQL dans la base privé d'un portail que d'aller chercher les informations directement chez les régies.

72 III Travail pratique Architecture Pour démontrer que le modèle fonctionne on a choisi de développer les applications suivantes: 1. Une régie fictive (immoone) avec le service web implémentant l'interface commune 2. Un intégrateur (immintegrator) avec le client permettant d'utiliser le service web offert par immone L'intégrateur et la régie seront publiés sur un serveur local mais, pour démontrer que le modèle fonctionne dans la réalité, on a publié une copie de immoone dans le web. La Figure III-4 montre l'output du travail. Figure III-4: Architecture de la solution

73 III Travail pratique Implémentation Ce sous-chapitre est dédié à l'implémentation des différentes applications. Dans une première partie on étudiera le deux approches dans le développement des services et on verra pourquoi on a choisi une approche qui se trouve au milieu pour décrire notre interface. Dans un deuxième temps on présente les applications et les outils Code-First ou Contract-First? Il existe deux approches quand on implémente des services web: l'approche contract-first consiste à définir l'interface d'un service web (XSD et WSDL) et dans un deuxième temps à coder l'application. Le code-first consiste à écrire le code (java, C++,.Net, etc.) et à générer en un deuxième temps l'interface WSDL automatiquement. L'approche code-first est très simple, et le processus de développement est plus court; mais avec ce modèle on n'atteint pas des niveaux d'interopérabilité acceptables (car les fichiers WSDL générés sont souvent liés à l'environnement de développement). Avec l'approche contract-first on atteint de niveaux d'interopérabilité élevés, mais le développement est assez long et la maintenance de l'interface n'est pas toujours facile [Site 44]. En raison de sa simplicité, on a décidé d'utiliser l'approche code-first. Il faut quand même dire qu'on a écrit l'application en respectant un prototype d'interface défini auparavant. Cet approche intermédiaire a facilité la publication du service web (grâce à la génération automatique du fichier WSDL) tout en maintenant un niveau d'interopérabilité acceptable. Evidemment le fichier WSDL montre des problèmes car certains types de données ne sont pas standard, mais vue la simplicité de l'application générée, cela n'est pas trop un problème! La Figure III-5 montre le fichier WSDL définitif (généré par la class NuSOAP).

74 III Travail pratique 64 Figure III-5: Fichier WSDL du service web

75 III Travail pratique Outils Pour implémenter les applications on a choisi différents outils. Ce sous-chapitre les montre avec, pour chacun une petite définition et les motivations du choix. Apache Server "est un serveur HTTP produit par la Apache Software Foundation. C'est le serveur HTTP le plus populaire du World Wide Web. C'est un logiciel libre avec un type spécifique de licence, nommée licence Apache" [Site 45]. On a choisi ce serveur car il supporte très bien PHP et on le connaissait déjà assez bien. PHP "est un langage de scripts libre principalement utilisé pour être exécuté par un serveur HTTP, mais il peut fonctionner comme n'importe quel langage interprété de façon locale, en exécutant les programmes en ligne de commande. PHP est un langage procédural disposant en version 5 de fonctionnalités de modèle objet complètes" [Site 46]. On a choisi PHP5 comme langage de programmation car on le connaissait très bien et il est un des langages les plus utilisés pour le web. Malheureusement au cours du développement des interfaces on c'est rendu compte que le support SOAP n'est pas encore mûre et cela a causé beaucoup de problèmes. MySQL 5.0 "est un gestionnaire de base de données libre. Il est très utilisé dans les projets libres et dans le milieu industriel" [Site 47]. On a choisi MySQL car c'est le gestionnaire des bases de données le plus utilisé avec PHP et Apache.

76 III Travail pratique ImmoOne Pour pouvoir vérifier le modèle, il fallait tout d'abord développer le site web d'une régie. ImmoOne est implémentée en PHP et pour en définir la structure de la base de données on c'est référé à la structure des applications Quorum [Annexe B] et à la structure des documents XML utilisés par homegate.ch [Annexe C] La Figure III-6 montre la structure de la base de données et la Figure III-7 est un screenshot représentant un objet immobilier à l'intérieur de ImmoOne. Figure III-6: Structure base de données de ImmOne

77 III Travail pratique 67 Figure III-7: Visualisation d'un objet immobilier dans ImmoOne Comme on peut le voir, les informations représentant un objet sont nombreux et c'est pour cela que dans la description de l'interface on c'est limité à 8 seulement (à savoir type, type de contrat, adresse, titre, pièces, prix, n de référence et url). Le service web Pour implémenter les services web (dans ce cas le serveur) on a utilisé la classe open source NuSOAP [Site 48]. Cette classe permet d'implémenter très facilement des services web, mais elle est aussi beaucoup limitée et très peu documentée! La Figure III-8 montre la structure des scripts qui forment le service web.

78 III Travail pratique 68 Figure III-8: Structure du service web dans ImmoOne Server.php est le point d'entrée du service web: c'est en effet ce script qui crée une instance de la classe soap_server (définie en nusoap.php). Le code III-1 montre la fonction PHP qui génère le résultats et le code III-2 montre la déclaration des paramètres (et des types) de cette fonction. De plus, toujours dans le code III-2, on rend la fonction accessible via service web. code III-1: Fonction GetListing en PHP code III-2: Enregistrement de la fonction GetListing avec paramètres et types

79 III Travail pratique 69 Pour finir avec immoone il faut rappeler que la classe NuSOAP génère automatiquement le fichier WSDL qui décrit le service. Pour y accéder il suffit de demander le document en utilisant la variable globale $_GET de PHP. On verra comment le faire dans l'étude de l'intégrateur ImmIntegrator Après avoir terminé le service web, il fallait implémenter l'intégrateur. La Figure III-9 en montre la structure des scripts. Figure III-9: Structure des scripts du ImmIntegrator La classe ClientClass.php est le script le plus important, car c'est lui qui s'occupe de créer les clients pour les différents services web connus. On l'étudiera plus en détail après. La Figure III-10 est l'interface de recherche de cet outil, et dans cette image on voit aussi une liste de résultats (noter que même si ces informations proviennent de plusieurs sites web on ne voit aucune différence). Figure III-10: Interface de ImmIntegrator

80 III Travail pratique 70 Les Clients Plus haut dans ce chapitre on a dit que la classe ClientClass.php est le script le plus important. À l'aide du code III-3 on explique pourquoi. code III-3: Création des clients Ce morceau de code se trouve dans le script index.php. Ce script crée une instance de ClientClass.php en lui passant comme argument l'adresse du fichier WSDL qui décrit le service. On a dit avant que NuSOAP génère un fichier WSDL automatiquement pour le faire il suffit donc d'ajouter?wsdl à l'adresse du service. Chaque instance de ClientClass contient un objet soap_client (défini dans nusoap.php) et en utilisant les méthodes offertes par ClientClass on peut accéder aux fonctionnalités dont on a besoin. Donc quand on appelle $immone_client->docall('getlisting', $params) ce qu'on est en traîne de faire est d'appeler la fonction du serveur GetListing en lui passant les paramètres de recherche introduits par l'utilisateur. Une des fonctionnalités utiles de NuSOAP est le parseur XML. Grâce à cet outil les réponses SOAP sont automatiquement transformées en un array PHP standard. De cette façon il est donc simple imprimer le résultats. Le code III-4 montre l'impression des résultats dans une table.

81 III Travail pratique 71 code III-4: Impression des résultats dans une table Démonstration Jusque là le modèle fonctionne avec les deux applications PHP, mais est-ce que les services web peuvent êtres utilisés par une application qui n'est pas écrite en PHP? Pour répondre à cette question on utilise l'outil SoapUI [Site 49]. Cet outil est capable de lire un fichier WSDL, de générer une requête et de lire une réponse. La Figure III-11 montre une requête SOAP générée à l'aide de SoapUI. Cette requête a été générée automatiquement par SoapUI en lisant le fichier WSDL. Figure III-11: Requête SOAP générée par SoapUI LaFigure III-12, par contre, montre la réponse envoyée par le service web.

82 III Travail pratique 72 Figure III-12: Réponse SOAP reçu par SoapUI Vue que SoapUI a été capable de communiquer avec le service web on a démontré que le modèle peut fonctionner indépendamment des langages de programmation utilisés. Le prochaine chapitre est dédié aux conclusions tirées de ce travail pratique. On évaluera le choix des outils et les résultats obtenus. De plus on proposera des possibles améliorations du modèle et des applications.

83 III Travail pratique 73 5 Conclusion travail pratique Les outils Le choix des outils est un point très important dans l'analyse d'un projet. À cause de l'inexpérience dans le domaine des services web, on a choisi un langage de programmation avec un support insuffisant du standard SOAP. On a résolu ce problème en utilisant la classe NuSOAP, mais on a quand même eu des problèmes avec la gestion des erreurs. De plus la génération automatique du fichier WSDL, bien que très utile, présente des problèmes de compatibilité avec d'autres outils (par exemple Visual Studio). Ceci dit, les autres outils ont été extrêmement faciles à utiliser et ils se sont démontrés le bon choix. Le résultat Pour ce que concerne le résultat, on est vraiment satisfait des applications construites. Le site web de la régie est assez stable, et même si cette application était seulement une base permettant la construction du service web, on a dédié beaucoup de temps à son analyse et implémentation. L'intégrateur couvre aussi les résultats espérés: l'application est très dynamique et il est très simple d'ajouter des nouveaux clients. Les résultats sont obtenus très rapidement (bien que cette propriété dépend su service web) et le seule problème est la gestion des erreurs SOAP. Avec ces applications, on a démontré que le modèle proposé est valable; donc les buts de ce projet ont était accomplis! Améliorations futures Evidemment le modèle implémenté n'est qu'un prototype. Il faut encore travailler sur la définition de l'interface (par exemple en utilisant le style "document/literal" pour respecter les directives du WS-I) et sur la gestion des erreurs.

84 III Travail pratique 74 Du coté de l'intégrateur on pourrait faciliter encore plus la gestion des clients en prévoyant une base de données permettant d'ajouter et effacer les régies de façon complètement dynamique (en évitant de toucher le code). À un niveau encore plus élevé on peut aussi définir un registre UDDI permettant de publier et chercher les régies qui implémentent l'interface et on pourrait aussi ajouter une couche sécuritaire. Conclusion En conclusion, ce travail peut être le point de départ dans la réalisation d'une bonne alternative aux modèles existants. Il est quand même claire qu'il y a encore beaucoup de travail à faire pour que un tel modèle soit réellement utilisable.

85 IV Références 75 IV. Références

86 IV Références 76 Pages Web [Site 1] [Site 2] [Site 3] [Site 4] [Site 5] [Site 6] [Site 7] [Site 8] The Greentree Gazette; the web service revolution Dernier accès le Informit; What s Next for Web Services: GXA and Beyond Dernier accès le The TechWeb Network; Web Services Adoption Spreads Globally Dernier accès le W3C World Wide Web Consortium; Web Services Glossary Dernier accès le Whatis.com; GML definition tml Dernier accès le Wikipedia; SGML definition Dernier accès le W3C World Wide Web Consortium; Happy Birthday, XML! Dernier accès le Webservices.org; The Past, Present and Future of Web Services, part 1 ure/the_past_present_and_future_of_web_services_part_1/(go)/arti cles Dernier accès le

87 IV Références 77 [site 9] CBDI; The web service protocol stack" Dernier accès le [Site 10] [Site 11] W3C World Wide Web Consortium; Web Services Architecture" Dernier accès le Xmlfr.org; Définition XML Dernier accès le [Site 13] W3C World Wide Web Consortium; Simple Object Access Protocol (SOAP) 1.1 note Dernier accès le [Site 14] Oracle; How to create a Document Style Web Service [Site 12] W3C World Wide Web Consortium; SOAP Version 1.2 Partie 1: Structure pour l'échange de messages part1.html Dernier accès le et/webservices/docservice/index.html Dernier accès le [Site 15] W3C World Wide Web Consortium; SOAP Version 1.2 Part 2: Adjuncts (Second Edition) Dernier accès le [Site 16] Alaide.com; Définiton WSDL Dernier accès le

88 IV Références 78 [Site 17] W3schools; Introduction to WSDL Dernier accès le [Site 18] W3C World Wide Web Consortium; Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language Dernier accès le [Site 19] [Site 20] W3schools; WSDL Documents Dernier accès le Global Learning Consortium, Inc; IMS General Web Services WSDL Binding Guidelines Dernier accès le [Site 21] PC Global Services; Définitions: UDDI Dernier accès le [Site 22] OASIS; OASIS UDDI Specification TC Dernier accès le [Site 23] OASIS UDDI; The evolution of UDDI Dernier accès le [Site 24] [Site 25] Wikipedia; Resource Description Framework Dernier accès le Wikipedia; Security assertion markup language Dernier accès le

89 IV Références 79 [Site 26] [Site 27] [Site 28] Journaldunet.com; PHP5: SimpleXML Dernier accès le Wikipedia; Confidentialité Dernier accès le Wikipedia; Intégrité ie%29 Dernier accès le [Site 29] Wikipedia; Clé de chiffrement Dernier accès le [Site 30] Wikipedia; Cryptographie Dernier accès le [Site 31] IBM; Glossary: Security Tokens com.ibm.db2.ii.of.doc/common/iiysgloss.htm Dernier accès le [Site 32] Wikipedia; Segnature numérique Dernier accès le [Site 33] Wikipedia; WS-Security Dernier accès le

90 IV Références 80 [Site 34] OASIS; Web Services Security: SOAP Message Security 1.1 (WS- Security 2004) Dernier accès le [Site 35] Dernier accès le [Site 36] OASIS; Username Token Profile Dernier accès le [Site 37] Wikipedia; Replay Attack Dernier accès le [Site 38] Immoscout24.ch; le point de rencontre de l offre et de la demande int&nav=5&subnav=9&lng=fr&wl=1 Dernier accès le [Site 39] Homegate.ch; Notre entreprise OASIS; Web Services Security: SOAP Message Security 1.1 (WS- Security 2004) Dernier accès le

91 IV Références 81 [Site 40] Homegate.ch; Facts et Figures Dernier accès le [Site 41] Wikipedia; Multiple Listing Service Dernier accès le [Site 42] Wikipedia; Alternatives and changes to the MLS system d_changes_to_the_mls_system Dernier accès le [Site 43] Wikipedia; Real Estate Transaction Standard Dernier accès le [Site 44] Javazone 2005; Contract-Aware Web Service Development Dernier accès le [Site 45] Wikipedia; Apache HTTP Server Dernier accès le [Site 46] Wikipedia; PHP: Hypertext Preprocessor Dernier accès le [Site 47] Wikipedia; MySQL Dernier accès le

92 IV Références 82 [Site 48] Dietrich Ayala Homepage; NuSOAP Homepage Dernier accès le [Site 49] Eviware; soapui Dernier accès le

93 IV Références 83 Livres [Snell 2001] Snell, Tidwell, Kulchenko: Programming Web Services with SOAP, 1st Edition. O'REILLY [St. Laurent 2001] St. Laurent, Johnston, Dumbill: Programming Web Services with XML-RPC, 1st Edition. O'REILLY [Harold 2004] [Iverson 2004] [Myer 2005] [Harold 2004] Harold, Means: XML in a Nutshell, Third Edition. O'REILLY Iverson: Real World Web Services, 1st Edition. O'REILLY Myer: No Nonsense XML Web Development with PHP, 1st Edition. O'REILLY Harold: XML 1.1 Bible, 3rd edition. Wiley Publishing Inc

94 V Annexes 84 V. Annexes

95 V Annexes 85 1 Annexe A: Interview Quorum Software Question: Est-ce que Quorum software pour les régies immobilières offre un module pour traiter les recherches d'objets immobilières on-line (par exemple un site on-line lié à la base de données utilisé par le programme)? Réponse: Oui il le permet et certains client en disposent. Toutefois les clients préfèrent passer par des portails largement connus. Question: Quorum software est-il lié aux grands portails de recherche comme Homegate.ch? Réponse: Oui Question: Comment ce passe-t-il l'échange d'informations entre les deux systèmes? Les données sont copiés dans la base de données du portail. Non il y a une copie FTP des données vers le portail dans un compte propre a chaque client. Le portail lit tous les fichiers plusieurs fois par jour pour actualiser son site. Les données sont envoyés à chaque recherche dans le portail (donc il y a un accès de lecture dans la base de données privée de la régie) Non les régies ne le voudrait pas. Plusieurs régies sont totalement fermées. Les données sont envoyés de façon différente (xml, webservices, ) à chaque requête. Non mais ce serais intéressante.

96 V Annexes 86 2 Annexe B: Structure des objets dans Quorum Software Zones d'un objet Description Type,Format Appartement pour handicapé LOGI - yes/no Ascenseur LOGI - yes/no Assurance perte de loyer LOGI - yes/no Budget publicité DECI - ->>>,>>9.99 Chemin de câble LOGI - yes/no Climatisation LOGI - yes/no Compteur SI 01 CHAR - x(20) Date début LDTR DATE Date début objet DATE Date début situation DATE Date fin LDTR DATE Date fin objet DATE Dispose d'un balcon LOGI - yes/no Désignation immeuble principal CHAR - x(40) Dispose d'un jardin LOGI - yes/no Désignation de l'objet (TBSD) CHAR - x(4) Dépendance 01 CHAR - x(4) Dépendance 02 CHAR - x(4) Dépendance 03 CHAR - x(4) Dépendance 04 CHAR - x(4) Dispose d'une terrasse LOGI - yes/no Dispose d'une cheminée LOGI - yes/no Entretien des appareils ménagers à la LOGI - yes/no charge du locataire Entretien du brûleur à la charge du LOGI - yes/no locataire Entretien détartrage par le locataire LOGI - yes/no Montant de l'estimation fiscale DECI - ->>,>>>,>>9.99 Etages (TBSD) INTE Etat général de l'objet (TBSD) CHAR - X(2) Genre de l'objet (TBSD) CHAR - x(4) Loyer cible DECI - ->>>,>>9.99 Résidentiel LOGI - yes/no Logement meublé LOGI - yes/no Loyer fiscal DECI - ->>>,>>9.99 Loyer LDTR DECI - ->>>,>>9.99 Monte-charge LOGI - yes/no Nombre de pièces canton DECI - >9.9 Nombre de pièces fédérales DECI - >9.9 Nombre de pièces théoriques DECI - >9.9 Nombre de points DECI - >,>>9.99 Nombreux rangements LOGI - yes/no Numéro dépendance 1 CHAR - x(8) Numéro dépendance 2 CHAR - x(8) Numéro dépendance 3 CHAR - x(8)

97 V Annexes 87 Numéro dépendance 4 CHAR - x(8) Numéro lot PPE (I) CHAR - x(10) Numéro PTT objet CHAR - x(6) Numéro WEG (I) CHAR - X(8) Numéro objet CHAR - x(12) Objet calme LOGI - yes/no Objet divisible LOGI - yes/no Objet fictif LOGI - yes/no Traversant LOGI - yes/no Pas dans les listes à louer LOGI - yes/no Catégories PO CHAR - X Adapté pour un animal LOGI - yes/no Publicité par fax LOGI - yes/no Publicité journaux LOGI - yes/no Publicité Internet LOGI - yes/no Publicité régie LOGI - yes/no Code de l'agence CHAR - x(2) Référence de l'immeuble INTE - >>9999 Référence de l'objet INTE Code regroupement ( CHAR - x(2) Réservation objet (TBSD) CHAR - x(2) Revêtement sol chambres (TBSD) CHAR - X(2) Référence de la société INTE - >>9999 Réservé OFL 20 % LOGI - yes/no Revêtement sol séjour (TBSD) CHAR - X(2) Subvention cantonale LOGI - yes/no Subvention fédérale LOGI - yes/no Surface balcon DECI - >>>,>>9.99 Surface objet en m2 DECI - >>>,>>9.99 Surface PPE DECI - >>>,>>9.99 Surface terrasse DECI - >>>,>>9.99 Texte compteur SI Numéro 1 CHAR - x(8) Texte 1 publicité CHAR - X(78) Texte 2 publicité CHAR - X(78) Texte 3 publicité CHAR - X(78) Téléréseau obligatoire LOGI - yes/no Texte recherche (I) CHAR - X(20) Taux d'abattement DECI - >>9.99 Type de cuisine (TBSD) CHAR - X(2) Type de loyer (TBSD) CHAR - x(1) Type de téléréseau (TBSD) CHAR - X(2) Usage de l'objet (TBSD) CHAR - x(4) Volume objet DECI - >>>,>>9.99 WC séparé LOGI - yes/no Surface totale location DECI - >>,>>9.99 Surface totale pondérée location DECI - >>,>>9.99

98 V Annexes 88 Zones complémentaires de l'objet durant la location Description Type,Format Action relocation CHAR - X(20) Montant des charges proposées DECI - ->>>,>>9.99 Collaborateur responsable travaux CHAR - X(4) Date de début travaux DATE Date début vacant (I) DATE Date de début de la publicité DATE Date entrée souhaitée DATE Date de fin travaux DATE Date disponible (IP 1) DATE Dossier terminé LOGI - yes/no Heure de visite CHAR - x(15) Référence de l'immeuble lié (I) INTE - >>9999 Loyer minimum DECI - ->>>,>>9.99 Loyer objet lié DECI - ->>>,>>9.99 Loyer proposé DECI - ->>>,>>9.99 Montant de travaux DECI - ->>>,>>9.99 Nombre de demandes INTE - ->>>9 Nombre de publicités INTE - >,>>9 Nouveau dans portefeuille LOGI - yes/no Référence de l'objet lié (I) INTE Portefeuille à proposer LOGI - yes/no Probabilité de réalisation DECI - >>9.99 Référence de l'immeuble INTE - >>9999 Référence de l'objet INTE Référence prospect location INTE - ->>>>>>>>>9 Réponse de la résiliation au propriétaire DATE Code réservation (TBSD) CHAR - x(2) Résiliation signalée au propriétaire DATE Référence de la société INTE - >>9999 Statut de l'objet vacant (TBSD) CHAR - x(1) Statut objets vacants (TBSD) CHAR - X(2) Subvention cantonale LOGI - yes/no Subvention fédérale LOGI - yes/no Travaux à faire CHAR - X(78) Travaux objets vacants (TBSD) CHAR - x(2) Travaux terminés LOGI - yes/no Type de recherche (TBSD) (I) CHAR - x(1) Visite préliminaire effectué LOGI - yes/no Visite collaborateur CHAR - X(40) Visite de l'objet (TBSD) CHAR - x(2) Visite CHAR - X(40) Visite natel CHAR - X(15) Visite service CHAR - X(40) Visite téléphone CHAR - X(15)

99 V Annexes 89 3 Annexe C: Structure des objets dans Homegate.ch Description type Wording on page version str(50) Tool-Version sender_id str(50) Sender-ID category str(25) Objektkategorie type int(3) Objettyp deal str(200) Verkauf/Vermietung ref_prop str(80) Liegenschaftsreferenz ref_house str(80) Hausreferenz ref_obj str(80) Objektreferenz street str(200) Strasse, Nr zip str(10) Postleitzahl city str(200) Ort state str(3) Kanton country str(2) Land region str(200) bitte leer lassen situation str(50) Situationsbeschrieb available_from date Verfügbar ab title str(200) Titel description str(4000) Beschreibungstext selling_price int(10) Verkaufspreis / Bruttomiete rent_net int(10) Netto Miete rent_extra int(10) Nebenkosten price_unit str(10) Preiseinheit ccy str(3) Währung gross_premium str(19) Bruttorendite floor int(6) Etage nb_rooms int(5,1) Anzahl Zimmer nb_appts int(5,1) Anzahl Wohnungen surface_living int(10) Wohnfläche surface_property int(10) Grundstückfläche surface_usable int(10) Nutzfläche volume int(10) Kubatur year_built int(4) Baujahr prop_view str(1) Aussicht prop_fireplace str(1) Cheminée prop_cabletv str(1) Kabelfernsehen prop_lift str(1) Lift prop_family str(1) Kinderfreundlich prop_parking str(1) Parkplatz prop_garage str(1) Garage prop_balcony str(1) Balkon/Sitzplatz prop_rooffloor str(1) bitte leer lassen dist_publictrans int(5) Distanz Öffentlicher Verkehr dist_shop int(5) Distanz Einkauf dist_kindergarten int(5) Distanz Kindergarten dist_school1 int(5) Distanz Primarschule

100 V Annexes 90 dist_school2 int(5) Distanz Oberstufe pic1 str(200) Bild1 pic2 str(200) Bild2 pic3 str(200) Bild3 pic4 str(200) Bild4 pic5 str(200) Bild5 pic_title1 str(200) Bild1 Titel pic_title2 str(200) Bild2 Titel pic_title3 str(200) Bild3 Titel pic_title4 str(200) Bild4 Titel pic_title5 str(200) Bild5 Titel pic_desc1 str(1800) Bild1 Beschreibung pic_desc2 str(1800) Bild2 Beschreibung pic_desc3 str(1800) Bild3 Beschreibung pic_desc4 str(1800) Bild4 Beschreibung pic_desc5 str(1800) Bild5 Beschreibung movie str(200) Film movie_title str(200) bitte leer lassen movie_desc str(1800) bitte leer lassen doc str(200) Dokumentation doc_title str(200) bitte leer lassen doc_desc str(1800) bitte leer lassen Link auf Homepage über das url str(200) Objekt der von homegate zugeteilte Benutzername agency_id str(10) agency_name str(200) Agentur Name agency_name2 str(255) Agentur Name (Zusatz) agency_ref str(200) Name Kontaktperson agency_street str(200) Strasse, Nr agency_zip str(200) Postleitzahl agency_city str(200) Ort agency_country str(2) Land agency_phone str(200) Telefonnummer agency_mobile str(200) Mobilenummer agency_fax str(200) Faxnummer agency_ str(200) Adresse agency_logo str(200) bitte leer lassen visit_name str(200) Name der Person für die Besichtigungstermine Telefonnummer (für Besichtigungsanfragen) visit_phone str(200) visit_ str(200) bitte leer lassen visit_remark str(200) Kommentar zur Besichtigung publish_until date bitte leer lassen destination str(200) bitte leer lassen pic6 str(200) Bild6 pic7 str(200) Bild7 pic8 str(200) Bild8 pic9 str(200) Bild9

101 V Annexes 91 pic_title6 str(200) Bild6 Titel pic_title7 str(200) Bild7 Titel pic_title8 str(200) Bild8 Titel pic_title9 str(200) Bild9 Titel pic_desc6 str(1800) Bild6 Beschreibung pic_desc7 str(1800) Bild7 Beschreibung pic_desc8 str(1800) Bild8 Beschreibung pic_desc9 str(1800) Bild9 Beschreibung PicturePhotoPlan1 int(1) bitte leer lassen PicturePhotoPlan2 int(1) bitte leer lassen PicturePhotoPlan3 int(1) bitte leer lassen PicturePhotoPlan4 int(1) bitte leer lassen PicturePhotoPlan5 int(1) bitte leer lassen PicturePhotoPlan6 int(1) bitte leer lassen PicturePhotoPlan7 int(1) bitte leer lassen PicturePhotoPlan8 int(1) bitte leer lassen PicturePhotoPlan9 int(1) bitte leer lassen DistFromMotorway int(5) Distanz Autobahnanschluss RoomHeight int(10,1) Raumhöhe HallHeight int(10,1) Hallenhöhe MaxFloorLoading int(10,1) Max. Bodenbelastung CarryingCapacityCrane int(10,1) max. Gewicht Kran CarryingCapacityElevator int(10,1) max. Gewicht Warenlift ISDN str(1) ISDN Anschluss WheelchairAccess str(1) Rollstuhlgängig AnimalAllowed str(1) Haustiere erlaubt Ramp str(1) Anfahrrampe LiftingPlatform str(1) Hebebühne RailwayTerminal str(1) Bahnanschluss Restrooms str(1) Toiletten WaterSupply str(1) Wasseranschluss SewageSupply str(1) Abwasseranschluss PowerSupply str(1) Stromanschluss GasSupply str(1) Gasanschluss MunicipalInfo str(1) bitte leer lassen

102 V Annexes 92 4 Annexe D: Code source de immone/ws/server.php <? require('lib/nusoap.php'); require('readdress.php'); require('reobject.php'); require('relisting.php'); //THIS IS THE WEB SERVICE ONLY FUNCTION! //Returns an array full of objects respecting the given criteria function GetListing($ObjectType, $ContractType, $MinPrice, $MaxPrice, $Zip, $MinRooms) { //create listing $listing = new ReListing($ObjectType, $ContractType, $MinPrice, $MaxPrice, $Zip, $MinRooms); } //do Search try { $listing->dosearch(); //generate listing array $arr_listing = $listing->getobjectarray(); //returning value return $arr_listing; } catch(exception $e) { //NUSOAP SOAP FAULT HANDLING DOES NOT WORK PROPERLY (VERY POOR DOCUMENTATION TOO!) $myerror = "error"; return array(); } $request = isset($http_raw_post_data)? $HTTP_RAW_POST_DATA : ''; $server = new soap_server(); $server->configurewsdl('immone_ws_wsdl', 'urn:immone_ws_wsdl'); //add ReAddress type to wsdl $server->wsdl->addcomplextype('readdress', 'complextype', 'struct', 'all', '', array( 'street'=>array('name'=>'street','type'=>'xsd:string'), 'zip'=>array('name'=>'zip', 'type'=>'xsd:int'), 'city'=>array('name'=>'city', 'type'=>'xsd:string'), 'area'=>array('name'=>'area', 'type'=>'xsd:string'), 'country'=>array('name'=>'country', 'type'=>'xsd:string') ) ); //add ReObject type to wsdl $server->wsdl->addcomplextype('reobject',

103 V Annexes 93 ); 'complextype', 'struct', 'all', '', array( 'object_type'=>array('name'=>'object_type','type'=>'xsd:string'), 'title'=>array('name'=>'title', 'type'=>'xsd:string'), 'rooms'=>array('name'=>'rooms', 'type'=>'xsd:float'), 'contract_type'=>array('name'=>'contract_type', 'type'=>'xsd:string'), 'price'=>array('name'=>'price', 'type'=>'xsd:float'), 'reference'=>array('name'=>'reference', 'type'=>'xsd:string'), 'url'=>array('name'=>'url', 'type'=>'xsd:string'), 'address'=>array('name'=>'address', 'type'=>'tns:readdress') ) //add ReListing type to wsdl $server->wsdl->addcomplextype('relisting', 'complextype', 'array', '', 'SOAP-ENC:Array', array(), array( array('ref'=>'soap-enc:arraytype','wsdl:arraytype'=>'tns:reobject[]') ), 'tns:reobject' ); //GetListing function input parameters array $GetListingParamIn = array('objecttype' => 'xsd:string', 'ContractType' => 'xsd:string', 'MinPrice' => 'xsd:double', 'MaxPrice' => 'xsd:double', 'Zip' => 'xsd:int', 'MinRooms' => 'xsd:float'); //GetListing function output parameters array $GetListingParamOut = array('return' => 'tns:relisting'); //register the GetListing function $server->register('getlisting', $GetListingParamIn, $GetListingParamOut, 'immone_ws_wsdl', 'immone_ws_wsdl#getlisting', 'rpc', 'encoded', 'Returns the the listing'); if(isset($error)) { $fault = $server->fault('soap:server','my description about why this error was thrown'); } $server->service($request);?>

104 V Annexes 94 5 Annexe E: Code Source de immintegrator/index.php <? include('ws_clients/clientclass.php'); include('header.php');?> <div id="formdiv"> <form name="immintegrform" action="<? $_SERVER['phpself']?>" method="get"> <table class="infotable formtable"> <tr> <td colspan="7"><center><b>search Form</b></center></td> </tr> <tr> <td colspan="7"><hr></td> </tr> <tr> <td><b>object Type</b></td> <td><b>contract</b></td> <td><b>min Price</b></td> <td><b>max Price</b></td> <td><b>zip</b></td> <td><b>min Rooms</b></td> <td><b> </b></td> </tr> <tr> <td> <select name="object_type"> <option value="apartment" selected>apartment</option> <option value="house">house</option> </select> </td> <td> <select name="contract_type"> <option value="rent" selected>rent</option> <option value="sell">sell</option> </select> </td> <td><input type="text" name="min_price" value="" size="6"></td> <td><input type="text" name="max_price" value="" size="6"></td> <td><input type="text" name="zip" value="" size="6"></td> <td><input type="text" name="min_rooms" value="" size="6"></td> <td><input type="submit" value="submit" name="submit"></td> </tr> </table> </div> </form> <? if(isset($_get['submit'])) { //Notify Query Parameters echo "<hr class=\"hr1\">"; echo "<p align=\"center\">results for query: "; echo "<b>object Type:</b> ".$_GET['object_type']." - "; echo "<b>contract Type:</b> ".$_GET['contract_type']." - "; echo "<b>min Price:</b> ".$_GET['min_price']." - "; echo "<b>max Price:</b> ".$_GET['max_price']." - ";

105 V Annexes 95 echo "<b>zip:</b> ".$_GET['zip']." - "; echo "<b>min Rooms:</b> ".$_GET['min_rooms']."</p>"; echo "<hr class=\"hr1\">"; //Analyse $_GET variables $minprice = 0; $maxprice = 0; $zip = 0; $minrooms = 0; if($_get['min_price']!= '' &&!is_null($_get['min_price'])) $minprice = (int)$_get['min_price']; if($_get['max_price']!= '' &&!is_null($_get['max_price'])) $maxprice = (int)$_get['max_price']; if($_get['zip']!= '' &&!is_null($_get['zip'])) (int)$zip = $_GET['zip']; if($_get['min_rooms']!= '' &&!is_null($_get['min_rooms'])) $minrooms = (float)$_get['min_rooms']; //set parameters for GetListing function $param = array('objecttype' => $_GET['object_type'], 'ContractType' => $_GET['contract_type'], 'MinPrice' => $minprice, 'MaxPrice' => $maxprice, 'Zip' => $zip, 'MinRooms' => $minrooms); //set the objects $immone_client = new ClientClass(' $immone_web_client = new ClientClass(' space.ch/immone/ws_web/server.php?wsdl'); $res = array(); $res[] = $immone_client->docall('getlisting', $param); $res[] = $immone_web_client->docall('getlisting', $param); $err = $immone_client->geterror(); $fault = $immone_client->getfault(); if ($err) { echo '<h2>immone error</h2><pre>'. $err. '</pre>'; } if($fault) { echo '<h2>immone fault</h2><pre>'. $fault. '</pre>'; }?> <div id="centercontainer"> <table class="editortable"> <tr class="rowstyle_0"> <td><b>type</b></td> <td><b>contract</b></td> <td><b>address</b></td> <td><b>title</b></td> <td><b>rooms</b></td> <td><b>price</b></td> <td><b>reference</b></td> <td><b>link</b></td>

106 V Annexes 96 <? </tr> $x = 1; foreach($res as $listing) { if(is_array($listing)) { foreach($listing as $obj) { $addr = array(); $addr = $obj['address']; $tr_style = 'rowstyle_'.$x++ % 2; echo "<tr class=\"$tr_style\">"; echo "<td>$obj[object_type]</td>"; echo "<td>$obj[contract_type]</td>"; echo "<td>$addr[street], $addr[zip] $addr[city] ($addr[area] - $addr[country])</td>"; echo "<td>$obj[title]</td>"; echo "<td>$obj[rooms]</td>"; echo "<td>$obj[price]</td>"; echo "<td>$obj[reference]</td>"; echo "<td><a href=\"$obj[url]\" target=\"_blank\"><img src=\"images/go.png\"></a></td>"; echo "</tr>"; } } }?> </table> </div> <? echo '<h2>request</h2><pre>'. htmlspecialchars($immone_client->getrequest(), ENT_QUOTES). '</pre>'; echo '<h2>response</h2><pre>'. htmlspecialchars($immone_client->getresponse(), ENT_QUOTES). '</pre>'; echo '<h2>debug</h2><pre>'. htmlspecialchars($immone_client->getdebug(), ENT_QUOTES). '</pre>'; } include('footer.php');?>

107 V Annexes 97 6 Annexe F: Code Source de ClientClass.php <? require('lib/nusoap.php'); Class ClientClass { //vars protected $wsdl_string; protected $client; protected $param_object; protected $result_array; //Constructor public function construct($wsdl) { //set the wsdl string $this->wsdl_string = $wsdl; } //create the real soap client $this->client = new soapclient2($this->wsdl_string, 'wsdl'); //executes a function call and returns the returned array public function docall($funct_name, $param_arr) { return $this->client->call($funct_name, $param_arr); } //returns the last soap request public function getrequest() { return $this->client->request; } //returns the last soap response public function getresponse() { return $this->client->response; } //return the debug string public function getdebug() { return $this->client->debug_str; } //returns the soap error if exists public function geterror() { return $this->client->geterror(); } //returns the soap fault if exists public function getfault() { //return $this->client->fault; if($this->client->fault)

108 V Annexes 98 } } { } else { } return $this->client->fault; return false;?>

109 V Annexes 99 7 Annexe G: Guide d'installation Les pages qui suivent concernent l'installation d'une plateforme de test (Apache, PHP5 et MySQL) et des applications développées dans le cadre de ce projet (ImmoOne et ImmIntegrator). Installer la plateforme Pour simplifier l'installation des outils nécessaires on propose d'installer la plateforme Wamp 10. Cette plateforme installe le serveur Apache, PHP5 et MySQL en une seule action. Pour installer Wamp sélectionnez le fichier wamp5_1.7.3.exe (contenu dans le cd-rom) et suivez les instructions à l'écran. Pour éviter des problèmes, il est mieux de laisser toutes les configurations par défaut. Une fois l'installation accomplie on peut voir une petite icône (en bas à droite): cette icône est le point de départ de la plateforme. 10

110 V Annexes 100 Configurations PHP Apres avoir installé Wamp il faut encore configurer le php. Pour le faire, cliquez sur Icône Wamp->php settings->short open tag comme montré dans l'image suivante.

111 V Annexes 101 Ensuite il faut aussi installer la librairie gd2. Après avoir cliqué sur php_gd2 il faut re-ouvrir la liste des extensions et contrôler que la librairie a été installée (on trouve une petite flèche à gauche).

112 V Annexes 102 Installer les applications Pour contrôler que la plateforme fonctionne il faut ouvrir le browser et aller à l'adresse Si tout a bien marché on verra la page suivante: Maintenant il faut ouvrir le dossier dans lequel on va mettre les applications: cliquez sur Icône Wamp->www directory

113 V Annexes 103 On voit que le dossier contient 3 fichiers À ce moment on doit copier les dossiers immone et immintegrator (contenus dans le cd-rom) dans ce dossier. Pour contrôler que les applications ont été bien installées il faut rafraîchir le browser. Si tout c'est bien passé, on trouvera les deux projets à gauche comme montré dans l'image suivante.

114 V Annexes 104 Création de la base de données Pour que les applications fonctionnent il faut maintenant créer la base de données de immoone. Ouvrez donc phpmyadmin

115 V Annexes 105 Dans la page ouverte on va donc créer une nouvelle base de données (appelée immone). Insérez "immone" dans le champ (comme dans l'image) et cliquez sur "create". Après avoir crée la base de données, il faut importer le fichier "immoneinstall.sql" contenu dans le cd-rom. Pour le faire cliquez sur "import" (en haut à droite).

116 V Annexes 106 Dans la fenêtre suivante cherchez le fichier et importez-le. Après avoir importé le fichier phpmyadmin montre un message de confirmation Tester les applications Finalement tout a été installé! Maintenant il faut tester les applications. Ouvrez le browser et allez à l'adresse Une page de login vous sera montrée

117 V Annexes 107 Tapez "guest" dans les deux champs (username et password) D'après l'authentification on cherche un objet pour tester le correcte fonctionnement de immoone. À gauche, dans le box "Search By Ref" tapez "IOA1223" et cliquez sur "go". Une fois que la recherche est finie, l'application vous montre l'objet dans la section centrale de la page

118 V Annexes 108 Bien! ImmoOne fonctionne très bien. Maintenant on va tester l'intégrateur. Pour le faire il faut visiter la page La page principale de l'intégrateur vous est montrée. Il suffit maintenant de cliquer sur submit pour rechercher tous les appartements à louer (la recherche est effectuée dans le site local ImmoOne et aussi dans la copie online). On voit donc les résultats et les requêtes/réponses SOAP. Félicitations: vous avez installé les deux applications.