You are on page 1of 118

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 1 6600 Locarno Suisse

Encadré par: Dr. Stefan Hüsemann

Septembre 2007

ii

A mes proches Merci pour le soutien continu

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

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

v Table des matières I. 1 2 3 4 II. 1 1.1. 1.2. Introduction............................................................................................................... 1 Motivations ........................................................................................................... 2 Objectifs du travail................................................................................................ 2 Questions traitées.................................................................................................. 3 A qui s’adresse le travail?..................................................................................... 3 Les Services Web...................................................................................................... 4 Théorie et principes des services web................................................................... 5 Qu'est-ce que un service web? ...................................................................... 5 Histoire des services web.............................................................................. 8 1.2.1. 1.2.2. 1.2.3. 1.3. 1.3.1. 1.3.2. 1.3.3. 1.3.4. 1.3.5. 1.4. 1.4.1. 1.4.2. 1.4.3. 1.4.4. 1.4.5. 1.4.6. 1.4.7. 2 2.1. 2.2. Le contexte............................................................................................ 8 L'histoire de XML................................................................................. 8 L’évolution des services web.............................................................. 10 Web Service Stack .............................................................................. 12 Extensible Markup Language ............................................................. 15 Simple Object Access Protocol........................................................... 21 Web Service Description Language ................................................... 31 Universal Description Discovery and Integration .............................. 34 Protocoles de package......................................................................... 38 Protocoles de description .................................................................... 38 Protocoles de recherche/découverte.................................................... 39 Protocoles de sécurité ......................................................................... 39 Protocoles de transport........................................................................ 40 Protocoles de routage et workflow ..................................................... 40 Langages de programmation et plateformes ....................................... 41

Technologies de base des services web ...................................................... 12

Autres Standards ......................................................................................... 38

Sécurité ............................................................................................................... 42 Terminologie............................................................................................... 43 Web Service Security.................................................................................. 45 2.2.1. 2.2.2. 2.2.3. Le modèle de sécurité ......................................................................... 46 Le Security header .............................................................................. 46 Username Token ................................................................................. 47

3

Conclusion Théorie............................................................................................. 52

vi III. Travail pratique....................................................................................................... 53 1 2 2.1. Introduction......................................................................................................... 54 Le problème de la recherche d'objets immobiliers ............................................. 54 Les portails dédiés ...................................................................................... 56 2.1.1. 2.1.2. 3 3.1. 3.2. 4 4.1. Homegate et Immoscout24 ................................................................. 56 Fonctionnement et limites des portails dédiés .................................... 57

Situation aux Etats-Unis et au Canada................................................................ 58 Multiple Listing Service (MLS) ................................................................. 58 Real Estate Transaction Protocol (RETS) .................................................. 58 Solution proposée ............................................................................................... 60 Modèle ........................................................................................................ 60 4.1.1. 4.1.2. 4.1.3. Fonctionnement .................................................................................. 61 Avantages............................................................................................ 61 Limites ................................................................................................ 61

4.2. 4.3.

Architecture ................................................................................................ 62 Implémentation ........................................................................................... 63 4.3.1. 4.3.2. 4.3.3. 4.3.4. 4.3.5. Code-First ou Contract-First? ............................................................. 63 Outils................................................................................................... 65 ImmoOne ............................................................................................ 66 ImmIntegrator ..................................................................................... 69 Démonstration..................................................................................... 71

5

Conclusion travail pratique................................................................................. 73

IV. Références............................................................................................................... 75 V. 1 2 3 4 5 6 7 Annexes .................................................................................................................. 84 Annexe A: Interview Quorum Software............................................................. 85 Annexe B: Structure des objets dans Quorum Software..................................... 86 Annexe C: Structure des objets dans Homegate.ch ............................................ 89 Annexe D: Code source de immone/ws/server.php............................................ 92 Annexe E: Code Source de immIntegrator/index.php ........................................ 94 Annexe F: Code Source de ClientClass.php....................................................... 97 Annexe G: Guide d'installation........................................................................... 99

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

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

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

Domaine Ressource 1 Ressource 2 . Ces ressources sont proposées pour étudier les aspects exclus ou qui n’ont pas étés présentés en détail.> <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.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….

I Introduction 1 I. Introduction .

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. 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. 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. 2 Objectifs du travail Le but de ce travail est. 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. 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. 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 une première partie. . 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. car la technologie n'est pas assez mûre [Site 2]. D’autre part.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.

Comment peut-on améliorer la recherche d'objets immobiliers? 2. 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. Quelles sont les standards utilisés dans les services web? 3. Est-ce que les services web sont l'outil adéquat? 3. D’autre part. Qu'est-ce qu'un service web? 2. 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. .I Introduction 3 3 Questions traitées Du point de vue théorique ce travail répond aux questions relatives les services web. 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. 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. 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. Quels sont les avantages des services web? 4. telles que: 1.

Les Services Web .II Les Services Web 4 II.

UDDI et WSDL (on en parlera après) et passer directement à une définition simple et au même temps précise. p1]. qui peut laisser place à une incompréhension partielle du domaine en question et causer des problèmes lors d'un étude plus détaillé.II Les Services Web 5 1 Théorie et principes des services web Ce premier chapitre explique de façon claire les services web. l’étude des différents langages avec une approche "bottom-up" nous aidera à construire les connaissances nécessaires à comprendre le cas d’étude. Dans les différents sites web dédiés à ce domaine de l'informatique et dans les sources de cet ouvrage. Certains auteurs clarifient les aspects théoriques. Par contre. Qu'est-ce que un service web? Même si cette question peut paraître très simple. Dans cette optique il est donc mieux d'éviter des termes comme SOAP. 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. il n'existe pas une réponse facile. "Un service web est une interface pour une application accessible par réseau construite en utilisant des technologies standards de l'Internet. De plus. 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." [Snell 2002. 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. p1] . 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!). il existe beaucoup de réponses hétérogènes. 1. il faut éviter une définition trop générique.1.

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é. Interface La Figure II-1 montre clairement le rôle d'interface qui est propre aux services web.3 on verra quels sont les standards dérivés de XML permettant la communication entre le client et le serveur. À ce propos il existe un canal très développé et expérimenté: l'Internet. Dans le sous-chapitre 1. Maintenant une définition plus complète peut être exprimée. 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é. 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.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. ces messages peuvent être échangés en utilisant d’autres protocoles (comme le SMTP par exemple). comme on le verra dans les chapitres suivants. Mais. Et quelle est la meilleure si non celle du W3C? [Site 4] . Plus précisément le protocole qui permet aux différents messages de voyager d'une application vers une autre est le HTTP. Figure II-1: Service Web [Snell 2002.

cette définition contient toutes les informations dont on a parlé précédemment et en ajoute des nouvelles. Cette nouvelle définition. cependant. Its definition can be discovered by other software systems. de XML (technologies standard) et des protocoles internet. using XML based messages conveyed by Internet protocols. These systems may then interact with the Web service in a manner prescribed by its definition.” Comme on le voit donc. La définition de Snell inclue les concepts d'interface. 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). .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.

L'histoire de XML Les bases de XML reviennent 30 ans à l’arrière. 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é). et . 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.2. avec le web les paramètres avaient beaucoup changés.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. une version internationale standardisée fût présentée au monde. Mais il fallait quand même attendre les années 80 pour que. 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. Ce premier pas était alors connu sous le nom de GML [Site 5]. 1 International Organization for Standardization . vers une approche machine-machine. Nonobstant la standardisation.2. 1. quand le chercheur de IBM Charles Goldfarb introduisait le concept de Markup (marquage). grâce à ISO1. Le contexte Evidemment le contexte des services web est l’Internet. 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.2.2. Cette révolution a introduit le besoin de standardiser la description de la structure de n'importe quel document.1. C'est là que XML entre en jeu! 1.II Les Services Web 8 1.

