Rapport WebServices

Universit de Nice-Sophia Antipolis
Licence dInformatique 3me anne
Les Web Services
Rapport de TE
tudiants
Cyrielle
Lablanche
Florens
Seine
Sbastien Gastaud
Encadrant
Herv
Chang
20042005
Table des matires

1 Introduction
1.1 Historique et Origine des Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1
3
2 Principes
2.1 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
5
6
3 RPC
3.1 Dfinition . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Principe de fonctionnement . . . . . . . . . . . . . . .
3.3 Interface . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 Processus serveur . . . . . . . . . . . . . . . . . . . . .
3.4.1 Squelette calcul_server.c (cf Figure 1.2) . . . .
3.5 Processus client . . . . . . . . . . . . . . . . . . . . . .
3.5.1 Squelette calcul_client.c (cf Figure 1.3,1.4,1.5)
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . .
3.7 Annexes RPC . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
9
9
10
10
10
10
11
11
4 XML
4.1 Dfinition . . . . . . . . . . . . . . . . . . . . . . .
4.2 Le prdcesseur de XML sur le Web : HTML . . .
4.2.1 Exemple de code HTML . . . . . . . . . . .
4.2.2 De HTML XML . . . . . . . . . . . . . .
4.3 Rgles dcriture au format XML . . . . . . . . . .
4.4 Ce que XML va rendre possible . . . . . . . . . . .
4.5 Les espaces de nommage(namespaces) . . . . . .
4.6 Les langages de prsentation (style) : CSS et XSL .
4.7 XML Schema . . . . . . . . . . . . . . . . . . . . .
4.8 Les langages de lien et dadressage . . . . . . . . .
4.9 Lavenir prvisible de XML . . . . . . . . . . . . .
4.10 Annexes XML . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
16
16
16
16
17
17
18
18
19
19
20
20
20
5 SOAP
5.1 Dfinition . . . . . . . .
5.2 Avantages . . . . . . . .
5.3 Appels de procdure . .
5.4 SOAP et XML . . . . .
5.5 Lenveloppe SOAP . . .
5.6 Reprsentation XML . .
5.7 Modle de donnes . . .
5.7.1 Traduction dune
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
22
22
22
22
23
24
24
24
24
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
structure
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
i
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5.8
5.9
5.7.2 Traduction dune liste (ou tableau) . . . . . . . . . . . . . . . . . . . . . . .

Le modle RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
25
25
6 UDDI
6.1 Dfinition . . . . . . . . . . . . . . .
6.2 Donnes du registre UDDI (cf Figure
6.2.1 Pages blanches . . . . . . . .
6.2.2 Pages jaunes . . . . . . . . .
6.2.3 Pages Vertes . . . . . . . . .
6.3 Enregistrement de types de services .
6.4 UDDI et SOAP (cd Figure 4.2) . . .
6.4.1 API (Messages SOAP) . . . .
6.4.2 Interagir avec XML . . . . .
6.4.3 Implmentation . . . . . . . .
6.5 Conclusion . . . . . . . . . . . . . .
6.6 Annexes UDDI . . . . . . . . . . . .
. . .
4.1)
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
27
27
27
27
27
28
28
28
28
28
29
31
32
7 WSDL
7.1 Dfinition . . . . .
7.2 Les dfinitions . . .
7.3 Les noms despace
7.4 Exemple WSDL (cf
7.5 Annexes WSDL . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
35
35
36
36
36
36
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
Language)
. . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
39
39
39
39
40
40
40
40
40
40
41
41
41
41
. . . . . . . .
. . . . . . . .
. . . . . . . .
Figures 5.*)
. . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8 Web services et entreprises

