Vous êtes sur la page 1sur 118

Universit de Fribourg, Suisse

Dpartement d'informatique
Bachelor en informatique de gestion

Travail de Bachelor
Sujet:

Conception et dveloppement d'un service web


pour
la recherche d'objets immobiliers
Prsent par:
Oscar Mora
Via alla Peschiera 1
6600 Locarno
Suisse

Encadr par:
Dr. Stefan Hsemann

Septembre 2007

ii

A mes proches
Merci pour le soutien continu

iii

Rsum
Dans le cadre de ce travail de Bachelor, l'auteur applique les connaissances
apprises au cours de systmes d'informations du professeur S.Hsemann au
problme de la recherche d'objets immobiliers.
Ce travail s'articule en deux parties:
La premire partie prsente les aspects thoriques des services web: dans un
premier temps, l'auteur tude l'volution des services web avant d'en prsenter
les technologies principales.
La deuxime partie du travail est ddie l'analyse et la conception d'un
modle orient service web capable de rsoudre les problmes actuels dans la
recherche des objets immobiliers. Dans cette partie l'auteur dveloppe aussi les
applications qui dmontrent le modle tudi.

iv

Remerciements
Je tiens remercier tous ceux qui ont contribu au dveloppement de ce projet. En
particulier je remercie M. Stefan Hsemann pour la patience dmontre 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 Rgie Estudiantine (REST).

v
Table des matires
I.

Introduction............................................................................................................... 1
1

Motivations ........................................................................................................... 2

Objectifs du travail................................................................................................ 2

Questions traites.................................................................................................. 3

A qui sadresse le travail?..................................................................................... 3

II.

Les Services Web...................................................................................................... 4


1

Thorie et principes des services web................................................................... 5

1.1.

Qu'est-ce que un service web? ...................................................................... 5

1.2.

Histoire des services web.............................................................................. 8

1.3.

1.4.

1.2.1.

Le contexte............................................................................................ 8

1.2.2.

L'histoire de XML................................................................................. 8

1.2.3.

Lvolution des services web.............................................................. 10

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


1.3.1.

Web Service Stack .............................................................................. 12

1.3.2.

Extensible Markup Language ............................................................. 15

1.3.3.

Simple Object Access Protocol........................................................... 21

1.3.4.

Web Service Description Language ................................................... 31

1.3.5.

Universal Description Discovery and Integration .............................. 34

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


1.4.1.

Protocoles de package......................................................................... 38

1.4.2.

Protocoles de description .................................................................... 38

1.4.3.

Protocoles de recherche/dcouverte.................................................... 39

1.4.4.

Protocoles de scurit ......................................................................... 39

1.4.5.

Protocoles de transport........................................................................ 40

1.4.6.

Protocoles de routage et workflow ..................................................... 40

1.4.7.

Langages de programmation et plateformes ....................................... 41

Scurit ............................................................................................................... 42

2.1.

Terminologie............................................................................................... 43

2.2.

Web Service Security.................................................................................. 45

2.2.1.

Le modle de scurit ......................................................................... 46

2.2.2.

Le Security header .............................................................................. 46

2.2.3.

Username Token ................................................................................. 47

Conclusion Thorie............................................................................................. 52

vi
III. Travail pratique....................................................................................................... 53
1

Introduction......................................................................................................... 54

Le problme de la recherche d'objets immobiliers ............................................. 54

2.1.

Les portails ddis ...................................................................................... 56


2.1.1.

Homegate et Immoscout24 ................................................................. 56

2.1.2.

Fonctionnement et limites des portails ddis .................................... 57

Situation aux Etats-Unis et au Canada................................................................ 58

3.1.

Multiple Listing Service (MLS) ................................................................. 58

3.2.

Real Estate Transaction Protocol (RETS) .................................................. 58

Solution propose ............................................................................................... 60

4.1.

Modle ........................................................................................................ 60
4.1.1.

Fonctionnement .................................................................................. 61

4.1.2.

Avantages............................................................................................ 61

4.1.3.

Limites ................................................................................................ 61

4.2.

Architecture ................................................................................................ 62

4.3.

Implmentation ........................................................................................... 63

4.3.1.

Code-First ou Contract-First? ............................................................. 63

4.3.2.

Outils................................................................................................... 65

4.3.3.

ImmoOne ............................................................................................ 66

4.3.4.

ImmIntegrator ..................................................................................... 69

4.3.5.

Dmonstration..................................................................................... 71

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

IV. Rfrences............................................................................................................... 75
V.

Annexes .................................................................................................................. 84
1

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

vii
Liste des figures
Figure II-1: Service Web [Snell 2002, p1] ....................................................................... 6
Figure II-2: Relation entre UDDI, WSDL et SOAP [Site 9] .......................................... 13
Figure II-3: Web Service Stack ...................................................................................... 14
Figure II-4: Ecran de validation de XMLSpy................................................................. 19
Figure II-5: Structure de l'enveloppe SOAP [Snell p13] ................................................ 21
Figure II-6: Chemin d'un message SOAP [Snell, p23]................................................... 29
Figure II-7: SOAP via http [Snell, p34].......................................................................... 30
Figure II-8: Structure d'un document WSDL [Site 20] .................................................. 33
Figure III-1: Utilisation des diffrents sites web des rgies immobilires ..................... 55
Figure III-2: Utilisation d'un intgrateur ordinaire ......................................................... 55
Figure III-3: Modle de recherche orient service web .................................................. 60
Figure III-4: Architecture de la solution ......................................................................... 62
Figure III-5: Fichier WSDL du service web................................................................... 64
Figure III-6: Structure base de donnes de ImmOne...................................................... 66
Figure III-7: Visualisation d'un objet immobilier dans ImmoOne ................................. 67
Figure III-8: Structure du service web dans ImmoOne .................................................. 68
Figure III-9: Structure des scripts du ImmIntegrator...................................................... 69
Figure III-10: Interface de ImmIntegrator ...................................................................... 69
Figure III-11: Requte SOAP gnre par SoapUI ........................................................ 71
Figure III-12: Rponse SOAP reu par SoapUI ............................................................. 72

viii
Liste des codes
code II-1: dclaration XML ............................................................................................ 15
code II-2: Elment simple............................................................................................... 16
code II-3: Elment avec attribut...................................................................................... 16
code II-4: Description d'un objet immobilier.................................................................. 16
code II-5: XMLSchema d'un objet immobilier............................................................... 18
code II-6: Objet immobilier invalide .............................................................................. 19
code II-7: Exemple de requte SOAP via HTTP [Site 13] ............................................. 22
code II-8: Exemple de rponse SOAP [Site 13] ............................................................. 22
code II-9: exemple de requte SOAP RPC style [site 14] .............................................. 23
code II-10: Exemple de requte avec SOAP Document style [Site 14] ......................... 24
code II-11: Exemple d'extension d'erreur SOAP ............................................................ 27
code II-12: Exemple d'erreur personnalis SOAP .......................................................... 27
code II-13: Ciblage d'un En-tte ..................................................................................... 29
code II-14: WSDL file [Site 19] ..................................................................................... 33
code II-15: Syntaxe et position de l'en-tte de scurit .................................................. 46
code II-16: Syntaxe de l'lment UsernameToken ......................................................... 48
code II-17: exemple avec PasswordText ........................................................................ 50
code II-18: exemple avec PasswordDigest ..................................................................... 51
code III-1: Fonction GetListing en PHP ......................................................................... 68
code III-2: Enregistrement de la fonction GetListing avec paramtres et types............. 68
code III-3: Cration des clients....................................................................................... 70
code III-4: Impression des rsultats dans une table ........................................................ 71

ix
Liste des tableaux
tableau II-1: Sous-lments dfinies dans l'lment Fault.............................................. 26
tableau II-2: Erreurs standard SOAP .............................................................................. 26
tableau II-3: lments principales d'un document WSDL [Site 19]............................... 32
tableau II-4: Diffrences entre les 3 types d'annuaires UDDI [Site 23, p5] ................... 36
tableau II-5: lments et attributs relatifs l'en-tte de scurit [Site 35, pp 22-23]..... 47
tableau II-6: lments et attributs relatifs le Username Token [Site 36, pp 8-9] ........... 48

x
Conventions
Les exemples
Lorsque c'est ncessaire dexpliquer des concepts laide dexemples de code
on utilise le format suivant:
<?xml version.>
<code>
<subElement>I am an element</subElement>
</code>

Ressources Externes
la fin de certains chapitres (et aussi bien l'interne) il arrive de trouver des
rfrences des liens externes. Ces ressources sont proposes pour tudier
les aspects exclus ou qui nont pas ts prsents en dtail.
Domaine

Ressource 1
Ressource 2

Introduction

I. Introduction

Introduction

Motivations

En tant que futur informaticien de gestion jai tout de suite montr intrt au
monde des services web. Dun coup les experts informaticiens (et pas
seulement eux) ont commenc parler de la puissance de cette technologie et
quelques uns les ont mme prsents comme la vraie rvolution de lInternet
[Site 1]!
On ne sait pas encore si cette dernire affirmation est vraie, car la technologie
n'est pas assez mre [Site 2]. Il existe encore beaucoup de problmes au
niveau de la scurit et cest surtout grce la communaut qui travaille
constamment lamlioration des protocoles et des standards quon atteint des
niveaux de scurit et de stabilit toujours plus levs.
Le fait qu'ils reprsentent ou pas la rvolution d'Internet ce n'est pas relevant:
les services web ont un trs grand potentiel et ce nest pas un cas
quentreprises telles que Microsoft, IBM et Sun Microsystems aient investi
normment de moyens pour les dvelopper et les faire connatre [Site 3]!
Avec ce travail je veux analyser en dtail ce domaine pour avoir une ide claire
des avantages et dsavantages que cette technologie offre dans la pratique.

Objectifs du travail

Le but de ce travail est, dans une premire partie, de prsenter les aspects de
base des services web et danalyser en dtail les standards les plus importants
pour pouvoir commencer crer des applications orientes service. Dans la
deuxime partie on passera laction en appliquant les notions apprises au
problme de la recherche dobjets immobiliers.
Avant de commencer avec la thorie il faut prciser que ce travail nest pas
ddi XML ou des langages de programmation spcifiques. Dautre part,
pour des raisons de clart on prsentera rapidement les aspects de XML
ncessaires la comprhension des standards bass sur ce dernier.

Introduction

Questions traites

Du point de vue thorique ce travail rpond aux questions relatives les services
web, telles que:
1. Qu'est-ce qu'un service web?
2. Quelles sont les standards utiliss dans les services web?
3. Quels sont les avantages des services web?
4. Quels sont les problmes qui doivent encore tre rsolus dans le
domaine des services web?
5. Comment ont-ils volus les services web?
6. quel point on en est avec la scurit dans le domaine des services
web?
Dans la partie pratique les questions principales sont:
1. Comment peut-on amliorer la recherche d'objets immobiliers?
2. Est-ce que les services web sont l'outil adquat?
3. Quels sont les standards d'change dans le domaine immobilier?

A qui sadresse le travail?

Ce document est adress aux tudiants en informatique et en informatique de


gestion qui sont intresss au domaine des services web et aux technologies
qui y sont lies. Pour cette raison tout le long du document le lecteur trouvera
des exemples permettant lassimilation des notions thoriques de faon plus
intuitive et chaque exemple ou partie de code peut tre aussi repr dans le cdrom.
Dautre part, le travail pratique sadresse principalement aux acteurs du march
immobilier qui voient dans les services web une approche intressante pour
rsoudre des problmes de caractre technique. Il faut quand mme dire que
cette partie est prsente comme un cas dtude et elle permet aux tudiants
de fixer les connaissances thoriques apprises tout au cours de la lecture.

II

Les Services Web

II.Les Services Web

II

Les Services Web

Thorie et principes des services web

Ce premier chapitre explique de faon claire les services web. Dans une
premire partie on rpond la question : "Qu'est-ce que c'est exactement un
service web?"
Aprs la dfinition et les explications ncessaires on trouve un sous-chapitre
dcrivant l'volution des services web (le lecteur comprendra que l'ide en
question n'est pas nouvelle!).
C'est aprs ce voyage dans le temps que tout devient un petit peu plus
technique: on verra les diffrentes technologies et protocoles qui permettent
l'existence des services web et on analysera la faon dont ces technologies
sont relies les unes avec les autres. De plus, ltude des diffrents langages
avec une approche "bottom-up" nous aidera construire les connaissances
ncessaires comprendre le cas dtude.

1.1.

Qu'est-ce que un service web?

Mme si cette question peut paratre trs simple, il n'existe pas une rponse
facile. Dans les diffrents sites web ddis ce domaine de l'informatique et
dans les sources de cet ouvrage, il existe beaucoup de rponses htrognes.
Certains auteurs clarifient les aspects thoriques, d'autres focalisent l'attention
sur les diffrents protocoles qui en permettent l'existence et d'autres enfin
proposent des dfinitions gnriques [Iverson 2004, p1].
Il est souvent difficile d'avoir une ide claire premire vue et les diffrents
lecteurs peuvent tre dsorients par des dfinitions trop techniques et pleines
de termes spcifiques. Par contre, il faut viter une dfinition trop gnrique, qui
peut laisser place une incomprhension partielle du domaine en question et
causer des problmes lors d'un tude plus dtaill.
Dans cette optique il est donc mieux d'viter des termes comme SOAP, UDDI
et WSDL (on en parlera aprs) et passer directement une dfinition simple et
au mme temps prcise.
"Un service web est une interface pour une application accessible par rseau
construite en utilisant des technologies standards de l'Internet." [Snell 2002, p1]

II

Les Services Web

Bien que cette explication est trs courte elle contient toutes les informations
dont on a besoin pour avoir une vision plus claire des services web.
Interface
La Figure II-1 montre clairement le rle d'interface qui est propre aux services
web. Cette interface est place entre l'application et l'utilisateur de faon offrir
une couche d'abstraction permettant la sparation de la plateforme et du
langage de programmation du code qui invoque la fonctionnalit.

Figure II-1: Service Web [Snell 2002, p1]

Technologies standard
Pour que les deux applications puissent communiquer il faut un langage
commun, et XML est bien sr un candidat idal grce sa puissance et
extensibilit. Dans le sous-chapitre 1.3 on verra quels sont les standards
drivs de XML permettant la communication entre le client et le serveur.
Internet
Maintenant qu'on a dfinit le rle d'un service web et on sait (trs
superficiellement) comment les application communiquent il faut trouver un
canal pour mettre en place la communication relle. ce propos il existe un
canal trs dvelopp et expriment: l'Internet.
Plus prcisment le protocole qui permet aux diffrents messages de voyager
d'une application vers une autre est le HTTP. Mais, comme on le verra dans les
chapitres suivants, ces messages peuvent tre changs en utilisant dautres
protocoles (comme le SMTP par exemple).
Maintenant une dfinition plus complte peut tre exprime. Et quelle est la
meilleure si non celle du W3C? [Site 4]

II

Les Services Web

A Web service is a software system identified by a URI, whose public


interfaces and bindings are defined and described using XML. Its definition can
be discovered by other software systems. These systems may then interact with
the Web service in a manner prescribed by its definition, using XML based
messages conveyed by Internet protocols.
Comme on le voit donc, cette dfinition contient toutes les informations dont on
a parl prcdemment et en ajoute des nouvelles.
La dfinition de Snell inclue les concepts d'interface, de XML (technologies
standard) et des protocoles internet. Cette nouvelle dfinition, cependant,
ajoute le fait qu'un service web est identifi par un URI (Universal Resource
Identifier) et qu'il peut tre dcouvert par d'autres systmes (souvent grce aux
registres UDDI et au langage WSDL dont on parlera aprs).

II

1.2.

Les Services Web

Histoire des services web