. La spécification de XML doit être disponible rapidement 8. 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. le 10 février 1998. le W3C formait en 1996 le SGML Editorial Review Board (successivement appelé XML Working Group) que. Il doit être facile d'écrire des programmes traitant les documents XML 5. La conception de XML doit être formelle et concise 9.0 naquit. tout en préservant ces idées fondamentales. idéalement à aucune 6. les objectifs ont été tous respectés et le XML 1. XML doit être compatible avec SGML et HTML 4. La concision dans le balisage de XML est peu importante Finalement. Les bases de ce projet se résument en 10 objectifs: 1. Les documents XML doivent être lisibles par l'homme et raisonnablement clairs 7. À ce propos tout le monde était d'accord sûr le fait que le SGML était parfait pour ces exigences. XML doit soutenir une grande variété d'applications 3. Il doit être facile de créer des documents XML 10. à comprendre et à l'implémenter. avec la participation active du SGML Working Group (successivement appelé XML Special Interest Group) travaillait au nouveau langage. XML doit pouvoir être utilisé sans difficulté sur Internet 2. [Site 7] Pour répondre à ces besoins. Le nombre d'options dans XML doit être réduit au minimum.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. mais il fallait le rendre plus simple à apprendre.

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. L'age des minicomputers est un peu ignorée (peut être à cause de la révolution des PC. L’évolution des services web La naissance des services web est due à beaucoup de facteurs. À 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. Present and Future of Web Services" de Uche Ogbuji [Site 8].II Les Services Web 10 1. Le secteur IT choisissait les objets comme standard de développement des applications (à cause des ses promesses sur la réutilisabilité. 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.2. . furent orientées dans ce sens. sur la maintenance et sur le Return On Investment). car il n'existaient pas des connexions entre les différents mainframes. Au début les managers IT ne devaient pas se préoccuper de la coopération entre les ordinateurs. En parallèle E-mail 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. La distribution de services entre les différents minicomputers requit beaucoup d'approches différentes pour communiquer de façon soit synchrone qu'asynchrone.3. Cette section résume les points les plus importants de l'article "The Past. 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. elles aussi. Les technologies distribuées. 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.

elle lançait sur le marché e-Speak. Une autre entreprise qui a lancé un produit très important est Useland avec son XML-RPC. La nouvelle technologie devait utiliser les standards de l'Internet. . mais c'est justement cette simplicité (trop de limitations) qu'en a limité son usage à la seule communauté Open Source. 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. Il fallait supporter les échanges à l'intérieur de l'entreprise et ceux entre différentes entreprises. Cette technologie était très simple.II Les Services Web 11 Aux portes du nouveau millenium les bases pour une nouvelle technologie de systèmes repartis étaient prêtes. Les développeurs et les managers devaient avoir un très riche support des différents revendeurs. En 1999. En 1999 arrivait aussi SOAP. qui permettait un échange de messages beaucoup plus complet que les autres. Elle devait être "Fault-tolerant". 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. tout en respectant le concept de "cross-platform". Elle devait supporter à plein la scalabilité Elle devait supporter à plein l'internationalisation. Il devait être possible d'échanger facilement messages simples et messages complexes dans un environnement sécurisé (où nécessaire). 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. qui peut être considérée la première technologie orienté service (elle utilisait HTTP et XML).

Dans un deuxième temps on a un aperçu de XML et on analyse dans les détails SOAP. 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. 1. C'est grâce à XML que des standards comme UDDI. 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.1. 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. • Universal Discovery. WSDL et UDDI seront montrés rapidement. . Ces protocoles sont maintenant universellement acceptés et sont donc des standards de facto. • Web Service Description Language (WSDL) – décrit un service web et la forme du message SOAP nécessaire pour effectuer les requêtes. Il est indépendant de n’importe quel moyen de transmission. Cette section présente brièvement l'architecture des services web et le Web Service Stack.3. Web Service Stack Les services web se composent d'une collection de standards que l'on regroupe sous le nom de Web Service Stack.3.II Les Services Web 12 1. WSDL et SOAP (pour en citer quelques uns seulement) sont nés. La Figure II-2 montre l’interaction des trois technologies.

La Figure II-3 montre la vision de la pile des protocoles actuels donnée par le W3C [Site 10] . du besoin croissant de décrire et implémenter nouveaux et plus complexes scénarios de business. Ces trois standards ont permis le développement initial des services web et ils ont incités beaucoup d’entreprises à leur utilisation. à cause des problèmes de sécurité et de fiabilité. WSDL et SOAP [Site 9] Pour comprendre cette image imaginons qu'un informaticien veut développer un système d'informations boursières. plusieurs autres standards ont été proposés. Dans ce système il veut montrer l'évolution de certaines actions. 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. [Site 9] La situation est en évolution continue et il existe différentes vues de la pile (quoique elles se ressemblent toutes). Certains se sont affirmés.II Les Services Web 13 Figure II-2: Relation entre UDDI. Cependant. 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. d’autres sont disparus et d’autres encore ont étés réunis pour en augmenter leur puissance.

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

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. p1]. 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. 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".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. 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. pourquoi est-il à la base des services web? Ce chapitre traitera de façon superficielle le langage.2. d'un élément racine (contenant tous les autres éléments) et des différents éléments et attributs.II Les Services Web 15 1. Structure d'un document XML Un document XML est composé fondamentalement d'une déclaration XML. Dans une première partie on verra l'utilisation de XML pour décrire des documents.3. . Mais qu'est-ce que c'est exactement? Qu'est-ce que rend XML tellement spécial? Et. Extensible Markup Language Tout le monde a déjà entendu parler de XML. [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.