8.1 Dfinition . . . . . . . . . . . . . . . . . .
8.2 Construction dun projet informatique . .
8.2.1 Introduction . . . . . . . . . . . .
8.2.2 Etapes . . . . . . . . . . . . . . . .
8.3 EAI . . . . . . . . . . . . . . . . . . . . .
8.3.1 Dfinition . . . . . . . . . . . . . .
8.3.2 Lintgration dapplications . . . .
8.3.3 Fonctions de lEAI . . . . . . . . .
8.4 Les processus mtiers . . . . . . . . . . . .
8.4.1 Dfinition . . . . . . . . . . . . . .
8.4.2 Dialogues . . . . . . . . . . . . . .
8.4.3 Les processus e-business . . . . . .
8.4.4 BPML (Business Process Modeling
8.5 Conclusion . . . . . . . . . . . . . . . . .
9 Scurit et fiabilit des Web Services

9.1 Quels mcanismes veut-on mettre en place pour assurer la scurit des Web Services ?
9.1.1 Authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.1.2 Autorisation daccs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.1.3 Mcanisme dencryptage et de dcryptage des donnes . . . . . . . . . . . .
9.1.4 Signature digitale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2 Scurisation des services Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.1 Scurisation de linfrastructure . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.2 Scurisation des connexions . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.3 Authentification et contrle daccs . . . . . . . . . . . . . . . . . . . . . . .
9.2.4 Scurisation de SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3 Standards XML de scurit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3.1 XML Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ii
43
43
43
43
43
43
44
44
44
45
45
45
45
9.3.2
9.3.3
9.3.4
XKMS XML Key Management Specifications . . . . . . . . . . . . . . . . .

SAML Security Assertion Markup Language . . . . . . . . . . . . . . . . .
WS-Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10 Conclusion
10.1 Apports . . . . . . . . . . .
10.2 Limites . . . . . . . . . . .
10.3 Evolution des Web Services
10.4 Enrichissement personnel .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
45
45
46
47
47
47
47
48
page iii de 48
Chapitre 1
Introduction
Selon la dfinition du W3C (World Wide Web Consortium), un Web service (ou service Web)
est une application appelable via Internet - par une autre application dun autre site Internet permettant lchange de donnes (de manire textuelle) afin que lapplication appelante puisse
intgrer le rsultat de lchange ses propres analyses. Les requtes et les rponses sont soumises
des standards et normalises chacun de leurs changes.
1.1
Historique et Origine des Concepts
Les Web services sont ns de leffort de plusieurs organisations qui ont partag un intrt commun en dveloppant et en maintenant "un march lectronique". Celles-ci souhaitaient pouvoir
communiquer plus simplement et sans avoir se concerter sur chacune de leur transaction pour
pouvoir interprter leurs diffrentes donnes. Elles souhaitaient supprimer lisolement de leur systme informatique avec les autres
Cest ainsi que naquit en 1975 lEDI (change de Donnes Informatises). LEDI peut tre
dfini comme lchange, dordinateur ordinateur, de donnes concernant des transactions en utilisant des rseaux et des formats normaliss. Il sagit dun format standard permettant lchange
dun certain type de donnes. Dun dveloppement assez semblable la cration du code Morse,
EDI permettait des personnes dune langue donne denvoyer des messages via cble des
interlocuteurs similaires situs dans un autre lieu. LEDI permet lentente entre les diffrentes
applications sur la modlisation des changes et sur les protocoles de communication. LEDI a
lavantage de ne pas avoir retaper les donnes. Elle permet donc un gain de temps et dargent,
en rduisant les erreurs de saisie. LEDI reste tout de mme incomplte. Le systme mis en place
est difficile implmenter. Les techniques employes sont complexes et coteuses.
Vers la fin des annes 80, lvidence fut que lge des systmes informatiques isols touchait
son terme tandis que diffrents ordinateurs, de tailles, de capacits et de formes varies, apparaissaient au sein dune mme organisation. Les dpartements informatiques voulurent bien
videmment exploiter au mieux et au plus bnfique la prcieuse puissance danalyse quils avaient
disposition. Il fallut donc rendre les applications informatiques capables de dplacer leurs travaux, cest--dire de procder un vritable traitement distributif.
Pour rpondre cette nouvelle situation, de nouvelles technologies apparurent telles que
CORBA (Common Object Request Broker Architecture) ou la version quen fit Microsoft, le Component Object Model (COM). CORBA, est une architecture logicielle, pour le dveloppement de
composants. Ces composants, qui sont assembls pour la construction dapplications compltes,
ont la possibilit dtre crits dans des langages de programmation diffrents, dtre excuts dans
1
des processus dissocis, voire dtre dploys sur des machines distinctes. Les composants CORBA
utilisent une approche essentiellement oriente objet (du point de vue dun langage de programmation, toutes les mthodes sont virtuelles, il ny a pas de polymorphisme paramtrique, ni mthodes
protges ou prives, ni surcharge doprateurs, ni fonctions de premire classe).
Chaque composant est dcrit sous la forme dune interface crite en langage IDL (Interface Description Language) qui est un langage permettant de dfinir linterface de composants logiciels
(IDL permet donc de faire interagir des modules dvelopps dans des langages distincts). Une
correspondance a t introduite entre le langage IDL et plusieurs langages de programmation. Des
pr-compilateurs spcifiques sont capables de gnrer automatiquement la structure de linterface
IDL dans un langage prcis. Ils produisent aussi le code qui garantie le transfert et la rponse
des appels de fonctions distantes (appeles skeleton et stub). Un module dont linterface est prsente en IDL pourra ainsi tre implment en C++, alors que les modules Java qui lutiliserait,
effectueraient des appels sur une interface Java gnre partir de la mme prsentation IDL.
Larchitecture CORBA assure lacheminement des appels entre les processus.
Les applications et les composants CORBA associent typage statique et dynamique, ainsi, chaque
composant est prsent statiquement par une interface mais les composants qui utilisent celui-ci
doivent vrifier dynamiquement que linterface est effectivement implante. Linconvnient majeur
de cette mthode est quelle ncessite une reprogrammation continuelle des architectures suivant
les organisations qui lutilisent. Ce qui implique une perte de temps, et dargent chaque changement dapplication puisque tout doit tre reprogramm pour aller dans le sens de la nouvelle
architecture.
Les annes 90 furent tmoin non seulement de la recrudescence des ordinateurs personnels,
mais aussi du dcollage phnomnale dInternet avec une demande grandissante de standards susceptibles de travailler sur nimporte quelle plateforme.
A la fin des annes 90, le-speak dHewlett Packard fit son apparition en mme temps que XML.
HP voulait ainsi concurrencer le-business dIBM qui par leur campagne de publicit retentissante
donnait la forte sensation dtre les inventeurs du systme de-services utilisant les protocoles
tablis comme lHTTP et XML pour permettre de passer outre les diffrences entre les divers
systmes coexistants dans un mme rseau. Sans le savoir, les services Web taient ns. Le-speak
passa pratiquement inaperu, seuls quelques observateurs sen souvinrent. Microsoft et IBM avait
dj pens une alternative grce EDI. Ils tentrent de coder des transactions EDI en XML
pour permettre de facilit les relations interentreprises grce au Web. EDI russit survivre grce
ses notions de scurit qui faisait normment dfaut aux services Web. Un nouveau standard
tait n : ebXML.
A peu prs la mme poque, un regroupement dorganisations recherchant une faon de structurer et dchanger des documents XML cra un protocole appel Simple Object Access Protocol
(SOAP) qui permet la transmission de messages entre applications distantes, ce qui veut dire quil
autorise un objet dune application invoquer des mthodes dobjets physiquement situs sur une
autre machine et pouvant tre cod par une autre application. Le transfert se fait le plus gnrale grce au protocole HTTP, mais peut tout aussi bien se faire par dautres protocoles, comme
SMTP. Le protocole SOAP se compose dune partie qui joue le rle denveloppe contenant des
informations sur le message lui-mme afin de permettre son transfert et son traitement, et dune
partie qui joue le rle de modle de donnes, caractrisant le format du message, cest--dire les
informations transfrer. Le SOAP a t conu partir des concepts qui avaient produit, entre
autres, des technologies comme CORBA et EDI, en lui ajoutant les composants XML et HTTP
de telle faon que les applications puissent interagir entre elles, mme travers les firewalls des
entreprises. Le SOAP a t largement accept, probablement grce ce que son nom vante : sa
simplicit. Le SOAP ne dfinit au final aucune smantique, il ne fait que livrer une programmation
dans une enveloppe protectrice, sans se proccuper de son type. On peut donc lassimiler dans ce
sens un messager discret qui - se doutant peut-tre que le contenu de son paquet est important
- mnerait quoi quil arrive bien son devoir de livraison la personne certifie pour analyser
ce quon lui apporte. On peut affirmer que cest avec SOAP que le concept de services Web est
page 2 de 48
dfinitivement apparu renforc par la cration de WSDL (Web Services Description Language) qui
donne la description au format XML des Web Services.
Aujourdhui, les services Web provoquent un intrt certain auprs des architectes et des dcideurs. Ds prsent, les Web Services sont sortis du champ des changes interentreprises pour
sadapter celui du rfrencement et de la mise disposition des ressources de lentreprise, empitant en ce sens sur les technologies de type EAI. Cette utilisation elle seule prouve la qualit du
modle et sa prennit, notamment au niveau des couches les plus basses. Par contre, la normalisation complte dune architecture distribue construite sur les Web Services nest pour linstant pas
encore tout fait tablie. Par ailleurs, ce modle nchappe pas des problmes de performance :
les donnes sont transfres en ASCII dans une encapsulation XML elle-mme intgre dans une
enveloppe SOAP puis HTTP... Le problme du choix de la bonne granularit du service, commun
toutes les architectures distribues, se prsente dans le cas des Web Services de manire plus
aigu encore. Mme si ils nont pas acquis la maturit ncessaire leur industrialisation, les Web
services se prsentent plus que jamais comme la solution approprie aux problmatiques dchange
de donnes et dintgration dapplications.
1.2
Motivations
Un Web service est un mcanisme qui tend donner plus dinteractions pour permettre deux
entits htrognes (entreprises, clients, applications, etc. ...) de dialoguer au travers du rseau
Internet. Les logiciels crits dans divers langages de programmation (C#, Visual Basic, Java, etc.
...), sur diverses plateformes (Linux, Windows, etc. ...) et avec diverses architectures peuvent employer des services Web pour changer des donnes travers des rseaux informatique. Chaque
Web service doit pouvoir tre dcouvert et invoqu dynamiquement par les applications.
Les aspects purement pratiques nont eux rien de fondamentalement novateurs. Au contraire,
larchitecture des services Web sest impose (tout comme le langage XML) grce sa simplicit,
sa lisibilit et ses fondations normalises. Lobjectif principal des services Web est de faciliter
le plus possible laccs aux applications entre entits et ainsi de simplifier les changes de donnes.
Cette interoprabilit est due lutilisation de normes ouvertes. LOSI et le W3C sont les comits de coordination responsables de larchitecture et de standardisation des services Web. Pour
amliorer linteroprabilit entre les ralisations de service Web, lorganisation WS-I a dvelopp
une srie de profils pour faire voluer les futures normes impliques. Laspect le plus important
des Web Services est quils reposent sur plusieurs standards qui permettent la structuration des
architectures. Cette collection de normes et de protocoles est appele Web Services Protocol Stack.
Elle contient entre autre XML et SOAP pour le formatage des donnes, WSDL pour la description
des services Web et UDDI pour la recherche des services Web ncessaire au bon fonctionnement
des applications.
Une des raisons principales pour lesquelles les services Web sont employs semble tre quils se
fondent sur le Internet et HTTP pour fonctionner. Pour comprendre ceci, il faut garder lesprit
que beaucoup dorganisations se sont protges en employant des firewalls qui filtrent et bloquent
beaucoup de trafic dInternet pour des raisons de scurit. Dans ce milieu, beaucoup de ports
(voire quasiment tous) sont ferms au trafic entrant et sortant, et les administrateurs des rseaux
nont pas lenvie de les ouvrir. Il en est un qui par contre est toujours ouvert, celui des navigateurs
par lequel transite le protocole HTTP. De cette faon les applications peuvent continuer interagir
entre elle et ce sans modifier la configuration de scurit des organisations.
Si lon devait rsumer les raisons de la cration des services Web, les qualificatifs tels que la
simplicit des changes, lamlioration de la communication entre les applications en seraient les
points principaux. En ajoutant cela linteroprabilit des programmes indiffremment de leur
page 3 de 48
langage et de leur plateforme, les services Web nous prouvent une nouvelle fois que leur technologie
est trs attrayante. Le vritable point fort du concept cest la normalisation des donnes au travers
de standards connus et accepts par tous.
Fonctionnement globale dun change de donnes grce aux services Web :
source : http ://www.softeam.fr/technologies_web_services.php
1. Lapplication construit sa requte et la normalise grce aux standards.

2. Le service Web traduit la requte, recherche lapplication ncessaire.
3. Les donnes sont traites.
4. Le service Web normalise la rponse de la requte et envoie le rsultat vers lapplication
appelante.
5. Les donnes rponses sont reues par lapplication. Elles peuvent directement tre interprtes.
page 4 de 48
Chapitre 2
Principes
Les motivations de simplicit et dinteroprabilit pour les services Web impliquent une structure bien huile pour un fonctionnement facilit et efficace. Les protocoles des services Web reposent donc sur des organisations et des architectures prdfinies.
2.1
Organisation
La normalisation actuelle autour des Web Services est cependant une organisation complexe
qui va bien au-del de la simple invocation dune mthode dun objet distant. Diffrents travaux
ont ainsi dmarr pour permettre dtablir une vritable infrastructure distribue, capable de satisfaire lensemble des besoins dune application distribue, aussi bien en terme de normalisation
des changes quen terme de services transverses.
Cette organisation par comits de normalisation peut tre schmatise selon le dcoupage
matriciel suivant :
Cette normalisation des services transverses se fait sur trois axes horizontaux :
Couche de transport : Dfinition de la structure des messages utiliss par les applications
pour se dcouvrir et dialoguer entre elles. Cette couche est lheure actuelle la seule rellement normalise et qui ne souffre daucune contestation. Elle sappuie sur le protocole
SOAP pour lchange des messages et sur le langage WSDL pour la dfinition du contrat
de linterface.
Couche de smantique : Normalisation des donnes participant aux changes selon des
critres mtier. Les initiatives de dfinition de la couche de smantiques des messages sont
nombreuses et nont pour le moment pas conduit une quelconque normalisation. Deux
types dorganisation sont actuellement ouverts, lune tablie selon les diffrents corps de
mtier, lautre suivant une approche plus globale autour de consortium tel que OASIS
(initiateur de ebXML) ou RosettaNet.
Couche de gestion des processus : Standardisation de la gestion des processus mtier qui
stendent sur plusieurs applications disponibles sur Internet. Lorchestration de transactions B2B (Business to Business) complexes, fonde sur une architecture normalise des
messages est aussi une tentative qui navance pas assez rapidement et sur des standards
non murs.
Cette normalisation des services transverses de fait aussi sur trois axes verticaux :
Service dannuaire : Standardisation des moyens daccs un service partir dune requte portant sur le contenu dun service ou sur un fournisseur. La premire proposition
dannuaire UDDI aurait du apporter une solution dfinitive. Le constat est quil nen est
rien et que la trame, trop globale, du projet ne suffit pas rgler cette problmatique
dchanges entre applications se connaissant. Une deuxime proposition dannuaire, WSInspection, vient concurrencer celle-ci. Moins ambitieuse puisque consistant en une simple
exposition, par agrgation, des services dune application, elle est toutefois plus adapte
cette seconde problmatique.
Service de scurit : Normalisation des moyens permettant de couvrir les problmatiques
dauthentification et de gestion des droits daccs. La gestion de la scurit est actuellement le frein le plus important la mise en place darchitectures distribues base de Web
Services. Plusieurs organisations sont ouvertes mais aucune nest rellement accepte. Il
semblerait que la norme XACML (eXtensible Access Control Markup Language) puisse
supplanter SAML (Security Assertion Markup Language) et simposer terme comme
standard de scurit.
Service de transaction : Normalisation des moyens permettant de garantir lintgrit des
transactions longues impliquant plusieurs Web Services. Le problme reste le mme que
pour la scurit. Les standards ne sont pas tout fait tablis. La lutte pour lobtention
dune norme est beaucoup plus ouverte que pour celle de la scurit, mme si BTP (Business Transaction Protocol ) semble plus soutenu actuellement.
Modlisation de la normalisation transverse que les diffrents axes :
2.2
Architecture
Pour comprendre le fonctionnement dune architecture de services Web, il faut commencer par
revoir certains principes. Si lon reprend la dfinition de Mark Colan, Web Service and XML Chief
Advocate chez IBM, les Web Services sont des "applications modulaires bases sur Internet qui
excutent des tches prcises et qui respectent un format spcifique". Ce sont donc des units
logiques applicatives qui sont accessibles grce au protocole Internet. Une dfinition conceptuelle
du terme service Web mettrait en avant les qualits dune fonctionnalit commerciale prsente
par une entit htrogne quelconque sur Internet afin de fournir un moyen duser de ce service
distance. Pour laspect oprationnel, les services Web ne sont que des applications modulaires
qui peuvent tre prsentes, publies, situes et invoques dans un rseau et ce automatiquement.
Ainsi, les applications peuvent faire appel des fonctionnalits situes sur dautres machines dans
dautres applications. Au final, on peut affirmer que le but initial dun service Web est de rendre
possible lutilisation dun composant applicatif de faon distribue.
page 6 de 48
Lapport majeur de ce modle dchange de donnes est dintroduire ces services comme des
"botes noires". En effet, les requtes-rponses dun service Web sont administres dans le contenu
de messages dont on sait la forme grce des interfaces clairement prsentes et sur lesquelles
limplmentation interne du traitement et le langage employ ne jouent pas au niveau de larchitecture. Grce cela on obtient un haut niveau de modularit et dinteroprabilit. Ce modle
de message permet donc doublier la structure, le langage ou encore la plate-forme qui va porter
le service : il suffit juste que le message suive une architecture donne pour quil puisse tre analys.
Il sagit maintenant didentifier chaque acteur de ses Web services et de comprendre comment
ils interagissent les uns avec les autres. Les trois lments les plus importants des services Web sont
les fournisseurs de service, les annuaires de services et les consommateurs de service. Le fournisseur
(ou serveur) cre le service Web et publie toutes ces caractristiques dans lannuaire de service.
Lannuaire rend disponible les interfaces daccs aux service et donnant le contrat et larchitecture employe pour permettre les interactions. Le consommateur (ou client) quant lui, accde
lannuaire pour rechercher les service Web dont il a besoin et avec lui les normalisation obtenir. Il peut ainsi envoyer ses requtes au service dsir et obtenir les rponses quil pourra analys.
Cette architecture fonctionne de la manire suivante :
1. Le client envoie une requte lannuaire de Service pour trouver le service Web dont il a
besoin.
2. Lannuaire cherche pour le client, trouve le service Web appropri et renvoie une rponse au
client en lui indiquant quel serveur dtient ce quil recherche.
3. Le client envoie une deuxime requte au serveur pour obtenir le contrat de normalisation
de ses donnes.
page 7 de 48
4. Le serveur envoie sa rponse sous la forme tablie par WSDL en langage XML.
5. Le client peut maintenant rdiger sa requte pour traiter les donnes dont il a besoin.
6. Le serveur fait les calculs ncessaires suite la requte du client, et renvoie sa rponse sous
la mme forme normalise.
page 8 de 48
Chapitre 3
RPC
3.1
Dfinition
La programmation utilise de nos jours couramment lappel de fonctions, cest pourquoi ce

mcanisme sapplique dsormais dans des applications distribues. Les appels se font ainsi sur des
machines distantes, expliquant ainsi le nom de Remote Procedure Call.
Le systme RPC est utilis pour toutes sortes dapplications client / serveur. On peut prendre en
exemple lutilisation dun ordinateur effectuant des calculs spcifiques. Celui-ci servira donc de
serveur et un autre ordinateur de client qui appellera la procdure distante pour que le serveur
effectue les calculs et que le client rcupre les rsultats.
Il existe de nombreux systmes RPC, ce qui nencourage pas la compatibilit. Un standard se
dmarque cependant, le Sun RPC dvelopp par Sun Microsystems. En effet, ses spcifications
sont dornavant dans le domaine public. Son but est de servir de base au systme NFS ( Network
File System ), trs utilis sous Linux.
3.2
Principe de fonctionnement
Le systme RPC est transparent pour le programmeur, cest--dire que la smantique habituelle
est respecte. La fonction locale trs souvent le mme nom que la fonction distante. Mais celleci appelle en ralit dautres fonctions de la librairie RPC prenant en charge les connexions,
paramtres et rsultats. Du ct serveur, cest sensiblement le mme principe exept pour lattente
des clients, le renvoi des rsultats, etc. La prise en charge des connexions rseaux se fait par
lintermdiaire de fonctions dites stub. Ainsi il faut rajouter au programme client et la fonction
distante un stub pour le client et le serveur.
La construction des stubs peut tre automatise par le programme rpcgen produisant du
code C.
3.3
Interface
On utilise lIDL (Interface Definition Language) de RPC. Il sert a la specification des interfaces
entre les clients et les serveurs.
Description dune fonction distante possedant 2 paramtres, rend la somme ainsi quun code
derreur (cf Figure 1.1).
Cette dfinition est enregistre dans le fichier calcul.x. Il contient une description : ici, le programme sappelle CALCUL, il est en version VERSION_UN et contient deux procdures CALCUL_NULL et CALCUL_ADDITION.
9
Le numro de CALCUL (ici 0x20000001) identifie le programme de manire unique dans le

monde. Cest notamment le cas pour le daemon NFS. Dans notre cas, le numro est choisi dans
lintervalle allant de 0x20000000 0x3FFFFFFF, rserv pour les utilisateurs. Il ne peut donc pas
entrer en conflit avec des programmes tournant dj sur la machine.
Chaque procdure un nom et un numro. La procdure de numro 0 (ici CALCUL_NULL)
est toujours requise. Elle sert de ping ou de procdure de test.
Le systme RPC naccepte quun seul argument en paramtre et en retour cest pourquoi on
utilise des structures.
Le programme rpcgen consomme ensuite ce fichier de dfinition :
> rpc a calcul.x
Loption -a permet de produire un squelette pour le client (calcul_client.c) et le serveur (calcul_server.c). calcul.h (entte), calcul_clnt.c (stub client), calcul_svc.c (stub serveur) et calcul_xdr.c (routines XDR) sont galement produits.
Le format XDR (eXternal Data Representation) dfinit les types utiliss pour lchange de variables entre le client et le serveur. Cela permet dadapter le programme sur diffrentes plateformes.
Ainsi, tous les types utiliss sont filtrs par XDR.
> gcc -c calcul_xdr.c
Les stubs fournis sont complets.
> gcc -c calcul_clnt.c
> gcc -c calcul_svc.c
3.4
3.4.1
Processus serveur
Squelette calcul_server.c (cf Figure 1.2)
On peut remarquer quelques diffrences. RPC travaille sur des pointeurs pour acclrer le
droulement du programme (pas de copie). On travaille sur des variables dclares static car on
doit passer ladresse dune variable existant encore aprs la fin de la fonction.
La fonction main est situe dans le stub serveur. Il soccupe de recevoir et de distribuer les
appels de fonctions.
> gcc -c calcul_server.c
> gcc -o server calcul_svc.o calcul_server.o calcul_xdr.o
3.5
3.5.1
Processus client
Squelette calcul_client.c (cf Figure 1.3,1.4,1.5)
Des variables sont dclares pour les arguments et les valeurs de retour. Chaque appel de procdure est suivi dun test qui dtecte les erreurs de niveau RPC (serveur ne rpondant pas,
machine inexistante, etc.). Lerreur ventuelle est alors explicite par la fonction clnt_perror().
Quand une erreur de niveau RPC se produit, le pointeur renvoy est NULL. Cette valeur (nonvaleur plutt !) est rserve RPC ; donc pour un niveau derreur autre que RPC, la valeur de
retour ne doit pas tre NULL.
Pour faire un vrai programme, il nous faut donner des valeurs aux paramtres et il faut utiliser
effectivement les rsultats des appels distants.
> gcc -c calcul_client.c
> gcc -o client calcul_client.o calcul_clnt.o calcul_xdr.o
> ./server&
>./client localhost
page 10 de 48
Addition avec 4294967280 et 10

Resultat : 4294967290
Addition avec 4294967295 et 10
Overflow
>
Le client prend en paramtre le nom de la machine serveur (ici localhost car le processus serveur a t dmarr sur la mme machine). Le nom peut tre court (machine) pour une machine
du mme domaine que le client ou complet (machine.domaine.com).
3.6
Conclusion
Aujourdhui des systmes plus perfectionns ont fait leur apparition comme par exemple
CORBA. Les RPC peuvent tre considrs comme les anctres de CORBA car il ne sagit plus de
fonctions mais dobjets distants servant la programmation oriente objet.
3.7
Annexes RPC
Sources : GNU/Linux & Hurd Magazine France
page 11 de 48
Fig. 3.1
page 12 de 48
Fig. 3.2
page 13 de 48
Fig. 3.3 Fonction de test de laddition
Fig. 3.4 Fonction de calcul
page 14 de 48
Fig. 3.5 Fonction principale du client
page 15 de 48
Chapitre 4
XML
4.1
Dfinition
XML (Extensible Markup Language, ou Langage Extensible de Balisage) est le langage destin
succder HTML. Comme HTML (Hypertext Markup Language) cest un langage de balisage
(markup) : il reprsente de linformation encadre par des balises. XML est un mtalangage, ce
qui veut dire que contrairement HTML qui possde un ensemble de balises de prsentation prdfinies, il va permettre dinventer de nouvelles balises disolement dinformations ou dagrgats
lmentaires que peut contenir une page Web.
XML a avec HTML un anctre commun : le SGML (Standard Generalized Markup Language).
Lune de ses caractristiques tait la sparation du formatage et du contenu. En effet, le format
dcrit indpendamment du contenu du document permettait dobtenir un rendu identique pour
une feuille de nimporte quel format. Ce principe est appliqu dans le sens o les donnes et le
schma du document sont spars, le schma reprsentant la structure et les types de donnes,
incluant la smantique ( importante pour que le document puisse interagir avec diffrents langages
de programmation et systmes ).
4.2
4.2.1
Le prdcesseur de XML sur le Web : HTML

Exemple de code HTML
red <H2>Bibliotheque</H2>
<UL>
<LI>Victor Hugo,
<I>Les miserables</I>,
1995,Dupond,Paris
</LI>
<LI>Frederic Beigbeider,
<I>Windows on the world</I>,
2004,Fayard,Paris
</LI>
</UL>
<->
Rsultat
16
Bibliotheque
Victor Hugo, Les miserables, 1995, Dupond, Paris

Frederic Beigbeider,Windows on the world, 2004, Fayard, Paris
Toutes les balises dune page HTML ne sont relatives qu sa prsentation. Rien ne permet
un logiciel de connatre le sens (la smantique) du texte autrement dit, dans notre exemple, de
savoir que Victor Hugo est lauteur dun livre intitul Les misrables, que Windows t dit en
2004 par Fayard, etc.
4.2.2
De HTML XML
red
< ?xml version=1.0 encoding=ISO-8859-1 ?>
<BIBLIO SUBJECT=XML>
<LIVRE ISBN=9742212030811 LANG=fr SUBJECT=applications>
<AUTEUR>
<PRENOM>Victor</PRENOM>
<NOM>Hugo</NOM>
</AUTEUR>
<TITRE>Les miserables</TITRE>
<EDITEUR>
<NOM>Dupond</NOM>
<LIEU>Paris</LIEU>
</EDITEUR>
<DATEPUB>1999</DATEPUB>
</LIVRE>
<LIVRE ISBN=3782242090420 LANG=fr SUBJECT=gnral>
<AUTEUR>
<PRENOM>Frederic</PRENOM>
<NOM>Beigbeider</NOM>
</AUTEUR>
<TITRE>Windows on the world</TITRE>
<EDITEUR>
<NOM>Fayard</NOM>
<LIEU>Paris</LIEU>
</EDITEUR>
<DATEPUB>2004</DATEPUB>
</LIVRE>
</BIBLIO>
Ici, aucune des balises ne dcrit la prsentation finale. On remarque, en revanche, que maintenant les balises ont un sens et une hirarchie. Par exemple, llment AUTEUR comprend le
prnom (balise PRENOM) et le nom (balise NOM) de lauteur. On remarque aussi que des informations supplmentaires (langue, sujet, n ISBN), ont pu tre ajoutes sous forme dattributs
situs lintrieur mme des balises (cf Figure 2.1).
4.3
Rgles dcriture au format XML
Les informations doivent tre :

Encadrs obligatoirement par des balises ouvrantes et fermantes. Ces lments ne doivent
pas se chevaucher. Les lments vides sont permis, selon le format<ELEMENTVIDE/>.
page 17 de 48
Soit incluses lintrieur mme des balises : on parle alors dattributs. Exemple :<LIVRE
SUJET=XML>. Ici lattribut SUJET de llment LIVRE a la valeur XML.
Soit encore dfinies sous forme dentits. Les entits sont des abrviations. Par ex ; si Extensible Markup Language est dclar comme une entit associe la notation xml ;
cette chane de caractres pourra tre abrge en &xml ; dans tout le fichier XML. Une
entit peut aussi reprsenter un fichier XML externe tout entier. Ainsi un mme fichier
XML (par exemple notre bibliographie) pourra tre utilis par plusieurs pages XML diffrentes (par exemple une page spcifiquement consacre XSL pourra prsenter la fin
la bibliographie spcifique dXSL extraite automatiquement de notre bibliographie XML)
La DTD (Dfinition de Type de Document). La structure arborescente du document XML
(intitul des balises, imbrications des balises, caractre obligatoire ou facultatif des balises
et de leur ordre de succession. . .) peut tre dclare formellement dans le corps du document XML ou dans un fichier part. Cette dclaration sappelle une Dfinition de Type de
Document (DTD). Elle seffectue selon un formalisme particulier dfini lui-aussi dans la spcification XML. En XML cette dclaration est facultative, ce qui donne une grande souplesse
aux dveloppeurs. On ncrira donc une DTD que lorsquil y aura vraiment intrt le faire
(par exemple pour contraindre la saisie/mise jour du document XML)
Lorsquun document XML possde une DTD associe et la respecte, on dit quil est valide.
Lorsquil respecte seulement les rgles de la grammaire XML (balises fermes, correctement imbriques. . .) on dit quil est bien form.
La spcification XML se trouve ladresse http ://www.w3.org/TR/REC-xml.
4.4
Ce que XML va rendre possible
XML va permettre :
aux utilisateurs :
de saisir (ou mettre jour) le contenu :
sans se soucier de la prsentation ou des traitements futurs,
sans avoir saisir des libells tels que auteur, sans avoir mettre les titres en italique.
Et den gnrer ensuite automatiquement :
de multiples prsentations (en tableau, en texte suivi. . .)
avec ventuellement tris, slections, rorganisations, gnration automatique de libells,
tables des matires, index, etc.
et ce sur de multiples mdias (cran, papier, terminal Braille, etc.)
aux logiciels de comprendre/exploiter au mieux le contenu de ces pages, rendu dsormais
explicite par un balisage spcifique, indpendant de toute application.
4.5
Les espaces de nommage(namespaces)
Cela va permettre de lever les ambiguts ventuelles concernant les balises. Le titre peut tre
affect un livre comme une personne par exemple. Ce mcanisme va nous permettre de les
diffrencier avec personne :titre et biblio :titre. Ces prfixes doivent tre associs une URL.
Elle peut tre fictive.
red <BIBLIO xmlns=http ://www.biblio.org/vocabulaire
xmlns :personne=http ://www.personel.org/profils/>
Ici, les balises non prfixes sont censes se rapporter lespace de nommage par dfaut, soit
page 18 de 48
lURL fictive http ://www.biblio.org/vocabulaire tandis que les balises prfixes par perso : se
rapportent lespace de nommage associ http ://www.personel.org/profils/.
4.6
Les langages de prsentation (style) : CSS et XSL
Le document XML va tre balis uniquement en fonction de son contenu et donc de sa smantique, tout ceci indpendamment de la restitution dont il fera lobjet sur papier, terminal, synthse
vocale, etc. ainsi que tout autre traitement automatique qui pourra lui tre appliqu.
Cela va lui confrer :
l interoprabilit
la durabilit/rutilisabilit (le document pourra tre utilis ne deviendra pas obsolte avec
lvolution des techniques informatiques ; il pourra sans difficult tre incorpor, en tout ou
partie, dans des documents de nature trs diffrente, tre trait par des applications non
prvues, voire non-existantes au dpart...).
En ce qui concerne sa restitution, lutilisation du langage de transformation normalis XSLT
(XSL Transformation) va permettre de transformer une DTD oriente contenu en une autre
DTD oriente restitution (cest--dire constitue dobjets formateurs). Lordre de restitution final y sera tabli (par exemple, classement de la bibliographie, mise en forme de certaines lignes,
generation de tables des matieres, liens (logiques) de navigation, etc.). Le niveau dindpendance
au niveau du support est conserv.
La spcification XSLT se trouve a ladresse http ://www.w3.org/TR/WD-xslt.
Le langage normalis de feuille de style XSL (Extensible Style Language) va permettre ensuite de
spcifier comment un type de document (DTD oriente restitution) donn va tre restitu sur
un support donn. Cest ce niveau que seront rgls les problmes de saut de page, les pied de
page, les liens de navigation, etc.
La spcification de XSL se trouve ladresse http ://www.w3.org/TR/WD-xsl.
Appel dun feuille de style XSL :
red < ?xml-stylesheet href=biblio.xsl type=text/xsl ?>
Le langage normalis de feuille de style CSS (Cascading Style Sheets) dj utilis avec HTML,
pourra galement tre utilis concurremment o au lieu de XSL :
red < ?xml-stylesheet href=biblio.css type=text/css ?>
4.7
XML Schema
XML Schema est un formalisme qui doit permettre de dfinir des contraintes en matire de
syntaxe, de structure et de valeurs applicables une classe de documents HTML. Il va permettre
entre autres choses deffectuer des contrles de validit lors de la saisie/mise jour de documents
XML (exactement comme pour la saisie/mise jour dune bases de donnes). Par exemple, dans
le cas de notre bibliographie, XML Schema va permettre de dclarer que llment DATEPUB
doit tre une date limite lanne, etc.
Le projet XML Schema se subdivise actuellement en deux parties :
Partie : Structures : http ://www.w3.org/TR/xmlschema-1
page 19 de 48
Types de donnes (Datatypes) : http ://www.w3.org/TR/xmlschema-2/

Le Modle objet de document est un langage normalis dinterface va permettre un programme Java par exemple de naviguer dans un arbre XML (ou HTML) et den lire ou den
modifier le contenu
Utilisation :
red
Livre = Doc.documentElement.firstChild ;
Sujet = Livre.getAttributeNode(SUJET).text ;
Auteur = Livre.selectSingleNode(AUTEUR) ;
Auteur = Auteur.nextSibling ;
La spcification Document Object Model (DOM) se subdivise en deux niveaux :

Niveau 1 : http ://www.w3.org/TR/REC-DOM-Level-1
Niveau 2 : http ://www.w3.org/TR/WD-DOM-Level-2
4.8
Les langages de lien et dadressage
Les mcanismes de lien (linking) et dadressage associs XML sont en cours de spcification
au sein de trois documents :
XPath (XML Path Language). XPath est le langage dexpression de chemins lintrieur
dun document XML, destin tre utilis la fois par XSLT et par Xpointer. Sa spcification
se trouve en http ://www.w3.org/TR/xpath
XPointer (XML Pointer Language). XPointer est le langage dadressage des contenus dun
document XML. Sa spcification se trouve en http ://www.w3.org/TR/WD-xptr
XLink (XML Linking Language). XLink spcifie les indications insrer dans les ressources
XML pour dcrire des liens entre objets. Il utilise la syntaxe XML pour crer des structures
qui peuvent dcrire non seulement des hyperliens unidirectionnels tels que ceux permis aujourdhui HTML mais aussi des liens plus complexes typs et terminaisons multiple. Sa
spcification se trouve en http ://www.w3.org/TR/xlink
4.9
Lavenir prvisible de XML
Il est prvoir que lusage dXML va dborder largement le WWW, en provoquant la convergence de deux mondes informatiques jusquici spars ; celui des documents et celui des donnes.
Il est trs probable quil va de ce fait devenir trs rapidement la lingua franca de linformatique,
parle tout autant par les SGBD que par les outils de bureautique et de documentation, par les
logiciels de gestion aussi bien que par les applications techniques et scientifiques. Quil va rendre
possible une automatisation des activits administratives et logistiques sans commune mesure avec
ce que permettent les outils daujourdhui. Et quil va considrablement simplifier lchanges de
Donnes Informatis (EDI).
4.10
Annexes XML
Sources : http ://fr.wikipedia.org/wiki/XML
page 20 de 48
Fig. 4.1 Le mme fichier XML affich par Microsoft Internet Explorer sans feuille de style sous
forme darborescence dpliable et repliable (signes + et -)
Fig. 4.2 Exemple de prsentation pour un fichier XML utilis ici pour trier le tableau par anne
page 21 de 48
Chapitre 5
SOAP
5.1
Dfinition
Cest un protocole de dialogue par appels de procdures distance entre objets logiciels. Sa
syntaxe dutilisation est fonde sur XML et ses commandes sont envoyes sur Internet par lintermdiaire du protocole HTTP mais aussi SMTP et POP sous forme de texte structur.
Il permet aux systmes objets distribus de solliciter et dobtenir des services rendus par
dautres objets, il est moins lourd mettre en oeuvre que dautres protocoles et cest pour cela
quil est de plus en plus adopt.
Le protocole SOAP est une note du Consortium W3C dont Microsoft fait partie, mais qui nest
pas spcifique Microsoft et Windows. IBM a galement particip llaboration de ce protocole.
De plus il existe des implmentations Java, et Borland vient dj dimplmenter SOAP sous Windows dans Delphi 6 et sous Linux avec Kylix.
Bien quil soit utilisable avec dautres protocoles de transport, HTTP est le plus couramment
utilis. Le deuxime standard, XML, utilis pour la structuration des donnes sous forme de messages est quand lui le seul utilis.
5.2
Avantages
Par rapport tous les autres protocoles de RPC, SOAP est inter oprable, ainsi il est indpendant des plates-formes et langages de programmation.
Lautre avantage rside dans le dploiement des applications. Pour communiquer entre deux socits via Internet, il est trs souvent dsagrable dutiliser autre chose que HTTP ou POP/SMTP
cause des Firewalls, qui doivent tres reconfigurs engendrant ainsi des trous de scurit. De plus,
cela implique de longues ngociations entre administrateurs rseaux.
5.3
Appels de procdure
Les appels de procdures distance sont de deux types. Ils sont appels middleware : RPC et
ORB (Object Request Broker), le second tant orient objet.
22
Les approches sont diffrentes. En effet, avec ORB, le poste client suspend lactivit de lapplication pendant le traitement des donnes par la mthode invoque sur le serveur qui renvoie
ensuite sa rponse. RPC, au contraire, envoie un message au serveur (initiant le traitement de
celui-ci) par un processus client qui suspend ses activits, ainsi lapplication sur le poste client
continue, elle, de tourner. Un autre message est envoy au processus client quand la procdure
appele sachve.
5.4
SOAP et XML
SOAP repose sur une approche RPC, base donc sur des messages dont le contenu est structur
en XML.
Exemple de requte HTTP contenant du code SOAP
Lenvoi dun message SOAP correspond une requte HTTP POST
red POST /StockQuote HTTP/1.1
Host : www.stockquoteserver.com
Content-Type : text/xml ; charset="utf-8"
Content-Length : nnnn
SOAPAction : "Some-URI"
red<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>
Rponse HTTP correspondante
redHTTP/1.1 200 OK
Content-Type : text/xml ; charset="utf-8"
Content-Length : nnnn
red<SOAP-ENV :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>
Il sagit ici de rpondre une requte SOAP (un message contenu dans une requte HTTP,
donc) demandant au serveur le montant dun prix. La dfinition dune "enveloppe" SOAP est
page 23 de 48
obligatoire : elle caractrise le message SOAP. Une "enveloppe" SOAP se subdivise en un en-tte
facultatif et un corps obligatoire.
SOAP est un protocole de communication dordinateur ordinateur sous HTTP trs simple, crit
en XML. Il permet lchange de donnes, quelque soit les systmes dexploitation. Les messages
SOAP sont des transmissions en sens unique dun metteur vers un rcepteur.
Cest maintenant un standard stabilis et dj employ.
5.5
Lenveloppe SOAP
Elle contient :
un en-tte optionnel qui est un mcanisme gnrique dextension de SOAP.
un corps obligatoire avec un contenu structur :
traduction du modle de donnes en XML
bas sur les schmas du W3C
5.6
Reprsentation XML
red< ?xml version="1.0" ?>

<env :Envelope
xmlns :env=="http ://schemas.xmlsoap.org/soap/envelope/">
<env :Header>
< ! en-tte >
</env :Header>
<env :Body>
< ! corps >
</env :Body>
</env :Envelope>
5.7
Modle de donnes
Types fondamentaux :
Ceux des schmas du W3C (http ://www.w3.org/TR/xmlschema-2/)
Entiers, rels, chanes de caractres, binaire, etc.
Dates, dure, URI, etc.
Types composs :
numration (une valeur parmi une liste)
Struct (compound) : accs nomm
Liste (array) : accs numrot
5.7.1
Traduction dune structure
red< ?xml version="1.0" encoding="ISO-8859-1" ?>

<pers :personne
xmlns :pers="http ://apiacoa.org/teaching/xml/personnes"
xmlns :env="http ://schemas.xmlsoap.org/soap/envelope/"
xmlns :xsi="http ://www.w3.org/1999/XMLSchema-instance"
xmlns :xsd="http ://www.w3.org/1999/XMLSchema"
env :encodingStyle="http ://schemas.xmlsoap.org/soap/encoding/">
page 24 de 48
<nom xsi :type="xsd :string">SEINE</nom>

<prnom xsi :type="xsd :string">Florens</prnom>
</pers :personne>
5.7.2
Traduction dune liste (ou tableau)
red<enc :Array
xmlns :env="http ://schemas.xmlsoap.org/soap/envelope/"
env :encodingStyle="http ://schemas.xmlsoap.org/soap/encoding/">
xmlns :enc="http ://schemas.xmlsoap.org/soap/encoding/"
enc :arrayType="xsd :ur-type[4]">
<x xsi :type="xsd :int">1</x>
<y xsi :type="xsd :decimal">15.23</y>
< ! les noms nimportent pas >
<x xsi :type="xsd :int">-34</x>
<x xsi :type="xsd :string">Bla bla bla</x>
</enc :Array>
5.8
Le modle RPC
Un appel de fonction (une opration dans la terminologie services web) est dcrit par un
message SOAP particulier :
Lappel est reprsent par une structure :
Le nom de la structure est celui de la fonction appele
Chaque paramtre de lappel est considr comme un champ de la structure
Le rsultat est reprsent par une structure
Le modle de fonction autorise 3 modes de passage pour les paramtres :
Mode in : paramtre utilis mais non modifi,apparat seulement dans lappel
Mode in/out : paramtre utilis et modifi,apparat dans lappel et la rponse
Mode out : paramtre de retour uniquement, apparat dans la rponse seulement
5.9
Exemple
Appel de la fonction CtoF (Celsius vers Fahrenheit) :

red< ?xml version="1.0" encoding="ISO-8859-1" ?>
<env :Envelope xmlns :env="http ://schemas.xmlsoap.org/soap/envelope/"
xmlns :xsi="http ://www.w3.org/2001/XMLSchema-instance">
<env :Body>
<ns1 :CtoF env :encodingStyle="http ://schemas.xmlsoap.org/soap/encoding/"
xmlns :ns1="urn :TempConverterIntf-ITempConverter">
<val xsi :type="xsd :int">40</val>
</ns1 :CtoF>
</env :Body>
</env :Envelope>
Un seul paramtre, val, de type xsd :int

page 25 de 48
Rsultat de lappel
red< ?xml version="1.0" encoding=UTF-8 ?>
<SOAP-ENV :Envelope
xmlns :SOAP-ENC="http ://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV :Body>
<NS1 :CtoFResponse xmlns :NS1="urn :TempConverterIntf-ITempConverter"
SOAP-ENV :encodingStyle="http ://schemas.xmlsoap.org/soap/encoding/">
<return xsi :type="xsd :int">86</return>
</NS1 :CtoFResponse>
</SOAP-ENV :Body>
Remarques :
Convention classique pour le nom de la structure : nom de la fonction suivi de Response
Convention classique pour le nom de valeur renvoye par la mthode : return (obligatoire en
SOAP 1.2)
page 26 de 48
Chapitre 6
UDDI
6.1
Dfinition
Dune manire gnrale, lUniversal Description Discovery and Integration est une interface
XML regroupant dautres services en ligne. Cest une norme dannuaire de services Web appele
via le protocole SOAP.
Il contient les registres Internet globaux regroupant les services et descriptions business depuis
septembre 2000.
Dautres services sont attendus ainsi que de nombreuses compagnies.
Cette technologie doit tre utilise avec un pare-feu.
Plus de 2000 entreprises sont enregistres.
Pour publier un nouveau service Web, il faut gnrer un document appel Business Registry, il
sera enregistr sur un UDDI Business Registry Node (IBM, Microsoft et SAP en hbergent chacun
un). Les nodes sont rpliqus entre eux suivant un mcanisme analogue aux DNS.
6.2
6.2.1
Donnes du registre UDDI (cf Figure 4.1)

Pages blanches
Nom du business
Texte de Description
Liste de chanes de caractres de plusieurs langues
Informations
Noms, Numros de tlphone, fax, sites Web, etc
Identifications connues :
Liste didentificateurs connus par DUNS, Thomas, et autres
6.2.2
Pages jaunes
Services organiss en catgories de business

3 grandes parties en V1 :
Industrie : NAICS (Codes industriels Gouvernement US)
Produits/Services : UN/SPSC (ECMA)
Lieu : Classification gographique
La classification est implment comme des paires Nom-Valeur pour faire correspondre un identificateur une page blanche.
27
6.2.3
Pages Vertes
Ensemble dinformations dcrivant comment faire du e-commerce avec ces compagnies.

Processus marqutiques
Descriptions des services rendus
Programmation, Plateforme, Implmentation
Catgorie de services
6.3
Enregistrement de types de services

Nom despace o le type de service est dcrit
Ce que les programmeurs doivent savoir pour utiliser le service
Identificateur pour le publicateur
Identificateur pour lenregistrement du type de service appel tModelKey
Utilis comme signature par les sites Web implmentant ces services
6.4
6.4.1
UDDI et SOAP (cd Figure 4.2)

API (Messages SOAP)
Renseignements
Recherche
find_business
find_service
find_binding
find_tModel
Obtention de details
get_businessDetail
get_serviceDetail
get_bindingDetail
get_tModelDetail
Publication
Sauvegarde
save_business
save_service
save_binding
save_tModel
6.4.2
Suppression
delete_business
delete_service
delete_binding
delete_tModel
Scurit
get_authToken
discard_authToken
Interagir avec XML
Le codage doit tre en UTF-8 et encapsul dans une enveloppe SOAP.

red < ?xml version=1.0 encoding=UTF-8 ?>
<Envelope xmlns=http ://schemas.xmlsoap.org/soap/envelope/>
<Body>
Code
</Body>
</Envelope>
Le contenu de peut tre nimporte quelle requte du schma UDDI.
red
Exemple de retour dinformations sur Microsoft :

<find_business generic="1.0" xmlns="urn :uddi-org :api">
<name>Microsoft</name>
page 28 de 48
</find_business>
6.4.3
Implmentation
Exemple par lintermdaiire dun fichier JScript (code Java) une page HTML avec le contrle
XMLHTTP fourni par MSXML :
red
http=new ActiveXObject("Microsoft.XMLHTTP") ;
http.open("POST",url,false) ;
http.setRequestHeader("Accept","text/xml") ;
http.setRequestHeader("Cache-Control","no-cache") ;
http.setRequestHeader("SOAPAction","") ;
http.send(msg) ;
On naccepte que les rsultats texte/xml.

On dsactive la mise en cache pour avoir des rsultats directs.
On dfinit le SOAPAction dans le header http.
Le retour est du XML.
Ici, on va obtenir une liste dtaille des lments <businessInfo> actuellement enregistrs pour
Microsoft.
red
<businessList generic="1.0" operator="Microsoft Corporation"

truncated="false" xmlns="urn :uddi-org :api">
<businessInfos>
<businessInfo businessKey="0076B468-EB27-42E5-AC09-9955CFF462A3">
<name>Microsoft Corporation</name>
<description xml :lang="en">
Procure aux utilisateurs des logiciels puissants
tout moment, partout et sur tous les dispositifs,
il y a la vision Microsoft.
En tant que leader mondial des logiciels pour
linformatique personnelle et linformatique dentreprise,
nous nous efforons de produire des produits et des services
novateurs qui rpondent aux besoins de nos clients.
</description>
<serviceInfos>
<serviceInfo businessKey="0076B468-EB27-42E5-AC09-9955CFF462A3"
serviceKey="1FFE1F71-2AF3-45FB-B788-09AF7FF151A4">
<name>Services Web pour recherche intelligente</name>
</serviceInfo>
serviceKey="A8E4999A-21A3-47FA-802E-EE50A88B266F">
Web UDDI</name>
</serviceInfo>
</serviceInfos>
</businessInfo>
</businessInfos>
</businessList>
<name>Sites
page 29 de 48
On va maintenant essayer dobtenir des informations sur le dernier service en reportant sa

businessKey dans une balise de recherche de service :
red<find_service generic=1.0 xmlns=urn :uddi-org :api
businessKey=0076B468-EB27-42E5-AC09-9955CFF462A3>
<name>Services Web UDDI</name>
</find_service>
Cela retourne les informations sur ce service :
red<serviceList generic="1.0" operator="Microsoft Corporation"
<serviceInfos>
serviceKey="D2BC296A-723B-4C45-9ED4-494F9E53F1D1">
</serviceInfo>
</serviceInfos>
</serviceList>
On utilise le serviceKey retourn :
red
<get_serviceDetail generic=1.0 xmlns=urn :uddi-org :api>

<serviceKey>D2BC296A-723B-4C45-9ED4-494F9E53F1D1</serviceKey>
</get_serviceDetail>
Cela retourne les <bindingTemplates> suivants :
red<serviceDetail generic="1.0" operator="Microsoft Corporation"
<businessService
businessKey="0076B468-EB27-42E5-AC09-9955CFF462A3"
Interfaces programmatiques des services Web UDDI
bases sur les messages SOAP/XML.
</description>
<bindingTemplates>
<bindingTemplate
bindingKey="A9CAFBE4-11C6-4BFE-90F5-595970D3DE24"
Serveur de production UDDI, Interface de demande dinformation
</description>
<accessPoint URLType="http">
http ://uddi.microsoft.com/inquire
</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo
tModelKey="uuid :4CD7E4BC-648B-426D-9936-443EAAC8AE23">
Interface de demande dinformation UDDI SOAP
</description>
page 30 de 48
</tModelInstanceInfo>
</tModelInstanceDetails>
</bindingTemplate>
...
</bindingTemplates>
<categoryBag>
<keyedReference keyName="KEYWORD" keyValue="API"
tModelKey="uuid :A035A07C-F362-44DD-8F95-E2B134BF43B4">
</keyedReference>
<keyedReference keyName="KEYWORD" keyValue="SOAP"
</keyedReference>
<keyedReference keyName="KEYWORD" keyValue="XML"
</keyedReference>
</categoryBag>
</businessService>
</serviceDetail>
Les informations obtenues deviennent de plus en plus prcises sur le service. Cela nous indique
quil y a un point daccs de production sur http ://uddi.microsoft.com et que les points daccs
UDDI de demande dinformation sont publiquement adressables via HTTP, et que les points daccs de publication sont sous protection HTTPS.
On pourra ensuite utiliser les informations tModelKey pour trouver toutes les entreprises enregistres fournissant un service Web UDDI :
red<find_business generic=1.0 xmlns=urn :uddi-org :api>
<tModelBag>
<tModelKey>uuid :4CD7E4BC-648B-426D-9936-443EAAC8AE23</tModelKey>
</find_business>
6.5
</tModelBag>
Conclusion
Si vous crez des applications qui doivent se connecter dynamiquement des services fournis
par des partenaires commerciaux externes, vous devez alors imprativement penser relier vos
applications au registre UDDI. Imaginez cela comme le DNS pour la couche application mtier.
Il serait intressant de pouvoir ajouter, changer et supprimer des points daccs en temps rel, et
dviter ainsi la semaine de retard, ou plus, quimplique la propagation DNS.
Aprs avoir trouv une socit et ses services dans lannuaire UDDI. Et bien, UDDI ne prtend pas tout rsoudre. Tenter de crer une spec du protocole b2b principal qui englobe tout ce
qui a jamais t invent est une lourde tche, qui ne verra probablement jamais le jour. Voici en
quoi consiste la thorie UDDI : vos applications sauront comment traiter avec certains types de
protocoles bien connus, et ces protocoles seront dcrits de telle manire que vous pourrez trouver
dynamiquement dautres entreprises qui reconnaissent ce protocole. Alternativement, vous pouvez
avoir un petit nombre de partenaires commerciaux de confiance, bien connus travers le monde,
avec qui vous utilisez simplement UDDI pour trouver les nouveaux services que ces derniers fournissent. Dans ce cas, vous avez dj probablement tabli dautres canaux srs afin de tlcharger
les adaptateurs ncessaires pour vous connecter chaque service.
page 31 de 48
Fig. 6.1 Donnes du registre UDDI
6.6
Annexes UDDI
Sources : http ://www.corbucci.com/essi/jerome.htm
page 32 de 48
Fig. 6.2 Couplage dune solution SOAP avec UDDI
Fig. 6.3 Navigateur UDDI de SAP
page 33 de 48
Fig. 6.4 Recherche dun service sur UDDI par lintermdiaire de SAP
page 34 de 48
Chapitre 7
WSDL
7.1
Dfinition
Cest un format de schma XML permettant de dcrire un service Web en prcisant les mthodes disponibles, les formats des messages dentre et de sortie et comment y accder. Il dfinit
un espace de travail extensible pour dcrire des interfaces de Services Web.
Il a t premirement dvelopp par Microsoft et IBM et soumit au W3C devant une commission
de 25 compagnies (fait exceptionnel). Il est au cur de lespace de travail dun service Web, desservant une faon de reprsenter les types de donnes envoys dans les messages, les oprations
effectuer sur les messages, et lenvoi des messages sur les rseaux.
Comme les autres technologies XML, WSDL est tellement extensible et possde un si grand
nombre doptions quassurer une compatibilit et une interoprabilit entre les diffrentes implmentations serait difficile. Si lexpditeur et le destinataire dun message peuvent partager et
comprendre le mme fichier WSD de la mme faon, alors linteroprabilit sera assur.
WSDL permet de dcrire :
Types des donnes
Messages
Oprations
Binding
Ces descriptions doivent tre exhaustives et precises, pour exemple lapi amazon necessite
1150 lignes WSDL pour 23 operations et 200 lignes pour google pour 3 operations.
Concepts lis WSDL :
Service : une collection de ports (port ou endpoints)
Port : une adresse rseau et un binding
Binding : un protocole et un format de donnes associ un type de port (port type)
Type de port : un ensemble doprations (proche dune interface au sens Java)
Opration : une action propose par un service web, dcrite par ses messages (proche dune
mthode au sens Java)
Message : un ensemble de donnes
Donne : une information type selon un systme de type comme celui des schmas du W3
Chaque lment principal peut tre spcifi dans un document XML et import dans diffrentes
combinaisons pour crer une description de service Web finale, ou ils peuvent tous tres dfinis
ensemble dans un seul document. Les dfinitions de type de donnes dterminent la structure
et le contenu des messages. Les oprations abstraites dterminent les oprations effectues sur le
35
contenu du message, et les services rendre dterminent le rseau de transport qui acheminera le
message destination.
7.2
Les dfinitions
La partie dfinitions inclut les dfinitions de types de donnes, les messages et les oprations
abstraites, qui sont similaires aux dfinitions dinterfaces en CORBA ou DCOM. Les messages
peuvent avoir plusieurs parties et tre dfinies avec un style dinteraction procdurale, orient document ou les deux.
Les dfinitions de type en WSDL sont bases sur des schmas XML, mais on peut utiliser un
autre systme quivalent ou similaire. Par exemple, les types de donnes dfinis en CORBA IDL
(Interface Definition Language) peuvent tre utiliss la place des schmas de dfinitions XML.
(Si un autre systme de dfinition de type est utilis, les deux parties du service Web doivent tre
capable de le comprendre).
7.3
Les noms despace
Les noms despaces XML sont utiliss pour assurer lunicit des noms dlments XML utiliss
dans chacun des trois parties principales de WSDL. Quand les lments WSD sont dveleopps
sparement et imports dans un seul fichier, les noms despaces utiliss dans les fichiers ne doivent
pas se chevaucher. Les schmas associs sont utiliss pour valider les fichiers, messages et oprations WSDL dfinis.
WSDL inclut beaucoup dextensions, de changements et dadditions en tant que service Web
mature. Comme SOAP, WSDL est un espace de travail XML extensible pouvant tre adapt
de multiples systmes dapplications de type de donnes, dfinitions de types de messages, oprations, transports.
7.4
Exemple WSDL (cf Figures 5.*)
Description dun service de mini annuaire de personnes.

On pourra effectuer un ajout de personne puis une recherche de personne en fonction du nom.
7.5
Annexes WSDL
Sources : http ://developpeur.journaldunet.com/tutoriel

/xml/021107xml_wsdl1b.shtml
page 36 de 48
Fig. 7.1 Code WSDL XML de dfinition de types, dclaration de messages et de types de port
page 37 de 48
Fig. 7.2 Code WSDL XML de dclaration dengagement et de service
Fig. 7.3 Code WSDL XML dimplmentation
page 38 de 48
Chapitre 8
Web services et entreprises

8.1
Dfinition
Avec lessor dInternet, il devient de plus en plus intressant pour les entreprises dutiliser un
support lectronique pour leurs transactions commerciales.
Le commerce lectronique ne se limite maintenant plus lchange de messages. En effet, les
entreprises veulent dsormais permettre leurs partenaires daffaires daccder directement aux
fonctions de leur systme dinformation.
Une nouvelle notion a t introduite, puisquelles veulent de plus que les diffrents logiciels
de gestion (ERP, SCM CRM) communiquent entre eux, on lappelle lintgration entre diffrents
systmes dinformation.
Les Web services sont une solution cette approche dintgration.
Ils promettent linteroprabilit entre toutes les applications. En se basant sur XML et en utilisant Internet comme un canal de communication, ils permettent en thorie de faire communiquer
entre elles les entreprises.
On se dirige donc vers une intgration des applications utilisant des langages propritaires.
Cest ce qui En outre, elles pourront, en retour, ouvrir leurs applications dautres socits.
8.2
8.2.1
Construction dun projet informatique

Introduction
XML est dsormais utilis pour dcrire les projets business des entreprises. Pour diffuser toutes
les informations vers des applications et dautres entreprises lorsquil y a collaboration, des technologies telles que XSLT leurs servent. Cest un langage qui complte XML dans le sens o il va
permettre lchange dinformations entre applications. Ce systme reprsente 80% de lutilisation
de XML dans les projets informatiques.
En rsum, XSLT diffuse les donnes formates et structures en XML.
8.2.2
Etapes
La cartographie et la formalisation des processus mtiers est ralise en XML et va permettre

lentreprise de matriser les ressources qui entrent en jeu dans le projet ainsi que duniformiser son systme informatique. Le systme devient alors capable de considrer la dimension
mtier, il peut alors comprendre et interprter les acteurs de lorganisation, ce quils doivent
faire et de quelle faon ils vont collaborer.
La mise en place des infrastructures B2B va permettre la connexion des applications de
lentreprise avec celles de ses partenaires.
39
Ladoption dun langage commun signifie la mise en place des dialogues entre entreprises, il
va pouvoir les transactions avec les partenaires.
XML sera employ pour toutes ces tapes car il va sadresser tous ces besoins. Il mettra
de plus daccord les diffrents acteurs sur des standards.
8.3
8.3.1
EAI
Dfinition
LEntreprise Application Integration est un concept. Cest le fait de regrouper un ensemble

des mthodes, technologies et outils qui permettent de consolider et coordonner lensemble des
applications htrognes dune entreprise. Lobjectif est daboutir une urbanisation du systme
dinformation de lentreprise.
Les Web services servent de base lEAI.
Ce sont de vritables systmes de composants pouvant tre utilis pour lintgration dapplications.
8.3.2
Lintgration dapplications
LEAI fait communiquer et collaborer les applications dune mme entreprise.

Lintgration des applications est devenue lune des priorits des entreprises car elle pourra
mettre en place une uniformisation de leur systme informatique.
Jusqu trs peu de temps, les systmes dinformation taient souvent composs dapplications
non communicantes.
Prenons lexemple dapplications de gestion, si les applications ne savent pas communiquer,
les commandes seront saisies en plusieurs endroits : savoir dans le logiciel de traitement des
commandes, dans le logiciel de facturation, etc.
Lintgration des diffrentes applications permet dviter les doublons, les informations errones
et damliorer la traabilit.
8.3.3
Fonctions de lEAI
Interfaage : extraction et injection des donnes dans une application. On se sert de WSDL
en particulier. On utilise les Web services car ils ont lavantage de pouvoir tre accds
partir de nimporte quel langage de programmation sur nimporte quelle plate-forme. Grce
WSDL, on va pouvoir donner une description normalise des fonctionnalits offertes par
les applications.
Transformation : conversion des donnes. Cest le rle de XSLT. Cela permet en particulier de
convertir des informations comprises par une application en informations comprises par une
autre. Par exemple, si une application de gestion des commandes transmet une description
de commande une application de facturation dans le but de gnrer une facture, et que ces
deux applications nont pas la mme faon de modliser une commande, une opration de
transformation est ncessaire.
Routage : transport des donnes vers le destinataire avec SOAP.
Gestion : suivi de ltat du processus. Pour cela on utilise la gestion des processus mtiers
avec BPML.
8.4
8.4.1
Les processus mtiers

Dfinition
Lobjectif des processus mtiers est de formaliser lexcution dactivits par des applications
de manire collaborative dans le but datteindre un objectif mtier.
Formellement, un processus mtier peut tre dfini comme un enchanement dactivits. Dans un
page 40 de 48
processus mtier, on tient compte des diffrents participants dune opration, de leur rle, de
lobjectif de cette opration et des moyens mis en uvre (messages, documents). On peut agir
sur ceux-ci en dfinissant des rgles mtier, des rgles de scurit, des rgles de transactions. On
peut ensuite lancer lexcution du modle (automate tats finis) et vrifier le fonctionnement
thorique des diffrents processus.
BPML est un standard mergeant soccupant de cela.
Un processus mtier est interne une entreprise et une seule. Il dcrit les activits ncessitant la
collaboration de plusieurs entits.
8.4.2
Dialogues
Un dialogue dfinit une collaboration entre plusieurs entreprises (partenaires), sous la forme
dchange de messages. Un dialogue comprend :
La dfinition des messages changs entre partenaires ;
Le squencement de ces messages ;
Les rles des diffrents partenaires.
8.4.3
Les processus e-business
Un dialogue fait abstraction des processus mtiers implments par chaque partenaire. Pour
lier dialogues et processus mtiers, On utilise la notion de processus e-business.
Un processus e-business est compos de deux parties :
Une interface publique : dfinition du dialogue prcisant linteraction entre les participants
du processus e-business. Elle est commune tous les participants.
Deux interfaces prives (une par partenaire) : dfinition des processus mtiers implments
par chaque partenaire.
8.4.4
BPML (Business Process Modeling Language)
Cest un mta langage de modlisation des processus mtiers dont les premires spcifications
sont apparues au printemps 2001. Il dfinit un modle abstrait dinteraction entre collaborateurs
participant une activit de lentreprise, voire entre une organisation et ses partenaires.
Il est bas sur XML et excut par un moteur.
BPML spcifie si les processus supportent les transactions courtes ou longues (mcanisme de
undo). Un des objectifs de BPML est dintgrer les applications existantes de lentreprise dans des
processus mtiers, afin de les utiliser dans les processus e-business.
8.5
Conclusion
LEAI garanti que chaque nouvelle application sinsre correctement et interagit avec les applications existantes. Mais une entreprise qui veut offrir ses applications lextrieur aura ncessairement besoin des web services explique Didier Martineau, le directeur des services de lditeur
de logiciels XML Software AG. En effet, pour lui, lEAI prend tout son sens dans un rle interne
lentreprise.
Ainsi, compter sur lutilisation des web services en interne pour lintgration dapplications, en
lieu et place des outils dEAI, naurait pas de sens. Les Web services ne vont pouvoir exister que
du fait de la prsence de lEAI.
Mme si toutes les applications entre les entreprises communiquent via les Web services, les EAI
page 41 de 48
seront toujours prsents pour assurer la transformation, le routage et le transport des donnes au
sein de lentreprise.
page 42 de 48
Chapitre 9
Scurit et fiabilit des Web Services

9.1
Quels mcanismes veut-on mettre en place pour assurer

la scurit des Web Services ?
Les Web Services doivent intgrer les mthodes de base de la scurit afin de permettre une
meilleur scurit et une bonne fiabilit. Parmis les stratgies utilises on peut citer celles-ci :
9.1.1
Authentification
Lauthentification consiste mettre en place un systme de login et de mot de passe afin

didentifier lentit qui tente de se connecter au systme. Lauthentification permet de :
1. vrifier si lutilisateur est connu du systme ;
2. dterminer les droits et privilges affects lutilisateur ;
3. contrer lusurpation frauduleuse de lidentit dun utilisateur, de ladministrateur ou dun
serveur ;
4. limiter lintrusion sur le rseau partir dun accs externe ou mme interne.
Lauthentification a pour but dassurer quun utilisateur, une application ou une interface peut ou
non dialoguer avec une application.
9.1.2
Autorisation daccs
Il sagit dun contrle daccs aux ressources dun systme dinformation. Le contrle daccs
assure que lutilisateur a accs aux ressources autorises. Pour cela on met en oeuvre des filtres
qui ne laissent transiter que les flux autoriss. Dans un contexte dintgration de services, aprs
lauthentification dun utilisateur ou dune interface, le systme permettra a chacun dassumer ses
rles.
9.1.3
Mcanisme dencryptage et de dcryptage des donnes
Afin que les donnes qui transitent sur le rseau ne puissent tre lues par une tierce personne, il
est utile de mettre en place un mcanisme dencryptage et de dcryptage des donnes. Le cryptage
a pour but de protger linformation et de la rendre incomprhensible a toute autre personne que
le destinataire du message.
9.1.4
Signature digitale
La signature digitale utilise la notion de cryptographie cl publique. La signature lectronique

permet lauthentification du signataire, chaque signature nappartient qu un seul document et
43
ne peut pas tre rutilise ni imite. Les signatures lectroniques permettent pour les Web Services
didentifier les entits mettrices de messages.
9.2
Scurisation des services Web
Les Web Services ne supportent pas explicitement les mcanismes de scurit. Afin de scuriser
les Web Services il faudrait commencer par scuriser linfrastructure informatique puis scuriser
spcifiquement les Web Services : Pour cela on peut rendre sres les connexions et les donnes en
utilisant les standards existants.
9.2.1
Scurisation de linfrastructure
Les Web Services reposant sur une infrastructure informatique, il est logiquement ncessaire de
commencer par scuriser celle-ci. Une telle scurisation de linfrastructure informatique ncessite
plusieurs technologies integres dans un plan de scurit global.
Cela suppose une identification des risques lis lenvironnement (virus, pirates , evenements
imprevisibles risquant de nuire linfrastructure(incendie, ...etc)). Mais il est aussi ncessaire
dintgrer des mesures de scurit tous les niveaux du rseau.
9.2.2
Scurisation des connexions
Pour scuriser les Web Services la solution la plus simple mettre en oeuvre est la scurisation
de la connexion entre le client et le serveur. Pour cela plusieurs moyens sont envisageables :
Systme de pare-feu
Les rgles de pare-feu permettent de limiter laccs une liste dadresses IP connues. Cette
technique sera utilise au sein dun rseau priv.
Protocole SSL
SSL (Secure Sockets Layer) permet dtablir des connexions scurises sur un rseau non scuris(Internet) .
SSL est en fait un systme de cryptage/dcryptage des messages qui circulent entre un client et un
serveur. SSL crypte le message envoy par un client. Ainsi ce message ne peut pas tre lu pendant
son transfert. SSL dcrypte le message une fois que celui-ci est parvenu au serveur et vrifie la
bonne identit de lexpditeur(authentification).
SSL utilise le concept de certificat pour lauthentification : Voici un petit exemple
1. Supposons un consommateur A et un site proposant des services B ;
2. A envoit son certificat B. Ce certificat contientla cl publique de A ;
3. Aprs rception dun message par B gnre un message alatoire et lenvoie A ;
4. A crypte ce message avec sa cl prive et le renvoie B ;
5. B dcrypte le message avec la cl pulique de A. B compare le message avec le message initial.
seul A a p renvoyer le message : Son identit est vrifie, le message na pas t envoy par
un usurpateur car seul A connait sa cl prive.
Lorsque HTTP est associ SSL, on parle de HTTPS. Lavantage de SSL est quil est dj trs
employ sur Internet. Cependant, SSL est uniquement disponible avec TCP/IP, or, le protocole
SOAP peut tre employ hors du contexte de TCP/IP. SSL est efficace en ce qui concerne la
scurit mais pse beaucoup sur les performances.
page 44 de 48
9.2.3
Authentification et contrle daccs
Lauthentification consiste vrifier lidentit de lmetteur dun message.

On dit que que lauthentification ncessite des informations didentification : un mot de passe peut
tre information didentification. Le systme vrifie ces informations didentification et si elles sont
valides authentifie lentit.
Cest seulement aprs cette authentification que des autorisations sont accordes selon le client.
certains client ont accs des taches ou des donnes inaccessibles dautres clients.
La plupart des Web Services utilisent les fonctions dauthentification du protocole HTTP. Pour
assurer linteroprabilit entre les Web Services il est ncessaire que les mthodes utilises tendent
la norme SOAP intgrant ainsi la scurit directement dans les Web Services
9.2.4
Scurisation de SOAP
Il est ncessaire de scuriser le protocole SOAP. Les messages seront encrypts afin de les
protger en ce qui concerne la confidentialit. Pour cela il existe plusieurs moyens :
Encrypter le corps du mesage SOAP ;
Utiliser SLL pour encrypter le trafic HTTP.
9.3
9.3.1
Standards XML de scurit

XML Signature
XML Signature permet dintgrer directement dans le document XML la signature et le certificat. Lavantage pour les Web Services est que les lements ncessaires la scurit sont inclus
dans le documen XML. XML Signature est totalement adapt aux Web Services et intgre :
1. Une protection du document par cryptage
2. Lauthentification de lentit qui a envoy le document
3. lintgrit du document
Les principaux avantages de la signature XML sont que des parties de documents ou des documents entiers peuvent tre protgs et les documents sont protgs mme en dehors du transfert
des documents.
Cependant ce standard ne couvre pas tous les lments de scurits comme par exemple la gestion
des droits daccs.
9.3.2
XKMS XML Key Management Specifications
La spcification XKMS offre une infrastructure de gestion es cls publiques afin de gnraliser
lutilisation de XML Signature.
Pour faciliter lemploi et le dveloppement de XML Signature, il faut fournir des entits de
confiance qui supportent la gestion de cls publiques, et plus seulement se limiter lutiliqation de certificats qui est trs contraignante. Dans cette approche, on identifie un service Web de
confiance qui offre une implmentation dun service XKMS permettant :
denregistrer une paire de cls et dobtenir en contrepartie un certificat.
de rechercher une cl publique.
de supprimer une paire de cls.
Autrement dit, lentit qui fournit limplantation XKMS joue le rle dune autorit de certifcation.
9.3.3
SAML Security Assertion Markup Language
Le standard SAML a pour but de favoriser linteroprabilit entre les solutions de gestion des
droits utilisateurs sur Internet.
page 45 de 48
SAML dfinit des formats de messages XML et un vocabulaire pour vhiculer des informations
qui composent une procdure dauthentification. Il est compos de deux schmas XML suivants :
Dclaration de nom : Il sagit dun document XML sign contenant une proposition de trois
lments : le type dauthentification, la source dauthentifiction et le sujet authentifi.
Habilitation : Il sagit dun document XML sign dcrivant les renseignements relatifs aux
autorisations dun sujet identifi. Lhabilitation suit lutilisateur dun domaine lautre pendant tout le cours dune transaction.
9.3.4
WS-Security
Cette spcification qui a t propose lorigine dans le but de dcrire lensemble des pratiques
de scurit les plus couramment utilises. Objectif terme : laborer une interface qui assure linteroprabilit entre solutions de scurit dentreprise, reposant sur des technologies htrognes.
Lensemble des mthodes prises en compte WS-Security couvre en premier lieu lauthentification de la partie cliente, cest--dire lmetteur du message SOAP. Dans le cas dune architecture
de Web Services, ce client peut renvoyer un individu mais galement une application (ou
composant) ou encore une machine. Do la prise en compte par la spcification de divers mcanismes : le couple identifiant/mot de passe, la mthode du jeton de scurit et celles des certificats
notamment. "Concrtement, WS-Security dfinit la manire de dcrire au sein dun message SOAP
les droits utilisateur correspondant ces diffrents systmes de scurit". Comment viter que la
connexion entre deux Web Services ne soit "sur coute" ? Ici, entre en jeu le chiffrement et la
gestion de lintgrit des messages, pour lesquels le langage propose un vocabulaire de gestion de
certificats : des outils qui peuvent tre utiliss aussi bien pour chiffrer un document lectronique
que pour le signer.
page 46 de 48
Chapitre 10
Conclusion
10.1
Apports
Les Web Services possdent une simplicit de mise en oeuvre : Ils rendent en effet accessibles
depuis Internet des fonctionnalits dune application exixtante tout en ne modifiant pas en profondeur le systeme dinformation de lentreprise.Il sagit de lajout de briques suplmentaires. Pour
cela, les Web Services exploitent les standards dchange Internet.
Les services Web avec ses protocoles et ses standards avance vers toujours plus de normalisation.
Dj, le protocole dchange de messages SOAP et le langage WSDL pour la dfinition de linterface standardsent la couche de transport. Les Web Services reposent sur des bases solides(SOAP et
WSDL)qui ont prouv leur efficacit et leur maturit mme si un normalisation complte nexiste
pas encore.
Cette standardisation permet une grande interoprabilit entre des applications de technologie
diffrente : les protocoles SOAP, WSDL et UDDI permettent de simplifier lutilisation des services auxquels ils sont lis par lutilisation de fichiers textuels, donc lisibles par lutilisateur. Leur
contenu se limitant aux lments essentiels dinteroprabilit, ces standards assurent une grande
indpendance de limplmentation par rapport au systme dexploitation, larchitecture de la
machine ou au standard utilis.
Un des avantages principaux des Web Services est quils sont bas sur Internet qui est on le sait
fiable et mature.
10.2
Limites
Les Web Services ont cependant des limites qui sont :

Toutes les normes ne sont pas tablies notament en matire de scurit ;
Les performances sont relativement faibles ;
Des contournements de scurit sont possibles.
Aucune norme de scurit nexiste dans les Web Services. En effet les standards qui exitent peuvent
trs bien ne pas tre utiliss ou peuvent nassurer quune partie des xigeances se scurit. De plus,
les Web Services utilisent HTTP et hritent des problmes de celui-ci : Les firewall peuvent tre
contourns.
En ce qui concerne les performances des Web Services, lchange de messages est particulirement
lent du fait que la quantit dinformations vehicule est importante.
10.3
Evolution des Web Services
L o les architectures prcdentes demandaient des resources importantes, en terme de dveloppement comme de dploiement, les Web Services hritent du pragmatisme des technologies du
47
Net, ce qui facilite leur adoption. Mais les Web Services sont encore en cours de stabilisation des
standards.
Il sera notament ncesaire de definir des normes de scurit qui posent un gros problme. Cependant les Web Services gagnent en maturit ce qui peut promettre quils seront adopts massivement
comme la rponse approprie aux problmatiques dchanges de donnes et dintgration dapplications.
Il est donc prvu un augmentation dutilisation des Web Services par les entreprises dans les annes
venir.
10.4
Enrichissement personnel
Ce travail dtudes nous a permis daborder une nouvelle technologie et den tudier divers
aspects : Les principes de fonctionnement et ses mises en oeuvre avec ltude des differentes
technologies qui accompagnent les Web Services.
Ltude des Web Services nous a galement permis de mieux comprendre les enjeux dans le domaine
du Web dans les entreprises autant sur le plan de limportance du Web que sur les exigeances qui
en dcoulent(scurit, fiabilit, performances, ...).
page 48 de 48

Rapport WebServices

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport WebServices

Transféré par

Droits d'auteur :

Formats disponibles

Universit de Nice-Sophia Antipolis

Licence dInformatique 3me anne

Les Web Services

Table des matires

5.7.2 Traduction dune liste (ou tableau) . . . . . . . . . . . . . . . . . . . . . . .

8 Web services et entreprises

9 Scurit et fiabilit des Web Services

XKMS XML Key Management Specifications . . . . . . . . . . . . . . . . .

Historique et Origine des Concepts

source : http ://www.softeam.fr/technologies_web_services.php

1. Lapplication construit sa requte et la normalise grce aux standards.

source : http ://www.softeam.fr/technologies_web_services.php

source : http ://www.softeam.fr/technologies_web_services.php

La programmation utilise de nos jours couramment lappel de fonctions, cest pourquoi ce

Le numro de CALCUL (ici 0x20000001) identifie le programme de manire unique dans le

Addition avec 4294967280 et 10

Sources : GNU/Linux & Hurd Magazine France

Fig. 3.3 Fonction de test de laddition

Fig. 3.4 Fonction de calcul

Fig. 3.5 Fonction principale du client

Le prdcesseur de XML sur le Web : HTML

Victor Hugo, Les miserables, 1995, Dupond, Paris

Rgles dcriture au format XML

Les informations doivent tre :

Ce que XML va rendre possible

Les espaces de nommage(namespaces)

Les langages de prsentation (style) : CSS et XSL

Types de donnes (Datatypes) : http ://www.w3.org/TR/xmlschema-2/

La spcification Document Object Model (DOM) se subdivise en deux niveaux :

Les langages de lien et dadressage

Lavenir prvisible de XML

Sources : http ://fr.wikipedia.org/wiki/XML

red< ?xml version="1.0" ?>

Traduction dune structure

red< ?xml version="1.0" encoding="ISO-8859-1" ?>

<nom xsi :type="xsd :string">SEINE</nom>

Traduction dune liste (ou tableau)

Appel de la fonction CtoF (Celsius vers Fahrenheit) :

Un seul paramtre, val, de type xsd :int

Donnes du registre UDDI (cf Figure 4.1)

Services organiss en catgories de business

Ensemble dinformations dcrivant comment faire du e-commerce avec ces compagnies.

Enregistrement de types de services

UDDI et SOAP (cd Figure 4.2)

Interagir avec XML

Le codage doit tre en UTF-8 et encapsul dans une enveloppe SOAP.

Exemple de retour dinformations sur Microsoft :

On naccepte que les rsultats texte/xml.

<businessList generic="1.0" operator="Microsoft Corporation"

On va maintenant essayer dobtenir des informations sur le dernier service en reportant sa

<get_serviceDetail generic=1.0 xmlns=urn :uddi-org :api>

Fig. 6.1 Donnes du registre UDDI

Sources : http ://www.corbucci.com/essi/jerome.htm

Fig. 6.2 Couplage dune solution SOAP avec UDDI

Fig. 6.3 Navigateur UDDI de SAP

Les noms despace

Exemple WSDL (cf Figures 5.*)

Description dun service de mini annuaire de personnes.

Sources : http ://developpeur.journaldunet.com/tutoriel

Fig. 7.2 Code WSDL XML de dclaration dengagement et de service

Fig. 7.3 Code WSDL XML dimplmentation

Web services et entreprises

Construction dun projet informatique

La cartographie et la formalisation des processus mtiers est ralise en XML et va permettre