Maintenant on sait quest-ce que un service web et on sait aussi quels sont les
standards ncessaires leur fonctionnement. Mais il est autant intressant de
connatre leur provenance pour apprendre au mieux leur potentiel et pour en
prvoir lvolution. Ce sous-chapitre introduit le contexte dans lequel se
trouvent les services web et parcourt les diffrentes tapes qui ont amen la
situation actuelle.
1.2.1. Le contexte
Evidemment le contexte des services web est lInternet. Cest lvolution du
rseau global qui a permis la naissance de nouvelles architectures et de
nouveaux langages pour les implmenter. Mais le fait le plus important dans le
domaine des services web a t le changement d'une approche hommemachine, vers une approche machine-machine. Cette rvolution a introduit le
besoin de standardiser la description de la structure de n'importe quel
document. C'est l que XML entre en jeu!
1.2.2. L'histoire de XML
Les bases de XML reviennent 30 ans larrire, quand le chercheur de IBM
Charles Goldfarb introduisait le concept de Markup (marquage). Ce premier pas
tait alors connu sous le nom de GML [Site 5].
Mais il fallait quand mme attendre les annes 80 pour que, grce ISO1, une
version internationale standardise ft prsente au monde. La version finale
de ce meta-langage a t prsente en 1986 sous le nom de SGML [Site 6] (ce
langage est encore utilis).
Nonobstant la standardisation, avec le web les paramtres avaient beaucoup
changs, et - grce ladoption comme meta-langage standard par le W3C
dans les annes 90 HTML fit sa rentre!
Il est intressant de noter le fait que HTML est un driv de SGML et que cest
la simplicit par rapport son "pre" (considr trop complexe) a en avoir rendu
le standard pour la prsentation des pages web.
1

International Organization for Standardization

II

Les Services Web

Mais l'volution de l'Internet tait trs rapide et on a rapidement compris la


ncessit d'un outil plus puissant, capable de fournir des fonctionnalits comme
la rutilisabilit des informations ou l'change de ces dernires entre diffrents
systmes htrognes. ce propos tout le monde tait d'accord sr le fait que
le SGML tait parfait pour ces exigences, mais il fallait le rendre plus simple
apprendre, comprendre et l'implmenter, tout en prservant ces ides
fondamentales. [Site 7]
Pour rpondre ces besoins, le W3C formait en 1996 le SGML Editorial
Review Board (successivement appel XML Working Group) que, avec la
participation active du SGML Working Group (successivement appel XML
Special Interest Group) travaillait au nouveau langage. Les bases de ce projet
se rsument en 10 objectifs:
1. XML doit pouvoir tre utilis sans difficult sur Internet
2. XML doit soutenir une grande varit d'applications
3. XML doit tre compatible avec SGML et HTML
4. Il doit tre facile d'crire des programmes traitant les documents XML
5. Le nombre d'options dans XML doit tre rduit au minimum, idalement
aucune
6. Les

documents

XML

doivent

tre

lisibles

par

l'homme

et

raisonnablement clairs
7. La spcification de XML doit tre disponible rapidement
8. La conception de XML doit tre formelle et concise
9. Il doit tre facile de crer des documents XML
10. La concision dans le balisage de XML est peu importante
Finalement, le 10 fvrier 1998, les objectifs ont t tous respects et le XML 1.0
naquit.

II

Les Services Web

10

1.2.3. Lvolution des services web


La naissance des services web est due beaucoup de facteurs. Cette section
rsume les points les plus importants de l'article "The Past, Present and Future
of Web Services" de Uche Ogbuji [Site 8].
Les applications distribues sont nes quand la computation typique s'est
dplace des mainframes vers les rseaux des minicomputers et PC. Au dbut
les managers IT ne devaient pas se proccuper de la coopration entre les
ordinateurs, car il n'existaient pas des connexions entre les diffrents
mainframes, et quand il tait vraiment ncessaire d'changer des informations
les EDI (Electronic Data Interchange) taient des units compltement
spares.
L'age des minicomputers est un peu ignore (peut tre cause de la rvolution
des PC, qui n'ont pas vraiment contribu aux systmes rpartis jusqu' l'age de
l'Internet) mais c'est eux qu'on doit les bases des services web.
La distribution de services entre les diffrents minicomputers requit beaucoup
d'approches

diffrentes

pour

communiquer

de

faon

soit

synchrone

qu'asynchrone. Le rsultat est que les grandes architectures et systmes


oprationnels des ces temps (HP et Sun) ont dveloppes des technologies de
messages distribus stupfiantes.
ce point une nouvelle gnration de technologies de calcul distribues tait
prte. Dans les grandes entreprises la computation tait dplace vers les
diffrents dpartements (en abandonnant le centre de calcul) et l'intgration
(non plus au niveau des plateformes mais au niveau du rseau) devenait donc
trs importante. Le secteur IT choisissait les objets comme standard de
dveloppement des applications ( cause des ses promesses sur la
rutilisabilit, sur la maintenance et sur le Return On Investment). Les
technologies distribues, elles aussi, furent orientes dans ce sens.
En parallle E-mail et le Web se montraient comme les technologies distribues
les plus stables et les designers et dveloppeurs cherchaient donc des
technologies avec des caractristiques similaires.

II

Les Services Web

11

Aux portes du nouveau millenium les bases pour une nouvelle technologie de
systmes repartis taient prtes. Cette nouvelle technologie tait base sur les
besoins des systmes d'information et sur les expriences des technologies
des rseaux:

Il fallait supporter les oprations reparties l'intrieur des applications et


les services gnriques entre applications.

Il fallait supporter les changes l'intrieur de l'entreprise et ceux entre


diffrentes entreprises; tout en respectant le concept de "cross-platform".

La nouvelle technologie devait utiliser les standards de l'Internet.

Elle devait supporter plein la scalabilit

Elle devait supporter plein l'internationalisation.

Elle devait tre "Fault-tolerant".

Les dveloppeurs et les managers devaient avoir un trs riche support


des diffrents revendeurs.

Il devait tre possible d'changer facilement messages simples et


messages complexes dans un environnement scuris (o ncessaire).

La premire entreprise encadrer ces besoins tait HP et elle commenait au


dbut des annes 90 travailler sur ces problmes. En 1999, elle lanait sur le
march e-Speak, qui peut tre considre la premire technologie orient
service (elle utilisait HTTP et XML).
Une autre entreprise qui a lanc un produit trs important est Useland avec son
XML-RPC. Cette technologie tait trs simple, mais c'est justement cette
simplicit (trop de limitations) qu'en a limit son usage la seule communaut
Open Source.
En 1999 arrivait aussi SOAP, qui permettait un change de messages
beaucoup plus complet que les autres.
Maintenant les services web sont en trane d'voluer dans toutes les directions
et on voit aussi des standards s'affirmant et d'autres disparatre.

II

Les Services Web

1.3.

12

Technologies de base des services web

Les services web existent fondamentalement grce XML. Le eXtensible


Markup Language est la colle qui permet la communication entre les diffrentes
applications crites dans diffrents langages de programmation.
C'est grce XML que des standards comme UDDI, WSDL et SOAP (pour en
citer quelques uns seulement) sont ns.
Cette section prsente brivement l'architecture des services web et le Web
Service Stack. Dans un deuxime temps on a un aperu de XML et on analyse
dans les dtails SOAP. WSDL et UDDI seront montrs rapidement.
1.3.1. Web Service Stack
Les services web se composent d'une collection de standards que l'on regroupe
sous le nom de Web Service Stack.
Les principaux protocoles qui formaient la spcification initiale des services web
sont:

Simple Object Access Protocol (SOAP) dfinit les messages qui


contiennent la requte et la rponse dun service. Il est indpendant de
nimporte quel moyen de transmission.

Web Service Description Language (WSDL) dcrit un service web et


la forme du message SOAP ncessaire pour effectuer les requtes.

Universal Discovery, Description and Integration (UDDI) cest le


rsultat dune coopration entre plusieurs entreprises avec le but de
fournir un outil dorganisation et de recherche pour les services web.

Ces protocoles sont maintenant universellement accepts et sont donc des


standards de facto. La Figure II-2 montre linteraction des trois technologies.

II

Les Services Web

13

Figure II-2: Relation entre UDDI, WSDL et SOAP [Site 9]

Pour comprendre cette image imaginons qu'un informaticien veut dvelopper


un systme d'informations boursires. Dans ce systme il veut montrer
l'volution de certaines actions. Tout ce qu'il doit faire c'est utiliser UDDI pour
interroger un registre qui lui permet de trouver un fournisseur de tel service
Quand la recherche est termine, l'informaticien pourra connatre la structure
des messages SOAP ncessaires pour l'utilisation du service grce la
description WSDL donne par le fournisseur.
Ces trois standards ont permis le dveloppement initial des services web et ils
ont incits beaucoup dentreprises leur utilisation. Cependant, cause des
problmes de scurit et de fiabilit, du besoin croissant de dcrire et
implmenter nouveaux et plus complexes scnarios de business, plusieurs
autres standards ont t proposs. Certains se sont affirms, dautres sont
disparus et dautres encore ont ts runis pour en augmenter leur puissance.
[Site 9]
La situation est en volution continue et il existe diffrentes vues de la pile
(quoique elles se ressemblent toutes). La Figure II-3 montre la vision de la pile
des protocoles actuels donne par le W3C [Site 10]

II

Les Services Web

14

Figure II-3: Web Service Stack

Tout en bas on trouve les protocoles ncessaires la transmission de


messages dans le rseau (HTTP, SMTP, FTP, etc.).
En vert on voit les technologies de base qui permettent l'existence des
standards qui se trouvent au niveau suprieur (XML sur toutes).
Bass sur les technologies dcrites en vert, on trouve dans l'ordre les
standards pour la construction et l'change des messages (SOAP), ceux pour
la description des services web (WSDL) et enfin ceux ncessaires pour les
processus lis aux services web (Recherche, agrgation, etc.).
Tout autour de cette pile centrale se trouvent les standards concernant la
scurit ou la gestion. Ces standards sont en effet logiquement placs tous
les niveaux pour avoir diffrents dgres de scurit.
Comme dj dit au dbut de cet ouvrage, on ne va pas dcrire tous les
protocoles et standards (cela serait assez long). L'attention sera ddie a ceux
ncessaires pour le fonctionnement de base des services web (UDDI, WSDL,
SOAP). De plus, le chapitre 2 prsentera la couche de la scurit.
Les prochaines sections prsentent les principaux standards cits en
prcdence avec une approche "bottom-up". C'est--dire qu'on commence par
tudier les technologies de base qui permettent de comprendre les autres
standards de plus haute niveau.

II

Les Services Web

15

1.3.2. Extensible Markup Language


Tout le monde a dj entendu parler de XML. C'tait le candidat numro 1 pour
tre la technologie la plus apprcie durant les annes 90 et elle l'est encore
aujourd'hui [Myer 2005, p1]. Mais qu'est-ce que c'est exactement? Qu'est-ce
que rend XML tellement spcial? Et, pourquoi est-il la base des services
web?
Ce chapitre traitera de faon superficielle le langage. Dans une premire partie
on verra l'utilisation de XML pour dcrire des documents, et dans une deuxime
partie on verra son utilisation dans la description d'autres langages (dialectes)
en affrontant les concepts de validit et de well-formedness.
Dfinition
"XML est un mta-langage permettant de marquer la structure de documents
texte de manire arborescente en insrant des balises dans le corps des
documents". [Site 11]
C'est--dire qu'avec XML il est possible de dcrire n'importe quelle structure de
document en crant des balises personnalises.
Structure d'un document XML
Un document XML est compos fondamentalement d'une dclaration XML, d'un
lment racine (contenant tous les autres lments) et des diffrents lments
et attributs.
La dclaration XML
Pour signaler qu'un document est dcrit en utilisant XML il est ncessaire
d'crire la ligne suivant juste au dbut du document:
<?xml version="1.0"?>
code II-1: dclaration XML

Grce cette indication n'importe quel dispositif sait qu'il est en trane de lire un
document XML.

II

Les Services Web

16

Elments
Un lment consiste en une balise d'ouverture, ses attributs, le contenu et une
balise de fermeture. Il n'y a pas de restrictions dans la dfinition d'lments. Il
faut quant mme se rappeler qu'un lment doit avoir une balise de fermeture
identique celle d'ouverture (sauf pour le '/'). Voil un exemple d'lment
simple:
<myElement>je suis un lment</myElement>
code II-2: Elment simple

Attributs
Les attributs sont utiliss pour ajouter des informations sr les lments. Il
n'existe pas une rgle pour dcider quelle information est un attribut et quelle
est un lment. Une "rgle" utilise souvent est: "Si le contenu est grand, alors
c'est un lment, sinon c'est un attribut".
Mais il faut se rappeler: C'est le dveloppeur qui dcide son propre langage ou
structure! Par exemple l'lment prcdent pourrait tre modifi de la faon
suivante pour en dfinir la langue (dans ce cas franais):
<myElement lang="fr">je suis un lment</myElement>
code II-3: Elment avec attribut

Le code II-4 est la description possible d'un objet immobilier utilisant les
lments et les attributs qu'on vient d'tudier.
<?xml version="1.0" ?>
<object type="house" mode="sell">
<title>Une belle maison</title>
<address>
<street>Avenue du Silo 34</street>
<zip>1020</zip>
<city>Renens</zip>
<area>VD</area>
<country>Switzerland</country>
</address>
<price currency="CHF">1200000</price>
</object>
code II-4: Description d'un objet immobilier

Dans cette simplification l'lment <object> (lment racine) se rfre l'objet


immobilier qu'on est en trane de dcrire. Cet objet a deux attributs (type et
mode) lesquels indiquent le type d'objet (maison, appartement) et la modalit
du contrat (en vente, louer). D'aprs on trouve les lments fils <title>,

II

Les Services Web

17

<address> et <price>. Grce la logique arborescente des documents XML