Il n'y a pas de restrictions dans la définition d'éléments. sinon c'est un attribut". à louer). ses attributs. D'après on trouve les éléments fils <title>. appartement) et la modalité du contrat (en vente. le contenu et une balise de fermeture. Il faut quant même se rappeler qu'un élément doit avoir une balise de fermeture identique à celle d'ouverture (sauf pour le '/'). <?xml version="1. Une "règle" utilisée souvent est: "Si le contenu est grand. Cet objet a deux attributs (type et mode) lesquels indiquent le type d'objet (maison. alors c'est un élément. . Voilà un exemple d'élément simple: <myElement>je suis un élément</myElement> code II-2: Elément simple Attributs Les attributs sont utilisés pour ajouter des informations sûr les éléments.II Les Services Web 16 Eléments Un élément consiste en une balise d'ouverture.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">1200000</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. Il n'existe pas une règle pour décider quelle information est un attribut et quelle est un élément. 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.

En effet. Pour continuer dans l'étude de XML ces concepts doivent êtres clarifiés. Même (X)HTML a été définit avec XML et il doit donc respecter de règles définies par le W3C. Well-formedness Un document XML doit être bien formé. etc. De plus les attributs doivent êtres contenus entre guillemets (attribut="valeur"). obligatoire qu'un document ait un élément racine (contenant tous les autres éléments).II Les Services Web 17 <address> et <price>. <zip>. 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. on l'utilise aussi pour définir d'autres langages (dialectes). C'est-à-dire qu'il doit respecter les règles de syntaxe du langage. Dans une optique très superficielle le fonctionnement est le suivant: . Il est. Grâce à la logique arborescente des documents XML l'élément <address> (élément complexe) peut avoir d'autres éléments fils (<street>. Jusqu'ici on n'a pas traité la validité ou le concept de "Well-formedness" (bien formé). par exemple. 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.). chacun avec ses propres règles. XML pour décrire des dialectes XML n'est pas limité à décrire la structure des documents.

"l'élément <object> doit avoir l'attribut mode. lequel peut avoir seulement les valeurs "rent" ou "sell".II Les Services Web 18 Le XMLSchema définit certaines règles (comme.w3. Le code II-5 définit un schéma pour les objets immobiliers. <?xml version="1.org/2001/XMLSchema" 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 .0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www. par exemple.

II Les Services Web 19 Une fois le schéma défini il est possible de valider un document.w3.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.com/products/xmlspy/xml_editor.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="myObjectSchema.html . La Figure II-4 est l'écran de validation de l'outil Altova XMLSpy2 Figure II-4: Ecran de validation de XMLSpy 2 http://www.altova.0" encoding="UTF-8"?> <object xmlns:xsi="http://www. Le code II-6 est un document invalide car l'attribut "mode" a une valeur autre que "rent" ou "sell". <?xml version="1. 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.

en associant ceux-ci avec des espaces de nommage désignés par des références d'URI3.yoyodesign.wikipedia.html . au niveau de la validation d'un document. 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.com/schema/default. 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.asp 3 http://www.org/wiki/XML#Wellformed_and_valid_XML_documents http://www.com/xml/xml_namespaces.w3schools. 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). Le chapitre qu'on vient de terminer n'est pas exhaustif. Ressources Externes WellFormedness XMLSchema Namespaces http://en.asp http://www.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. quel est le schéma à utiliser? 2. 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.w3schools.org/doc/w3c/xml-namespace/Overview.

SOAP est une application de XML et. Figure II-5: Structure de l'enveloppe SOAP [Snell p13] .3.II Les Services Web 21 1. 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). 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. 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.3. [Site 12] Plus en détail. distribué. de plus. la spécification du SOAP ne définit rien d'autre qu'une enveloppe contenant les informations à transmettre. La Figure II-5 montre la structure d'une enveloppe SOAP. Simple Object Access Protocol Définition SOAP est un protocole léger destiné à l'échange d'informations structurées dans un environnement décentralisé. 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.

xmlsoap.1 200 OK Content-Type: text/xml.stockquoteserver.xmlsoap. est la réponse générée qui est envoyé au client.org/soap/envelope/ Sérialisation: http://schemas. charset="utf-8" Content-Length: nnnn <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.II Les Services Web 22 Le SOAP namespace La syntaxe à utiliser pour les messages SOAP est définie dans les deux namespaces suivantes: • • Enveloppe: http://schemas.org/soap/encoding/"> <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 .org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.5</Price> </m:GetLastTradePriceResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> code II-8: Exemple de réponse SOAP [Site 13] .com Content-Type: text/xml.xmlsoap.xmlsoap.xmlsoap.1 Host: www.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas. HTTP/1.xmlsoap. par contre.org/soap/encoding/ 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. charset="utf-8" Content-Length: nnnn: SOAPAction: Some-URI" <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas. POST /StockQuote HTTP/1.org/soap/encoding/"/> <SOAP-ENV:Body> <m:GetLastTradePriceResponse xmlns:m="Some-URI"> <Price>34.

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. envoyées par un émetteur vers un destinataire.. Il existe deux façons d'implémenter le système de requête/réponse: le RPC style et le Document style. La structure de ce document n'est pas lié à la méthode et à ses paramètres.> <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 requête est transformée en méthode et une réponse contenant l'output est générée. . comme l'exemple précédente le montre. C'est l'application (le service) qui s'occupe de lire le document XML et appeler la méthode désirée. on implémente souvent un système de requête/réponse. Quand le message arrive au serveur.. Le WS-I (Web Service Interoperability Organization) conseille l'utilisation du style "Document".II Les Services Web 23 Le modèle d'échange des messages SOAP Les messages SOAP sont normalement des transmissions en une seule direction. Mais. Au début SOAP supportait seulement le style RPC mais à partir de la version 1.0 les deux sont supportés. 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.

Si l'expéditeur requière la compréhension d'un bloque Header il doit ajouter l'attribut MustUnderstand = "true" au bloque... <SOAP-ENV:Envelope . . Cet attribut assure donc la compréhension de toute l'enveloppe SOAP. L'attribut MustUnderstand Quand une application envoie un message à une autre. Comme on a déjà dit. 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. Voyons-les un peu plus en détail. 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). un message SOAP est composé de l'enveloppe (obligatoire).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". l'en-tête (optionnel) et le corps (obligatoire). 3. dans le cas que l'application SOAP ne soit pas le destinataire final. vérifier que toutes les parties nécessaires (identifiées dans l'étape 1) soient supportées par l'application et traitées correctement. identifier toutes les parties du message destinées à cette application 2. Dans le cas où le destinataire trouve ce flag et il ne comprend pas l'en-tête il doit rejeter tout le message. il faut éliminer toutes les parties identifiées dans l'étape 1 avant de passer le message au destinataire suivant.> <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. il est implicite que le destinataire soit capable de traiter le message.

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

xmlsoap. C'est-à-dire que le message est mal formé (mauvaise utilisation des règles de codage). il n'est pas obligatoire. Cet élément doit être présente si l'erreur est généré à cause d'un problème lié au corps du message. Le tableau II-2 les montre avec une description. Erreur VersionMismatch Description L'enveloppe SOAP est en train d'utiliser une version invalide de l'espace de nom pour l'élément enveloppe. 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 http://schemas. MustUnderstand Un bloque en-tête contenant le flag mustUnderstand="true" n'a pas été compris Server Un erreur non pas lié au processus de traitement du message est arrivé Client L'erreur est causé par le message. Faultstring Faultactor Detail 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.II Les Services Web Description 26 Elément Faultcode C'est une valeur générée algorithmiquement qui identifie le type d'erreur. Cette valeur doit être qualifié dans l'XML namespace.org/soap/envelope/. Dans le cas d'un erreur lié à d'autres aspects du traitement du message. ou que les informations contenues sont fausses tableau II-2: Erreurs standard SOAP .

Le code II-12 montre un erreur personnalisé." (cette notation implique que la partie à droite est plus détaillée que celle à gauche).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. l'extensibilité des types standard. La seule requête est qu'ils soient définis correctement dans un espace de nommage. 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. dans le cas où l'extension des types standard ne soit pas suffisante.authentication</faultcode> <faultstring> Invalid credentials </faultstring> <faultactor>http://acme. . <s:envelope xmlns:s="…"> <s:body> <s:fault> <faultcode>client. <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.com</faultactor> <details> <!-. rend les erreurs personnalisés inutiles dans la plus part des cas. Pour étendre un type il faut utiliser le point ".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.

Ces intermédiaires peuvent chacun faire quelque chose avec le message avant de l'envoyer envers les autres acteurs. mais il est possible que le message passe par divers intermédiaires avant d'arriver à destination. Les intermédiaires qui ne s'identifient pas avec l'attribut "actor" doivent ignorer le header. Pour destiner un en-tête à un acteur il faut utiliser l'attribut spéciale "actor". p23]: Imaginons qu'un revendeur reçoit une grande commande d'un client par le biais de son service web. La construction d'une message path n'est pas couverte par la spécification SOAP. Le service fonctionne en vérifiant la validité de l'en-tête contenant la signature numérique. Cet identifiant peut être le URL où l'acteur se trouve (mais aussi quelque chose plus générique). 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 ê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. Il existent diverses extensions SOAP. . 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. comme le Microsoft's SOAP Routing Protocol (WS-Routing).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). qui s'occupent de cette problématique. Voyons maintenant un exemple [Snell 2002. dont la valeur est un identifient unique de l'intermédiaire auquel l'en-tête est destiné. L'ensemble d'intermédiaires à travers lesquels le message passe est appelé message path (chemin du message) et chaque intermédiaire est un acteur. Ce que SOAP spécifie est un mécanisme pour identifier quelles parties du messages sont destinées à quels acteurs.

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. comme dans le code II-13. Cela est accompli en ciblant l'en-tête avec la signature au service de vérification. La Figure II-6 montre la transaction Figure II-6: Chemin d'un message SOAP [Snell. Comme exemple de cette flexibilité. Cette particularité rend SOAP extrêmement flexible et en permet l'utilisation en n'importe quelle situation ou structure de réseau. le message est routé à travers le service de validation.II Les Services Web 29 Quand le client envoie la commande au revendeur. dans le Web Services Stack. <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. SOAP::Lite – l'implémentation de service web SOAP basée sur Perl. 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. 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. SOAP est placé au dessus des couches de transport. écrite par Pavel Kulchenko – supporte la capacité .

que même la spécification SOAP le traite de manière spéciale. 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" . SOAP via HTTP À cause de sa profonde présence dans l'Internet. 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. Le fonctionnement est montré à l'aide de la Figure II-7. Figure II-7: SOAP via http [Snell. Il est tellement important. TCP. MQSeries et Jabber [Snell 2002. p34]. en fournissant des détails sur la sémantique du modèle d'échange SOAP en relation à HTTP [Site 15]. SMTP. HTTP est le moyen de transport le plus utilisé pour l'échange des messages SOAP.II Les Services Web 30 d'échanger messages SOAP via http. 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. FTP. POP3. Bien que cette couple fonctionne très bien.

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

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

w3schools.org/TR/wsdl http://www.w3.com/wsdl/default.asp . 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 http://www.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.

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

Le tableau II-4 montre les différences entre les trois types: de l'entreprise. 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é. la description identifiants.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. • 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. mais également l'ensemble de ses . On y retrouve donc des informations comme le nom de l'entreprise. Ces informations concernent les descriptions de services et d'information de liaison ou encore les processus métiers associés. ses coordonnées.

jsp?topic=/com.wasee. Microsoft. Les données peuvent être échangés avec d'autres annuaires auxquels on fait confiance. Jusqu'au 12 janvier 2006 l'annuaire publique par excellence était le UDDI Business Registry (UBR). C'était un annuaire publique et libre. tableau II-4: Différences entre les 3 types d'annuaires UDDI [Site 23.com/infocenter/adiehelp/index. Les données ne sont pas échangés avec d'autres registres Semi-privé C'est un annuaire d'un fournit à Extranet Trading partner network l'intérieur contrôlé. Tout le monde 4 5 http://www. 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).doc/info/ee/ae/twsu_e p.html . seulement environnement que ont C'est-à-dire les partenaires accès aux différents outils. Intranet isolé du réseau publique.xmethods.net http://publib. mais la consultation est essentiellement libre. NTT Communications et SAP.ibm. Soit les outils administratives que la IBM WebSphere UDDI Registry5 consultation sont sécurisés. Les données peuvent êtres échangés avec d'autres registres Privé Se trouve derrière un firewall. géré en concomitance par IBM.II Les Services Web 36 Type Publique Description Analogie web exemple Xmethods4 Les outils administratives peuvent Website êtres sécurisés.ibm.boulder.

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

4. et ce chapitre les présente rapidement divisés par catégorie. Jabber Jabber est un protocole de transport et de package qui peut être utilisé dans un système peer-to-peer asynchrone.semanticweb. Cependant. http://daml.org 1.org .org/.jabber. pp 175-179] car c'est une des sources les plus complètes. http://www.2.1.4.xmlrpc.4.II Les Services Web 38 1. Autres Standards Les sections précédentes traitaient les technologies et protocoles les plus utilisés et standardisées. Chaque standard ou protocole présenté est suivi par une ressource (pour ce qui sont intéressés). 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. Protocoles de package XML-RPC C'est la manifestation originale du SOAP idée par Dave Winer de Userland Software. http://www. 1. La liste suivante est surtout extraite de [Snell 2002. Ce simple protocole était beaucoup utilisé dans la communauté open source (mais il est désormais un protocole abandonné). il en existent beaucoup plus.

w3.org/rdf. Développé par le W3C.4. 1. Il inclut beaucoup plus d' informations que UDDI. Cet approche est différente mais non pas incompatible avec UDDI.4. RDF est le langage de base du Web sémantique.org/signature/ .ebxml. http://www. Beaucoup d'exemples ont été développés. http://www.ibm.w3.-106.org/ 1.com/developerworkds/webservices/library/wswsilspec. Une des syntaxes (sérialisation) de ce langage est RDF/XML [Site 24].html 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. et il existe aussi une version modifié de WSDL conforme à la syntaxe RDF. Il y a eu certains discussions sûr la possibilité de décrire les services web très facilement avec RDF.II RDF Les Services Web 39 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. 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. 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.4.3. http://www. de façon à permettre le traitement automatique de telles descriptions. http://www.

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.microsoft.ibm. http://www. http://www.xkms.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 a été développé par OASIS [Site 25]. Basé sur le langage XML.5.org/encryption/2001 SAML Le Security Assertions Markup Language est un standard informatique définissant un protocole pour échanger des informations liées à la sécurité.org/committees/security/ 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.org/tr/xkms http://www.w3. http://msdn2.w3.4.com/developerworks/webservices/library/ws-phtt/ 1.aspx .com/en-us/library/ms951249. http://www-128.6. 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.oasis-open. http://www.org 1.4.

II

Les Services Web

41

WS-Address C'est un mécanisme de routage pensé pour surclasser le WS-Routing. http://www.w3.org/Submission/ws-addressing/ 1.4.7. 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. http://java.sun.com/webservices/jaxp/index.jsp JAX-RPC Le Java API for XML RPC est l'effort du JCP pour standardiser les API Java pour utiliser les services web. https://jax-rpc.dev.java.net/ 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]. http://ch2.php.net/simplexml 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é.

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

II

Les Services Web

43

2.1.

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

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

Cependant il n'est pas nécessaire d'utiliser un type de token spécifique. Web Service Security Originellement développé par IBM. un mécanisme général pour associer des tokens aux messages. l'intégrité des messages est assurée en combinant les signatures XML et les security tokens. Parmi les tokens décrits on trouve: • • • • • Username tokens X. WS-Security décrit comment encoder tokens de sécurité binaires et comment les attacher aux messages SOAP. à ce moment.0) a été lancée le 19 avril 2004 et le 17 février 2006 le comité a lancé la version 1. La première spécification (WS-Security 1. le protocole Web Service Security (WS-Security) permet d'appliquer de la sécurité aux services web. De plus. Le WS-Security propose aussi. 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. VeriSign et Forum Systems et.1 [Site 33].2.509 tokens SAML tokens REL Tokens Kerberos tokens D'ailleurs. 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. Microsoft. .II Les Services Web 45 2. 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]. conduit par le comité OASIS-OPEN.

II Les Services Web 46 2.1.</wsse:Security> </s11:Header> … </s11:Envelope> code II-15: Syntaxe et position de l'en-tête de sécurité . 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="…"> … …. 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. Comme pour les signatures.2.2. Ce modèle permet aussi l'utilisation de plusieurs signatures par différents acteurs. l'extensibilité du mécanisme d'intégrité permet l'utilisation de formats de signature autres que le XMLSIG. De plus. 2. 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.2. 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. 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.

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

/wsse:UsernameToken/wsse:Nonce Valeur aléatoire crypté /wsse:UsernameToken/wsse:Nonce/@EncodingType Spécifie le type de Nonce. ou que le token lui-même soit crypté. comme le hash).. Il est recommandé que cet élément soit utilisé seulement avec un canal sécurisé. /wsse:UsernameToken/wsse:Password/@Type Cet attribut spécifie le type de mot de passe utilisé. la Optionnel valeur par défaut est Base64 /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.. tel que le HTTP/S..."> <S11:Header> . </S11:Envelope> code II-16: Syntaxe de l'élément UsernameToken 48 Autres info. <wsse:Security> <wsse:UsernameToken wsu:Id="…"> <wsse:Username> … </wsse:Username> </wsse:UsernameToken> </wsse:Security> . pp 8-9] Optionnel Optionnel .... /wsse:UsernameToken/wsse:Password/@{any} Ceci est un mécanisme permettant l'addition d'autres attributs. Si cet attribut n'est pas spécifié.." xmlns:wsse=".II Les Services Web <S11:Envelope xmlns:S11=".. </S11:Header> . /wsse:UsernameToken/wsse:Password Cet élément est utilisé pour fournir un mot de passe (ou un équivalent. basés sur des schémas..

4) Bob ferme la communication avec Alicia 5) Cleancy retransmet la PasswordDigest de Bob à Alicia. elle n'offre pas une sécurité plus élevée qu'un mot de passe PasswordText. 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. Le types de mots de passe peuvent être librement choisis (derived password.) mais on trouve souvent le type PasswordText ou PasswordDigest. l'information contenue est un Digest. Evidemment si on utilise un mot de passe du type PasswordText l'information sera en texte plain (lisible). Cet attaque consiste à intercepter une information génuine et la répéter pour s'authentifier auprès d'un service [Site 37]. au contraire. 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. c'est-à-dire un équivalent du mot de passe originale (par exemple le hash). Les éléments <wsse:Nonce> et <wsse:Created> Une des attaques les plus simples à mettre en œuvre est le "Replay Attack". Dans le cas de PasswordDigest. etc. S/KEY.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>. . 2) Cleancy intercepte la communication 3) Alicia donne accès à la ressource à Bob parce que le mot de passe c'est correcte. 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é. Les points suivantes montrent le fonctionnement de cet attaque: 1) Bob Envoie une requête ad Alicia en lui communicant sa PasswordDigest.

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é. l'émetteur doit coller au message l'élément Created..... Le problème est que le serveur doit avoir une liste des Nonces déjà utilisés consumant ainsi des ressources. 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:Header> . Un Nonce est un numéro généré avec un algorithme aléatoire. <wsse:Security> <wsse:UsernameToken> <wsse:Username>Bob</wsse:Username> …….."> <S11:Header> .. <S11:Envelope xmlns:S11=". </S11:Envelope> code II-17: exemple avec PasswordText .II Les Services Web 50 Les éléments <Nonce> et <Created> sont utilisés pour protéger le service de ce type d'attaque.. Pour diminuer les ressources destinées à ce contrôle. Cet élément n'est rien d'autre qu'un timestamp généré au moment de la création du message.<wsse:Password>BobPassword</wsse:Password> </wsse:UsernameToken> </wsse:Security> . 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.." xmlns:wsse="...

