Rapport Web Services

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Principes 2.1 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 RPC 3.1 Dnition . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 4 XML 4.1 Dnition . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 5 SOAP 5.1 Dnition . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . structure . . . . . . . . . . . . . . . . . . . . . . . . i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 3 5 5 6 9 9 9 9 10 10 10 10 11 11 16 16 16 16 17 17 18 18 19 19 20 20 20 22 22 22 22 23 24 24 24 24
5.8 5.9
5.7.2 Traduction dune liste (ou tableau) . . . . . . . . . . . . . . . . . . . . . . . Le modle RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25 25 25 27 27 27 27 27 28 28 28 28 28 29 31 32 35 35 36 36 36 36 39 39 39 39 39 40 40 40 40 40 40 41 41 41 41 43 43 43 43 43 43 44 44 44 45 45 45 45
6 UDDI 6.1 Dnition . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . 7 WSDL 7.1 Dnition . . . . . 7.2 Les dnitions . . . 7.3 Les noms despace 7.4 Exemple WSDL (cf 7.5 Annexes WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . Figures 5.*) . . . . . . . . . . . . . . . . . .
8 Web services et entreprises 8.1 Dnition . . . . . . . . . . . . . . . . . . 8.2 Construction dun projet informatique . . 8.2.1 Introduction . . . . . . . . . . . . 8.2.2 Etapes . . . . . . . . . . . . . . . . 8.3 EAI . . . . . . . . . . . . . . . . . . . . . 8.3.1 Dnition . . . . . . . . . . . . . . 8.3.2 Lintgration dapplications . . . . 8.3.3 Fonctions de lEAI . . . . . . . . . 8.4 Les processus mtiers . . . . . . . . . . . . 8.4.1 Dnition . . . . . . . . . . . . . . 8.4.2 Dialogues . . . . . . . . . . . . . . 8.4.3 Les processus e-business . . . . . . 8.4.4 BPML (Business Process Modeling 8.5 Conclusion . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Language) . . . . . . .
9 Scurit et abilit des Web Services 9.1 Quels mcanismes veut-on mettre en place pour assurer la scurit des Web Services ? 9.1.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Authentication et contrle daccs . . . . . . . . . . . . . . . . . . . . . . . 9.2.4 Scurisation de SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3 Standards XML de scurit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3.1 XML Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii
9.3.2 9.3.3 9.3.4
XKMS XML Key Management Specications . . . . . . . . . . . . . . . . . SAML Security Assertion Markup Language . . . . . . . . . . . . . . . . . WS-Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45 45 46 47 47 47 47 48
10 Conclusion 10.1 Apports . . . . . . . . . . . 10.2 Limites . . . . . . . . . . . 10.3 Evolution des Web Services 10.4 Enrichissement personnel .
page iii de 48
Chapitre 1
Introduction
Selon la dnition 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) an 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 leort 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 direntes 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 dni 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 direntes 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 dicile implmenter. Les techniques employes sont complexes et coteuses. Vers la n des annes 80, lvidence fut que lge des systmes informatiques isols touchait son terme tandis que dirents 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 bnque 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 t 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 dirents, 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 dnir 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 spciques 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, eectueraient 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 vrier dynamiquement que linterface est eectivement 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 n des annes 90, le-speak dHewlett Packard t 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 dirences 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 an 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 rewalls des entreprises. Le SOAP a t largement accept, probablement grce ce que son nom vante : sa simplicit. Le SOAP ne dnit au nal 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 certie pour analyser ce quon lui apporte. On peut armer que cest avec SOAP que le concept de services Web est page 2 de 48
dnitivement 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 simplier 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 prols 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 rewalls qui ltrent et bloquent beaucoup de trac dInternet pour des raisons de scurit. Dans ce milieu, beaucoup de ports (voire quasiment tous) sont ferms au trac 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 modier la conguration de scurit des organisations. Si lon devait rsumer les raisons de la cration des services Web, les qualicatifs tels que la simplicit des changes, lamlioration de la communication entre les applications en seraient les points principaux. En ajoutant cela linteroprabilit des programmes indiremment 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 ecace. Les protocoles des services Web reposent donc sur des organisations et des architectures prdnies.
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. Dirents 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 : Dnition 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 soure daucune contestation. Elle sappuie sur le protocole SOAP pour lchange des messages et sur le langage WSDL pour la dnition du contrat de linterface. Couche de smantique : Normalisation des donnes participant aux changes selon des critres mtier. Les initiatives de dnition 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 dirents 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 dnitive. Le constat est quil nen est rien et que la trame, trop globale, du projet ne sut 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 dauthentication 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 dirents axes :
2.2
Architecture
Pour comprendre le fonctionnement dune architecture de services Web, il faut commencer par revoir certains principes. Si lon reprend la dnition 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 spcique". Ce sont donc des units logiques applicatives qui sont accessibles grce au protocole Internet. Une dnition conceptuelle du terme service Web mettrait en avant les qualits dune fonctionnalit commerciale prsente par une entit htrogne quelconque sur Internet an 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 nal, on peut armer 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 eet, 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 sut juste que le message suive une architecture donne pour quil puisse tre analys. Il sagit maintenant didentier 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 Dnition
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 eectuant des calculs spciques. Celui-ci servira donc de serveur et un autre ordinateur de client qui appellera la procdure distante pour que le serveur eectue 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 eet, ses spcications 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 Denition Language) de RPC. Il sert a la specication 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 dnition est enregistre dans le chier 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) identie 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 conit 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 chier de dnition : > 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) dnit les types utiliss pour lchange de variables entre le client et le serveur. Cela permet dadapter le programme sur direntes plateformes. Ainsi, tous les types utiliss sont ltrs 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 dirences. 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 n 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 eectivement 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 Overow > 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 Dnition
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 prdnies, 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 eet, 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 dirents 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 nale. 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 dnies 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 chier XML. Une entit peut aussi reprsenter un chier XML externe tout entier. Ainsi un mme chier XML (par exemple notre bibliographie) pourra tre utilis par plusieurs pages XML diffrentes (par exemple une page spciquement consacre XSL pourra prsenter la n la bibliographie spcique dXSL extraite automatiquement de notre bibliographie XML) La DTD (Dnition 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 chier part. Cette dclaration sappelle une Dnition de Type de Document (DTD). Elle seectue selon un formalisme particulier dni lui-aussi dans la spcication 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 spcication 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 spcique, 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 aect un livre comme une personne par exemple. Ce mcanisme va nous permettre de les direncier avec personne :titre et biblio :titre. Ces prxes doivent tre associs une URL. Elle peut tre ctive. red <BIBLIO xmlns=http ://www.biblio.org/vocabulaire xmlns :personne=http ://www.personel.org/profils/> Ici, les balises non prxes sont censes se rapporter lespace de nommage par dfaut, soit page 18 de 48
lURL ctive http ://www.biblio.org/vocabulaire tandis que les balises prxes par perso : se rapportent lespace de nommage associ http ://www.personel.org/prols/.
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 dicult tre incorpor, en tout ou partie, dans des documents de nature trs dirente, 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 nal 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 spcication 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 spcier 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 spcication 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 dnir des contraintes en matire de syntaxe, de structure et de valeurs applicables une classe de documents HTML. Il va permettre entre autres choses deectuer 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 modier le contenu Utilisation : red Livre = Doc.documentElement.rstChild ; Sujet = Livre.getAttributeNode(SUJET).text ; Auteur = Livre.selectSingleNode(AUTEUR) ; Auteur = Auteur.nextSibling ;
La spcication 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 spcication 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 spcication se trouve en http ://www.w3.org/TR/xpath XPointer (XML Pointer Language). XPointer est le langage dadressage des contenus dun document XML. Sa spcication se trouve en http ://www.w3.org/TR/WD-xptr XLink (XML Linking Language). XLink spcie 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 spcication 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 scientiques. 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 simplier 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 chier XML ach par Microsoft Internet Explorer sans feuille de style sous forme darborescence dpliable et repliable (signes + et -)
Fig. 4.2 Exemple de prsentation pour un chier XML utilis ici pour trier le tableau par anne
page 21 de 48
Chapitre 5
SOAP
5.1 Dnition
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 spcique 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 recongurs 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 direntes. En eet, 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 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>
Il sagit ici de rpondre une requte SOAP (un message contenu dans une requte HTTP, donc) demandant au serveur le montant dun prix. La dnition 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/" 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/"> 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 modi,apparat seulement dans lappel Mode in/out : paramtre utilis et modi,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 :xsd="http ://www.w3.org/2001/XMLSchema" 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-ENV="http ://schemas.xmlsoap.org/soap/envelope/" xmlns :xsd="http ://www.w3.org/2001/XMLSchema" xmlns :xsi="http ://www.w3.org/2001/XMLSchema-instance" 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> </SOAP-ENV :Envelope> 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 Dnition
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 Identications connues : Liste didenticateurs 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 : Classication gographique La classication est implment comme des paires Nom-Valeur pour faire correspondre un identicateur 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 Identicateur pour le publicateur Identicateur 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 nd_business nd_service nd_binding nd_tModel Obtention de details get_businessDetail get_serviceDetail get_bindingDetail get_tModelDetail Publication Sauvegarde save_business save_service save_binding save_tModel Suppression delete_business delete_service delete_binding delete_tModel Scurit get_authToken discard_authToken
6.4.2
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 chier 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 dnit 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. <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> <serviceInfo businessKey="0076B468-EB27-42E5-AC09-9955CFF462A3" serviceKey="A8E4999A-21A3-47FA-802E-EE50A88B266F"> Web UDDI</name> </serviceInfo> </serviceInfos> </businessInfo> </businessInfos> </businessList> red
<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" truncated="false" xmlns="urn :uddi-org :api"> <serviceInfos> <serviceInfo businessKey="0076B468-EB27-42E5-AC09-9955CFF462A3" serviceKey="D2BC296A-723B-4C45-9ED4-494F9E53F1D1"> <name>Services Web UDDI</name> </serviceInfo> </serviceInfos> </serviceList> On utilise le serviceKey retourn : <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" truncated="false" xmlns="urn :uddi-org :api"> <businessService businessKey="0076B468-EB27-42E5-AC09-9955CFF462A3" serviceKey="D2BC296A-723B-4C45-9ED4-494F9E53F1D1"> <name>Services Web UDDI</name> <description xml :lang="en"> Interfaces programmatiques des services Web UDDI bases sur les messages SOAP/XML. </description> <bindingTemplates> <bindingTemplate bindingKey="A9CAFBE4-11C6-4BFE-90F5-595970D3DE24" serviceKey="D2BC296A-723B-4C45-9ED4-494F9E53F1D1"> <description xml :lang="en"> 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"> <description xml :lang="en"> Interface de demande dinformation UDDI SOAP </description> page 30 de 48 red
</tModelInstanceInfo> </tModelInstanceDetails> </bindingTemplate> ... </bindingTemplates> <categoryBag> <keyedReference keyName="KEYWORD" keyValue="API" tModelKey="uuid :A035A07C-F362-44DD-8F95-E2B134BF43B4"> </keyedReference> <keyedReference keyName="KEYWORD" keyValue="SOAP" tModelKey="uuid :A035A07C-F362-44DD-8F95-E2B134BF43B4"> </keyedReference> <keyedReference keyName="KEYWORD" keyValue="XML" tModelKey="uuid :A035A07C-F362-44DD-8F95-E2B134BF43B4"> </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>
</tModelBag>
6.5
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 conance, 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 an 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 Dnition
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 dnit 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 eectuer 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 direntes implmentations serait dicile. Si lexpditeur et le destinataire dun message peuvent partager et comprendre le mme chier 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 spci dans un document XML et import dans direntes combinaisons pour crer une description de service Web nale, ou ils peuvent tous tres dnis ensemble dans un seul document. Les dnitions de type de donnes dterminent la structure et le contenu des messages. Les oprations abstraites dterminent les oprations eectues sur le 35
contenu du message, et les services rendre dterminent le rseau de transport qui acheminera le message destination.
7.2
Les dnitions
La partie dnitions inclut les dnitions de types de donnes, les messages et les oprations abstraites, qui sont similaires aux dnitions dinterfaces en CORBA ou DCOM. Les messages peuvent avoir plusieurs parties et tre dnies avec un style dinteraction procdurale, orient document ou les deux. Les dnitions 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 dnis en CORBA IDL (Interface Denition Language) peuvent tre utiliss la place des schmas de dnitions XML. (Si un autre systme de dnition 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 chier, les noms despaces utiliss dans les chiers ne doivent pas se chevaucher. Les schmas associs sont utiliss pour valider les chiers, messages et oprations WSDL dnis. 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, dnitions de types de messages, oprations, transports.
7.4
Exemple WSDL (cf Figures 5.*)
Description dun service de mini annuaire de personnes. On pourra eectuer 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 dnition 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 Dnition
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 eet, les entreprises veulent dsormais permettre leurs partenaires daaires daccder directement aux fonctions de leur systme dinformation. Une nouvelle notion a t introduite, puisquelles veulent de plus que les dirents logiciels de gestion (ERP, SCM CRM) communiquent entre eux, on lappelle lintgration entre dirents 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 diuser 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 diuse 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 signie 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 dirents acteurs sur des standards.
8.3
8.3.1
EAI
Dnition
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 direntes 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 oertes 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

Dnition
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 dni comme un enchanement dactivits. Dans un page 40 de 48
processus mtier, on tient compte des dirents 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 dnissant des rgles mtier, des rgles de scurit, des rgles de transactions. On peut ensuite lancer lexcution du modle (automate tats nis) et vrier le fonctionnement thorique des dirents 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 dnit une collaboration entre plusieurs entreprises (partenaires), sous la forme dchange de messages. Un dialogue comprend : La dnition des messages changs entre partenaires ; Le squencement de ces messages ; Les rles des dirents 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 : dnition du dialogue prcisant linteraction entre les participants du processus e-business. Elle est commune tous les participants. Deux interfaces prives (une par partenaire) : dnition 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 spcications sont apparues au printemps 2001. Il dnit 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 spcie 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, an 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 orir ses applications lextrieur aura ncessairement besoin des web services explique Didier Martineau, le directeur des services de lditeur de logiciels XML Software AG. En eet, 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 abilit 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 an de permettre une meilleur scurit et une bonne abilit. Parmis les stratgies utilises on peut citer celles-ci :
9.1.1
Authentication
Lauthentication consiste mettre en place un systme de login et de mot de passe an didentier lentit qui tente de se connecter au systme. Lauthentication permet de : 1. vrier si lutilisateur est connu du systme ; 2. dterminer les droits et privilges aects 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. Lauthentication 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 ltres qui ne laissent transiter que les ux autoriss. Dans un contexte dintgration de services, aprs lauthentication dun utilisateur ou dune interface, le systme permettra a chacun dassumer ses rles.
9.1.3
Mcanisme dencryptage et de dcryptage des donnes
An 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 lauthentication 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 didentier les entits mettrices de messages.
9.2
Scurisation des services Web
Les Web Services ne supportent pas explicitement les mcanismes de scurit. An de scuriser les Web Services il faudrait commencer par scuriser linfrastructure informatique puis scuriser spciquement 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 identication 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 vrie la bonne identit de lexpditeur(authentication). SSL utilise le concept de certicat pour lauthentication : Voici un petit exemple 1. Supposons un consommateur A et un site proposant des services B ; 2. A envoit son certicat B. Ce certicat 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 vrie, 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 ecace en ce qui concerne la scurit mais pse beaucoup sur les performances. page 44 de 48
9.2.3
Authentication et contrle daccs
Lauthentication consiste vrier lidentit de lmetteur dun message. On dit que que lauthentication ncessite des informations didentication : un mot de passe peut tre information didentication. Le systme vrie ces informations didentication et si elles sont valides authentie lentit. Cest seulement aprs cette authentication 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 dauthentication 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 an de les protger en ce qui concerne la condentialit. Pour cela il existe plusieurs moyens : Encrypter le corps du mesage SOAP ; Utiliser SLL pour encrypter le trac 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 certicat. 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. Lauthentication 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 Specications
La spcication XKMS ore une infrastructure de gestion es cls publiques an de gnraliser lutilisation de XML Signature. Pour faciliter lemploi et le dveloppement de XML Signature, il faut fournir des entits de conance qui supportent la gestion de cls publiques, et plus seulement se limiter lutiliqation de certicats qui est trs contraignante. Dans cette approche, on identie un service Web de conance qui ore une implmentation dun service XKMS permettant : denregistrer une paire de cls et dobtenir en contrepartie un certicat. 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 dnit des formats de messages XML et un vocabulaire pour vhiculer des informations qui composent une procdure dauthentication. 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 dauthentication, la source dauthentiction et le sujet authenti. Habilitation : Il sagit dun document XML sign dcrivant les renseignements relatifs aux autorisations dun sujet identi. Lhabilitation suit lutilisateur dun domaine lautre pendant tout le cours dune transaction.
9.3.4
WS-Security
Cette spcication 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 lauthentication 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 spcication de divers mcanismes : le couple identiant/mot de passe, la mthode du jeton de scurit et celles des certicats notamment. "Concrtement, WS-Security dnit la manire de dcrire au sein dun message SOAP les droits utilisateur correspondant ces dirents systmes de scurit". Comment viter que la connexion entre deux Web Services ne soit "sur coute" ? Ici, entre en jeu le chirement et la gestion de lintgrit des messages, pour lesquels le langage propose un vocabulaire de gestion de certicats : des outils qui peuvent tre utiliss aussi bien pour chirer 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 eet accessibles depuis Internet des fonctionnalits dune application exixtante tout en ne modiant 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 dnition de linterface standardsent la couche de transport. Les Web Services reposent sur des bases solides(SOAP et WSDL)qui ont prouv leur ecacit et leur maturit mme si un normalisation complte nexiste pas encore. Cette standardisation permet une grande interoprabilit entre des applications de technologie dirente : les protocoles SOAP, WSDL et UDDI permettent de simplier lutilisation des services auxquels ils sont lis par lutilisation de chiers 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 able 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 eet 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 rewall 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 denir 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 dierentes 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, abilit, performances, ...).
page 48 de 48

Rapport Web Services

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 Web Services

Transféré par

Droits d'auteur :

Formats disponibles

Universit de Nice-Sophia Antipolis

Licence dInformatique 3me anne

Les Web Services

Table des matires

9.3.2 9.3.3 9.3.4

Historique et Origine des Concepts

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

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

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

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

Rgles dcriture au format XML

Ce que XML va rendre possible

Les espaces de nommage(namespaces)

Les langages de prsentation (style) : CSS et XSL

Les langages de lien et dadressage

Lavenir prvisible de XML

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

Traduction dune structure

Traduction dune liste (ou tableau)

Un seul paramtre, val, de type xsd :int page 25 de 48

Donnes du registre UDDI (cf Figure 4.1)

Enregistrement de types de services

UDDI et SOAP (cd Figure 4.2)

Interagir avec XML

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

Sources : http ://developpeur.journaldunet.com/tutoriel /xml/021107xml_wsdl1b.shtml

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

Les processus mtiers

Les processus e-business

BPML (Business Process Modeling Language)

Scurit et abilit des Web Services

Mcanisme dencryptage et de dcryptage des donnes

Scurisation des services Web

Scurisation des connexions

Authentication et contrle daccs

Standards XML de scurit

XKMS XML Key Management Specications

SAML Security Assertion Markup Language

Evolution des Web Services

Vous aimerez peut-être aussi