l'lment <address> (lment complexe) peut avoir d'autres lments fils
(<street>, <zip>, etc.).
XML pour dcrire des dialectes
XML n'est pas limit dcrire la structure des documents. En effet, on l'utilise
aussi pour dfinir d'autres langages (dialectes), chacun avec ses propres
rgles. Mme (X)HTML a t dfinit avec XML et il doit donc respecter de
rgles dfinies par le W3C.
Jusqu'ici on n'a pas trait la validit ou le concept de "Well-formedness" (bien
form). Pour continuer dans l'tude de XML ces concepts doivent tres clarifis.
Well-formedness
Un document XML doit tre bien form. C'est--dire qu'il doit respecter les
rgles de syntaxe du langage. Il est, par exemple, obligatoire qu'un document
ait un lment racine (contenant tous les autres lments). De plus les attributs
doivent tres contenus entre guillemets (attribut="valeur").
Ils existent diffrentes rgles suivre pour respecter le principe de wellformedness mais elles ne seront pas traites dans ce texte pour des raisons
d'espace. la fin de ce chapitre le lecteur trouvera les rfrences ncessaires
pour tudier fond ces rgles.
Validit et validation
La validit d'un document est vrifie par rapport aux rgles spcifies soit
dans un DTD (Document Type Definition) ou dans un XMLSchema.
Le DTD est le vieux systme de validation (on l'utilise encore) mais maintenant
beaucoup des gens prfrent les XMLSchemas car avec eux on a un contrle
plus profond sur les lments.
Dans une optique trs superficielle le fonctionnement est le suivant:

II

Les Services Web

18

Le XMLSchema dfinit certaines rgles (comme, par exemple, "l'lment


<object> doit avoir l'attribut mode, lequel peut avoir seulement les valeurs "rent"
ou "sell".
Le code II-5 dfinit un schma pour les objets immobiliers.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.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

II

Les Services Web

19

Une fois le schma dfini il est possible de valider un document. Pour valider un
document par rapport une grammaire (XMLSchema) il faut utiliser un parseur
validant en lui fournissant soit le document XML soit une rfrence au schma.
Le code II-6 est un document invalide car l'attribut "mode" a une valeur autre
que "rent" ou "sell".
<?xml version="1.0" encoding="UTF-8"?>
<object
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="myObjectSchema.xsd"
type="house" mode="rent_for_holidays">
<title>Une maison de vacances</title>
<address>
<street>via alla Peschiera 1</street>
<zip>6600</zip>
<city>Locarno</city>
<area>Ti</area>
<country>Switzerland</country>
</address>
<price currency="CHF">2000</price>
</object>
code II-6: Objet immobilier invalide

Grce 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 schma
XML et l'attribut xsi: noNamespaceSchemaLocation indique le nom et le chemin
du schma.
La Figure II-4 est l'cran de validation de l'outil Altova XMLSpy2

Figure II-4: Ecran de validation de XMLSpy

http://www.altova.com/products/xmlspy/xml_editor.html

II

Les Services Web

20

Une fonctionnalit dsire de la cration de nouveaux dialectes est la possibilit


d'utiliser

lments

dfinis

dans

des

grammaires

diffrentes.

Cette

caractristique permet donc d'utiliser le travail d'autres personnes en vitant de


recrer la roue!
Evidemment l'utilisation d'lments drivantes des plusieurs grammaires pose
les problmes suivants:
1. au niveau de la validation d'un document, quel est le schma utiliser?
2. il est possible que deux grammaires utilisent le mme nom pour
lments diffrents comment rsoudre cette ambigut?
La solution ces problmes sont les namespaces (espaces de nommage).
Les Namespaces
Les espaces de nommage XML (namespace) offrent une mthode simple pour
qualifier les noms des lments et des attributs utiliss dans des documents
XML, en associant ceux-ci avec des espaces de nommage dsigns par des
rfrences d'URI3.
Le chapitre qu'on vient de terminer n'est pas exhaustif. Pour continuer aisment
la lecture de cet ouvrage (surtout pour la partie pratique) le lecteur est invit
tudier fond l'XML (spcialement les espaces de nommage) et les
XMLSchemas en utilisant les sources proposes.
Ressources Externes
Well-

http://en.wikipedia.org/wiki/XML#Well-

Formedness

formed_and_valid_XML_documents

XMLSchema

http://www.w3schools.com/schema/default.asp

Namespaces

http://www.w3schools.com/xml/xml_namespaces.asp

http://www.yoyodesign.org/doc/w3c/xml-namespace/Overview.html

II

Les Services Web

21

1.3.3. Simple Object Access Protocol


Dfinition
SOAP est un protocole lger destin l'change d'informations structures
dans un environnement dcentralis, distribu. Il utilise des technologies XML
pour dfinir une structure d'change de messages fournissant une construction
de messages pouvant tre changs sur divers protocoles sous-jacents. La
structure a t conue pour tre indpendante de tout modle de
programmation et autres smantiques spcifiques d'implmentation. [Site 12]
Plus en dtail, la spcification du SOAP ne dfinit rien d'autre qu'une enveloppe
contenant les informations transmettre, et un set de rgles pour la
transformation des types des donnes spcifiques aux applications et aux
plates-formes en reprsentation XML.
SOAP est une application de XML et, de plus, il est fortement bas sr 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-tte) (optionnel)

le Body(corps) (obligatoire).

La Figure II-5 montre la structure d'une enveloppe SOAP.

Figure II-5: Structure de l'enveloppe SOAP [Snell p13]

II

Les Services Web

22

Le SOAP namespace
La syntaxe utiliser pour les messages SOAP est dfinie dans les deux
namespaces suivantes:

Enveloppe: http://schemas.xmlsoap.org/soap/envelope/

Srialisation: http://schemas.xmlsoap.org/soap/encoding/

Un exemple SOAP
Le code II-7 est une requte SOAP envoye via HTTP pour obtenir des
informations sr le prix d'une action auprs d'un service d'information boursire.
POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn:
SOAPAction: Some-URI"
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.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 requte SOAP via HTTP [Site 13]

Le code II-8 , par contre, est la rponse gnre qui est envoy au client.
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<SOAP-ENV:Body>
<m:GetLastTradePriceResponse xmlns:m="Some-URI">
<Price>34.5</Price>
</m:GetLastTradePriceResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
code II-8: Exemple de rponse SOAP [Site 13]

II

Les Services Web

23

Le modle d'change des messages SOAP


Les messages SOAP sont normalement des transmissions en une seule
direction, envoyes par un metteur vers un destinataire. Mais, comme
l'exemple prcdente le montre, on implmente souvent un systme de
requte/rponse.
Il existe deux faons d'implmenter le systme de requte/rponse: le RPC
style et le Document style. Au dbut SOAP supportait seulement le style RPC
mais partir de la version 1.0 les deux sont supports.
RPC Style
Le style "RPC" (Remote Procedure Call) prvoit un message SOAP contenant
le nom de la mthode qu'on veut utiliser avec une liste de paramtres. Quand le
message arrive au serveur, la requte est transforme en mthode et une
rponse contenant l'output est gnre. Le style "RPC" est "tightly coupled" car
le message est li la dfinition de la mthode!
Le code II-9 montre une requte SOAP RPC style qui appelle la mthode
GetStockQuote avec le parametre Symbol = ORCL.
<SOAP-ENV:Envelope...>
<SOAP-ENV:Body>
<m:GetStockQuote xmlns:m="urn:xmethods:example">
<m:Symbol>ORCL</m:Symbol>
</m:GetStockQuote>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
code II-9: exemple de requte SOAP RPC style [site 14]

Document Style
Les service web avec style "Document" sont "loosely coupled". C'est dire que
le client envoie la requte et les paramtres au service dans un document XML.
La structure de ce document n'est pas li la mthode et ses paramtres.
C'est l'application (le service) qui s'occupe de lire le document XML et appeler
la mthode dsire.
Le WS-I (Web Service Interoperability Organization) conseille l'utilisation du
style "Document".

II

Les Services Web

24

Le code II-10 montre la mme requte que celle du code II-9 mais en style
"Document".
<SOAP-ENV:Envelope ...>
<SOAP-ENV:Body>
<StockQuoteRequest symbol="ORCL"/>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
code II-10: Exemple de requte avec SOAP Document style [Site 14]

Une application SOAP doit tre capable de traiter le message SOAP suivant
ces trois actions (en cet ordre):
1. identifier toutes les parties du message destines cette application
2. vrifier que toutes les parties ncessaires (identifies dans l'tape 1)
soient supportes par l'application et traites correctement. dans le cas
contraire l'application doit rejeter le message (quoique il est possible
d'ignorer les parties optionnelles identifis dans l'tape 1 sans
compromettre l'change message/rponse).
3. dans le cas que l'application SOAP ne soit pas le destinataire final, il faut
liminer toutes les parties identifies dans l'tape 1 avant de passer le
message au destinataire suivant.
L'attribut MustUnderstand
Quand une application envoie un message une autre, il est implicite que le
destinataire soit capable de traiter le message. Cela n'est pourtant pas vrai pour
les en-ttes: un destinataire ne doit pas forcement comprendre l'en-tte pour
traiter correctement le message. Si l'expditeur require la comprhension d'un
bloque Header il doit ajouter l'attribut MustUnderstand = "true" au bloque. Dans
le cas o le destinataire trouve ce flag et il ne comprend pas l'en-tte il doit
rejeter tout le message.
Cet attribut assure donc la comprhension de toute l'enveloppe SOAP.
Comme on a dj dit, un message SOAP est compos de l'enveloppe
(obligatoire), l'en-tte (optionnel) et le corps (obligatoire). Voyons-les un peu
plus en dtail.

II

Les Services Web

25

L'enveloppe SOAP
L'enveloppe

est

la

couche

externe

d'un

message

SOAP.

Elle

doit

obligatoirement contenir un lment Body. Dans le cas o l'enveloppe contient


aussi un lment Header, elle ne peut pas en contenir plus qu'un et il doit tre
le premier fils de l'lment enveloppe (plac avant le corps).
L'en-tte SOAP
L'en-tte peut contenir plusieurs lments, condition qu'ils soient tous valides
et qualifis avec les espaces de nommage. Chaque lment contenu dans l'entte s'appelle header block (bloque d'en-tte). Les bloques d'en-tte servent
communiquer informations contextuelles relevantes pour le traitement du
message. Un exemple peut tre un bloque qui contient information sur
l'authentification, sur le routage ou, comme montr dans le chapitre Le Security
header2.2.2, sur la scurit.
Le corps SOAP
L'lment Body contient l'information change. Cet lment peut avoir
plusieurs fils et, comme pour l'en-tte, il faut seulement que chaque fils soit un
lment XML bien form, valide, qualifi avec un espace de nommage et il ne
doit pas faire rfrence aux DTDs.
SOAP Fault (les erreurs)
L'lment SOAP Fault est utilis pour transmettre informations sur les erreurs
et/ou le statut de l'application. Quand il est prsent, il doit se trouver l'intrieur
du corps du message, et ne peut apparatre plus qu'une fois.
Le tableau II-1 rsume les sous-lments dfinies dans l'lment Fault.

II

Les Services Web

26

Elment

Description

Faultcode

C'est une valeur gnre algorithmiquement qui identifie le


type d'erreur. Cette valeur doit tre qualifi dans l'XML
namespace.

Faultstring

C'est une explication "humaine" de l'erreur

Faultactor

C'est l'identificateur unique du noeud o l'erreur est arriv

Detail

Est utilis pour exprimer des dtails spcifiques


l'application sur la nature de l'erreur et o c'est il produit.
Cet lment doit tre prsente si l'erreur est gnr
cause d'un problme li au corps du message. Dans le cas
d'un erreur li d'autres aspects du traitement du
message, il n'est pas obligatoire.
tableau II-1: Sous-lments dfinies dans l'lment Fault

Codes erreurs standards SOAP


Ils existent 4 types standard d'erreur (faultcodes) appartenant l'espace de
nommage http://schemas.xmlsoap.org/soap/envelope/. Le tableau II-2 les
montre avec une description.
Erreur

Description

VersionMismatch

L'enveloppe SOAP est en train d'utiliser une version


invalide de l'espace de nom pour l'lment enveloppe.

MustUnderstand

Un bloque en-tte 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. C'est--dire que le


message est mal form (mauvaise utilisation des rgles de
codage), ou que les informations contenues sont fausses
tableau II-2: Erreurs standard SOAP

II

Les Services Web

27

Ces codes sont extensibles (comme le code II-11 le dmontre) et on peut donc
spcifier plus en dtail les types d'erreurs. Pour tendre un type il faut utiliser le
point "." (cette notation implique que la partie droite est plus dtaille que
celle gauche).
<s:envelope xmlns:s="">
<s:body>
<s:fault>
<faultcode>client.authentication</faultcode>
<faultstring>
Invalid credentials
</faultstring>
<faultactor>http://acme.com</faultactor>
<details>
<!-- application specific details -->
</details>
</s:fault>
</s:body>
</s:envelope>
code II-11: Exemple d'extension d'erreur SOAP

Erreurs personnaliss
Il est aussi possible de dfinir un set d'erreurs personnaliss, dans le cas o
l'extension des types standard ne soit pas suffisante. La seule requte est qu'ils
soient dfinis correctement dans un espace de nommage. Le code II-12 montre
un erreur personnalis.
<s:envelope xmlns:s="">
<s:body>
<s:fault xmlns:xyz="urn:myCustomFaults">
<faultcode>xyz:CustomFault</faultcode>
<faultstring>
My custom error
</faultstring>
</s:fault>
</s:body>
</s:envelope>
code II-12: Exemple d'erreur personnalis SOAP

Il faut quand mme tre attentifs dans l'exploitation de cette possibilit: en tant
que personnaliss, ces erreurs ne peuvent pas tre interprts par tous les
clients et certains ne pourront pas se comporter de faon intelligente face un
tel erreur!
De plus, l'extensibilit des types standard, rend les erreurs personnaliss
inutiles dans la plus part des cas.

II

Les Services Web

28

Acteurs et message paths


Un message SOAP voyage essentiellement en une seule direction (de
l'expditeur vers le destinataire), mais il est possible que le message passe par
divers intermdiaires avant d'arriver destination. Ces intermdiaires peuvent
chacun faire quelque chose avec le message avant de l'envoyer envers les
autres acteurs.
Un intermdiaire SOAP et principalement un service web qui ajoute de la valeur
ou des fonctionnalits la transaction entre l'expditeur et le destinataire.
L'ensemble d'intermdiaires travers lesquels le message passe est appel
message path (chemin du message) et chaque intermdiaire est un acteur.
La construction d'une message path n'est pas couverte par la spcification
SOAP. Il existent diverses extensions SOAP, comme le Microsoft's SOAP
Routing Protocol (WS-Routing), qui s'occupent de cette problmatique.
Ce que SOAP spcifie est un mcanisme pour identifier quelles parties du
messages sont destines quels acteurs. Ce mcanisme est connue comme
"Targeting" (ciblage) et agisse seulement sur les en-tte et non pas sur le corps
du message.
Pour destiner un en-tte un acteur il faut utiliser l'attribut spciale "actor", dont
la valeur est un identifient unique de l'intermdiaire auquel l'en-tte est destin.
Cet identifiant peut tre le URL o l'acteur se trouve (mais aussi quelque chose
plus gnrique). Les intermdiaires qui ne s'identifient pas avec l'attribut "actor"
doivent ignorer le header.
Voyons maintenant un exemple [Snell 2002, p23]:
Imaginons qu'un revendeur reoit une grande commande d'un client par le biais
de son service web. Pour tre sr 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 numriques. Le
service fonctionne en vrifiant la validit de l'en-tte contenant la signature
numrique.

II

Les Services Web

29

Quand le client envoie la commande au revendeur, le message est rout


travers le service de validation, lequel validera la signature contenue dans l'entte et ajoutera un autre header qui contient l'information concernant la validit
ou invalidit de la signature. La Figure II-6 montre la transaction

Figure II-6: Chemin d'un message SOAP [Snell, p23]

Pour que la vrification soit effectue il est ncessaire que le service des tiers
soit capable de comprendre quel est l'en-tte qui contient la signature. Cela est
accompli en ciblant l'en-tte avec la signature au service de vrification, comme
dans le code II-13.
<s:Envelope xmlns:s="">
<s:Header>
<x:signature actor="uri:signatureVerifier">

</x:signature>
</s:Header>
<s:Body>
<abc:purchaseOrder></abc:purchaseOrder>
</s:Body>
</s:Envelope>
code II-13: Ciblage d'un En-tte

Le transport des messages SOAP


Comme dj dit dans ce chapitre, dans le Web Services Stack, SOAP est plac
au dessus des couches de transport. En tant que protocole de package il ne
doit pas se proccuper des protocoles de transport qui seront utiliss pour
l'change des messages. Cette particularit rend SOAP extrmement flexible et
en permet l'utilisation en n'importe quelle situation ou structure de rseau.
Comme exemple de cette flexibilit, SOAP::Lite l'implmentation de service
web SOAP base sur Perl, crite par Pavel Kulchenko supporte la capacit

II

Les Services Web

30

d'changer messages SOAP via http, FTP, TCP, SMTP, POP3, MQSeries et
Jabber [Snell 2002, p34].
SOAP via HTTP
cause de sa profonde prsence dans l'Internet, HTTP est le moyen de
transport le plus utilis pour l'change des messages SOAP. Il est tellement
important, que mme la spcification SOAP le traite de manire spciale, en
fournissant des dtails sur la smantique du modle d'change SOAP en
relation HTTP [Site 15].
SOAP et HTTP sont une couple naturelle parce que HTTP est un protocole
bas sur le systme requte/rponse et reflte parfaitement le concept du
modle SOAP RPC. Le fonctionnement est montr l'aide de la Figure II-7.

Figure II-7: SOAP via http [Snell, p34]

La requte SOAP est envoye au serveur au moyen d'une requte HTTP et le


serveur rend la rponse en utilisant une rponse HTTP.
Bien que cette couple fonctionne trs bien, il faut dire qu'elle ne reflte pas
forcment le modle asynchrone qu'on veut atteindre pour avoir un "loosecoupling" avec le style "Document"

II

Les Services Web

31

1.3.4. Web Service Description Language


La section 1.3.3, tant ddie au protocole SOAP, fournisse les bases
ncessaires pour implmenter un systme d'change des messages en
utilisant les moyens de transport dj existantes (comme le HTTP ou le SMTP).
Dans une situation hypothtique, on pourrait dvelopper une application digne
d'tre mise disposition du monde entier par le biais des services web.
Tout ce qu'on devrait faire serait d'expliquer au gens comment utiliser ce
service. On devrait leur dire quel est son but, quels sont les mthodes
disposition et sous quelle forme les rsultats leur seraient envoys. De plus, on
devrait aussi leur expliquer quels sont les messages d'erreur et leur origine.
Fournir toutes ces informations personnellement serait infaisable pour tous les
possibles utilisateurs. Donc Il faut un systme capable de fournir les
explications ncessaires tous les clients potentielles.
C'est pour rsoudre cette problmatique que le WSDL (Web Service
Description Language) entre en jeu. Ce protocole fournit les outils ncessaires
dcrire de faon assez complte les services web.
Le but de cette section n'est pas d'expliquer le fonctionnement du protocole au
niveau technique, mais plutt d'en montrer trs rapidement les proprits les
plus importantes.
Dfinition
WSDL est un "format XML dfinit par le groupe W3C. Il permet de dcrire les
diffrents services d'un rseau en tant que des fournisseurs accessibles
travers l'utilisation de messages. Ces messages contiennent des informations
orientes soit document, soit procdure". [Site 16]
Histoire
Le WSDL 1.1 a t prsent comme note au W3C en mars 2001 par Ariba, IBM
et Miscrosoft. Le but tait celui de dcrire les services pour le W3C XML Activity

II

Les Services Web

32

on XML Protocols. En juillet 2002, la premire version Working Draft WSDL 1.2
a t distribue [Site 17].
En juin 2007 la version WSDL 2.0 est devenue une recommandation W3C [Site
18]
La structure des documents WSDL 1.0
Un document WSDL est compos de 4 lments principales. Le tableau II-3
montre chaque lment avec une brve description.
lment

Description

<portType>

Ceci est l'lment le plus important d'un document WSDL. Il


dcrit un service web, les oprations qui peuvent tres
excutes et les messages changs.
On peut comparer cet lment une librairie de fonctions ou
une classe dans les langages de programmation
communs.

<message>

Cet lment dfinit les donnes d'une opration. Chaque


message peut tre compos de plusieurs parties et chaque
partie peut tre compare un attribut d'un fonction dans les
un langage de programmation commun.

<types>

Il dfinit les types de donnes utilises par le service web.


Pour des raisons de convivialit avec les diffrentes
plateformes, WSDL utilise la syntaxe des XMLSchemas pour
dfinir les types.

<bindings>

Dfinit les protocoles de communications utilises pour


chacun <portTypes>

<definitions>

C'est l'lment racine d'un document WSDL

<service>

Contient l'adresse o on trouve le service.


tableau II-3: lments principales d'un document WSDL [Site 19]

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 trs simple.

Figure II-8: Structure d'un document WSDL [Site 20]


<definitions>
<message name="getTermRequest">
<part name="term" type="xs:string"/>
</message>
<message name="getTermResponse">
<part name="value" type="xs:string"/>
</message>
<portType name="glossaryTerms">
<operation name="getTerm">
<input message="getTermRequest"/>
<output message="getTermResponse"/>
</operation>
</portType>
</definitions>
code II-14: WSDL file [Site 19]

Ressources Externes
spcification
Tutorial

http://www.w3.org/TR/wsdl
http://www.w3schools.com/wsdl/default.asp

II

Les Services Web

34

1.3.5. Universal Description Discovery and Integration


Une fois qu'une application est dveloppe, que le systme de requte/rponse
est implant grce SOAP et qu'on est capable de le dcrire l'aide de WSDL,
ce qui reste faire est permettre aux possibles utilisateurs de trouver le service
web dans le lieu chaotique que c'est l'Internet.
Pour ce faire, dans ce chapitre on tudiera UDDI, car c'est un des projets qui
accomplissent au mieux cette tache.
Dfinition
"UDDI Est une norme base sur XML, pousse par une quarantaine de
socits, qui doit permettre de dfinir, de trouver et d'utiliser des service web
facilement" [Site 21].
UDDI est une des spcifications centrales des services web. Il est interrog en
utilisant SOAP et fournisse accs aux documents WSDL qui dcrivent les
diffrents services.
Malheureusement en ralit personne l'utilise!
Histoire
Le projet UDDI a commenc en octobre 2000 par une collaboration entre
Microsoft, Ariba et IBM. Au cours de temps d'autres entreprises s'y sont jointes
comme Sun Microsystems, Oracle, HP et SAP.
En 2005 la version UDDI V3.2 a t approuve comme OASIS Standard.
ce moment, le OASIS UDDI Spec TC travail sur l'amlioration de la scurit,
de la fidlit et de la smantique. De plus, on cherche d'aligner le plus possible
UDDI l'architecture des services web et aux autres standards [Site 22].

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 associes ces dernires. On y retrouve donc des
informations comme le nom de l'entreprise, ses coordonnes, la
description

de

l'entreprise,

mais

galement

l'ensemble

de

ses

identifiants.

Pages jaunes: recensent les services web de chacune des entreprises


sous le standard WSDL

Pages vertes: fournissent des informations techniques prcises sur les


services fournis. Ces informations concernent les descriptions de
services et d'information de liaison ou encore les processus mtiers
associs.

La consultation
Il existe trois types d'annuaires UDDI: l'annuaire priv l'entreprise (avec accs
restreints), l'annuaire publique et l'annuaire semi-priv.
Le tableau II-4 montre les diffrences entre les trois types:

II

Les Services Web

36

Type

Description

Publique

Les outils administratives peuvent Website


tres

Analogie web

scuriss,

mais

exemple
Xmethods4

la

consultation est essentiellement


libre. Les donnes peuvent tres
changs avec d'autres registres
Priv

Se trouve derrire un firewall, Intranet

IBM

isol du rseau publique. Soit les

WebSphere

outils

UDDI

administratives

que

la

consultation sont scuriss. Les

Registry5

donnes ne sont pas changs


avec d'autres registres
Semi-priv C'est

un

l'intrieur
contrl.
seulement

annuaire
d'un

fournit

environnement

C'est--dire
les

Extranet

partenaires

que

Trading
partner
network

ont

accs aux diffrents outils. Les


donnes peuvent tre changs
avec d'autres annuaires auxquels
on fait confiance.
tableau II-4: Diffrences entre les 3 types d'annuaires UDDI [Site 23, p5]

Une entreprise peut choisir de crer plusieurs registres de faon sparer les
informations internes de ces accessibles au publique (on parle toujours
d'informations relatives aux services).
Jusqu'au 12 janvier 2006 l'annuaire publique par excellence tait le UDDI
Business Registry (UBR). C'tait un annuaire publique et libre, gr en
concomitance par IBM, Microsoft, NTT Communications et SAP. Tout le monde

http://www.xmethods.net

http://publib.boulder.ibm.com/infocenter/adiehelp/index.jsp?topic=/com.ibm.wasee.doc/info/ee/ae/twsu_e
p.html

II

Les Services Web

37

tait libre de publier des informations n'importe quel noeud UBR et d'y faire
des requtes.
partir du 12 janvier 2006 le UBR t abandonn cause de la
standardisation en 2005 de la version UDDI V3.2 parce que les entreprises qui
le graient on dfini les buts du projet comme achevs.
Quel que soit le type d'annuaire, pour lancer une requte on utilise des
messages SOAP.
L'utilisation d'UDDI est en dehors des buts de ce document. Pour le lecteur qui
veut approfondir ce domaine les ressources externes sont un bon point de
dpart.
Ressources Externes
Spcification

http://uddi.org/pubs/uddi_v3.htm

UDDI V3.0.2
http://searchwebservices.techtarget.com/originalContent/
Tutorial

0,289142,sid26_gci916789,00.html

II

1.4.

Les Services Web

38

Autres Standards

Les sections prcdentes traitaient les technologies et protocoles les plus


utiliss et standardises. Cependant, il en existent beaucoup plus, et ce
chapitre les prsente rapidement diviss par catgorie. Chaque standard ou
protocole prsent est suivi par une ressource (pour ce qui sont intresss).
La liste suivante est surtout extraite de [Snell 2002, pp 175-179] car c'est une
des sources les plus compltes.
1.4.1. Protocoles de package
XML-RPC
C'est la manifestation originale du SOAP ide par Dave Winer de Userland
Software. Ce simple protocole tait beaucoup utilis dans la communaut open
source (mais il est dsormais un protocole abandonn).
http://www.xmlrpc.org/.
Jabber
Jabber est un protocole de transport et de package qui peut tre utilis dans un
systme peer-to-peer asynchrone.
http://www.jabber.org
1.4.2. Protocoles de description
DAML-S
Le DARPA Agent Markup Language Ontology for web services est un projet de
recherche acadmique pour dcrire smantiquement les services web.
http://daml.semanticweb.org

II

Les Services Web

39

RDF
Le Resource Description Framework (RDF) est un modle de graphe destin
dcrire de faon formelle les ressources Web et leurs mtadonnes, de faon
permettre le traitement automatique de telles descriptions. Dvelopp par le
W3C, RDF est le langage de base du Web smantique. Une des syntaxes
(srialisation) de ce langage est RDF/XML [Site 24].
Il y a eu certains discussions sr la possibilit de dcrire les services web trs
facilement avec RDF. Beaucoup d'exemples ont t dvelopps, et il existe
aussi une version modifi de WSDL conforme la syntaxe RDF.
http://www.w3.org/rdf.
1.4.3. Protocoles de recherche/dcouverte
WS-Inspection
Le Web Service Inspection Language fournit un indice XML pour trouver les
services disponibles un certain endroit dans le rseau.
http://www.-106.ibm.com/developerworkds/webservices/library/wswsilspec.html
ebXML Registry
Fait partie du projet ebXML et le but c'est de dfinir un model standard pour
rechercher et trouver les services web purement business. Cet approche est
diffrente mais non pas incompatible avec UDDI. Il inclut beaucoup plus d'
informations que UDDI.
http://www.ebxml.org/
1.4.4. Protocoles de scurit
XML Digital Signatures
C'est un effort commun du W3C et du IETF pour dfinir une mthode standard
de reprsentation des signatures numriques en XML.
http://www.w3.org/signature/

II

Les Services Web

40

XML Encryption
C'est un effort du W3C pour dfinir une mthode standard de cryptage des
contus XML et de reprsenter des donnes crypts sous la forme de XML.
http://www.w3.org/encryption/2001
SAML
Le Security Assertions Markup Language est un standard informatique
dfinissant un protocole pour changer des informations lies la scurit.
Bas sur le langage XML. SAML a t dvelopp par OASIS [Site 25].
http://www.oasis-open.org/committees/security/
XKMS
Le XML Key Management Service est une spciation pour implmenter une
infrastructure de management des cls publiques base sur les services web.
http://www.w3.org/tr/xkms
http://www.xkms.org
1.4.5. 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.
http://www-128.ibm.com/developerworks/webservices/library/ws-phtt/
1.4.6. Protocoles de routage et workflow
WS-Routing
C'est un mcanisme propos par microsoft pour dfinir le chemin d'un message
SOAP parmi diffrents intermdiaires.
http://msdn2.microsoft.com/en-us/library/ms951249.aspx

II

Les Services Web

41

WS-Address
C'est un mcanisme 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 consacres
XML, et prsente 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 montre n'est
rien d'autre qu'une slection parmi les multitudes qu'on trouve. L'exclusion d'un
protocole de cette liste n'est en aucun cas interprter comme un jugement sur
sa validit.

II

Les Services Web

42

Scurit

Le concept de scurit est primordial quand on parle des systmes en rseau.


Il existe diverses manires de protger les donns. On passe de l'accs limit
(login, intranets, etc.) l'utilisation de mthodes de cryptage ou de signature de
documents numriques. Ce chapitre rpond la question sur la scurit qu'on
s'est pos au dbut de cet ouvrage.
L'ide la base des ces services web est l'change d'informations permettant
d'amliorer les processus des chaque partenaire. La nature de ces informations
est trs variable, mais il arrive souvent qu'on s'change informations
confidentielles (numros des cartes de crdit, donnes personnels, donnes
business, etc.). Vue cette nature, il est trs important de protger ces donnes
de toute modification et accs interdit.
Un exemple de ce besoin de protection peut tre une compagnie arienne qui
offre un service web permettant la rservation des places pour ses vols. Cette
compagnie doit tre certaine que seulement les partenaires autoriss puissent
utiliser le service de faon viter des problmes de nature conomique dans
le cas de fausses rservations.
Un autre cas, beaucoup plus intressant, est le cas des services web qui
valident les cartes de crdit. Dans ce cas, il est strictement ncessaire
d'interdire un tiers de lire et/ou modifier les informations qui voyagent dans le
web (on parle de scurit end-to-end).
Avec les exemples montrs, on comprends donc la ncessit d'ajouter la
couche "Scurit" au Web Services Stack tudi dans le chapitre 1.3.1.
Ce chapitre tudie le concept de scurit et on analysera en dtail la
spcification OASIS Web Service Security (WSS). De plus, on tudiera la
thorie et l'utilisation du Username Token.

II

2.1.

Les Services Web

43

Terminologie

Le domaine de la scurit est assez complexe, et avant de commencer son


tude il est trs important de connatre la terminologie. Ce sous-chapitre
prsente quelques dfinitions.
Confidentialit
La confidentialit a t dfinie par l'Organisation internationale de normalisation
(ISO) comme "le fait de s'assurer que l'information n'est seulement accessible
qu' ceux dont l'accs est autoris", et est une des pierres angulaires de la
scurit de l'information. La confidentialit est l'une des raisons d'tre des
cryptosystmes, rendus possibles dans la pratique par les techniques de la
cryptographie moderne [Site 27].
Intgrit
De manire gnrale, l'intgrit des donnes dsigne l'tat de donnes qui, lors
de leur traitement, de leur conservation ou de leur transmission, ne subissent
aucune altration ou destruction volontaire ou accidentelle, et conservent un
format permettant leur utilisation [Site 28].
Cl de chiffrement
Une cl est un paramtre utilis en entre d'une opration cryptographique
(chiffrement, dchiffrement, scellement, signature numrique, vrification de
signature).
Une cl de chiffrement peut tre symtrique (cryptographie symtrique) ou
asymtrique (cryptographie asymtrique) : dans le premier cas, la mme cl
sert chiffrer et dchiffrer ; dans le second cas on utilise deux cls
diffrentes, la cl de chiffrement est publique alors que celle servant au
dchiffrement est garde secrte (la cl secrte, ou cl prive, ne peut pas se
dduire de la cl publique) [Site 29].

II

Les Services Web

44

Cryptographie
La cryptographie est une des disciplines de la cryptologie s'attachant protger
des messages (assurant confidentialit, authenticit et intgrit) en s'aidant
souvent de secrets ou cls [Site 30].
Security Token (Marque de scurit)
Un Security token contient les informations sur l'identit et la scurit. Il est
utilis pour autoriser l'accs documents et ressources [Site 31].
Signature numrique
Est un mcanisme permettant d'authentifier l'auteur d'un document lectronique
et de garantir son intgrit, par analogie avec la signature manuscrite d'un
document papier [Site 32].

II

Les Services Web

2.2.

45

Web Service Security

Originellement dvelopp par IBM, Microsoft, VeriSign et Forum Systems et,


ce moment, conduit par le comit OASIS-OPEN, le protocole Web Service
Security (WS-Security) permet d'appliquer de la scurit aux services web.
La premire spcification (WS-Security 1.0) a t lance le 19 avril 2004 et le
17 fvrier 2006 le comit a lanc la version 1.1 [Site 33].
Dfinition
La spcification Web Service Security (WS-Security) propose un set standard
d'extensions SOAP qui peuvent tre utilises dans le dveloppement de
services web scuriss de faon implmenter l'intgrit et la confidentialit
des messages changs [Site 34].
Le WS-Security propose aussi, un mcanisme gnral pour associer des
tokens aux messages. Cependant il n'est pas ncessaire d'utiliser un type de
token spcifique. En effet, WS-Security a t structur de faon tre
extensible (c'est--dire qu'il supporte des formats de token multiples) pour
permettre diffrents mcanismes d'authentification et scurisation.
De plus, WS-Security dcrit comment encoder tokens de scurit binaires et
comment les attacher aux messages SOAP. Parmi les tokens dcrits on trouve:

Username tokens

X.509 tokens

SAML tokens

REL Tokens

Kerberos tokens

D'ailleurs, l'intgrit des messages est assure en combinant les signatures


XML et les security tokens. De cette faon on peut assurer que les messages
ont t envoys par un expditeur appropri et ils n'ont pas ts modifis
durant l'change.

II

Les Services Web

46

2.2.1. Le modle de scurit


Le WS-Security spcifie un modle de scurit des messages en termes d'une
combinaison de security tokens et des signatures numriques avec le but de
protger les messages SOAP. Principalement il est fondamental qu'aucune
modification ne soit pas faite sans qu'on la dtecte (intgrit) et que les
messages

soient

lisibles

exclusivement

aux

destinataires

prvus

(confidentialit)!
L'intgrit des messages est garantie par l'utilisation des XML Signatures
(XMLSIG) en combinaison avec les security tokens de faon dtecter les
modifications. Ce modle permet aussi l'utilisation de plusieurs signatures par
diffrents acteurs. De plus, l'extensibilit du mcanisme d'intgrit permet
l'utilisation de formats de signature autres que le XMLSIG.
La confidentialit des messages se base sr l'utilisation de XML Encryption
(XMLENC) en conjonction avec les security tokens de faon rendre
diffrentes parties du message confidentielles. Comme pour les signatures, il
est possible d'utiliser d'autres processus cryptographiques en dehors du
XMLENC.
2.2.2. Le Security header
Le security header (<wsse:Security>)permet d'ajouter informations de scurit
un message SOAP. Cet lment a les attributs optionnels "actor" et "role" et
ils sont utiliss pour adresser l'en-tte un destinataire spcifique (si le
message passe travers plusieurs intermdiaires).
Le code II-15 montre la syntaxe et la position de l'en-tte de scurit
<s11:Envelope>
<s11:Header>

<wsse:Security s11:actor="" s11:mustUnderstand="">

.</wsse:Security>
</s11:Header>

</s11:Envelope>
code II-15: Syntaxe et position de l'en-tte de scurit

II

Les Services Web

47

Le tableau II-5 est un extrait de ce prsent dans la spcification OASIS et


montre les lments et attributs relatifs l'en-tte de scurit avec leur
signification et d'autres dtails.
Autres info.
/wsse:Security
L'en-tte permettant d'envoyer informations de scurit
/wsse:Security/@actor
Cet attribut permet l'identification d'un acteur spcifique

Optionnel

/wsse:Security/@mustUnderstand
Cet attribut est utilis pour indiquer si un lment doit tre La non utilisation
forcement trait au non. True (Vrai) signifie "traitement implique valeur =
forc"

false

/wsse:Security/@{any}
Ceci est un mcanisme permettant l'addition d'autres
attributs, bass sur des schmas. Attributs non reconnus
devraient causer un erreur
tableau II-5: lments et attributs relatifs l'en-tte de scurit [Site 35, pp 22-23]

l'intrieur de l'en-tte de scurit on trouve lments tels que les security


tokens et les signatures. Il faut se rappeler que l'en-tte peut contenir n'importe
quel type de token ou de signature.
2.2.3. Username Token
Comme on a dj vue dans les chapitres prcdents, le WS-Security header
permet l'utilisation de plusieurs security tokens. Cette section traite le
Username token (le plus simple) pour comprendre le mcanisme de
fonctionnement. Plus tard, nous regarderons superficiellement les autres tokens
de faon en savoir un peu plus sr les possibilits existantes.
Le

Username

token

permet

de

soumettre

un

nom

d'utilisateur

et,

ventuellement, un mot de passe. Le code II-16 en montre la syntaxe et le


tableau II-6 est montre les lments et les attributs relatifs au Username Token.

II

Les Services Web

48

<S11:Envelope xmlns:S11="..." xmlns:wsse="...">


<S11:Header>
...
<wsse:Security>
<wsse:UsernameToken wsu:Id="">
<wsse:Username> </wsse:Username>
</wsse:UsernameToken>
</wsse:Security>
...
</S11:Header>
...
</S11:Envelope>
code II-16: Syntaxe de l'lment UsernameToken

Autres info.
/wsse:UsernameToken/wsse:Password
Cet lment est utilis pour fournir un mot de passe (ou un
quivalent, comme le hash). Il est recommand que cet
lment soit utilis seulement avec un canal scuris, tel que
le HTTP/S, ou que le token lui-mme soit crypt.
/wsse:UsernameToken/wsse:Password/@Type
Cet attribut spcifie le type de mot de passe utilis.

Optionnel

/wsse:UsernameToken/wsse:Password/@{any}
Ceci est un mcanisme permettant l'addition d'autres attributs,
bass sur des schmas.
/wsse:UsernameToken/wsse:Nonce
Valeur alatoire crypt

Optionnel

/wsse:UsernameToken/wsse:Nonce/@EncodingType
Spcifie le type de Nonce. Si cet attribut n'est pas spcifi, la Optionnel
valeur par dfaut est Base64
/wsse:UsernameToken/wsu:Created
Spcifie un timestamp pour indiquer le temps de cration d'un Optionnel
message
tableau II-6: lments et attributs relatifs le Username Token [Site 36, pp 8-9]

II

Les Services Web

49

L'lment <wsse:Password>
En couple avec l'lment <wsse:Username> il est aussi possible de spcifier un
lment <wsse:Password>. Le types de mots de passe peuvent tre librement
choisis (derived password, S/KEY, etc.) mais on trouve souvent le type
PasswordText ou PasswordDigest.
Evidemment si on utilise un mot de passe du type PasswordText l'information
sera en texte plain (lisible). Dans le cas de PasswordDigest, au contraire,
l'information contenue est un Digest, c'est--dire un quivalent du mot de passe
originale (par exemple le hash).
Les mots de passe du type PasswordDigest sont dfinies comme tant le
rsultat du codage en Base64[XML-Schema] du valeur de hash SHA-1 du mot
de passe cod UTF8. Il est quand mme important de noter que si la
PasswrodDigest n'est pas envoye par le biais d'un canal scuris, elle n'offre
pas une scurit plus leve qu'un mot de passe PasswordText.
Les lments <wsse:Nonce> et <wsse:Created>
Une des attaques les plus simples mettre en uvre est le "Replay Attack".
Cet attaque consiste intercepter une information gnuine et la rpter pour
s'authentifier auprs d'un service [Site 37]. Les points suivantes montrent le
fonctionnement de cet attaque:
1) Bob