<wsse:Nonce>WscqanjCEAC4mQoBE07sAQ==</wsse:Nonce> …….. <wsse:Security> <wsse:UsernameToken> <wsse:Username>Bob</wsse:Username> …….php?wg_abbrev=wss#technical . En tout cas..oasisopen. quand on utilise des messages d'erreur personnalisés. Ressources Externes Liste des spécifications pour les différents tokens http://www. 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... </S11:Header> . 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."> <S11:Header> .II Les Services Web 51 <S11:Envelope xmlns:S11=".<wsse:Password Type="…#PasswordDigest"> weYI3nXd8LjMNVksCKFV8t3rgHh3Rw== </wsse:Password> …….." xmlns:wsse="...org/committees/tc_home. </S11:Envelope> code II-18: exemple avec PasswordDigest Erreurs Les implémentations devraient utiliser le set d'erreurs définis dans la spécification WSS:SOAP Message Security pour augmenter l'interopérabilité...<wsu:Created>2003-07-16T01:24:32Z</wsu:Created> </wsse:UsernameToken> </wsse:Security> ..

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

III Travail pratique 53 III. Travail pratique .

. 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. 2 Le problème de la recherche d'objets immobiliers Au moment actuel.) les processus à suivre sont deux7: 1. 7 Evidemment on parle ici de l'utilisation des technologies de l'Internet. 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. 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). 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. Finalement le chapitre 5 regroupe l'évaluation du projet et les considérations personnelles. quand une personne recherche un objet immobilier (appartement. maison. Utiliser les différents sites web des régies 2.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. Cela dit. etc. 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.

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é. Figure III-2: Utilisation d'un intégrateur ordinaire . 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.

1.ch fait partie des entreprises en ligne qui ont la plus vaste audience [Site 40]. Avec. 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. mais il faut quand même dire qu'il a des limites et des problèmes structurels assez évidents.ch9 Cette entreprise est une filiale de la Banque Cantonale de Zurich. Ce site propose quotidiennement plus de 52’000 offres on-line. Immoscout24. Homegate et Immoscout24 En Suisse les deux acteurs principales sont Immoscout24.homegate. homegate. Les portails dédiés Ce sous-chapitre est divisé en deux parties.immoscout24. 8 9 http://www. chaque mois.1. environ 2. homegate.2 million de visites de plus de 650'000 visiteurs.ch8 ImmoScout24 est la plus importante place de marché électronique de Suisse pour les logements.ch/IS24Web/Public/Home. Elle a été fondée le 1er mars 2001 et son siège est à Adliswil. Le chapitre 2.aspx?nav=-1&lng=fr&wl=1 http://www. ImmoScout24 est une plate-forme du groupe Scout24. 2.III Travail pratique 56 À la situation actuelle ce deuxième modèle est le meilleur. Ces deux portails présentent un nombre très grand d'annonces immobilières.ch et Homegate. 2.ch/homegate/index?layout=&agency=&lang=fr . tout près de Zurich [Site 39].1.ch. les immeubles commerciaux et de vacances. leader incontesté du réseau suisse des places de marché on-line [Site 38].1 présente en détail ce modèle.

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.2. 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.III Travail pratique 57 2. Le prochain chapitre analyse la réalité des Etats-Unis et du canada et présente un standard d'échange. Même si pour l'utilisateur il existe beaucoup d'avantages. Plusieurs fois par jour le portail prend les fichiers et sauvegarde les informations dans sa base de données [Annexe A]. • 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. 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.1. . 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. 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?).

agents immobiliers.1. 3. 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. 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. 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. RETS satisfait ce . 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].2. Ce type de service est très utilisé aux Etats-Unis et en Canada.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. 3. C'est pour consolider les informations provenant de plusieurs MLS que le Real Estate Standards Organization (RESO) a développé le RETS. 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]. Ces services s'appellent Multiple Listing Services et ils sont comparables aux sites (bien plus petits) présentés pour la Suisse. clients) désirant partager et distribuer les informations immobilières. mais on commence à en voir la présence aussi en Europe. Toutefois grâce au développement de l'Internet et donc grâce à un accès plus simple aux informations.