Envoie

une

requte

ad

Alicia

en

lui

communicant

sa

PasswordDigest.
2) Cleancy intercepte la communication
3) Alicia donne accs la ressource Bob parce que le mot de passe c'est
correcte.
4) Bob ferme la communication avec Alicia
5) Cleancy retransmet la PasswordDigest de Bob Alicia. Il s'approprie
donc de l'identit de Bob
6) Alicia n'a aucun lment pour comprendre ce qui est en trane d'arriver
et donne accs Cleancy.

II

Les Services Web

50

Les lments <Nonce> et <Created> sont utiliss pour protger le service de ce


type d'attaque.
Un Nonce est un numro gnr avec un algorithme alatoire. Ce numro doit
tre coll chaque message envoy de faon ce que le serveur puisse
dtecter les nombres dj utiliss et donc rejeter un message dj arriv.
Le problme est que le serveur doit avoir une liste des Nonces dj utiliss
consumant ainsi des ressources. Pour diminuer les ressources destines ce
contrle, l'metteur doit coller au message l'lment Created. Cet lment n'est
rien d'autre qu'un timestamp gnr au moment de la cration du message.
En combinant le Nonce et le Timestamp (Created) le serveur peut retenir
seulement les dernires nonces arrivs (on dfini une limite de temps soit par
exemple 5 minutes) et diminuer donc les ressources utilises.
Quand on utilise ces deux lments il faut les inclure dans le PasswordDigest
de la faon suivante:
PasswordDigest = Base64(SHA-1(nonce + created + password)
Le code II-17 est un exemple avec PasswordText et le code II-18 en est un
avec PasswordDigest.
<S11:Envelope xmlns:S11="..." xmlns:wsse="...">
<S11:Header>
...
<wsse:Security>
<wsse:UsernameToken>
<wsse:Username>Bob</wsse:Username>
.<wsse:Password>BobPassword</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
...
</S11:Header>
...
</S11:Envelope>
code II-17: exemple avec PasswordText

II

Les Services Web

51

<S11:Envelope xmlns:S11="..." xmlns:wsse="...">


<S11:Header>
...
<wsse:Security>
<wsse:UsernameToken>
<wsse:Username>Bob</wsse:Username>
.<wsse:Password Type="#PasswordDigest">
weYI3nXd8LjMNVksCKFV8t3rgHh3Rw==
</wsse:Password>
.<wsse:Nonce>WscqanjCEAC4mQoBE07sAQ==</wsse:Nonce>
.<wsu:Created>2003-07-16T01:24:32Z</wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
...
</S11:Header>
...
</S11:Envelope>
code II-18: exemple avec PasswordDigest

Erreurs
Les implmentations devraient utiliser le set d'erreurs dfinis dans la
spcification WSS:SOAP Message Security pour augmenter l'interoprabilit.
S'il est vraiment ncessaire d'utiliser des codes d'erreur personnaliss il faut
qu'ils soient dfinies dans des espaces de noms privs. En tout cas, quand on
utilise des messages d'erreur personnaliss, il faut tre attentifs ne pas fournir
des vulnrabilits facilitant les attaques!
Les autres tokens compatibles avec la WS-Security sont trs bien documents
et une fois compris le fonctionnement du security token il est assez simple
d'apprendre utiliser les autres.
Ressources Externes
Liste des spcifications pour les diffrents tokens
http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=wss#technical

II

Les Services Web

52

Conclusion Thorie

Les technologies
Les services web sont des technologies en volution continue. Aujourd'hui
certaines des ces technologies se sont imposes comme des standards et elles
sont presque globalement adoptes. D'autres par contre sont destines
disparatre. La jungle des technologies est pleine de nouveaux protocoles et le
temps seulement pourra nous dire lesquels formeront les services web du futur.
Le dveloppement
Les dveloppeurs ont toujours plus d'environnements qui simplifient leur travail
dans le domaine des services web. Par exemple, ils existent maintenant des
diteurs visuels qui permettent une gnration trs simple des documents
WSDL ou des prototypes de service web6. De plus, il est toujours plus simple
de transformer une application normale en un service web (l'environnement
Microsoft .Net Framework est un des outils les plus avancs en ce sens).
La scurit
Au niveau de la scurit on a fait des progrs normes, mais ce domaine est
encore trop chaotique. Il faut quand mme dire qu'un des points forts des
services web est l'utilisation des technologies standard de l'Internet. Cela
permet d'atteindre des niveaux de scurit acceptables en utilisant technologies
mres comme le HTTPS, SSL, SSH ou VPN.
Le business
C'est dj longtemps que les grandes entreprises ont compris les potentialits
des services web (maintenant on voit aussi entreprises plus petites s'intresser
ce domaine), mais la plus grande partie des services web qu'on trouve dans
le rseau, sont assez simples. Je ne veux pas dire que les services web
existants sont presque inutiles, mais dans le futur, on devrait voir des grands
rseaux de services avec des capacits beaucoup plus intressantes.

Par exemple Altova MissionKit

III

Travail pratique

III. Travail pratique

53

III

Travail pratique

54

Introduction

Dans la section prcdente on a tudi les diffrents standards ncessaires au


dveloppement des services web. Cette section est ddie aux services web
dans la pratique et dans les chapitres qui suivent nous allons appliquer les
connaissances apprises au dveloppement d'un outil de recherche d'objets
immobiliers bas sur les services web.
Dans le deuxime chapitre on prsente le problme central de ce travail et dans
le troisime on analyse la situation aux Etats-Unis (car la ralit nordamricaine est plus avance de celle suisse dans l'utilisation des nouvelles
technologies du web). Aprs cette analyse on passe vraiment au projet pratique
et le chapitre 4 est ddi l'architecture et l'implmentation de notre solution.
Finalement le chapitre 5 regroupe l'valuation du projet et les considrations
personnelles.

Le problme de la recherche d'objets immobiliers

Au moment actuel, quand une personne recherche un objet immobilier


(appartement, maison, etc.) les processus suivre sont deux7:
1. Utiliser les diffrents sites web des rgies
2. Utiliser un portail ddi qui regroupe les objets des diffrentes rgies
dans une seule base de donnes
l'aide de la Figure III-1 on voit que dans le premier cas l'utilisateur excute
diffrentes requtes dans les diffrents sites web des rgies. Cela dit, il est
claire que l'utilisateur doit tout d'abord connatre l'endroit o les sites se trouvent
et il doit aussi apprendre utiliser les diffrentes interfaces proposes.

Evidemment on parle ici de l'utilisation des technologies de l'Internet.

III

Travail pratique

55

Figure III-1: Utilisation des diffrents sites web des rgies immobilires

La Figure III-2 montre l'interaction avec un site ddi. On voit toute de suite les
bnfices d'une telle approche: l'utilisateur n'a qu' excuter une requte dans
le site web ddi en ayant comme rsultat tous les objets des rgies
partenaires.

Figure III-2: Utilisation d'un intgrateur ordinaire

III

Travail pratique

56

la situation actuelle ce deuxime modle est le meilleur, mais il faut quand


mme dire qu'il a des limites et des problmes structurels assez vidents. Le
chapitre 2.1 prsente en dtail ce modle.

2.1.

Les portails ddis

Ce sous-chapitre est divis en deux parties. La premire prsente les deux


principaux

portails

ddis

en

Suisse

et

la

deuxime

explique

leur

fonctionnement avant de mettre en vidence les problmes existants.


2.1.1. Homegate et Immoscout24
En Suisse les deux acteurs principales sont Immoscout24.ch et Homegate.ch.
Ces deux portails prsentent un nombre trs grand d'annonces immobilires.
Immoscout24.ch8
ImmoScout24 est la plus importante place de march lectronique de Suisse
pour les logements, les immeubles commerciaux et de vacances.
Ce site propose quotidiennement plus de 52000 offres on-line. ImmoScout24
est une plate-forme du groupe Scout24, leader incontest du rseau suisse des
places de march on-line [Site 38].
homegate.ch9
Cette entreprise est une filiale de la Banque Cantonale de Zurich. Elle a t
fonde le 1er mars 2001 et son sige est Adliswil, tout prs de Zurich [Site
39].
Avec, chaque mois, environ 2.2 million de visites de plus de 650'000 visiteurs,
homegate.ch fait partie des entreprises en ligne qui ont la plus vaste audience
[Site 40].

8
9

http://www.immoscout24.ch/IS24Web/Public/Home.aspx?nav=-1&lng=fr&wl=1
http://www.homegate.ch/homegate/index?layout=&agency=&lang=fr

III

Travail pratique

57

2.1.2. Fonctionnement et limites des portails ddis


Le fonctionnement des portails ddis est plus ou moins le suivant:
Le portail a diffrents partenaires. Chaque partenaire peut insrer des
annonces directement dans le systme du portail ou prparer ( une intervalle
prcise) un fichier texte (gnralement XML) contenant tous les objets prsents
dans la propre base de donnes. Plusieurs fois par jour le portail prend les
fichiers et sauvegarde les informations dans sa base de donnes [Annexe A].
Mme si pour l'utilisateur il existe beaucoup d'avantages, ce modle prsente
certains erreurs conceptuels:

Tout d'abord il faut noter que la mme information est rpte: les objets
d'une rgie partenaire sont contenus dans deux au plusieurs bases de
donnes (dans le cas qu'une rgie soit partenaire avec plusieurs
portails).

De plus, il y a le risque que l'information transmise l'utilisateur soit


obsolte (que se passe-t-il si l'utilisateur reoit le prix d'un objet et
malheureusement ce prix a chang depuis la dernire mise jour?).

Finalement dans une analyse globale du systme (rgies + portails)


l'utilisation de mmoire et de ressources est double cause de la
rptition des informations.

Le prochain chapitre analyse la ralit des Etats-Unis et du canada et prsente


un standard d'change, dvelopp par les associations du march immobilier
de ces pays pour rsoudre des problmes similaires ceux mise en vidence
dans ce chapitre.

III

Travail pratique

58

Situation aux Etats-Unis et au Canada

En Amrique du nord il existe des services runissant les objets immobiliers


provenant de plusieurs parties du continent. Ces services s'appellent Multiple
Listing Services et ils sont comparables aux sites (bien plus petits) prsents
pour la Suisse.

3.1.

Multiple Listing Service (MLS)

Dfinition
Selon wikipedia le Multiple Listing Service c'est une base de donnes
permettant de montrer les objets immobiliers en vente dans une certaine rgion.
Parmi les objets on trouve ceux mis en vente par les agents immobilires
affilis ce particulier MLS ou appartenant la National Associtation of
Realtors (NAR) ou la Canadian Real Estate Association (CREA) [Site 41].
Ce type de service est trs utilis aux Etats-Unis et en Canada, mais on
commence en voir la prsence aussi en Europe.
Le but d'un MLS est de simplifier la recherche d'objets immobiliers dans une
certaine rgion en augmentant la productivit des agents immobiliers.
Toutefois grce au dveloppement de l'Internet et donc grce un accs plus
simple aux informations, il existe maintenant plus de 800 MLS (seulement aux
Etats-Unis) et il faut donc trouver une solution pour consolider toutes les
informations [Site 42].
C'est pour consolider les informations provenant de plusieurs MLS que le Real
Estate Standards Organization (RESO) a dvelopp le RETS.

3.2.

Real Estate Transaction Protocol (RETS)

Dfinition
Selon Wikipedia RETS a t cr pour surmonter les difficults prsentes par
l'existence d'un grand nombre d'organismes (MLS, agents immobiliers, clients)
dsirant partager et distribuer les informations immobilires. RETS satisfait ce

III

Travail pratique

59

besoin en fournissant une norme commune pour l'change des donnes


immobilires. Beaucoup de MLS emploient le protocole RETS [Site 43].
Ce moment la version 2 de RETS est devenue un standard.
RETS et XML
La premire version de RETS utilisait partiellement XML et les technologies
drivantes. Mais les standards de base de RETS2 (standardis en 2006) sont
SOAP, WSDL, XML et XMLSchema. Pour ce que concerne la scurit, RETS2
utilise WS-Security et plus en dtail, SOAP Message Security, Username
Token Profile, X.509 Certificate Token Profile, et SAML Token Profiles.
RETS2 et UDDI
La NAR (National Association of Realtors) a dcid d'exclure UDDI des
standards lis RETS2 car les services offerts par ce standard sont
normalement fournis aprs accords contractuels. C'est--dire que personne
peut chercher un MLS RETS-compliant et l'utiliser librement.
Considrations personnelles
RETS2 est un pas norme dans le dveloppement d'un langage commun entre
les diffrents acteurs immobiliers. Les technologies des base des services web
sont valables et RETS2 en est la preuve. Malheureusement RETS est trop li
au march nord-amricaine et surtout aux objets en vente seulement. Il faudrait
dvelopper un standard plus gnral, capable de reprsenter aussi les autres
objets.
L'outil dvelopp dans le cadre de ce projet n'utilise pas RETS car il est trop
complexe pour les objectifs prfixs.

III

Travail pratique

60

Solution propose

Pour rsoudre les problmes existants dans les modles actuels on propose
une solution alternative aux portails ddis. La solution propose est la
conception d'une interface commune permettant l'change des informations sur
les objets immobiliers en utilisant les services web.
Le chapitre 4.1 prsente l'architecture du modle. On commence par son
fonctionnement pour passer aux avantages et limites. Dans le chapitre 4.2 le
lecteur verra l'architecture des applications dveloppes pour dmontrer le
fonctionnement du modle.

Finalement le chapitre 4.3 est ddi

l'implmentation.

4.1.

Modle

La Figure III-3 prsente le modle orient service web. Dans ce modle les
rgies implmentent une interface avec des mthodes prdfinies de faon
ce que l'intgrateur puisse dfinir un client capable d'appeler ces mthodes
pour retrouver les objets respectant certains critres de recherche.

Figure III-3: Modle de recherche orient service web

III

Travail pratique

61

4.1.1. Fonctionnement
L'utilisateur doit envoyer sa requte l'intgrateur seulement. Ce dernier
construit des requtes SOAP et les envoie aux diffrents services web des
rgies. Finalement les rgies excutent les requtes dans leur bases de
donnes prives et envoient une rponse SOAP l'intgrateur. Une fois que
toutes les rponses arrivent, l'intgrateur prsente les rsultats sous forme
d'html.
4.1.2. Avantages
Ce modle permet d'viter des problmes de redondance (les informations des
objets sont contenues dans les bases de donnes prives des rgies) et les
informations prsentes l'utilisateur sont toujours jour.
Un autre avantage est que l'intgrateur ne doit pas remplir aucune base de
donnes prive en lisant intervalles rgulires les documents des rgies (il
pargne des ressources).
De plus, en respectant la logique des services web, chaque rgie peut choisir
l'architecture qu'elle prfre (la seule chose respecter c'est l'interface
prdfinie). Dans cette optique on peut avoir par exemple un service web
implment en Perl, un autre en Java et l'intgrateur en PHP ou .Net!
4.1.3. Limites
Ce modle est quand mme simplifi car les but du projet taient d'implmenter
l'interface et l'intgrateur seulement. cause de cela, on ne voit donc pas un
registre et l'intgrateur ne peut donc pas chercher des nouvelles rgies
implmentant l'interface.
De plus, par rapport aux portails ddis, il est important de noter que le temps
pour transmettre le rsultats l'utilisateur sera majeur, car il est beaucoup plus
rapide d'excuter une requte SQL dans la base priv d'un portail que d'aller
chercher les informations directement chez les rgies.

III

Travail pratique

4.2.

62

Architecture

Pour dmontrer que le modle fonctionne on a choisi de dvelopper les


applications suivantes:
1. Une rgie fictive (immoOne) avec le service web implmentant l'interface
commune
2. Un intgrateur (immIntegrator) avec le client permettant d'utiliser le
service web offert par immOne
L'intgrateur et la rgie seront publis sur un serveur local mais, pour
dmontrer que le modle fonctionne dans la ralit, on a publi une copie de
immoOne dans le web. La Figure III-4 montre l'output du travail.

Figure III-4: Architecture de la solution

III

4.3.

Travail pratique

63

Implmentation

Ce sous-chapitre est ddi l'implmentation des diffrentes applications.


Dans une premire partie on tudiera le deux approches dans le
dveloppement des services et on verra pourquoi on a choisi une approche qui
se trouve au milieu pour dcrire notre interface. Dans un deuxime temps on
prsente les applications et les outils.
4.3.1. Code-First ou Contract-First?
Il existe deux approches quand on implmente des services web: l'approche
contract-first consiste dfinir l'interface d'un service web (XSD et WSDL) et
dans un deuxime temps coder l'application. Le code-first consiste crire le
code (java, C++, .Net, etc.) et gnrer en un deuxime temps l'interface
WSDL automatiquement.
L'approche code-first est trs simple, et le processus de dveloppement est
plus court; mais avec ce modle on n'atteint pas des niveaux d'interoprabilit
acceptables (car les fichiers WSDL gnrs sont souvent lis l'environnement
de dveloppement). Avec l'approche contract-first on atteint de niveaux
d'interoprabilit levs, mais le dveloppement est assez long et la
maintenance de l'interface n'est pas toujours facile [Site 44].
En raison de sa simplicit, on a dcid d'utiliser l'approche code-first. Il faut
quand mme dire qu'on a crit l'application en respectant un prototype
d'interface dfini auparavant. Cet approche intermdiaire a facilit la publication
du service web (grce la gnration automatique du fichier WSDL) tout en
maintenant un niveau d'interoprabilit acceptable.
Evidemment le fichier WSDL montre des problmes car certains types de
donnes ne sont pas standard, mais vue la simplicit de l'application gnre,
cela n'est pas trop un problme!
La Figure III-5 montre le fichier WSDL dfinitif (gnr par la class NuSOAP).