XML et XMLSchema. capable de représenter aussi les autres objets. . WSDL. Les technologies des base des services web sont valables et RETS2 en est la preuve. 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. Beaucoup de MLS emploient le protocole RETS [Site 43]. C'est-à-dire que personne peut chercher un MLS RETS-compliant et l'utiliser librement. X. RETS et XML La première version de RETS utilisait partiellement XML et les technologies dérivantes.509 Certificate Token Profile.III Travail pratique 59 besoin en fournissant une norme commune pour l'échange des données immobilières. SOAP Message Security. Mais les standards de base de RETS2 (standardisé en 2006) sont SOAP. RETS2 utilise WS-Security et plus en détail. et SAML Token Profiles. À Ce moment la version 2 de RETS est devenue un standard. Username Token Profile. Pour ce que concerne la sécurité. Il faudrait développer un standard plus général. Malheureusement RETS est trop lié au marché nord-américaine et surtout aux objets en vente seulement. 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. Considérations personnelles RETS2 est un pas énorme dans le développement d'un langage commun entre les différents acteurs immobiliers.

1.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. Dans le chapitre 4. On commence par son fonctionnement pour passer aux avantages et limites. Modèle La Figure III-3 présente le modèle orienté service web. 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. Figure III-3: Modèle de recherche orienté service web .3 est dédié à 4. Finalement le chapitre 4.1 présente l'architecture du modèle. Le chapitre 4. 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. l'implémentation.2 le lecteur verra l'architecture des applications développées pour démontrer le fonctionnement du modèle.