III

Travail pratique

64

Figure III-5: Fichier WSDL du service web

III

Travail pratique

65

4.3.2. Outils
Pour implmenter les applications on a choisi diffrents outils. Ce sous-chapitre
les montre avec, pour chacun une petite dfinition et les motivations du choix.
Apache Server 2.2.4
"est un serveur HTTP produit par la Apache Software Foundation. C'est le
serveur HTTP le plus populaire du World Wide Web. C'est un logiciel libre avec
un type spcifique de licence, nomme licence Apache" [Site 45].
On a choisi ce serveur car il supporte trs bien PHP et on le connaissait dj
assez bien.
PHP 5.2.4
"est un langage de scripts libre principalement utilis pour tre excut par un
serveur HTTP, mais il peut fonctionner comme n'importe quel langage
interprt de faon locale, en excutant les programmes en ligne de
commande. PHP est un langage procdural disposant en version 5 de
fonctionnalits de modle objet compltes" [Site 46].
On a choisi PHP5 comme langage de programmation car on le connaissait trs
bien et il est un des langages les plus utiliss pour le web. Malheureusement au
cours du dveloppement des interfaces on c'est rendu compte que le support
SOAP n'est pas encore mre et cela a caus beaucoup de problmes.
MySQL 5.0
"est un gestionnaire de base de donnes libre. Il est trs utilis dans les projets
libres et dans le milieu industriel" [Site 47].
On a choisi MySQL car c'est le gestionnaire des bases de donnes le plus
utilis avec PHP et Apache.

III

Travail pratique

66

4.3.3. ImmoOne
Pour pouvoir vrifier le modle, il fallait tout d'abord dvelopper le site web
d'une rgie. ImmoOne est implmente en PHP et pour en dfinir la structure
de la base de donnes on c'est rfr la structure des applications Quorum
[Annexe B] et la structure des documents XML utiliss par homegate.ch
[Annexe C]
La Figure III-6 montre la structure de la base de donnes et la Figure III-7 est
un screenshot reprsentant un objet immobilier l'intrieur de ImmoOne.

Figure III-6: Structure base de donnes de ImmOne

III

Travail pratique

67

Figure III-7: Visualisation d'un objet immobilier dans ImmoOne

Comme on peut le voir, les informations reprsentant un objet sont nombreux et


c'est pour cela que dans la description de l'interface on c'est limit 8
seulement ( savoir type, type de contrat, adresse, titre, pices, prix, n de
rfrence et url).
Le service web
Pour implmenter les services web (dans ce cas le serveur) on a utilis la
classe open source NuSOAP [Site 48]. Cette classe permet d'implmenter trs
facilement des services web, mais elle est aussi beaucoup limite et trs peu
documente!
La Figure III-8 montre la structure des scripts qui forment le service web.

III

Travail pratique

68

Figure III-8: Structure du service web dans ImmoOne

Server.php est le point d'entre du service web: c'est en effet ce script qui cre
une instance de la classe soap_server (dfinie en nusoap.php).
Le code III-1 montre la fonction PHP qui gnre le rsultats et le code III-2
montre la dclaration des paramtres (et des types) de cette fonction. De plus,
toujours dans le code III-2, on rend la fonction accessible via service web.

code III-1: Fonction GetListing en PHP

code III-2: Enregistrement de la fonction GetListing avec paramtres et types

III

Travail pratique

69

Pour finir avec immoOne il faut rappeler que la classe NuSOAP gnre
automatiquement le fichier WSDL qui dcrit le service. Pour y accder il suffit
de demander le document en utilisant la variable globale $_GET de PHP. On
verra comment le faire dans l'tude de l'intgrateur.
4.3.4. ImmIntegrator
Aprs avoir termin le service web, il fallait implmenter l'intgrateur. La Figure
III-9 en montre la structure des scripts.

Figure III-9: Structure des scripts du ImmIntegrator

La classe ClientClass.php est le script le plus important, car c'est lui qui
s'occupe de crer les clients pour les diffrents services web connus. On
l'tudiera plus en dtail aprs.
La Figure III-10 est l'interface de recherche de cet outil, et dans cette image on
voit aussi une liste de rsultats (noter que mme si ces informations
proviennent de plusieurs sites web on ne voit aucune diffrence).

Figure III-10: Interface de ImmIntegrator

III

Travail pratique

70

Les Clients
Plus haut dans ce chapitre on a dit que la classe ClientClass.php est le script le
plus important. l'aide du code III-3 on explique pourquoi.

code III-3: Cration des clients

Ce morceau de code se trouve dans le script index.php. Ce script cre une


instance de ClientClass.php en lui passant comme argument l'adresse du
fichier WSDL qui dcrit le service. On a dit avant que NuSOAP gnre un
fichier WSDL automatiquement pour le faire il suffit donc d'ajouter ?wsdl
l'adresse du service.
Chaque instance de ClientClass contient un objet soap_client (dfini dans
nusoap.php) et en utilisant les mthodes offertes par ClientClass on peut
accder aux fonctionnalits dont on a besoin.
Donc quand on appelle $immone_client->doCall('GetListing', $params) ce qu'on
est en trane de faire est d'appeler la fonction du serveur GetListing en lui
passant les paramtres de recherche introduits par l'utilisateur.
Une des fonctionnalits utiles de NuSOAP est le parseur XML. Grce cet outil
les rponses SOAP sont automatiquement transformes en un array PHP
standard. De cette faon il est donc simple imprimer le rsultats. Le code III-4
montre l'impression des rsultats dans une table.

III

Travail pratique

71

code III-4: Impression des rsultats dans une table

4.3.5. Dmonstration
Jusque l le modle fonctionne avec les deux applications PHP, mais est-ce
que les services web peuvent tres utiliss par une application qui n'est pas
crite en PHP?
Pour rpondre cette question on utilise l'outil SoapUI [Site 49]. Cet outil est
capable de lire un fichier WSDL, de gnrer une requte et de lire une rponse.
La Figure III-11 montre une requte SOAP gnre l'aide de SoapUI. Cette
requte a t gnre automatiquement par SoapUI en lisant le fichier WSDL.

Figure III-11: Requte SOAP gnre par SoapUI

LaFigure III-12 , par contre, montre la rponse envoye par le service web.

III

Travail pratique

72

Figure III-12: Rponse SOAP reu par SoapUI

Vue que SoapUI a t capable de communiquer avec le service web on a


dmontr que le modle peut fonctionner indpendamment des langages de
programmation utiliss.
Le prochaine chapitre est ddi aux conclusions tires de ce travail pratique.
On valuera le choix des outils et les rsultats obtenus. De plus on proposera
des possibles amliorations du modle et des applications.

III

Travail pratique

73

Conclusion travail pratique

Les outils
Le choix des outils est un point trs important dans l'analyse d'un projet.
cause de l'inexprience dans le domaine des services web, on a choisi un
langage de programmation avec un support insuffisant du standard SOAP. On
a rsolu ce problme en utilisant la classe NuSOAP, mais on a quand mme eu
des problmes avec la gestion des erreurs. De plus la gnration automatique
du fichier WSDL, bien que trs utile, prsente des problmes de compatibilit
avec d'autres outils (par exemple Visual Studio).
Ceci dit, les autres outils ont t extrmement faciles utiliser et ils se sont
dmontrs le bon choix.
Le rsultat
Pour ce que concerne le rsultat, on est vraiment satisfait des applications
construites.
Le site web de la rgie est assez stable, et mme si cette application tait
seulement une base permettant la construction du service web, on a ddi
beaucoup de temps son analyse et implmentation.
L'intgrateur couvre aussi les rsultats esprs: l'application est trs dynamique
et il est trs simple d'ajouter des nouveaux clients. Les rsultats sont obtenus
trs rapidement (bien que cette proprit dpend su service web) et le seule
problme est la gestion des erreurs SOAP.
Avec ces applications, on a dmontr que le modle propos est valable; donc
les buts de ce projet ont tait accomplis!
Amliorations futures
Evidemment le modle implment n'est qu'un prototype. Il faut encore
travailler sur la dfinition de l'interface (par exemple en utilisant le style
"document/literal" pour respecter les directives du WS-I) et sur la gestion des
erreurs.

III

Travail pratique

74

Du cot de l'intgrateur on pourrait faciliter encore plus la gestion des clients en


prvoyant une base de donnes permettant d'ajouter et effacer les rgies de
faon compltement dynamique (en vitant de toucher le code).
un niveau encore plus lev on peut aussi dfinir un registre UDDI permettant
de publier et chercher les rgies qui implmentent l'interface et on pourrait
aussi ajouter une couche scuritaire.
Conclusion
En conclusion, ce travail peut tre le point de dpart dans la ralisation d'une
bonne alternative aux modles existants. Il est quand mme claire qu'il y a
encore beaucoup de travail faire pour que un tel modle soit rellement
utilisable.

IV

Rfrences

75

IV. Rfrences

IV

Rfrences

76

Pages Web
[Site 1]

The Greentree Gazette; the web service revolution


http://www.infometh.com/0301WebServices.pdf
Dernier accs le 15.09.2007

[Site 2]

Informit; Whats Next for Web Services: GXA and Beyond


http://www.informit.com/articles/article.aspx?p=25871&rl=1
Dernier accs le 15.09.2007

[Site 3]

The TechWeb Network; Web Services Adoption Spreads Globally


http://www.informit.com/articles/article.aspx?p=25871&rl=1
Dernier accs le 15.09.2007

[Site 4]

W3C World Wide Web Consortium; Web Services Glossary


http://www.w3.org/TR/2002/WD-ws-gloss-20021114/#webservice
Dernier accs le 15.09.2007

[Site 5]

Whatis.com; GML definition


http://whatis.techtarget.com/definition/0,289893,sid9_gci213985,00.h
tml
Dernier accs le 15.09.2007

[Site 6]

Wikipedia; SGML definition


http://en.wikipedia.org/wiki/Sgml
Dernier accs le 15.09.2007

[Site 7]

W3C World Wide Web Consortium; Happy Birthday, XML!


http://www.w3.org/2003/02/xml-at-5.html
Dernier accs le 15.09.2007

[Site 8]

Webservices.org; The Past, Present and Future of Web Services,


part 1
http://www.webservices.org/categories/enterprise/strategy_architect
ure/the_past_present_and_future_of_web_services_part_1/(go)/Arti
cles
Dernier accs le 15.09.2007

IV

Rfrences

[site 9]

77

CBDI; The web service protocol stack"


http://roadmap.cbdiforum.com/reports/protocols/
Dernier accs le 15.09.2007

[Site 10]

W3C World Wide Web Consortium; Web Services Architecture"


http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/
Dernier accs le 15.09.2007

[Site 11]

Xmlfr.org; Dfinition XML


http://xmlfr.org/index/object.title/xml/
Dernier accs le 15.09.2007

[Site 12]

W3C World Wide Web Consortium; SOAP Version 1.2 Partie 1:


Structure pour l'change de messages
http://www.w3.org/2002/07/SOAP-TRANSLATION/SOAP12part1.html
Dernier accs le 15.09.2007

[Site 13]

W3C World Wide Web Consortium; Simple Object Access Protocol


(SOAP) 1.1 note
http://www.w3.org/TR/2000/NOTE-SOAP-20000508
Dernier accs le 15.09.2007

[Site 14]

Oracle; How to create a Document Style Web Service


http://www.oracle.com/technology/sample_code/tech/java/codesnipp
et/webservices/docservice/index.html
Dernier accs le 15.09.2007

[Site 15]

W3C World Wide Web Consortium; SOAP Version 1.2 Part 2:


Adjuncts (Second Edition)
http://www.w3.org/TR/2007/REC-soap12-part220070427/#soapinhttp
Dernier accs le 15.09.2007

[Site 16]

Alaide.com; Dfiniton WSDL


http://www.alaide.com/dico.php?q=WSDL&ix=1828
Dernier accs le 15.09.2007

IV

Rfrences

[Site 17]

78

W3schools; Introduction to WSDL


http://www.w3schools.com/wsdl/wsdl_intro.asp
Dernier accs le 15.09.2007

[Site 18]

W3C World Wide Web Consortium; Web Services Description


Language (WSDL) Version 2.0 Part 1: Core Language
http://www.w3.org/TR/wsdl20/
Dernier accs le 15.09.2007

[Site 19]

W3schools; WSDL Documents


http://www.w3schools.com/wsdl/wsdl_documents.asp
Dernier accs le 15.09.2007

[Site 20]

Global Learning Consortium, Inc; IMS General Web Services WSDL


Binding Guidelines
http://www.imsglobal.org/gws/gwsv1p0/imsgws_wsdlBindv1p0.html
Dernier accs le 15.09.2007

[Site 21]

PC Global Services; Dfinitions: UDDI


http://www.ecranbureau.com/dictionnaire/U/UDDI.html
Dernier accs le 15.09.2007

[Site 22]

OASIS; OASIS UDDI Specification TC


http://www.oasis-open.org/committees/uddi-spec/faq.php#status
Dernier accs le 15.09.2007

[Site 23]

OASIS UDDI; The evolution of UDDI


http://www.uddi.org/pubs/the_evolution_of_uddi_20020719.pdf
Dernier accs le 15.09.2007

[Site 24]

Wikipedia; Resource Description Framework


http://fr.wikipedia.org/wiki/Resource_Description_Framework
Dernier accs le 15.09.2007

[Site 25]

Wikipedia; Security assertion markup language


http://fr.wikipedia.org/wiki/Security_assertion_markup_language
Dernier accs le 15.09.2007

IV

Rfrences

[Site 26]

79

Journaldunet.com; PHP5: SimpleXML


http://www.journaldunet.com/developpeur/tutoriel/php/040921-phpseguy-simplexml-1a.shtml
Dernier accs le 15.09.2007

[Site 27]

Wikipedia; Confidentialit
http://fr.wikipedia.org/wiki/Confidentialit%C3%A9
Dernier accs le 15.09.2007

[Site 28]

Wikipedia; Intgrit
http://fr.wikipedia.org/wiki/Int%C3%A9grit%C3%A9_%28cryptograph
ie%29
Dernier accs le 15.09.2007

[Site 29]

Wikipedia; Cl de chiffrement
http://fr.wikipedia.org/wiki/Cl%C3%A9_de_chiffrement
Dernier accs le 15.09.2007

[Site 30]

Wikipedia; Cryptographie
http://fr.wikipedia.org/wiki/Cryptographie
Dernier accs le 15.09.2007

[Site 31]

IBM; Glossary: Security Tokens


http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/
com.ibm.db2.ii.of.doc/common/iiysgloss.htm
Dernier accs le 15.09.2007

[Site 32]

Wikipedia; Segnature numrique


http://fr.wikipedia.org/wiki/Signature_num%C3%A9rique
Dernier accs le 15.09.2007

[Site 33]

Wikipedia; WS-Security
http://fr.wikipedia.org/wiki/WS-Security
Dernier accs le 15.09.2007

IV

Rfrences

[Site 34]

80

OASIS; Web Services Security: SOAP Message Security 1.1 (WSSecurity 2004)
http://www.oasis-open.org/committees/download.php/21257/wssv1.1-spec-errata-os-SOAPMessageSecurity.htm
Dernier accs le 15.09.2007

[Site 35]

OASIS; Web Services Security: SOAP Message Security 1.1 (WSSecurity 2004)
http://www.oasis-open.org/committees/download.php/16790/wssv1.1-spec-os-SOAPMessageSecurity.pdf
Dernier accs le 15.09.2007

[Site 36]

OASIS; Username Token Profile


http://www.oasis-open.org/committees/download.php/16782/wssv1.1-spec-os-UsernameTokenProfile.pdf
Dernier accs le 15.09.2007

[Site 37]

Wikipedia; Replay Attack


http://it.wikipedia.org/wiki/Replay_attack
Dernier accs le 15.09.2007

[Site 38]

Immoscout24.ch; le point de rencontre de loffre et de la demande


http://www.immoscout24.ch/IS24Web/Public/Content.aspx?key=impr
int&nav=5&subnav=9&lng=fr&wl=1
Dernier accs le 15.09.2007

[Site 39]

Homegate.ch; Notre entreprise


http://www.homegate.ch/homegate/article?articleId=UEcomp_fr_CH.xml&l=default&a=default
Dernier accs le 15.09.2007

IV

Rfrences

[Site 40]

81

Homegate.ch; Facts et Figures


http://www.homegate.ch/homegate/article?articleId=UEfig_fr_CH.xml&l=default&a=default
Dernier accs le 15.09.2007

[Site 41]

Wikipedia; Multiple Listing Service


http://en.wikipedia.org/wiki/Multiple_Listing_Service
Dernier accs le 15.09.2007

[Site 42]

Wikipedia; Alternatives and changes to the MLS system


http://en.wikipedia.org/wiki/Multiple_Listing_Service#Alternatives_an
d_changes_to_the_MLS_system
Dernier accs le 15.09.2007

[Site 43]

Wikipedia; Real Estate Transaction Standard


http://en.wikipedia.org/wiki/Real_Estate_Transaction_Specification
Dernier accs le 15.09.2007

[Site 44]

Javazone 2005; Contract-Aware Web Service Development


http://www4.java.no/web/show.do?page=92&articleid=5266
Dernier accs le 15.09.2007

[Site 45]

Wikipedia; Apache HTTP Server


http://fr.wikipedia.org/wiki/Apache_(logiciel)
Dernier accs le 15.09.2007

[Site 46]

Wikipedia; PHP: Hypertext Preprocessor


http://fr.wikipedia.org/wiki/Php
Dernier accs le 15.09.2007

[Site 47]

Wikipedia; MySQL
http://fr.wikipedia.org/wiki/Mysql
Dernier accs le 15.09.2007

IV

Rfrences

[Site 48]

Dietrich Ayala Homepage; NuSOAP Homepage


http://dietrich.ganx4.com/nusoap/
Dernier accs le 15.09.2007

[Site 49]

Eviware; soapUI
http://www.soapui.org/
Dernier accs le 15.09.2007

82

IV

Rfrences

83

Livres
[Snell 2001]

Snell, Tidwell, Kulchenko: Programming Web Services with


SOAP, 1st Edition.
O'REILLY 2001.

[St. Laurent 2001] St. Laurent, Johnston, Dumbill: Programming Web Services
with XML-RPC, 1st Edition.
O'REILLY 2001.
[Harold 2004]

Harold, Means: XML in a Nutshell, Third Edition.


O'REILLY 2004.

[Iverson 2004]

Iverson: Real World Web Services, 1st Edition.


O'REILLY 2001.

[Myer 2005]

Myer: No Nonsense XML Web Development with PHP, 1st


Edition.
O'REILLY 2005.

[Harold 2004]

Harold: XML 1.1 Bible, 3rd edition.


Wiley Publishing Inc. 2004.

Annexes

84

V. Annexes

Annexes

85

Annexe A: Interview Quorum Software

Question: Est-ce que Quorum software pour les rgies immobilires offre un
module pour traiter les recherches d'objets immobilires on-line (par exemple
un site on-line li la base de donnes utilis par le programme)?
Rponse: Oui il le permet et certains client en disposent. Toutefois les clients
prfrent passer par des portails largement connus.
Question: Quorum software est-il li aux grands portails de recherche comme
Homegate.ch?
Rponse: Oui
Question: Comment ce passe-t-il l'change d'informations entre les deux
systmes?
Les donnes sont copis dans la base de donnes du portail. Non il y a
une copie FTP des donnes vers le portail dans un compte propre a
chaque client. Le portail lit tous les fichiers plusieurs fois par jour pour
actualiser son site.
Les donnes sont envoys chaque recherche dans le portail (donc il y
a un accs de lecture dans la base de donnes prive de la rgie) Non
les rgies ne le voudrait pas. Plusieurs rgies sont totalement fermes.
Les donnes sont envoys de faon diffrente (xml, webservices, )
chaque requte. Non mais ce serais intressante.

Annexes

86

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 cble
Climatisation
Compteur SI 01
Date dbut LDTR
Date dbut objet
Date dbut situation
Date fin LDTR
Date fin objet
Dispose d'un balcon
Dsignation immeuble principal
Dispose d'un jardin
Dsignation de l'objet (TBSD)
Dpendance 01
Dpendance 02
Dpendance 03
Dpendance 04
Dispose d'une terrasse
Dispose d'une chemine
Entretien des appareils mnagers la
charge du locataire
Entretien du brleur la charge du
locataire
Entretien dtartrage par le locataire
Montant de l'estimation fiscale
Etages (TBSD)
Etat gnral de l'objet (TBSD)
Genre de l'objet (TBSD)
Loyer cible
Rsidentiel
Logement meubl
Loyer fiscal
Loyer LDTR
Monte-charge
Nombre de pices canton
Nombre de pices fdrales
Nombre de pices thoriques
Nombre de points
Nombreux rangements
Numro dpendance 1
Numro dpendance 2
Numro dpendance 3

Type,Format
LOGI - yes/no
LOGI - yes/no
LOGI - yes/no
DECI - ->>>,>>9.99
LOGI - yes/no
LOGI - yes/no
CHAR - x(20)
DATE - 99.99.9999
DATE - 99.99.9999
DATE - 99.99.9999
DATE - 99.99.9999
DATE - 99.99.9999
LOGI - yes/no
CHAR - x(40)
LOGI - yes/no
CHAR - x(4)
CHAR - x(4)
CHAR - x(4)
CHAR - x(4)
CHAR - x(4)
LOGI - yes/no
LOGI - yes/no
LOGI - yes/no
LOGI - yes/no
LOGI - yes/no
DECI - ->>,>>>,>>9.99
INTE - 999
CHAR - X(2)
CHAR - x(4)
DECI - ->>>,>>9.99
LOGI - yes/no
LOGI - yes/no
DECI - ->>>,>>9.99
DECI - ->>>,>>9.99
LOGI - yes/no
DECI - >9.9
DECI - >9.9
DECI - >9.9
DECI - >,>>9.99
LOGI - yes/no
CHAR - x(8)
CHAR - x(8)
CHAR - x(8)

Annexes
Numro dpendance 4
Numro lot PPE (I)
Numro PTT objet
Numro WEG (I)
Numro objet
Objet calme
Objet divisible
Objet fictif
Traversant
Pas dans les listes louer
Catgories PO
Adapt pour un animal
Publicit par fax
Publicit journaux
Publicit Internet
Publicit rgie
Code de l'agence
Rfrence de l'immeuble
Rfrence de l'objet
Code regroupement (
Rservation objet (TBSD)
Revtement sol chambres (TBSD)
Rfrence de la socit
Rserv OFL 20 %
Revtement sol sjour (TBSD)
Subvention cantonale
Subvention fdrale
Surface balcon
Surface objet en m2
Surface PPE
Surface terrasse
Texte compteur SI Numro 1
Texte 1 publicit
Texte 2 publicit
Texte 3 publicit
Tlrseau obligatoire
Texte recherche (I)
Taux d'abattement
Type de cuisine (TBSD)
Type de loyer (TBSD)
Type de tlrseau (TBSD)
Usage de l'objet (TBSD)
Volume objet
WC spar
Surface totale location
Surface totale pondre location

87
CHAR - x(8)
CHAR - x(10)
CHAR - x(6)
CHAR - X(8)
CHAR - x(12)
LOGI - yes/no
LOGI - yes/no
LOGI - yes/no
LOGI - yes/no
LOGI - yes/no
CHAR - X
LOGI - yes/no
LOGI - yes/no
LOGI - yes/no
LOGI - yes/no
LOGI - yes/no
CHAR - x(2)
INTE - >>9999
INTE - 999999
CHAR - x(2)
CHAR - x(2)
CHAR - X(2)
INTE - >>9999
LOGI - yes/no
CHAR - X(2)
LOGI - yes/no
LOGI - yes/no
DECI - >>>,>>9.99
DECI - >>>,>>9.99
DECI - >>>,>>9.99
DECI - >>>,>>9.99
CHAR - x(8)
CHAR - X(78)
CHAR - X(78)
CHAR - X(78)
LOGI - yes/no
CHAR - X(20)
DECI - >>9.99
CHAR - X(2)
CHAR - x(1)
CHAR - X(2)
CHAR - x(4)
DECI - >>>,>>9.99
LOGI - yes/no
DECI - >>,>>9.99
DECI - >>,>>9.99

Annexes

88

Zones complmentaires de l'objet durant la location


Description
Action relocation
Montant des charges proposes
Collaborateur responsable travaux
Date de dbut travaux
Date dbut vacant (I)
Date de dbut de la publicit
Date entre souhaite
Date de fin travaux
Date disponible (IP 1)
Dossier termin
Heure de visite
Rfrence de l'immeuble li (I)
Loyer minimum
Loyer objet li
Loyer propos
Montant de travaux
Nombre de demandes
Nombre de publicits
Nouveau dans portefeuille
Rfrence de l'objet li (I)
Portefeuille proposer
Probabilit de ralisation
Rfrence de l'immeuble
Rfrence de l'objet
Rfrence prospect location
Rponse de la rsiliation au propritaire
Code rservation (TBSD)
Rsiliation signale au propritaire
Rfrence de la socit
Statut de l'objet vacant (TBSD)
Statut objets vacants (TBSD)
Subvention cantonale
Subvention fdrale
Travaux faire
Travaux objets vacants (TBSD)
Travaux termins
Type de recherche (TBSD) (I)
Visite prliminaire effectu
Visite collaborateur
Visite de l'objet (TBSD)
Visite email
Visite natel
Visite service
Visite tlphone

Type,Format
CHAR - X(20)
DECI - ->>>,>>9.99
CHAR - X(4)
DATE - 99.99.9999
DATE - 99.99.9999
DATE - 99.99.9999
DATE - 99.99.9999
DATE - 99.99.9999
DATE - 99.99.9999
LOGI - yes/no
CHAR - x(15)
INTE - >>9999
DECI - ->>>,>>9.99
DECI - ->>>,>>9.99
DECI - ->>>,>>9.99
DECI - ->>>,>>9.99
INTE - ->>>9
INTE - >,>>9
LOGI - yes/no
INTE - 999999
LOGI - yes/no
DECI - >>9.99
INTE - >>9999
INTE - 999999
INTE - ->>>>>>>>>9
DATE - 99.99.9999
CHAR - x(2)
DATE - 99.99.9999
INTE - >>9999
CHAR - x(1)
CHAR - X(2)
LOGI - yes/no
LOGI - yes/no
CHAR - X(78)
CHAR - x(2)
LOGI - yes/no
CHAR - x(1)
LOGI - yes/no
CHAR - X(40)
CHAR - x(2)
CHAR - X(40)
CHAR - X(15)
CHAR - X(40)
CHAR - X(15)

Annexes

89

Annexe C: Structure des objets dans Homegate.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, Nr
Postleitzahl
Ort
Kanton
Land
bitte leer lassen
Situationsbeschrieb
Verfgbar ab
Titel
Beschreibungstext
Verkaufspreis / Bruttomiete
Netto Miete
Nebenkosten
Preiseinheit
Whrung
Bruttorendite
Etage
Anzahl Zimmer
Anzahl Wohnungen
Wohnflche
Grundstckflche
Nutzflche
Kubatur
Baujahr
Aussicht
Chemine
Kabelfernsehen
Lift
Kinderfreundlich
Parkplatz
Garage
Balkon/Sitzplatz
bitte leer lassen
Distanz ffentlicher Verkehr
Distanz Einkauf
Distanz Kindergarten
Distanz Primarschule

Annexes

90

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

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)