Fonctionnement L'utilisateur doit envoyer sa requête à l'intégrateur seulement. 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. en respectant la logique des services web. De plus.2. À cause de cela. 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.1. 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). l'intégrateur présente les résultats sous forme d'html. 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.3. par rapport aux portails dédiés. De plus. 4. chaque régie peut choisir l'architecture qu'elle préfère (la seule chose à respecter c'est l'interface prédéfinie).1.Net! 4.1. 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.III Travail pratique 61 4. Une fois que toutes les réponses arrivent. il est important de noter que le temps pour transmettre le résultats à l'utilisateur sera majeur. Ce dernier construit des requêtes SOAP et les envoie aux différents services web des régies. on ne voit donc pas un registre et l'intégrateur ne peut donc pas chercher des nouvelles régies implémentant l'interface. un autre en Java et l'intégrateur en PHP ou .1. . Dans cette optique on peut avoir par exemple un service web implémenté en Perl.

Figure III-4: Architecture de la solution . 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.2. on a publié une copie de immoOne dans le web. La Figure III-4 montre l'output du travail.III Travail pratique 62 4. pour démontrer que le modèle fonctionne dans la réalité. 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.

L'approche code-first est très simple. En raison de sa simplicité. 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. Avec l'approche contract-first on atteint de niveaux d'interopérabilité élevés. . on a décidé d'utiliser l'approche code-first. Le code-first consiste à écrire le code (java.1.3. 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. mais le développement est assez long et la maintenance de l'interface n'est pas toujours facile [Site 44].3. Dans un deuxième temps on présente les applications et les outils.Net. 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).) et à générer en un deuxième temps l'interface WSDL automatiquement.III Travail pratique 63 4. 4. Evidemment le fichier WSDL montre des problèmes car certains types de données ne sont pas standard. Implémentation Ce sous-chapitre est dédié à l'implémentation des différentes applications. 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. et le processus de développement est plus court. 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). etc. Il faut quand même dire qu'on a écrit l'application en respectant un prototype d'interface défini auparavant. C++. mais vue la simplicité de l'application générée. .

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

2. en exécutant les programmes en ligne de commande.2. . On a choisi ce serveur car il supporte très bien PHP et on le connaissait déjà assez bien. PHP 5. Apache Server 2. Ce sous-chapitre les montre avec.4 "est un serveur HTTP produit par la Apache Software Foundation.4 "est un langage de scripts libre principalement utilisé pour être exécuté par un serveur HTTP.0 "est un gestionnaire de base de données libre.3. MySQL 5. nommée licence Apache" [Site 45]. Il est très utilisé dans les projets libres et dans le milieu industriel" [Site 47].III Travail pratique 65 4. On a choisi MySQL car c'est le gestionnaire des bases de données le plus utilisé avec PHP et Apache.2. mais il peut fonctionner comme n'importe quel langage interprété de façon locale. C'est le serveur HTTP le plus populaire du World Wide Web. pour chacun une petite définition et les motivations du choix. C'est un logiciel libre avec un type spécifique de licence. PHP est un langage procédural disposant en version 5 de fonctionnalités de modèle objet complètes" [Site 46]. Outils Pour implémenter les applications on a choisi différents outils. 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. 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.

3. 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.III Travail pratique 66 4. il fallait tout d'abord développer le site web d'une régie.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 .3. ImmoOne Pour pouvoir vérifier le modèle.

type de contrat.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. pièces. prix. Le service web Pour implémenter les services web (dans ce cas le serveur) on a utilisé la classe open source NuSOAP [Site 48]. 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. . n° de référence et url). adresse. Cette classe permet d'implémenter très facilement des services web. titre.

on rend la fonction accessible via service web.php).III Travail pratique 68 Figure III-8: Structure du service web dans ImmoOne Server. 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. code III-1: Fonction GetListing en PHP code III-2: Enregistrement de la fonction GetListing avec paramètres et types .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.

La Figure III-10 est l'interface de recherche de cet outil. On verra comment le faire dans l'étude de l'intégrateur. Figure III-10: Interface de ImmIntegrator .php est le script le plus important. La Figure III-9 en montre la structure des scripts. 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). Pour y accéder il suffit de demander le document en utilisant la variable globale $_GET de PHP. il fallait implémenter l'intégrateur.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.3. Figure III-9: Structure des scripts du ImmIntegrator La classe ClientClass. On l'étudiera plus en détail après. car c'est lui qui s'occupe de créer les clients pour les différents services web connus.4. 4. ImmIntegrator Après avoir terminé le service web.

code III-3: Création des clients Ce morceau de code se trouve dans le script index. Chaque instance de ClientClass contient un objet soap_client (défini dans nusoap. . Le code III-4 montre l'impression des résultats dans une table. Une des fonctionnalités utiles de NuSOAP est le parseur XML.php.php) et en utilisant les méthodes offertes par ClientClass on peut accéder aux fonctionnalités dont on a besoin. Grâce à cet outil les réponses SOAP sont automatiquement transformées en un array PHP standard. Donc quand on appelle $immone_client->doCall('GetListing'. 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. $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.III Travail pratique 70 Les Clients Plus haut dans ce chapitre on a dit que la classe ClientClass. À l'aide du code III-3 on explique pourquoi. Ce script crée une instance de ClientClass.php est le script le plus important. De cette façon il est donc simple imprimer le résultats.php en lui passant comme argument l'adresse du fichier WSDL qui décrit le service.

La Figure III-11 montre une requête SOAP générée à l'aide de SoapUI.III Travail pratique 71 code III-4: Impression des résultats dans une table 4. par contre. montre la réponse envoyée par le service web. 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. Cette requête a été générée automatiquement par SoapUI en lisant le fichier WSDL. Démonstration Jusque là le modèle fonctionne avec les deux applications PHP. Figure III-11: Requête SOAP générée par SoapUI LaFigure III-12 .3. . de générer une requête et de lire une réponse.5.

Le prochaine chapitre est dédié aux conclusions tirées de ce travail pratique. . De plus on proposera des possibles améliorations du modèle et des applications.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. On évaluera le choix des outils et les résultats obtenus.

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. les autres outils ont été extrêmement faciles à utiliser et ils se sont démontrés le bon choix. 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. Le site web de la régie est assez stable. . 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. on a choisi un langage de programmation avec un support insuffisant du standard SOAP. on a démontré que le modèle proposé est valable. Ceci dit. À cause de l'inexpérience dans le domaine des services web. donc les buts de ce projet ont était accomplis! Améliorations futures Evidemment le modèle implémenté n'est qu'un prototype. on a dédié beaucoup de temps à son analyse et implémentation. Le résultat Pour ce que concerne le résultat. on est vraiment satisfait des applications construites. On a résolu ce problème en utilisant la classe NuSOAP. et même si cette application était seulement une base permettant la construction du service web. Avec ces applications.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. bien que très utile. présente des problèmes de compatibilité avec d'autres outils (par exemple Visual Studio). 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.

À 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.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). 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. Conclusion En conclusion. ce travail peut être le point de départ dans la réalisation d'une bonne alternative aux modèles existants. .

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

2007 .IV Références 76 Pages Web [Site 1] The Greentree Gazette.2007 [Site 4] W3C World Wide Web Consortium.09. “Web Services Glossary” http://www.aspx?p=25871&rl=1 Dernier accès le 15.com/articles/article. “Happy Birthday. “The Past.techtarget. “What’s Next for Web Services: GXA and Beyond” http://www.w3.com/articles/article. Present and Future of Web Services.09.w3.org/2003/02/xml-at-5.webservices.aspx?p=25871&rl=1 Dernier accès le 15.sid9_gci213985.informit.pdf Dernier accès le 15.289893.com/0301WebServices.2007 [Site 8] Webservices. XML!” http://www. “Web Services Adoption Spreads Globally” http://www.wikipedia.09.informit.2007 [Site 7] W3C World Wide Web Consortium.org/TR/2002/WD-ws-gloss-20021114/#webservice Dernier accès le 15.2007 [Site 2] Informit.2007 [Site 5] Whatis.org/wiki/Sgml Dernier accès le 15.09.com/definition/0. part 1” http://www.2007 [Site 6] Wikipedia.09.2007 [Site 3] The TechWeb Network.infometh.com. “the web service revolution” http://www.html Dernier accès le 15.org/categories/enterprise/strategy_architect ure/the_past_present_and_future_of_web_services_part_1/(go)/Arti cles Dernier accès le 15.org.09. “SGML definition” http://en. “GML definition” http://whatis.h tml Dernier accès le 15.09.00.09.

2007 77 [site 9] [Site 10] W3C World Wide Web Consortium.2007 .09.2007 [Site 14] Oracle. “SOAP Version 1.php?q=WSDL&ix=1828 Dernier accès le 15. “The web service protocol stack" http://roadmap.2007 [Site 15] W3C World Wide Web Consortium.2007 [Site 13] W3C World Wide Web Consortium. “Web Services Architecture" http://www.09.org/TR/2000/NOTE-SOAP-20000508 Dernier accès le 15.oracle.2007 [Site 12] W3C World Wide Web Consortium.2007 [Site 16] Alaide. “Simple Object Access Protocol (SOAP) 1.org/TR/2007/REC-soap12-part220070427/#soapinhttp Dernier accès le 15.alaide.IV Références CBDI. “Définiton WSDL” http://www.org/TR/2004/NOTE-ws-arch-20040211/ Dernier accès le 15.com.html Dernier accès le 15.org/index/object.org.w3.09.com/reports/protocols/ Dernier accès le 15.w3.com/dico.org/2002/07/SOAP-TRANSLATION/SOAP12part1.09.w3.2 Partie 1: Structure pour l'échange de messages” http://www.html Dernier accès le 15.cbdiforum.com/technology/sample_code/tech/java/codesnipp et/webservices/docservice/index.title/xml/ Dernier accès le 15.09.09.1 note” http://www. “Définition XML” http://xmlfr.09.2007 [Site 11] Xmlfr. “SOAP Version 1. “How to create a Document Style Web Service” http://www.2 Part 2: Adjuncts (Second Edition)” http://www.w3.09.

wikipedia.09.org/pubs/the_evolution_of_uddi_20020719.html Dernier accès le 15.2007 [Site 25] Wikipedia.2007 [Site 22] OASIS.wikipedia.2007 [Site 21] PC Global Services.2007 [Site 20] Global Learning Consortium. Inc.org/wiki/Resource_Description_Framework Dernier accès le 15.09.w3schools. “WSDL Documents” http://www. “Web Services Description Language (WSDL) Version 2.imsglobal. “Définitions: UDDI” http://www.w3.2007 [Site 19] W3schools. “The evolution of UDDI” http://www.pdf Dernier accès le 15.ecranbureau.com/wsdl/wsdl_documents.asp Dernier accès le 15.org/committees/uddi-spec/faq.com/dictionnaire/U/UDDI. “Security assertion markup language” http://fr.IV Références W3schools.php#status Dernier accès le 15.org/TR/wsdl20/ Dernier accès le 15.org/gws/gwsv1p0/imsgws_wsdlBindv1p0.09.2007 .09. “Introduction to WSDL” http://www. “Resource Description Framework” http://fr.0 Part 1: Core Language” http://www.org/wiki/Security_assertion_markup_language Dernier accès le 15.oasis-open.09.2007 [Site 23] OASIS UDDI.09.html Dernier accès le 15.w3schools. “IMS General Web Services WSDL Binding Guidelines” http://www.09. “OASIS UDDI Specification TC” http://www.2007 [Site 24] Wikipedia.09.asp Dernier accès le 15.uddi.2007 78 [Site 17] [Site 18] W3C World Wide Web Consortium.com/wsdl/wsdl_intro.09.

wikipedia. “Intégrité” http://fr.2007 [Site 28] Wikipedia.2007 [Site 33] Wikipedia.com/developpeur/tutoriel/php/040921-phpseguy-simplexml-1a. “WS-Security” http://fr.doc/common/iiysgloss.com/infocenter/db2luw/v8/index.db2.wikipedia.IV Références Journaldunet.org/wiki/Signature_num%C3%A9rique Dernier accès le 15.09.org/wiki/WS-Security Dernier accès le 15.wikipedia.09.org/wiki/Confidentialit%C3%A9 Dernier accès le 15. “Cryptographie” http://fr.2007 .journaldunet.wikipedia.ii.org/wiki/Cryptographie Dernier accès le 15.2007 [Site 32] Wikipedia.ibm.com.wikipedia. “PHP5: SimpleXML” 79 [Site 26] http://www.09.2007 [Site 31] IBM.boulder.09.org/wiki/Cl%C3%A9_de_chiffrement Dernier accès le 15.of. “Confidentialité” http://fr.09.2007 [Site 30] Wikipedia.wikipedia.jsp?topic=/ com.09.ibm. “Segnature numérique” http://fr.org/wiki/Int%C3%A9grit%C3%A9_%28cryptograph ie%29 Dernier accès le 15.09.2007 [Site 27] Wikipedia.09.htm Dernier accès le 15.2007 [Site 29] Wikipedia.shtml Dernier accès le 15. “Clé de chiffrement” http://fr. “Glossary: Security Tokens” http://publib.

1 (WSSecurity 2004)” http://www.2007 [Site 39] Homegate.1-spec-os-UsernameTokenProfile.09.1-spec-errata-os-SOAPMessageSecurity.2007 .aspx?key=impr int&nav=5&subnav=9&lng=fr&wl=1 Dernier accès le 15.1-spec-os-SOAPMessageSecurity.php/16790/wssv1.oasis-open.09.oasis-open.oasis-open.ch.2007 [Site 36] OASIS.org/committees/download. “Notre entreprise” http://www. “Replay Attack” http://it.2007 [Site 37] Wikipedia. “Username Token Profile” http://www.1 (WSSecurity 2004)” http://www.ch/IS24Web/Public/Content.IV Références 80 [Site 34] OASIS.org/committees/download.2007 [Site 35] OASIS.php/21257/wssv1.09.org/wiki/Replay_attack Dernier accès le 15.xml&l=default&a=default Dernier accès le 15.org/committees/download. “Web Services Security: SOAP Message Security 1.homegate.pdf Dernier accès le 15.php/16782/wssv1.ch. “Web Services Security: SOAP Message Security 1.htm Dernier accès le 15.09.wikipedia.immoscout24. “le point de rencontre de l’offre et de la demande” http://www.2007 [Site 38] Immoscout24.09.09.ch/homegate/article?articleId=UEcomp_fr_CH.pdf Dernier accès le 15.

2007 [Site 47] Wikipedia.wikipedia. “Multiple Listing Service” http://en.wikipedia.09.2007 [Site 46] Wikipedia.org/wiki/Php Dernier accès le 15.2007 [Site 44] Javazone 2005.IV Références Homegate. “MySQL” http://fr.java.homegate.09.no/web/show.2007 [Site 45] Wikipedia.wikipedia.wikipedia.org/wiki/Real_Estate_Transaction_Specification Dernier accès le 15. “Facts et Figures” http://www.wikipedia.org/wiki/Multiple_Listing_Service Dernier accès le 15.do?page=92&articleid=5266 Dernier accès le 15.09.ch/homegate/article?articleId=UEfig_fr_CH.09.09.org/wiki/Multiple_Listing_Service#Alternatives_an d_changes_to_the_MLS_system Dernier accès le 15. “PHP: Hypertext Preprocessor” http://fr.wikipedia.ch.09.2007 . “Contract-Aware Web Service Development” http://www4.org/wiki/Mysql Dernier accès le 15.2007 [Site 43] Wikipedia.2007 [Site 42] Wikipedia.org/wiki/Apache_(logiciel) Dernier accès le 15.09.09. “Alternatives and changes to the MLS system” http://en.2007 81 [Site 40] [Site 41] Wikipedia. “Real Estate Transaction Standard” http://en. “Apache HTTP Server” http://fr.xml&l=default&a=default Dernier accès le 15.