url

str(200)

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

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)

visit_name

str(200)

visit_phone
visit_email
visit_remark
publish_until
destination
pic6
pic7
pic8
pic9

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, Nr
Postleitzahl
Ort
Land
Telefonnummer
Mobilenummer
Faxnummer
E-Mail Adresse
bitte leer lassen
Name der Person fr die
Besichtigungstermine
Telefonnummer (fr
Besichtigungsanfragen)
bitte leer lassen
Kommentar zur Besichtigung
bitte leer lassen
bitte leer lassen
Bild6
Bild7
Bild8
Bild9

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

91
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,1)
int(10,1)
int(10,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
Raumhhe
Hallenhhe
Max. Bodenbelastung
max. Gewicht Kran
max. Gewicht Warenlift
ISDN Anschluss
Rollstuhlgngig
Haustiere erlaubt
Anfahrrampe
Hebebhne
Bahnanschluss
Toiletten
Wasseranschluss
Abwasseranschluss
Stromanschluss
Gasanschluss
bitte leer lassen

Annexes

92

Annexe D: Code source de immone/ws/server.php

<?
require('lib/nusoap.php');
require('ReAddress.php');
require('ReObject.php');
require('ReListing.php');
//THIS IS THE WEB SERVICE ONLY FUNCTION!
//Returns an array full of objects respecting the given criteria
function GetListing($ObjectType, $ContractType, $MinPrice, $MaxPrice, $Zip, $MinRooms)
{
//create listing
$listing = new ReListing($ObjectType, $ContractType, $MinPrice, $MaxPrice, $Zip,
$MinRooms);
//do Search
try
{
$listing->doSearch();
//generate listing array
$arr_listing = $listing->getObjectArray();
//returning value
return $arr_listing;

}
catch(exception $e)
{
//NUSOAP SOAP FAULT HANDLING DOES NOT WORK PROPERLY (VERY
POOR DOCUMENTATION TOO!)
$myError = "error";
return array();
}
}
$request = isSet($HTTP_RAW_POST_DATA) ? $HTTP_RAW_POST_DATA : '';
$server = new soap_server();
$server->configureWSDL('immone_ws_wsdl', 'urn:immone_ws_wsdl');
//add ReAddress type to wsdl
$server->wsdl->addComplexType('ReAddress',
'complexType',
'struct',
'all',
'',
array(
'street'=>array('name'=>'street','type'=>'xsd:string'),
'zip'=>array('name'=>'zip', 'type'=>'xsd:int'),
'city'=>array('name'=>'city', 'type'=>'xsd:string'),
'area'=>array('name'=>'area', 'type'=>'xsd:string'),
'country'=>array('name'=>'country', 'type'=>'xsd:string')
)
);
//add ReObject type to wsdl
$server->wsdl->addComplexType('ReObject',

);

Annexes

93

'complexType',
'struct',
'all',
'',
array(
'object_type'=>array('name'=>'object_type','type'=>'xsd:string'),
'title'=>array('name'=>'title', 'type'=>'xsd:string'),
'rooms'=>array('name'=>'rooms', 'type'=>'xsd:float'),
'contract_type'=>array('name'=>'contract_type', 'type'=>'xsd:string'),
'price'=>array('name'=>'price', 'type'=>'xsd:float'),
'reference'=>array('name'=>'reference', 'type'=>'xsd:string'),
'url'=>array('name'=>'url', 'type'=>'xsd:string'),
'address'=>array('name'=>'address', 'type'=>'tns:ReAddress')
)

//add ReListing type to wsdl


$server->wsdl->addComplexType('ReListing',
'complexType',
'array',
'',
'SOAP-ENC:Array',
array(),
array(
array('ref'=>'SOAP-ENC:arrayType','wsdl:arrayType'=>'tns:ReObject[]')
),
'tns:ReObject'
);
//GetListing function input parameters array
$GetListingParamIn = array('ObjectType' => 'xsd:string',
'ContractType' => 'xsd:string',
'MinPrice' => 'xsd:double',
'MaxPrice' => 'xsd:double',
'Zip' => 'xsd:int',
'MinRooms' => 'xsd:float');
//GetListing function output parameters array
$GetListingParamOut = array('return' => 'tns:ReListing');
//register the GetListing function
$server->register('GetListing',

$GetListingParamIn,
$GetListingParamOut,
'immone_ws_wsdl',
'immone_ws_wsdl#GetListing',
'rpc',
'encoded',
'Returns the the listing');

if(isset($error))
{
$fault = $server->fault('soap:Server','My description about why this error was thrown');
}
$server->service($request);
?>

Annexes

Annexe E: Code Source de immIntegrator/index.php

<?
include('ws_clients/ClientClass.php');
include('header.php');
?>
<div id="formDiv">
<form name="immIntegrForm" action="<? $_SERVER['phpself'] ?>" method="GET">
<table class="infoTable formTable">
<tr>
<td colspan="7"><center><b>Search Form</b></center></td>
</tr>
<tr>
<td colspan="7"><hr></td>
</tr>
<tr>
<td><b>Object Type</b></td>
<td><b>Contract</b></td>
<td><b>Min Price</b></td>
<td><b>Max Price</b></td>
<td><b>Zip</b></td>
<td><b>Min Rooms</b></td>
<td><b>&nbsp;</b></td>
</tr>
<tr>
<td>
<select name="object_type">
<option value="apartment" selected>Apartment</option>
<option value="house">House</option>
</select>
</td>
<td>
<select name="contract_type">
<option value="rent" selected>Rent</option>
<option value="sell">Sell</option>
</select>
</td>
<td><input type="text" name="min_price" value="" size="6"></td>
<td><input type="text" name="max_price" value="" size="6"></td>
<td><input type="text" name="zip" value="" size="6"></td>
<td><input type="text" name="min_rooms" value="" size="6"></td>
<td><input type="submit" value="submit" name="submit"></td>
</tr>
</table>
</div>
</form>
<?
if(isset($_GET['submit']))
{
//Notify Query Parameters
echo "<hr class=\"hr1\">";
echo "<p align=\"center\">Results for query: ";
echo "<b>Object Type:</b> ".$_GET['object_type']." - ";
echo "<b>Contract Type:</b> ".$_GET['contract_type']." - ";
echo "<b>Min Price:</b> ".$_GET['min_price']." - ";
echo "<b>Max Price:</b> ".$_GET['max_price']." - ";

94

Annexes
echo "<b>Zip:</b> ".$_GET['zip']." - ";
echo "<b>Min Rooms:</b> ".$_GET['min_rooms']."</p>";
echo "<hr class=\"hr1\">";
//Analyse $_GET variables
$minPrice = 0;
$maxPrice = 0;
$zip = 0;
$minRooms = 0;

if($_GET['min_price'] != '' && !is_null($_GET['min_price'])) $minPrice =


(int)$_GET['min_price'];
if($_GET['max_price'] != '' && !is_null($_GET['max_price'])) $maxPrice =
(int)$_GET['max_price'];
if($_GET['zip'] != '' && !is_null($_GET['zip'])) (int)$zip = $_GET['zip'];
if($_GET['min_rooms'] != '' && !is_null($_GET['min_rooms'])) $minRooms =
(float)$_GET['min_rooms'];
//set parameters for GetListing function
$param = array('ObjectType' => $_GET['object_type'],
'ContractType' => $_GET['contract_type'],
'MinPrice' => $minPrice,
'MaxPrice' => $maxPrice,
'Zip' => $zip,
'MinRooms' => $minRooms);
//set the objects
$immone_client = new ClientClass('http://homer2/immone/ws/server.php?wsdl');
$immone_web_client = new ClientClass('http://www.os
space.ch/immone/ws_web/server.php?wsdl');
$res = array();
$res[] = $immone_client->doCall('GetListing', $param);
$res[] = $immone_web_client->doCall('GetListing', $param);
$err = $immone_client->getError();
$fault = $immone_client->getFault();
if ($err) {
echo '<h2>Immone error</h2><pre>' . $err . '</pre>';
}
if($fault)
{
echo '<h2>Immone fault</h2><pre>' . $fault . '</pre>';
}
?>
<div id="centerContainer">
<table class="editorTable">
<tr class="rowStyle_0">
<td><b>Type</b></td>
<td><b>Contract</b></td>
<td><b>Address</b></td>
<td><b>Title</b></td>
<td><b>Rooms</b></td>
<td><b>Price</b></td>
<td><b>Reference</b></td>
<td><b>Link</b></td>

95

Annexes
<?

96
</tr>
$x = 1;
foreach($res as $listing)
{
if(is_array($listing))
{
foreach($listing as $obj)
{
$addr = array();
$addr = $obj['address'];
$tr_style = 'rowStyle_'.$x++ % 2;
echo "<tr class=\"$tr_style\">";
echo "<td>$obj[object_type]</td>";
echo "<td>$obj[contract_type]</td>";
echo "<td>$addr[street], $addr[zip] $addr[city]

($addr[area] - $addr[country])</td>";

echo "<td>$obj[title]</td>";
echo "<td>$obj[rooms]</td>";
echo "<td>$obj[price]</td>";
echo "<td>$obj[reference]</td>";
echo "<td><a href=\"$obj[url]\"
target=\"_blank\"><img src=\"images/go.png\"></a></td>";
echo "</tr>";
}
}
}
?>
</table>
</div>
<?
echo '<h2>Request</h2><pre>' . htmlspecialchars($immone_client->getRequest(),
ENT_QUOTES) . '</pre>';
echo '<h2>Response</h2><pre>' . htmlspecialchars($immone_client->getResponse(),
ENT_QUOTES) . '</pre>';
echo '<h2>Debug</h2><pre>' . htmlspecialchars($immone_client->getDebug(),
ENT_QUOTES) . '</pre>';
}
include('footer.php');
?>

Annexes

97

Annexe F: Code Source de ClientClass.php

<?
require('lib/nusoap.php');
Class ClientClass
{
//vars
protected $wsdl_string;
protected $client;
protected $param_object;
protected $result_array;
//Constructor
public function __construct($wsdl)
{
//set the wsdl string
$this->wsdl_string = $wsdl;

//create the real soap client


$this->client = new soapClient2($this->wsdl_string, 'wsdl');

//executes a function call and returns the returned array


public function doCall($funct_name, $param_arr)
{
return $this->client->call($funct_name, $param_arr);
}
//returns the last soap request
public function getRequest()
{
return $this->client->request;
}
//returns the last soap response
public function getResponse()
{
return $this->client->response;
}
//return the debug string
public function getDebug()
{
return $this->client->debug_str;
}
//returns the soap error if exists
public function getError()
{
return $this->client->getError();
}
//returns the soap fault if exists
public function getFault()
{
//return $this->client->fault;
if($this->client->fault)

Annexes

98
{
}
else
{

}
?>

return $this->client->fault;

return false;

Annexes

99

Annexe G: Guide d'installation

Les pages qui suivent concernent l'installation d'une plateforme de test


(Apache, PHP5 et MySQL) et des applications dveloppes dans le cadre de
ce projet (ImmoOne et ImmIntegrator).
Installer la plateforme
Pour simplifier l'installation des outils ncessaires on propose d'installer la
plateforme Wamp10. Cette plateforme installe le serveur Apache, PHP5 et
MySQL en une seule action.
Pour installer Wamp slectionnez le fichier wamp5_1.7.3.exe (contenu dans le
cd-rom) et suivez les instructions l'cran.

Pour viter des problmes, il est mieux de laisser toutes les configurations par
dfaut. Une fois l'installation accomplie on peut voir une petite icne (en bas
droite): cette icne est le point de dpart de la plateforme.

10

http://www.wampserver.com/

Annexes

100

Configurations PHP
Apres avoir install Wamp il faut encore configurer le php. Pour le faire, cliquez
sur Icne Wamp->php settings->short open tag comme montr dans l'image
suivante.

Annexes

101

Ensuite il faut aussi installer la librairie gd2.

Aprs avoir cliqu sur php_gd2 il faut re-ouvrir la liste des extensions et
contrler que la librairie a t installe (on trouve une petite flche gauche).

Annexes

Installer les applications


Pour contrler 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 Icne Wamp->www directory

102

Annexes

103

On voit que le dossier contient 3 fichiers

ce moment on doit copier les dossiers immone et immIntegrator (contenus


dans le cd-rom) dans ce dossier.

Pour contrler que les applications ont t bien installes il faut rafrachir le
browser.
Si tout c'est bien pass, on trouvera les deux projets gauche comme montr
dans l'image suivante.

Annexes

Cration de la base de donnes


Pour que les applications fonctionnent il faut maintenant crer la base de
donnes de immoOne.
Ouvrez donc phpmyadmin

104

Annexes

105

Dans la page ouverte on va donc crer une nouvelle base de donnes (appele
immone). Insrez "immone" dans le champ (comme dans l'image) et cliquez
sur "create".

Aprs avoir cre la base de donnes, il faut importer le fichier "immoneinstall.sql" contenu dans le cd-rom. Pour le faire cliquez sur "import" (en haut
droite).

Annexes

106

Dans la fentre suivante cherchez le fichier et importez-le.

Aprs avoir import le fichier phpmyadmin montre un message de confirmation

Tester les applications


Finalement tout a t install! Maintenant il faut tester les applications.
Ouvrez le browser et allez l'adresse http://localhost/immone. Une page de
login vous sera montre

Annexes

Tapez "guest" dans les deux champs (username et password)


D'aprs l'authentification on cherche un objet pour tester le correcte
fonctionnement de immoOne. gauche, dans le box "Search By Ref" tapez
"IOA1223" et cliquez sur "go".

Une fois que la recherche est finie, l'application vous montre l'objet dans la
section centrale de la page

107

Annexes

108

Bien! ImmoOne fonctionne trs bien. Maintenant on va tester l'intgrateur. Pour


le faire il faut visiter la page http://localhost/immintegrator. La page principale de
l'intgrateur vous est montre.

Il suffit maintenant de cliquer sur submit pour rechercher tous les appartements
louer (la recherche est effectue dans le site local ImmoOne et aussi dans la
copie online).

On voit donc les rsultats et les requtes/rponses SOAP.


Flicitations: vous avez install les deux applications.

Vous aimerez peut-être aussi