ganx4.IV Références Dietrich Ayala Homepage.09.soapui. “NuSOAP Homepage” http://dietrich.2007 82 [Site 48] [Site 49] Eviware. “soapUI” http://www.2007 .org/ Dernier accès le 15.com/nusoap/ Dernier accès le 15.09.

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

Annexes .V Annexes 84 V.

Plusieurs régies sont totalement fermées.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. Toutefois les clients préfèrent passer par des portails largement connus. Le portail lit tous les fichiers plusieurs fois par jour pour actualiser son site.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. □ 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. Question: Quorum software est-il lié aux grands portails de recherche comme Homegate. . Non il y a une copie FTP des données vers le portail dans un compte propre a chaque client. Non mais ce serais intéressante. □ Les données sont envoyés de façon différente (xml. …) à chaque requête. webservices.

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

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

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

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

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

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

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

'url'=>array('name'=>'url'. 'address'=>array('name'=>'address'. 'type'=>'tns:ReAddress') ) 93 ). 'struct'. //GetListing function input parameters array $GetListingParamIn = array('ObjectType' => 'xsd:string'. ''. 'tns:ReObject' ). 'immone_ws_wsdl'. array( array('ref'=>'SOAP-ENC:arrayType'. //add ReListing type to wsdl $server->wsdl->addComplexType('ReListing'. 'type'=>'xsd:string'). array(). array( 'object_type'=>array('name'=>'object_type'. 'type'=>'xsd:float'). 'SOAP-ENC:Array'. } $server->service($request). 'encoded'. 'immone_ws_wsdl#GetListing'. 'all'. 'type'=>'xsd:string'). //register the GetListing function $server->register('GetListing'. 'MinPrice' => 'xsd:double'.'My description about why this error was thrown'). $GetListingParamIn. 'MaxPrice' => 'xsd:double'. 'complexType'. $GetListingParamOut. 'ContractType' => 'xsd:string'. 'type'=>'xsd:float'). 'MinRooms' => 'xsd:float'). //GetListing function output parameters array $GetListingParamOut = array('return' => 'tns:ReListing').V Annexes 'complexType'.'type'=>'xsd:string'). 'array'. 'Returns the the listing'). 'reference'=>array('name'=>'reference'. ''. 'price'=>array('name'=>'price'. 'type'=>'xsd:string'). 'title'=>array('name'=>'title'. 'Zip' => 'xsd:int'. 'contract_type'=>array('name'=>'contract_type'.'wsdl:arrayType'=>'tns:ReObject[]') ). ?> . 'type'=>'xsd:string'). 'rpc'. 'rooms'=>array('name'=>'rooms'. if(isset($error)) { $fault = $server->fault('soap:Server'.

V Annexes 94 5 Annexe E: Code Source de immIntegrator/index. echo "<b>Max Price:</b> ". echo "<b>Min Price:</b> ". include('header."." .</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\">"." .php <? include('ws_clients/ClientClass.$_GET['min_price'].$_GET['max_price'].$_GET['object_type']. echo "<p align=\"center\">Results for query: ". echo "<b>Object Type:</b> "." ."." . echo "<b>Contract Type:</b> ".".". ?> <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>&nbsp.php'). .php').$_GET['contract_type'].

'MaxPrice' => $maxPrice. if($_GET['zip'] != '' && !is_null($_GET['zip'])) (int)$zip = $_GET['zip']. $res[] = $immone_client->doCall('GetListing'. } ?> <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> . //Analyse $_GET variables $minPrice = 0.php?wsdl'). $param). $res[] = $immone_web_client->doCall('GetListing'. $err . 'MinRooms' => $minRooms)."</p>".". 'Zip' => $zip. //set parameters for GetListing function $param = array('ObjectType' => $_GET['object_type']." .V Annexes echo "<b>Zip:</b> ". $minRooms = 0.$_GET['min_rooms']. $fault . echo "<hr class=\"hr1\">". '</pre>'. 'MinPrice' => $minPrice.ch/immone/ws_web/server.php?wsdl'). echo "<b>Min Rooms:</b> ". if ($err) { echo '<h2>Immone error</h2><pre>' .$_GET['zip']. $param). $fault = $immone_client->getFault(). //set the objects $immone_client = new ClientClass('http://homer2/immone/ws/server.os space. } if($fault) { echo '<h2>Immone fault</h2><pre>' . $err = $immone_client->getError(). 95 if($_GET['min_price'] != '' && !is_null($_GET['min_price'])) $minPrice = (int)$_GET['min_price']. $res = array(). if($_GET['max_price'] != '' && !is_null($_GET['max_price'])) $maxPrice = (int)$_GET['max_price']. $maxPrice = 0. 'ContractType' => $_GET['contract_type']. $zip = 0. '</pre>'. $immone_web_client = new ClientClass('http://www. if($_GET['min_rooms'] != '' && !is_null($_GET['min_rooms'])) $minRooms = (float)$_GET['min_rooms'].

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

} //executes a function call and returns the returned array public function doCall($funct_name. protected $client. } //returns the soap fault if exists public function getFault() { //return $this->client->fault. 'wsdl'). if($this->client->fault) . //create the real soap client $this->client = new soapClient2($this->wsdl_string. } //returns the soap error if exists public function getError() { return $this->client->getError().V Annexes 97 6 Annexe F: Code Source de ClientClass. $param_arr). } //returns the last soap response public function getResponse() { return $this->client->response. protected $result_array. $param_arr) { return $this->client->call($funct_name. Class ClientClass { //vars protected $wsdl_string.php').php <? require('lib/nusoap. //Constructor public function __construct($wsdl) { //set the wsdl string $this->wsdl_string = $wsdl. } //return the debug string public function getDebug() { return $this->client->debug_str. protected $param_object. } //returns the last soap request public function getRequest() { return $this->client->request.

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

3.V Annexes 99 7 Annexe G: Guide d'installation Les pages qui suivent concernent l'installation d'une plateforme de test (Apache. Pour éviter des problèmes.wampserver.exe (contenu dans le cd-rom) et suivez les instructions à l'écran.7. Pour installer Wamp sélectionnez le fichier wamp5_1. il est mieux de laisser toutes les configurations par défaut. Cette plateforme installe le serveur Apache. Installer la plateforme Pour simplifier l'installation des outils nécessaires on propose d'installer la plateforme Wamp10. PHP5 et MySQL) et des applications développées dans le cadre de ce projet (ImmoOne et ImmIntegrator). 10 http://www. PHP5 et MySQL en une seule action. 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.com/ .

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

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

V Annexes 102 Installer les applications Pour contrôler que la plateforme fonctionne il faut ouvrir le browser et aller à l'adresse http://localhost. 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 .

on trouvera les deux projets à gauche comme montré dans l'image suivante. Pour contrôler que les applications ont été bien installées il faut rafraîchir le browser. . Si tout c'est bien passé.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.

Ouvrez donc phpmyadmin .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.

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

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.V Annexes 106 Dans la fenêtre suivante cherchez le fichier et importez-le. Ouvrez le browser et allez à l'adresse http://localhost/immone. Une page de login vous sera montrée .

l'application vous montre l'objet dans la section centrale de la page . Une fois que la recherche est finie. À gauche. dans le box "Search By Ref" tapez "IOA1223" et cliquez sur "go".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.

Félicitations: vous avez installé les deux applications. 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). La page principale de l'intégrateur vous est montrée. On voit donc les résultats et les requêtes/réponses SOAP. Maintenant on va tester l'intégrateur. . Pour le faire il faut visiter la page http://localhost/immintegrator.V Annexes 108 Bien! ImmoOne fonctionne très bien.