Université de Nice-Sophia Antipolis Licence d’Informatique — 3ème année

Les Web Services

Rapport de TE

ÉtudiantsCyrielle LablancheFlorens SeineSébastien Gastaud

EncadrantHervé Chang

2004–2005

Table des matières

1 Introduction 11.1 Historique et Origine des Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Principes 52.1 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 RPC 93.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2 Principe de fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.3 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.4 Processus serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.4.1 Squelette calcul_server.c (cf Figure 1.2) . . . . . . . . . . . . . . . . . . . . 103.5 Processus client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.5.1 Squelette calcul_client.c (cf Figure 1.3,1.4,1.5) . . . . . . . . . . . . . . . . 103.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.7 Annexes RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 XML 164.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.2 Le prédécesseur de XML sur le Web : HTML . . . . . . . . . . . . . . . . . . . . . 16

4.2.1 Exemple de code HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.2.2 De HTML à XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.3 Règles d’écriture au format XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.4 Ce que XML va rendre possible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.5 Les ’espaces de nommage’(namespaces) . . . . . . . . . . . . . . . . . . . . . . . . 184.6 Les langages de présentation (style) : CSS et XSL . . . . . . . . . . . . . . . . . . . 194.7 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.8 Les langages de lien et d’adressage . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.9 L’avenir prévisible de XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.10 Annexes XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5 SOAP 225.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.2 Avantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.3 Appels de procédure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.4 SOAP et XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.5 L’enveloppe SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.6 Représentation XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.7 Modèle de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.7.1 Traduction d’une structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

i

5.7.2 Traduction d’une liste (ou tableau) . . . . . . . . . . . . . . . . . . . . . . . 255.8 Le modèle RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.9 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6 UDDI 276.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.2 Données du registre UDDI (cf Figure 4.1) . . . . . . . . . . . . . . . . . . . . . . . 27

6.2.1 Pages blanches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.2.2 Pages jaunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.2.3 Pages Vertes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.3 Enregistrement de types de services . . . . . . . . . . . . . . . . . . . . . . . . . . . 286.4 UDDI et SOAP (cd Figure 4.2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.4.1 API (Messages SOAP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286.4.2 Interagir avec XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286.4.3 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316.6 Annexes UDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

7 WSDL 357.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357.2 Les définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367.3 Les noms d’espace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367.4 Exemple WSDL (cf Figures 5.*) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367.5 Annexes WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

8 Web services et entreprises 398.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398.2 Construction d’un projet informatique . . . . . . . . . . . . . . . . . . . . . . . . . 39

8.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398.2.2 Etapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

8.3 EAI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408.3.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408.3.2 L’intégration d’applications . . . . . . . . . . . . . . . . . . . . . . . . . . . 408.3.3 Fonctions de l’EAI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

8.4 Les processus métiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408.4.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408.4.2 Dialogues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418.4.3 Les processus e-business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418.4.4 BPML (Business Process Modeling Language) . . . . . . . . . . . . . . . . 41

8.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

9 Sécurité et fiabilité des Web Services 439.1 Quels mécanismes veut-on mettre en place pour assurer la sécurité des Web Services ? 43

9.1.1 Authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439.1.2 Autorisation d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439.1.3 Mécanisme d’encryptage et de décryptage des données . . . . . . . . . . . . 439.1.4 Signature digitale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

9.2 Sécurisation des services Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449.2.1 Sécurisation de l’infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . 449.2.2 Sécurisation des connexions . . . . . . . . . . . . . . . . . . . . . . . . . . . 449.2.3 Authentification et contrôle d’accès . . . . . . . . . . . . . . . . . . . . . . . 459.2.4 Sécurisation de SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

9.3 Standards XML de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459.3.1 XML Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

ii

9.3.2 XKMS XML Key Management Specifications . . . . . . . . . . . . . . . . . 459.3.3 SAML Security Assertion Markup Language . . . . . . . . . . . . . . . . . 459.3.4 WS-Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

10 Conclusion 4710.1 Apports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4710.2 Limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4710.3 Evolution des Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4710.4 Enrichissement personnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

page iii de 48

Chapitre 1

Introduction

Selon la définition du W3C (World Wide Web Consortium), un Web service (ou service Web)est une application appelable via Internet - par une autre application d’un autre site Internet -permettant l’échange de données (de manière textuelle) afin que l’application appelante puisseintégrer le résultat de l’échange à ses propres analyses. Les requêtes et les réponses sont soumisesà des standards et normalisées à chacun de leurs échanges.

1.1 Historique et Origine des Concepts

Les Web services sont nés de l’effort de plusieurs organisations qui ont partagé un intérêt com-mun en développant et en maintenant "un marché électronique". Celles-ci souhaitaient pouvoircommuniquer plus simplement et sans avoir à se concerter sur chacune de leur transaction pourpouvoir interpréter leurs différentes données. Elles souhaitaient supprimer l’isolement de leur sys-tème informatique avec les autres

C’est ainsi que naquit en 1975 l’EDI (Échange de Données Informatisées). L’EDI peut êtredéfini comme l’échange, d’ordinateur à ordinateur, de données concernant des transactions en uti-lisant des réseaux et des formats normalisés. Il s’agit d’un format standard permettant l’échanged’un certain type de données. D’un développement assez semblable à la création du code Morse,EDI permettait à des personnes d’une langue donnée d’envoyer des messages via câble à desinterlocuteurs similaires situés dans un autre lieu. L’EDI permet l’entente entre les différentesapplications sur la modélisation des échanges et sur les protocoles de communication. L’EDI al’avantage de ne pas avoir à retaper les données. Elle permet donc un gain de temps et d’argent,en réduisant les erreurs de saisie. L’EDI reste tout de même incomplète. Le système mis en placeest difficile à implémenter. Les techniques employées sont complexes et coûteuses.

Vers la fin des années 80, l’évidence fut que l’âge des systèmes informatiques isolés touchaità son terme tandis que différents ordinateurs, de tailles, de capacités et de formes variées, ap-paraissaient au sein d’une même organisation. Les départements informatiques voulurent bienévidemment exploiter au mieux et au plus bénéfique la précieuse puissance d’analyse qu’ils avaientà disposition. Il fallut donc rendre les applications informatiques capables de déplacer leurs tra-vaux, c’est-à-dire de procéder à un véritable traitement distributif.

Pour répondre à cette nouvelle situation, de nouvelles technologies apparurent telles queCORBA (Common Object Request Broker Architecture) ou la version qu’en fit Microsoft, le Com-ponent Object Model (COM). CORBA, est une architecture logicielle, pour le développement decomposants. Ces composants, qui sont assemblés pour la construction d’applications complètes,ont la possibilité d’être écrits dans des langages de programmation différents, d’être exécutés dans

1

des processus dissociés, voire d’être déployés sur des machines distinctes. Les composants CORBAutilisent une approche essentiellement orientée objet (du point de vue d’un langage de programma-tion, toutes les méthodes sont virtuelles, il n’y a pas de polymorphisme paramétrique, ni méthodesprotégées ou privées, ni surcharge d’opérateurs, ni fonctions de première classe).Chaque composant est décrit sous la forme d’une interface écrite en langage IDL (Interface Des-cription Language) qui est un langage permettant de définir l’interface de composants logiciels(IDL permet donc de faire interagir des modules développés dans des langages distincts). Unecorrespondance a été introduite entre le langage IDL et plusieurs langages de programmation. Despré-compilateurs spécifiques sont capables de générer automatiquement la structure de l’interfaceIDL dans un langage précisé. Ils produisent aussi le code qui garantie le transfert et la réponsedes appels de fonctions distantes (appelées skeleton et stub). Un module dont l’interface est pré-sentée en IDL pourra ainsi être implémenté en C++, alors que les modules Java qui l’utiliserait,effectueraient des appels sur une interface Java générée à partir de la même présentation IDL.L’architecture CORBA assure l’acheminement des appels entre les processus.Les applications et les composants CORBA associent typage statique et dynamique, ainsi, chaquecomposant est présenté statiquement par une interface mais les composants qui utilisent celui-cidoivent vérifier dynamiquement que l’interface est effectivement implantée. L’inconvénient majeurde cette méthode est qu’elle nécessite une reprogrammation continuelle des architectures suivantles organisations qui l’utilisent. Ce qui implique une perte de temps, et d’argent à chaque chan-gement d’application puisque tout doit être reprogrammé pour aller dans le sens de la nouvellearchitecture.

Les années 90 furent témoin non seulement de la recrudescence des ordinateurs personnels,mais aussi du décollage phénoménale d’Internet avec une demande grandissante de standards sus-ceptibles de travailler sur n’importe quelle plateforme.A la fin des années 90, l’e-speak d’Hewlett Packard fit son apparition en même temps que XML.HP voulait ainsi concurrencer l’e-business d’IBM qui par leur campagne de publicité retentissantedonnait la forte sensation d’être les inventeurs du système d’e-services utilisant les protocolesétablis comme l’HTTP et XML pour permettre de passer outre les différences entre les diverssystèmes coexistants dans un même réseau. Sans le savoir, les services Web étaient nés. L’e-speakpassa pratiquement inaperçu, seuls quelques observateurs s’en souvinrent. Microsoft et IBM avaitdéjà pensé à une alternative grâce à EDI. Ils tentèrent de coder des transactions EDI en XMLpour permettre de facilité les relations interentreprises grâce au Web. EDI réussit à survivre grâceà ses notions de sécurité qui faisait énormément défaut aux services Web. Un nouveau standardétait né : ebXML.

A peu près à la même époque, un regroupement d’organisations recherchant une façon de struc-turer et d’échanger des documents XML créa un protocole appelé Simple Object Access Protocol(SOAP) qui permet la transmission de messages entre applications distantes, ce qui veut dire qu’ilautorise un objet d’une application à invoquer des méthodes d’objets physiquement situés sur uneautre machine et pouvant être codé par une autre application. Le transfert se fait le plus géné-rale grâce au protocole HTTP, mais peut tout aussi bien se faire par d’autres protocoles, commeSMTP. Le protocole SOAP se compose d’une partie qui joue le rôle d’enveloppe contenant desinformations sur le message lui-même afin de permettre son transfert et son traitement, et d’unepartie qui joue le rôle de modèle de données, caractérisant le format du message, c’est-à-dire lesinformations à transférer. Le SOAP a été conçu à partir des concepts qui avaient produit, entreautres, des technologies comme CORBA et EDI, en lui ajoutant les composants XML et HTTPde telle façon que les applications puissent interagir entre elles, même à travers les firewalls desentreprises. Le SOAP a été largement accepté, probablement grâce à ce que son nom vante : sasimplicité. Le SOAP ne définit au final aucune sémantique, il ne fait que livrer une programmationdans une enveloppe protectrice, sans se préoccuper de son type. On peut donc l’assimiler dans cesens à un messager discret qui - se doutant peut-être que le contenu de son paquet est important- mènerait quoi qu’il arrive à bien son devoir de livraison à la personne certifiée pour analyserce qu’on lui apporte. On peut affirmer que c’est avec SOAP que le concept de services Web est

page 2 de 48

définitivement apparu renforcé par la création de WSDL (Web Services Description Language) quidonne la description au format XML des Web Services.

Aujourd’hui, les services Web provoquent un intérêt certain auprès des architectes et des dé-cideurs. Dès à présent, les Web Services sont sortis du champ des échanges interentreprises pours’adapter à celui du référencement et de la mise à disposition des ressources de l’entreprise, empié-tant en ce sens sur les technologies de type EAI. Cette utilisation à elle seule prouve la qualité dumodèle et sa pérennité, notamment au niveau des couches les plus basses. Par contre, la normalisa-tion complète d’une architecture distribuée construite sur les Web Services n’est pour l’instant pasencore tout à fait établie. Par ailleurs, ce modèle n’échappe pas à des problèmes de performance :les données sont transférées en ASCII dans une encapsulation XML elle-même intégrée dans uneenveloppe SOAP puis HTTP... Le problème du choix de la bonne granularité du service, communà toutes les architectures distribuées, se présente dans le cas des Web Services de manière plusaiguë encore. Même si ils n’ont pas acquis la maturité nécessaire à leur industrialisation, les Webservices se présentent plus que jamais comme la solution appropriée aux problématiques d’échangede données et d’intégration d’applications.

1.2 Motivations

Un Web service est un mécanisme qui tend à donner plus d’interactions pour permettre à deuxentités hétérogènes (entreprises, clients, applications, etc. ...) de dialoguer au travers du réseauInternet. Les logiciels écrits dans divers langages de programmation (C#, Visual Basic, Java, etc....), sur diverses plateformes (Linux, Windows, etc. ...) et avec diverses architectures peuvent em-ployer des services Web pour échanger des données à travers des réseaux informatique. ChaqueWeb service doit pouvoir être découvert et invoqué dynamiquement par les applications.

Les aspects purement pratiques n’ont eux rien de fondamentalement novateurs. Au contraire,l’architecture des services Web s’est imposée (tout comme le langage XML) grâce à sa simplicité,à sa lisibilité et à ses fondations normalisées. L’objectif principal des services Web est de faciliterle plus possible l’accès aux applications entre entités et ainsi de simplifier les échanges de données.Cette interopérabilité est due à l’utilisation de normes ouvertes. L’OSI et le W3C sont les comi-tés de coordination responsables de l’architecture et de standardisation des services Web. Pouraméliorer l’interopérabilité entre les réalisations de service Web, l’organisation WS-I a développéune série de profils pour faire évoluer les futures normes impliquées. L’aspect le plus importantdes Web Services est qu’ils reposent sur plusieurs standards qui permettent la structuration desarchitectures. Cette collection de normes et de protocoles est appelée Web Services Protocol Stack.Elle contient entre autre XML et SOAP pour le formatage des données, WSDL pour la descriptiondes services Web et UDDI pour la recherche des services Web nécessaire au bon fonctionnementdes applications.

Une des raisons principales pour lesquelles les services Web sont employés semble être qu’ils sefondent sur le Internet et HTTP pour fonctionner. Pour comprendre ceci, il faut garder à l’espritque beaucoup d’organisations se sont protégées en employant des firewalls qui filtrent et bloquentbeaucoup de trafic d’Internet pour des raisons de sécurité. Dans ce milieu, beaucoup de ports(voire quasiment tous) sont fermés au trafic entrant et sortant, et les administrateurs des réseauxn’ont pas l’envie de les ouvrir. Il en est un qui par contre est toujours ouvert, celui des navigateurspar lequel transite le protocole HTTP. De cette façon les applications peuvent continuer à interagirentre elle et ce sans modifier la configuration de sécurité des organisations.

Si l’on devait résumer les raisons de la création des services Web, les qualificatifs tels que lasimplicité des échanges, l’amélioration de la communication entre les applications en seraient lespoints principaux. En ajoutant à cela l’interopérabilité des programmes indifféremment de leur

page 3 de 48

langage et de leur plateforme, les services Web nous prouvent une nouvelle fois que leur technologieest très attrayante. Le véritable point fort du concept c’est la normalisation des données au traversde standards connus et acceptés par tous.

Fonctionnement globale d’un échange de données grâce aux services Web :

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

1. L’application construit sa requête et la normalise grâce aux standards.2. Le service Web traduit la requête, recherche l’application nécessaire.3. Les données sont traitées.4. Le service Web normalise la réponse de la requête et envoie le résultat vers l’application

appelante.5. Les données réponses sont reçues par l’application. Elles peuvent directement être interpré-

tées.

page 4 de 48

Chapitre 2

Principes

Les motivations de simplicité et d’interopérabilité pour les services Web impliquent une struc-ture bien huilée pour un fonctionnement facilité et efficace. Les protocoles des services Web re-posent donc sur des organisations et des architectures prédéfinies.

2.1 Organisation

La normalisation actuelle autour des Web Services est cependant une organisation complexequi va bien au-delà de la simple invocation d’une méthode d’un objet distant. Différents travauxont ainsi démarré pour permettre d’établir une véritable infrastructure distribuée, capable de sa-tisfaire l’ensemble des besoins d’une application distribuée, aussi bien en terme de normalisationdes échanges qu’en terme de services transverses.

Cette organisation par comités de normalisation peut être schématisée selon le découpagematriciel suivant :

– Cette normalisation des services transverses se fait sur trois axes horizontaux :

– Couche de transport : Définition de la structure des messages utilisés par les applicationspour se découvrir et dialoguer entre elles. Cette couche est à l’heure actuelle la seule réel-lement normalisée et qui ne souffre d’aucune contestation. Elle s’appuie sur le protocoleSOAP pour l’échange des messages et sur le langage WSDL pour la définition du contratde l’interface.

– Couche de sémantique : Normalisation des données participant aux échanges selon descritères métier. Les initiatives de définition de la couche de sémantiques des messages sontnombreuses et n’ont pour le moment pas conduit à une quelconque normalisation. Deuxtypes d’organisation sont actuellement ouverts, l’une établie selon les différents corps demétier, l’autre 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 métier quis’étendent sur plusieurs applications disponibles sur Internet. L’orchestration de transac-tions B2B (Business to Business) complexes, fondée sur une architecture normalisée desmessages est aussi une tentative qui n’avance pas assez rapidement et sur des standardsnon murs.

– Cette normalisation des services transverses de fait aussi sur trois axes verticaux :

5

– Service d’annuaire : Standardisation des moyens d’accès à un service à partir d’une re-quête portant sur le contenu d’un service ou sur un fournisseur. La première propositiond’annuaire UDDI aurait du apporter une solution définitive. Le constat est qu’il n’en estrien et que la trame, trop globale, du projet ne suffit pas à régler cette problématiqued’échanges entre applications se connaissant. Une deuxième proposition d’annuaire, WS-Inspection, vient concurrencer celle-ci. Moins ambitieuse puisque consistant en une simpleexposition, par agrégation, des services d’une application, elle est toutefois plus adaptée àcette seconde problématique.

– Service de sécurité : Normalisation des moyens permettant de couvrir les problématiquesd’authentification et de gestion des droits d’accès. La gestion de la sécurité est actuelle-ment le frein le plus important à la mise en place d’architectures distribuées à base de WebServices. Plusieurs organisations sont ouvertes mais aucune n’est réellement acceptée. Ilsemblerait que la norme XACML (eXtensible Access Control Markup Language) puissesupplanter SAML (Security Assertion Markup Language) et s’imposer à terme commestandard de sécurité.

– Service de transaction : Normalisation des moyens permettant de garantir l’intégrité destransactions longues impliquant plusieurs Web Services. Le problème reste le même quepour la sécurité. Les standards ne sont pas tout à fait établis. La lutte pour l’obtentiond’une norme est beaucoup plus ouverte que pour celle de la sécurité, même si BTP (Bu-siness Transaction Protocol ) semble plus soutenu actuellement.

Modélisation de la normalisation transverse que les différents axes :

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

2.2 Architecture

Pour comprendre le fonctionnement d’une architecture de services Web, il faut commencer parrevoir certains principes. Si l’on reprend la définition de Mark Colan, Web Service and XML ChiefAdvocate chez IBM, les Web Services sont des "applications modulaires basées sur Internet quiexécutent des tâches précises et qui respectent un format spécifique". Ce sont donc des unitéslogiques applicatives qui sont accessibles grâce au protocole Internet. Une définition conceptuelledu terme service Web mettrait en avant les qualités d’une fonctionnalité commerciale présentéepar une entité hétérogène quelconque sur Internet afin de fournir un moyen d’user de ce serviceà distance. Pour l’aspect opérationnel, les services Web ne sont que des applications modulairesqui peuvent être présentées, publiées, situées et invoquées dans un réseau et ce automatiquement.Ainsi, les applications peuvent faire appel à des fonctionnalités situées sur d’autres machines dansd’autres applications. Au final, on peut affirmer que le but initial d’un service Web est de rendrepossible l’utilisation d’un composant applicatif de façon distribuée.

page 6 de 48

L’apport majeur de ce modèle d’échange de données est d’introduire ces services comme des"boîtes noires". En effet, les requêtes-réponses d’un service Web sont administrées dans le contenude messages dont on sait la forme grâce à des interfaces clairement présentées et sur lesquellesl’implémentation interne du traitement et le langage employé ne jouent pas au niveau de l’archi-tecture. Grâce à cela on obtient un haut niveau de modularité et d’interopérabilité. Ce modèlede message permet donc d’oublier la structure, le langage ou encore la plate-forme qui va porterle service : il suffit juste que le message suive une architecture donnée pour qu’il puisse être analysé.

Il s’agit maintenant d’identifier chaque acteur de ses Web services et de comprendre commentils interagissent les uns avec les autres. Les trois éléments les plus importants des services Web sontles fournisseurs de service, les annuaires de services et les consommateurs de service. Le fournisseur(ou serveur) crée le service Web et publie toutes ces caractéristiques dans l’annuaire de service.L’annuaire rend disponible les interfaces d’accès aux service et donnant le contrat et l’architec-ture employée pour permettre les interactions. Le consommateur (ou client) quant à lui, accèdeà l’annuaire pour rechercher les service Web dont il a besoin et avec lui les normalisation à ob-tenir. Il peut ainsi envoyer ses requêtes au service désiré et obtenir les réponses qu’il pourra analysé.

Cette architecture fonctionne de la manière suivante :

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

1. Le client envoie une requête à l’annuaire de Service pour trouver le service Web dont il abesoin.

2. L’annuaire cherche pour le client, trouve le service Web approprié et renvoie une réponse auclient en lui indiquant quel serveur détient ce qu’il recherche.

3. Le client envoie une deuxième requête au serveur pour obtenir le contrat de normalisationde ses données.

page 7 de 48

4. Le serveur envoie sa réponse sous la forme établie par WSDL en langage XML.5. Le client peut maintenant rédiger sa requête pour traiter les données dont il a besoin.6. Le serveur fait les calculs nécessaires suite à la requête du client, et renvoie sa réponse sous

la même forme normalisée.

page 8 de 48

Chapitre 3

RPC

3.1 Définition

La programmation utilise de nos jours couramment l’appel de fonctions, c’est pourquoi cemécanisme s’applique désormais dans des applications distribuées. Les appels se font ainsi sur desmachines distantes, expliquant ainsi le nom de «Remote Procedure Call».Le système RPC est utilisé pour toutes sortes d’applications client / serveur. On peut prendre enexemple l’utilisation d’un ordinateur à effectuant des calculs spécifiques. Celui-ci servira donc deserveur et un autre ordinateur de client qui appellera la procédure distante pour que le serveureffectue les calculs et que le client récupère les résultats.

Il existe de nombreux systèmes RPC, ce qui n’encourage pas la compatibilité. Un standard sedémarque cependant, le «Sun RPC» développé par Sun Microsystems. En effet, ses spécificationssont dorénavant dans le domaine public. Son but est de servir de base au système NFS ( NetworkFile System ), très utilisé sous Linux.

3.2 Principe de fonctionnement

Le système RPC est transparent pour le programmeur, c’est-à-dire que la sémantique habituelleest respectée. La fonction locale à très souvent le même nom que la fonction distante. Mais celle-ci appelle en réalité d’autres fonctions de la librairie RPC prenant en charge les connexions,paramètres et résultats. Du côté serveur, c’est sensiblement le même principe exepté pour l’attentedes clients, le renvoi des résultats, etc. La prise en charge des connexions réseaux se fait parl’intermédiaire de fonctions dites «stub». Ainsi il faut rajouter au programme client et à la fonctiondistante un stub pour le client et le serveur.

La construction des «stubs» peut être automatisée par le programme «rpcgen» produisant ducode C.

3.3 Interface

On utilise l’IDL (Interface Definition Language) de RPC. Il sert ‘a la sp’ecification des interfacesentre les clients et les serveurs.Description d’une fonction distante poss’edant 2 paramètres, rend la somme ainsi qu’un coded’erreur (cf Figure 1.1).

Cette définition est enregistrée dans le fichier calcul.x. Il contient une description : ici, le pro-gramme s’appelle CALCUL, il est en version VERSION_UN et contient deux procédures CAL-CUL_NULL et CALCUL_ADDITION.

9

Le numéro de CALCUL (ici 0x20000001) identifie le programme de manière unique dans lemonde. C’est notamment le cas pour le daemon NFS. Dans notre cas, le numéro est choisi dansl’intervalle allant de 0x20000000 à 0x3FFFFFFF, réservé pour les utilisateurs. Il ne peut donc pasentrer en conflit avec des programmes tournant déjà sur la machine.

Chaque procédure à un nom et un numéro. La procédure de numéro 0 (ici CALCUL_NULL)est toujours requise. Elle sert de «ping» ou de procédure de test.Le système RPC n’accepte qu’un seul argument en paramètre et en retour – c’est pourquoi onutilise des structures.Le programme rpcgen consomme ensuite ce fichier de définition :

> rpc –a calcul.xL’option -a permet de produire un squelette pour le client (calcul_client.c) et le serveur (cal-

cul_server.c). calcul.h (entête), calcul_clnt.c (stub client), calcul_svc.c (stub serveur) et cal-cul_xdr.c (routines XDR) sont également produits.

Le format XDR (eXternal Data Representation) définit les types utilisés pour l’échange de va-riables entre le client et le serveur. Cela permet d’adapter le programme sur différentes plateformes.Ainsi, tous les types utilisés sont filtrés par XDR.

> gcc -c calcul_xdr.cLes stubs fournis sont complets.> gcc -c calcul_clnt.c> gcc -c calcul_svc.c

3.4 Processus serveur

3.4.1 Squelette calcul_server.c (cf Figure 1.2)

On peut remarquer quelques différences. RPC travaille sur des pointeurs pour accélérer ledéroulement du programme (pas de copie). On travaille sur des variables déclarées «static» car ondoit passer l’adresse d’une variable existant encore après la fin de la fonction.

La fonction «main» est située dans le stub serveur. Il s’occupe de recevoir et de distribuer lesappels de fonctions.

> gcc -c calcul_server.c> gcc -o server calcul_svc.o calcul_server.o calcul_xdr.o

3.5 Processus client

3.5.1 Squelette calcul_client.c (cf Figure 1.3,1.4,1.5)

Des variables sont déclarées pour les arguments et les valeurs de retour. Chaque appel de pro-cédure est suivi d’un test qui détecte les erreurs de niveau «RPC» (serveur ne répondant pas,machine inexistante, etc.). L’erreur éventuelle est alors explicitée par la fonction clnt_perror().Quand une erreur de niveau «RPC» se produit, le pointeur renvoyé est NULL. Cette valeur (non-valeur plutôt !) est réservée à RPC ; donc pour un niveau d’erreur autre que RPC, la valeur deretour ne doit pas être NULL.

Pour faire un vrai programme, il nous faut donner des valeurs aux paramètres et il faut utilisereffectivement les résultats 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 10Resultat : 4294967290Addition avec 4294967295 et 10Overflow

>

Le client prend en paramètre le nom de la machine serveur (ici localhost car le processus ser-veur a été démarré sur la même machine). Le nom peut être court (machine) pour une machinedu même domaine que le client ou complet (machine.domaine.com).

3.6 ConclusionAujourd’hui des systèmes plus perfectionnés ont fait leur apparition comme par exemple

CORBA. Les RPC peuvent être considérés comme les ancêtres de CORBA car il ne s’agit plus defonctions mais d’objets distants servant à la programmation orientée objet.

3.7 Annexes RPCSources : 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 l’addition

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 Définition

XML (Extensible Markup Language, ou Langage Extensible de Balisage) est le langage destinéà succéder à HTML. Comme HTML (Hypertext Markup Language) c’est un langage de balisage(markup) : il représente de l’information encadrée par des balises. XML est un métalangage, cequi veut dire que contrairement à HTML qui possède un ensemble de balises de présentation pré-définies, il va permettre d’inventer de nouvelles balises d’isolement d’informations ou d’agrégatsélémentaires que peut contenir une page Web.

XML a avec HTML un ancêtre commun : le SGML (Standard Generalized Markup Language).L’une de ses caractéristiques était la séparation du formatage et du contenu. En effet, le formatdécrit indépendamment du contenu du document permettait d’obtenir un rendu identique pourune feuille de n’importe quel format. Ce principe est appliqué dans le sens où les données et leschéma du document sont séparés, le schéma représentant la structure et les types de données,incluant la sémantique ( importante pour que le document puisse interagir avec différents langagesde programmation et systèmes ).

4.2 Le prédécesseur de XML sur le Web : HTML

4.2.1 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>

<->Résultat

16

Bibliotheque

• Victor Hugo, Les miserables, 1995, Dupond, Paris• Frederic Beigbeider,Windows on the world, 2004, Fayard, Paris

Toutes les balises d’une page HTML ne sont relatives qu’à sa présentation. Rien ne permet àun logiciel de connaître le sens (la sémantique) du texte autrement dit, dans notre exemple, desavoir que Victor Hugo est l’auteur d’un livre intitulé Les misérables, que Windows à été édité en2004 par Fayard, etc.

4.2.2 De HTML à XMLred < ?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=’général’><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 décrit la présentation finale. On remarque, en revanche, que mainte-nant les balises ont un sens et une hiérarchie. Par exemple, l’élément ’AUTEUR’ comprend leprénom (balise ’PRENOM’) et le nom (balise ’NOM’) de l’auteur. On remarque aussi que des in-formations supplémentaires (langue, sujet, n◦ ISBN), ont pu être ajoutées sous forme d”attributs’situés à l’intérieur même des balises (cf Figure 2.1).

4.3 Règles d’écriture au format XML– Les informations doivent être :

– Encadrés obligatoirement par des balises ouvrantes et fermantes. Ces éléments ne doiventpas se chevaucher. Les éléments vides sont permis, selon le format<ELEMENTVIDE/>.

page 17 de 48

– Soit incluses à l’intérieur même des balises : on parle alors d’attributs. Exemple :<LIVRESUJET=’XML’>. Ici l’attribut SUJET de l’élément LIVRE a la valeur ’XML’.

– Soit encore définies sous forme d’entités. Les entités sont des abréviations. Par ex ; si ’Ex-tensible Markup Language’ est déclaré comme une entité associée à la notation ’xml’ ;cette chaîne de caractères pourra être abrégée en ’&xml ;’ dans tout le fichier XML. Uneentité peut aussi représenter un fichier XML externe tout entier. Ainsi un même fichierXML (par exemple notre bibliographie) pourra être utilisé par plusieurs pages XML dif-férentes (par exemple une page spécifiquement consacrée à XSL pourra présenter à la finla bibliographie spécifique d’XSL extraite automatiquement de notre bibliographie XML)

– La DTD (Définition de Type de Document). La structure arborescente du document XML(intitulé des balises, imbrications des balises, caractère obligatoire ou facultatif des baliseset de leur ordre de succession. . .) peut être déclarée formellement dans le corps du docu-ment XML ou dans un fichier à part. Cette déclaration s’appelle une Définition de Type deDocument (DTD). Elle s’effectue selon un formalisme particulier défini lui-aussi dans la spé-cification XML. En XML cette déclaration est facultative, ce qui donne une grande souplesseaux développeurs. On n’écrira donc une DTD que lorsqu’il y aura vraiment intérêt à le faire(par exemple pour contraindre la saisie/mise à jour du document XML)

Lorsqu’un document XML possède une DTD associée et la respecte, on dit qu’il est valide.Lorsqu’il respecte seulement les règles de la grammaire XML (balises fermées, correctement im-briquées. . .) on dit qu’il est bien formé.

La spécification XML se trouve à l’adresse 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 présentation ou des traitements futurs,– sans avoir à saisir des libellés tels que ’auteur’, sans avoir à mettre les titres en italique.

– Et d’en générer ensuite automatiquement :– de multiples présentations (en tableau, en texte suivi. . .)– avec éventuellement tris, sélections, réorganisations, génération automatique de libellés,

tables des matières, index, etc.– et ce sur de multiples médias (écran, papier, terminal Braille, etc.)

– aux logiciels de comprendre/exploiter au mieux le contenu de ces pages, rendu désormaisexplicite par un balisage spécifique, indépendant de toute application.

4.5 Les ’espaces de nommage’(namespaces)

Cela va permettre de lever les ambiguïtés éventuelles concernant les balises. Le titre peut êtreaffecté à un livre comme à une personne par exemple. Ce mécanisme va nous permettre de lesdifférencier avec ’personne :titre’ et ’biblio :titre’. Ces préfixes doivent être associés à 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 préfixées sont censées se rapporter à l’espace de nommage par défaut, soit

page 18 de 48

l’URL fictive http ://www.biblio.org/vocabulaire tandis que les balises préfixées par ’perso :’ serapportent à l’espace de nommage associé à ’http ://www.personel.org/profils/’.

4.6 Les langages de présentation (style) : CSS et XSL

Le document XML va être balisé uniquement en fonction de son contenu et donc de sa séman-tique, tout ceci indépendamment de la restitution dont il fera l’objet sur papier, terminal, synthèsevocale, etc. ainsi que tout autre traitement automatique qui pourra lui être appliqué.

Cela va lui conférer :– l’ interopérabilité– la durabilité/réutilisabilité (le document pourra être utilisé ne deviendra pas obsolète avec

l’évolution des techniques informatiques ; il pourra sans difficulté être incorporé, en tout oupartie, dans des documents de nature très différente, être traité par des applications nonprévues, voire non-existantes au départ...).

En ce qui concerne sa restitution, l’utilisation du langage de transformation normalisé XSLT(XSL Transformation) va permettre de transformer une DTD ’orientée contenu’ en une autreDTD ’orientée restitution’ (c’est-à-dire constituée d’objets formateurs’). L’ordre de restitution fi-nal y sera établi (par exemple, classement de la bibliographie, mise en forme de certaines lignes,g’en’eration de tables des mati‘eres, liens (logiques) de navigation, etc.). Le niveau d’indépendanceau niveau du support est conservé.La spécification à XSLT se trouve ‘a l’adresse http ://www.w3.org/TR/WD-xslt.Le langage normalisé de feuille de style XSL (Extensible Style Language) va permettre ensuite despécifier comment un type de document (DTD ’orientée restitution’) donné va être restitué surun support donné. C’est à ce niveau que seront réglés les problèmes de ’saut de page’, les ’pied depage’, les liens de navigation, etc.La spécification de XSL se trouve à l’adresse http ://www.w3.org/TR/WD-xsl.

Appel d’un feuille de style XSL :

red < ?xml-stylesheet href=’biblio.xsl’ type=’text/xsl’ ?>

Le langage normalisé de feuille de style CSS (Cascading Style Sheets) déjà 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 définir des contraintes en matière desyntaxe, de structure et de valeurs applicables à une classe de documents HTML. Il va permettreentre autres choses d’effectuer des contrôles de validité lors de la saisie/mise à jour de documentsXML (exactement comme pour la saisie/mise à jour d’une bases de données). Par exemple, dansle cas de notre bibliographie, XML Schema va permettre de déclarer que l’élément DATEPUBdoit être une date limitée à l’année, 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 données (Datatypes) : http ://www.w3.org/TR/xmlschema-2/

Le Modèle objet de document est un langage normalisé d’interface va permettre à un pro-gramme Java par exemple de naviguer dans un arbre XML (ou HTML) et d’en lire ou d’enmodifier le contenuUtilisation :

red Livre = Doc.documentElement.firstChild ;Sujet = Livre.getAttributeNode(’SUJET’).text ;Auteur = Livre.selectSingleNode(’AUTEUR’) ;Auteur = Auteur.nextSibling ;

La spécification 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 d’adressageLes mécanismes de lien (linking) et d’adressage associés à XML sont en cours de spécification

au sein de trois documents :– XPath (XML Path Language). XPath est le langage d’expression de chemins à l’intérieur

d’un document XML, destiné à être utilisé à la fois par XSLT et par Xpointer. Sa spécificationse trouve en http ://www.w3.org/TR/xpath

– XPointer (XML Pointer Language). XPointer est le langage d’adressage des contenus d’undocument XML. Sa spécification se trouve en http ://www.w3.org/TR/WD-xptr

– XLink (XML Linking Language). XLink spécifie les indications à insérer dans les ressourcesXML pour décrire des liens entre objets. Il utilise la syntaxe XML pour créer des structuresqui peuvent décrire non seulement des hyperliens unidirectionnels tels que ceux permis au-jourd’hui HTML mais aussi des liens plus complexes typés et à terminaisons multiple. Saspécification se trouve en http ://www.w3.org/TR/xlink

4.9 L’avenir prévisible de XMLIl est à prévoir que l’usage d’XML va déborder largement le WWW, en provoquant la conver-

gence de deux mondes informatiques jusqu’ici séparés ; celui des documents et celui des données.Il est très probable qu’il va de ce fait devenir très rapidement la lingua franca de l’informatique,parlée tout autant par les SGBD que par les outils de bureautique et de documentation, par leslogiciels de gestion aussi bien que par les applications techniques et scientifiques. Qu’il va rendrepossible une automatisation des activités administratives et logistiques sans commune mesure avecce que permettent les outils d’aujourd’hui. Et qu’il va considérablement simplifier l’Échanges deDonnées Informatisé (EDI).

4.10 Annexes XMLSources : http ://fr.wikipedia.org/wiki/XML

page 20 de 48

Fig. 4.1 – Le même fichier XML affiché par Microsoft Internet Explorer sans feuille de style sousforme d’arborescence dépliable et repliable (signes ’+’ et ’-’)

Fig. 4.2 – Exemple de présentation pour un fichier XML utilisé ici pour trier le tableau par année

page 21 de 48

Chapitre 5

SOAP

5.1 Définition

C’est un protocole de dialogue par appels de procédures à distance entre objets logiciels. Sasyntaxe d’utilisation est fondée sur XML et ses commandes sont envoyées sur Internet par l’inter-médiaire du protocole HTTP mais aussi SMTP et POP sous forme de texte structuré.

Il permet aux systèmes objets distribués de solliciter et d’obtenir des services rendus pard’autres objets, il est moins lourd à mettre en oeuvre que d’autres protocoles et c’est pour celaqu’il est de plus en plus adopté.

Le protocole SOAP est une note du Consortium W3C dont Microsoft fait partie, mais qui n’estpas spécifique à Microsoft et Windows. IBM a également participé à l’élaboration de ce protocole.De plus il existe des implémentations Java, et Borland vient déjà d’implémenter SOAP sous Win-dows dans Delphi 6 et sous Linux avec Kylix.

Bien qu’il soit utilisable avec d’autres protocoles de transport, HTTP est le plus courammentutilisé. Le deuxième standard, XML, utilisé pour la structuration des données sous forme de mes-sages est quand à lui le seul utilisé.

5.2 Avantages

Par rapport à tous les autres protocoles de RPC, SOAP est inter opérable, ainsi il est indé-pendant des plates-formes et langages de programmation.

L’autre avantage réside dans le déploiement des applications. Pour communiquer entre deux so-ciétés via Internet, il est très souvent désagréable d’utiliser autre chose que HTTP ou POP/SMTPà cause des Firewalls, qui doivent êtres reconfigurés engendrant ainsi des trous de sécurité. De plus,cela implique de longues négociations entre administrateurs réseaux.

5.3 Appels de procédure

Les appels de procédures à distance sont de deux types. Ils sont appelés middleware : RPC etORB (Object Request Broker), le second étant orienté objet.

22

Les approches sont différentes. En effet, avec ORB, le poste client suspend l’activité de l’ap-plication pendant le traitement des données par la méthode invoquée sur le serveur qui renvoieensuite sa réponse. RPC, au contraire, envoie un message au serveur (initiant le traitement decelui-ci) par un processus client qui suspend ses activités, ainsi l’application sur le poste clientcontinue, elle, de tourner. Un autre message est envoyé au processus client quand la procédureappelée s’achève.

5.4 SOAP et XML

SOAP repose sur une approche RPC, basée donc sur des messages dont le contenu est structuréen XML.

Exemple de requête HTTP contenant du code SOAP

L’envoi d’un message SOAP correspond à une requête HTTP POST

red POST /StockQuote HTTP/1.1Host : www.stockquoteserver.comContent-Type : text/xml ; charset="utf-8"Content-Length : nnnnSOAPAction : "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>

Réponse HTTP correspondante

redHTTP/1.1 200 OKContent-Type : text/xml ; charset="utf-8"Content-Length : nnnn

red<SOAP-ENV :Envelopexmlns :SOAP-ENV="http ://schemas.xmlsoap.org/soap/envelope/"SOAP-ENV :encodingStyle="http ://schemas.xmlsoap.org/soap/encoding/"/><SOAP-ENV :Body>

<m :GetLastTradePriceResponsexmlns :m="Some-URI"><Price>34.5</Price>

</m :GetLastTradePriceResponse></SOAP-ENV :Body>

</SOAP-ENV :Envelope>

Il s’agit ici de répondre à une requête SOAP (un message contenu dans une requête HTTP,donc) demandant au serveur le montant d’un prix. La définition d’une "enveloppe" SOAP est

page 23 de 48

obligatoire : elle caractérise le message SOAP. Une "enveloppe" SOAP se subdivise en un en-têtefacultatif et un corps obligatoire.SOAP est un protocole de communication d’ordinateur à ordinateur sous HTTP très simple, écriten XML. Il permet l’échange de données, quelque soit les systèmes d’exploitation. Les messagesSOAP sont des transmissions en sens unique d’un émetteur vers un récepteur.C’est maintenant un standard stabilisé et déjà employé.

5.5 L’enveloppe SOAP

Elle contient :– un en-tête optionnel qui est un mécanisme générique d’extension de SOAP.– un corps obligatoire avec un contenu structuré :

– traduction du modèle de données en XML– basé sur les schémas du W3C

5.6 Représentation XML

red< ?xml version="1.0" ?><env :Envelope

xmlns :env=="http ://schemas.xmlsoap.org/soap/envelope/"><env :Header>

< !– en-tête –></env :Header><env :Body>

< !– corps –></env :Body>

</env :Envelope>

5.7 Modèle de données– Types fondamentaux :

– Ceux des schémas du W3C (http ://www.w3.org/TR/xmlschema-2/)– Entiers, réels, chaînes de caractères, binaire, etc.– Dates, durée, URI, etc.

– Types composés :– énumération (une valeur parmi une liste)– Struct (compound) : accès nommé– Liste (array) : accès numéroté

5.7.1 Traduction d’une 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><prénom xsi :type="xsd :string">Florens</prénom>

</pers :personne>

5.7.2 Traduction d’une 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 n’importent pas –><x xsi :type="xsd :int">-34</x><x xsi :type="xsd :string">Bla bla bla</x>

</enc :Array>

5.8 Le modèle RPCUn appel de fonction (une opération dans la terminologie services web) est décrit par un

message SOAP particulier :– L’appel est représenté par une structure :– Le nom de la structure est celui de la fonction appelée– Chaque paramètre de l’appel est considéré comme un champ de la structure– Le résultat est représenté par une structure– Le modèle de fonction autorise 3 modes de passage pour les paramètres :

– Mode in : paramètre utilisé mais non modifié,apparaît seulement dans l’appel– Mode in/out : paramètre utilisé et modifié,apparaît dans l’appel et la réponse– Mode out : paramètre de retour uniquement, apparaît dans la réponse seulement

5.9 ExempleAppel 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 paramètre, val, de type xsd :int

page 25 de 48

Résultat de l’appel

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 renvoyée par la méthode : return (obligatoire en

SOAP 1.2)

page 26 de 48

Chapitre 6

UDDI

6.1 Définition

D’une manière générale, l’Universal Description Discovery and Integration est une interfaceXML regroupant d’autres services en ligne. C’est une norme d’annuaire de services Web appeléevia le protocole SOAP.Il contient les registres Internet globaux regroupant les services et descriptions business depuisseptembre 2000.D’autres services sont attendus ainsi que de nombreuses compagnies.Cette technologie doit être utilisée avec un pare-feu.Plus de 2000 entreprises sont enregistrées.Pour publier un nouveau service Web, il faut générer un document appelé Business Registry, ilsera enregistré sur un UDDI Business Registry Node (IBM, Microsoft et SAP en hébergent chacunun). Les nodes sont répliqués entre eux suivant un mécanisme analogue aux DNS.

6.2 Données du registre UDDI (cf Figure 4.1)

6.2.1 Pages blanches

– Nom du business– Texte de Description

Liste de chaînes de caractères de plusieurs langues– Informations

– Noms, Numéros de téléphone, fax, sites Web, etc– Identifications connues :

Liste d’identificateurs connus par DUNS, Thomas, et autres

6.2.2 Pages jaunes

Services organisés en catégories de business3 grandes parties en V1 :

– Industrie : NAICS (Codes industriels – Gouvernement US)– Produits/Services : UN/SPSC (ECMA)– Lieu : Classification géographique

La classification est implémenté comme des paires Nom-Valeur pour faire correspondre un identi-ficateur à une page blanche.

27

6.2.3 Pages Vertes

Ensemble d’informations décrivant comment faire du e-commerce avec ces compagnies.– Processus marquétiques– Descriptions des services rendus– Programmation, Plateforme, Implémentation– Catégorie de services

6.3 Enregistrement de types de services

– Nom d’espace où le type de service est décrit– Ce que les programmeurs doivent savoir pour utiliser le service– Identificateur pour le publicateur– Identificateur pour l’enregistrement du type de service appelé “tModelKey”

Utilisé comme signature par les sites Web implémentant ces services

6.4 UDDI et SOAP (cd Figure 4.2)

6.4.1 API (Messages SOAP)

Renseignements

Recherche Obtention de d’etailsfind_business get_businessDetailfind_service get_serviceDetailfind_binding get_bindingDetailfind_tModel get_tModelDetail

Publication

Sauvegarde Suppression Sécuritésave_business delete_business get_authTokensave_service delete_service discard_authTokensave_binding delete_bindingsave_tModel delete_tModel

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 n’importe quelle requête du schéma UDDI.

Exemple de retour d’informations sur Microsoft :red <find_business generic="1.0" xmlns="urn :uddi-org :api">

<name>Microsoft</name>

page 28 de 48

</find_business>

6.4.3 Implémentation

Exemple par l’intermédaiire d’un fichier JScript (code Java) une page HTML avec le contrôleXMLHTTP 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 n’accepte que les résultats texte/xml.On désactive la mise en cache pour avoir des résultats directs.On définit le SOAPAction dans le header http.

Le retour est du XML.Ici, on va obtenir une liste détaillée des éléments <businessInfo> actuellement enregistrés pourMicrosoft.

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 pourl’informatique personnelle et l’informatique d’entreprise,

nous nous efforçons de produire des produits et des servicesnovateurs qui répondent 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"> <name>SitesWeb UDDI</name>

</serviceInfo></serviceInfos>

</businessInfo></businessInfos>

</businessList>

page 29 de 48

On va maintenant essayer d’obtenir des informations sur le dernier service en reportant sabusinessKey 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é :

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"truncated="false" xmlns="urn :uddi-org :api">

<businessServicebusinessKey="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 UDDIbasées sur les messages SOAP/XML.

</description><bindingTemplates>

<bindingTemplatebindingKey="A9CAFBE4-11C6-4BFE-90F5-595970D3DE24"serviceKey="D2BC296A-723B-4C45-9ED4-494F9E53F1D1">

<description xml :lang="en">Serveur de production UDDI, Interface de demande d’information

</description><accessPoint URLType="http">

http ://uddi.microsoft.com/inquire</accessPoint><tModelInstanceDetails>

<tModelInstanceInfotModelKey="uuid :4CD7E4BC-648B-426D-9936-443EAAC8AE23"><description xml :lang="en">

Interface de demande d’information 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"

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 précises sur le service. Cela nous indiquequ’il y a un point d’accès de production sur http ://uddi.microsoft.com et que les points d’accèsUDDI de demande d’information sont publiquement adressables via HTTP, et que les points d’ac-cès de publication sont sous protection HTTPS.On pourra ensuite utiliser les informations tModelKey pour trouver toutes les entreprises enregis-trées 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> </tModelBag></find_business>

6.5 Conclusion

Si vous créez des applications qui doivent se connecter dynamiquement à des services fournispar des partenaires commerciaux externes, vous devez alors impérativement penser à relier vosapplications au registre UDDI. Imaginez cela comme le DNS pour la couche application métier.Il serait intéressant de pouvoir ajouter, changer et supprimer des points d’accès en temps réel, etd’éviter ainsi la semaine de retard, ou plus, qu’implique la propagation DNS.

Après avoir trouvé une société et ses services dans l’annuaire UDDI. Et bien, UDDI ne pré-tend pas tout résoudre. Tenter de créer une spec du protocole b2b principal qui englobe tout cequi a jamais été inventé est une lourde tâche, qui ne verra probablement jamais le jour. Voici enquoi consiste la théorie UDDI : vos applications sauront comment traiter avec certains types deprotocoles bien connus, et ces protocoles seront décrits de telle manière que vous pourrez trouverdynamiquement d’autres entreprises qui reconnaissent ce protocole. Alternativement, vous pouvezavoir 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 four-nissent. Dans ce cas, vous avez déjà probablement établi d’autres canaux sûrs afin de téléchargerles adaptateurs nécessaires pour vous connecter à chaque service.

page 31 de 48

Fig. 6.1 – Données du registre UDDI

6.6 Annexes UDDISources : http ://www.corbucci.com/essi/jerome.htm

page 32 de 48

Fig. 6.2 – Couplage d’une solution SOAP avec UDDI

Fig. 6.3 – Navigateur UDDI de SAP

page 33 de 48

Fig. 6.4 – Recherche d’un service sur UDDI par l’intermédiaire de SAP

page 34 de 48

Chapitre 7

WSDL

7.1 Définition

C’est un format de schéma XML permettant de décrire un service Web en précisant les mé-thodes disponibles, les formats des messages d’entrée et de sortie et comment y accéder. Il définitun espace de travail extensible pour décrire des interfaces de Services Web.Il a été premièrement développé par Microsoft et IBM et soumit au W3C devant une commissionde 25 compagnies (fait exceptionnel). Il est au cœur de l’espace de travail d’un service Web, des-servant une façon de représenter les types de données envoyés dans les messages, les opérations àeffectuer sur les messages, et l’envoi des messages sur les réseaux.

Comme les autres technologies XML, WSDL est tellement extensible et possède un si grandnombre d’options qu’assurer une compatibilité et une interopérabilité entre les différentes im-plémentations serait difficile. Si l’expéditeur et le destinataire d’un message peuvent partager etcomprendre le même fichier WSD de la même façon, alors l’interopérabilité sera assuré.

WSDL permet de décrire :– Types des données– Messages– Opérations– Binding

Ces descriptions doivent être exhaustives et pr’ecises, pour exemple l’api amazon n’ecessite1150 lignes WSDL pour 23 op’erations et 200 lignes pour google pour 3 op’erations.

Concepts liés à WSDL :– Service : une collection de ports (port ou endpoints)– Port : une adresse réseau et un binding– Binding : un protocole et un format de données associé à un type de port (port type)– Type de port : un ensemble d’opérations (proche d’une interface au sens Java)– Opération : une action proposée par un service web, décrite par ses messages (proche d’une

méthode au sens Java)– Message : un ensemble de données– Donnée : une information typée selon un système de type comme celui des schémas du W3

Chaque élément principal peut être spécifié dans un document XML et importé dans différentescombinaisons pour créer une description de service Web finale, ou ils peuvent tous êtres définisensemble dans un seul document. Les définitions de type de données déterminent la structureet le contenu des messages. Les opérations abstraites déterminent les opérations effectuées sur le

35

contenu du message, et les services à rendre déterminent le réseau de transport qui acheminera lemessage à destination.

7.2 Les définitionsLa partie définitions inclut les définitions de types de données, les messages et les opérations

abstraites, qui sont similaires aux définitions d’interfaces en CORBA ou DCOM. Les messagespeuvent avoir plusieurs parties et être définies avec un style d’interaction procédurale, orienté do-cument ou les deux.

Les définitions de type en WSDL sont basées sur des schémas XML, mais on peut utiliser unautre système équivalent ou similaire. Par exemple, les types de données définis en CORBA IDL(Interface Definition Language) peuvent être utilisés à la place des schémas de définitions XML.(Si un autre système de définition de type est utilisé, les deux parties du service Web doivent êtrecapable de le comprendre).

7.3 Les noms d’espaceLes noms d’espaces XML sont utilisés pour assurer l’unicité des noms d’éléments XML utilisés

dans chacun des trois parties principales de WSDL. Quand les éléments WSD sont déveleoppésséparement et importés dans un seul fichier, les noms d’espaces utilisés dans les fichiers ne doiventpas se chevaucher. Les schémas associés sont utilisés pour valider les fichiers, messages et opéra-tions WSDL définis.

WSDL inclut beaucoup d’extensions, de changements et d’additions en tant que service Web«mature». Comme SOAP, WSDL est un espace de travail XML extensible pouvant être adapté àde multiples systèmes d’applications de type de données, définitions de types de messages, opéra-tions, transports.

7.4 Exemple WSDL (cf Figures 5.*)Description d’un 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 WSDLSources : http ://developpeur.journaldunet.com/tutoriel

/xml/021107xml_wsdl1b.shtml

page 36 de 48

Fig. 7.1 – Code WSDL XML de définition de types, déclaration de messages et de types de port

page 37 de 48

Fig. 7.2 – Code WSDL XML de déclaration d’engagement et de service

Fig. 7.3 – Code WSDL XML d’implémentation

page 38 de 48

Chapitre 8

Web services et entreprises

8.1 Définition

Avec l’essor d’Internet, il devient de plus en plus intéressant pour les entreprises d’utiliser unsupport électronique pour leurs transactions commerciales.

Le commerce électronique ne se limite maintenant plus à l’échange de messages. En effet, lesentreprises veulent désormais permettre à leurs partenaires d’affaires d’accéder directement auxfonctions de leur système d’information.

Une nouvelle notion a été introduite, puisqu’elles veulent de plus que les différents logicielsde gestion (ERP, SCM CRM) communiquent entre eux, on l’appelle l’intégration entre différentssystèmes d’information.

Les Web services sont une solution à cette approche d’intégration.Ils promettent l’interopérabilité entre toutes les applications. En se basant sur XML et en utili-

sant Internet comme un canal de communication, ils permettent en théorie de faire communiquerentre elles les entreprises.

On se dirige donc vers une intégration des applications utilisant des langages propriétaires.C’est ce qui En outre, elles pourront, en retour, ouvrir leurs applications à d’autres sociétés.

8.2 Construction d’un projet informatique

8.2.1 Introduction

XML est désormais utilisé pour décrire les projets business des entreprises. Pour diffuser toutesles informations vers des applications et d’autres entreprises lorsqu’il y a collaboration, des tech-nologies telles que XSLT leurs servent. C’est un langage qui complète XML dans le sens où il vapermettre l’échange d’informations entre applications. Ce système représente 80% de l’utilisationde XML dans les projets informatiques.

En résumé, XSLT diffuse les données formatées et structurées en XML.

8.2.2 Etapes

– La cartographie et la formalisation des processus métiers est réalisée en XML et va permettreà l’entreprise de maîtriser les ressources qui entrent en jeu dans le projet ainsi que d’unifor-miser son système informatique. Le système devient alors capable de considérer la dimensionmétier, il peut alors comprendre et interpréter les acteurs de l’organisation, ce qu’ils doiventfaire et de quelle façon ils vont collaborer.

– La mise en place des infrastructures B2B va permettre la connexion des applications del’entreprise avec celles de ses partenaires.

39

– L’adoption d’un langage commun signifie la mise en place des dialogues entre entreprises, ilva pouvoir les transactions avec les partenaires.

– XML sera employé pour toutes ces étapes car il va s’adresser à tous ces besoins. Il mettrade plus d’accord les différents acteurs sur des standards.

8.3 EAI

8.3.1 Définition

L’Entreprise Application Integration est un concept. C’est le fait de regrouper un ensembledes méthodes, technologies et outils qui permettent de consolider et coordonner l’ensemble desapplications hétérogènes d’une entreprise. L’objectif est d’aboutir à une urbanisation du systèmed’information de l’entreprise.

Les Web services servent de base à l’EAI.Ce sont de véritables systèmes de composants pouvant être utilisé pour l’intégration d’applications.

8.3.2 L’intégration d’applications

L’EAI fait communiquer et collaborer les applications d’une même entreprise.L’intégration des applications est devenue l’une des priorités des entreprises car elle pourra

mettre en place une uniformisation de leur système informatique.Jusqu’à très peu de temps, les systèmes d’information étaient souvent composés d’applications

non communicantes.Prenons l’exemple d’applications de gestion, si les applications ne savent pas communiquer,

les commandes seront saisies en plusieurs endroits : à savoir dans le logiciel de traitement descommandes, dans le logiciel de facturation, etc.

L’intégration des différentes applications permet d’éviter les doublons, les informations erronéeset d’améliorer la traçabilité.

8.3.3 Fonctions de l’EAI

– Interfaçage : extraction et injection des données dans une application. On se sert de WSDLen particulier. On utilise les Web services car ils ont l’avantage de pouvoir être accédés àpartir de n’importe quel langage de programmation sur n’importe quelle plate-forme. Grâceà WSDL, on va pouvoir donner une description normalisée des fonctionnalités offertes parles applications.

– Transformation : conversion des données. C’est le rôle de XSLT. Cela permet en particulier deconvertir des informations comprises par une application en informations comprises par uneautre. Par exemple, si une application de gestion des commandes transmet une descriptionde commande à une application de facturation dans le but de générer une facture, et que cesdeux applications n’ont pas la même façon de modéliser une commande, une opération detransformation est nécessaire.

– Routage : transport des données vers le destinataire avec SOAP.– Gestion : suivi de l’état du processus. Pour cela on utilise la gestion des processus métiers

avec BPML.

8.4 Les processus métiers

8.4.1 Définition

L’objectif des processus métiers est de formaliser l’exécution d’activités par des applicationsde manière collaborative dans le but d’atteindre un objectif métier.Formellement, un processus métier peut être défini comme un enchaînement d’activités. Dans un

page 40 de 48

processus métier, on tient compte des différents participants d’une opération, de leur rôle, del’objectif de cette opération et des moyens mis en œuvre (messages, documents). On peut agirsur ceux-ci en définissant des règles métier, des règles de sécurité, des règles de transactions. Onpeut ensuite lancer l’exécution du modèle (automate à états finis) et vérifier le fonctionnementthéorique des différents processus.BPML est un standard émergeant s’occupant de cela.Un processus métier est interne à une entreprise et une seule. Il décrit les activités nécessitant lacollaboration de plusieurs entités.

8.4.2 Dialogues

Un dialogue définit une collaboration entre plusieurs entreprises (partenaires), sous la formed’échange de messages. Un dialogue comprend :

– La définition des messages échangés entre partenaires ;

– Le séquencement de ces messages ;– Les rôles des différents partenaires.

8.4.3 Les processus e-business

Un dialogue fait abstraction des processus métiers implémentés par chaque partenaire. Pourlier dialogues et processus métiers, On utilise la notion de processus e-business.Un processus e-business est composé de deux parties :

– Une interface publique : définition du dialogue précisant l’interaction entre les participantsdu processus e-business. Elle est commune à tous les participants.

– Deux interfaces privées (une par partenaire) : définition des processus métiers implémentéspar chaque partenaire.

8.4.4 BPML (Business Process Modeling Language)

C’est un méta langage de modélisation des processus métiers dont les premières spécificationssont apparues au printemps 2001. Il définit un modèle abstrait d’interaction entre collaborateursparticipant à une activité de l’entreprise, voire entre une organisation et ses partenaires.

Il est basé sur XML et exécuté par un moteur.BPML spécifie si les processus supportent les transactions courtes ou longues (mécanisme deundo). Un des objectifs de BPML est d’intégrer les applications existantes de l’entreprise dans desprocessus métiers, afin de les utiliser dans les processus e-business.

8.5 Conclusion

L’EAI garanti que chaque nouvelle application s’insère correctement et interagit avec les ap-plications existantes. Mais une entreprise qui veut offrir ses applications à l’extérieur aura néces-sairement besoin des web services explique Didier Martineau, le directeur des services de l’éditeurde logiciels XML Software AG. En effet, pour lui, l’EAI prend tout son sens dans un rôle interneà l’entreprise.

Ainsi, compter sur l’utilisation des web services en interne pour l’intégration d’applications, enlieu et place des outils d’EAI, n’aurait pas de sens. Les Web services ne vont pouvoir exister quedu fait de la présence de l’EAI.Même si toutes les applications entre les entreprises communiquent via les Web services, les EAI

page 41 de 48

seront toujours présents pour assurer la transformation, le routage et le transport des données ausein de l’entreprise.

page 42 de 48

Chapitre 9

Sécurité et fiabilité des Web Services

9.1 Quels mécanismes veut-on mettre en place pour assurerla sécurité des Web Services ?

Les Web Services doivent intégrer les méthodes de base de la sécurité afin de permettre unemeilleur sécurité et une bonne fiabilité. Parmis les stratégies utilisées on peut citer celles-ci :

9.1.1 Authentification

L’authentification consiste à mettre en place un système de login et de mot de passe afind’identifier l’entité qui tente de se connecter au système. L’authentification permet de :

1. vérifier si l’utilisateur est connu du système ;2. déterminer les droits et privilèges affectés à l’utilisateur ;3. contrer l’usurpation frauduleuse de l’identité d’un utilisateur, de l’administrateur ou d’un

serveur ;4. limiter l’intrusion sur le réseau à partir d’un accès externe ou même interne.

L’authentification a pour but d’assurer qu’un utilisateur, une application ou une interface peut ounon dialoguer avec une application.

9.1.2 Autorisation d’accès

Il s’agit d’un contrôle d’accès aux ressources d’un système d’information. Le contrôle d’accèsassure que l’utilisateur a accès aux ressources autorisées. Pour cela on met en oeuvre des filtresqui ne laissent transiter que les flux autorisés. Dans un contexte d’intégration de services, aprèsl’authentification d’un utilisateur ou d’une interface, le système permettra a chacun d’assumer sesrôles.

9.1.3 Mécanisme d’encryptage et de décryptage des données

Afin que les données qui transitent sur le réseau ne puissent être lues par une tierce personne, ilest utile de mettre en place un mécanisme d’encryptage et de décryptage des données. Le cryptagea pour but de protéger l’information et de la rendre incompréhensible a toute autre personne quele destinataire du message.

9.1.4 Signature digitale

La signature digitale utilise la notion de cryptographie à clé publique. La signature électroniquepermet l’authentification du signataire, chaque signature n’appartient qu’à un seul document et

43

ne peut pas être réutilisée ni imitée. Les signatures électroniques permettent pour les Web Servicesd’identifier les entités émettrices de messages.

9.2 Sécurisation des services Web

Les Web Services ne supportent pas explicitement les mécanismes de sécurité. Afin de sécuriserles Web Services il faudrait commencer par sécuriser l’infrastructure informatique puis sécuriserspécifiquement les Web Services : Pour cela on peut rendre sûres les connexions et les données enutilisant les standards existants.

9.2.1 Sécurisation de l’infrastructure

Les Web Services reposant sur une infrastructure informatique, il est logiquement nécessaire decommencer par sécuriser celle-ci. Une telle sécurisation de l’infrastructure informatique nécessiteplusieurs technologies integrées dans un plan de sécurité global.Cela suppose une identification des risques liés à l’environnement (virus, pirates , evenementsimprevisibles risquant de nuire à l’infrastructure(incendie, ...etc)). Mais il est aussi nécessaired’intégrer des mesures de sécurité à tous les niveaux du réseau.

9.2.2 Sécurisation des connexions

Pour sécuriser les Web Services la solution la plus simple à mettre en oeuvre est la sécurisationde la connexion entre le client et le serveur. Pour cela plusieurs moyens sont envisageables :

Système de pare-feu

Les règles de pare-feu permettent de limiter l’accès à une liste d’adresses IP connues. Cettetechnique sera utilisée au sein d’un réseau privé.

Protocole SSL

SSL (Secure Sockets Layer) permet d’établir des connexions sécurisées sur un réseau non sécu-risé(Internet) .SSL est en fait un système de cryptage/décryptage des messages qui circulent entre un client et unserveur. SSL crypte le message envoyé par un client. Ainsi ce message ne peut pas être lu pendantson transfert. SSL décrypte le message une fois que celui-ci est parvenu au serveur et vérifie labonne identité de l’expéditeur(authentification).SSL utilise le concept de certificat pour l’authentification : 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. Après réception d’un message par B génère un message aléatoire et l’envoie à A ;

4. A crypte ce message avec sa clé privée et le renvoie à B ;

5. B décrypte 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 vérifiée, le message n’a pas été envoyé parun usurpateur car seul A connait sa clé privée.

Lorsque HTTP est associé à SSL, on parle de HTTPS. L’avantage de SSL est qu’il est déjà trèsemployé sur Internet. Cependant, SSL est uniquement disponible avec TCP/IP, or, le protocoleSOAP peut être employé hors du contexte de TCP/IP. SSL est efficace en ce qui concerne lasécurité mais pèse beaucoup sur les performances.

page 44 de 48

9.2.3 Authentification et contrôle d’accès

L’authentification consiste à vérifier l’identité de l’émetteur d’un message.On dit que que l’authentification nécessite des informations d’identification : un mot de passe peutêtre information d’identification. Le système vérifie ces informations d’identification et si elles sontvalides authentifie l’entité.C’est seulement après cette authentification que des autorisations sont accordées selon le client.certains client ont accès à des taches ou des données inaccessibles à d’autres clients.

La plupart des Web Services utilisent les fonctions d’authentification du protocole HTTP. Pourassurer l’interopérabilité entre les Web Services il est nécessaire que les méthodes utilisées étendentla norme SOAP intégrant ainsi la sécurité directement dans les Web Services

9.2.4 Sécurisation de SOAP

Il est nécessaire de sécuriser le protocole SOAP. Les messages seront encryptés afin de lesprotéger 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 Standards XML de sécurité

9.3.1 XML Signature

XML Signature permet d’intégrer directement dans le document XML la signature et le cer-tificat. L’avantage pour les Web Services est que les élements nécessaires à la sécurité sont inclusdans le documen XML. XML Signature est totalement adapté aux Web Services et intègre :

1. Une protection du document par cryptage2. L’authentification de l’entité qui a envoyé le document3. l’intégrité du document

Les principaux avantages de la signature XML sont que des parties de documents ou des docu-ments entiers peuvent être protégés et les documents sont protégés même en dehors du transfertdes documents.Cependant ce standard ne couvre pas tous les éléments de sécurités comme par exemple la gestiondes droits d’accès.

9.3.2 XKMS XML Key Management Specifications

La spécification XKMS offre une infrastructure de gestion es clés publiques afin de généraliserl’utilisation de XML Signature.Pour faciliter l’emploi et le développement de XML Signature, il faut fournir des entités deconfiance qui supportent la gestion de clés publiques, et plus seulement se limiter à l’utiliqa-tion de certificats qui est très contraignante. Dans cette approche, on identifie un service Web deconfiance qui offre une implémentation d’un service XKMS permettant :

– d’enregistrer une paire de clés et d’obtenir en contrepartie un certificat.– de rechercher une clé publique.– de supprimer une paire de clés.

Autrement dit, l’entité qui fournit l’implantation XKMS joue le rôle d’une autorité de certifcation.

9.3.3 SAML Security Assertion Markup Language

Le standard SAML a pour but de favoriser l’interopérabilité entre les solutions de gestion desdroits utilisateurs sur Internet.

page 45 de 48

SAML définit des formats de messages XML et un vocabulaire pour véhiculer des informationsqui composent une procédure d’authentification. Il est composé de deux schémas XML suivants :

– Déclaration de nom : Il s’agit d’un document XML signé contenant une proposition de troiséléments : le type d’authentification, la source d’authentifiction et le sujet authentifié.

– Habilitation : Il s’agit d’un document XML signé décrivant les renseignements relatifs auxautorisations d’un sujet identifié. L’habilitation suit l’utilisateur d’un domaine à l’autre pen-dant tout le cours d’une transaction.

9.3.4 WS-SecurityCette spécification qui a été proposée à l’origine dans le but de décrire l’ensemble des pratiques

de sécurité les plus couramment utilisées. Objectif à terme : élaborer une interface qui assure l’in-teropérabilité entre solutions de sécurité d’entreprise, reposant sur des technologies hétérogènes.

L’ensemble des méthodes prises en compte WS-Security couvre en premier lieu l’authentifica-tion de la partie cliente, c’est-à-dire l’émetteur du message SOAP. Dans le cas d’une architecturede Web Services, ce client peut renvoyer à un individu mais également à une application (oucomposant) ou encore à une machine. D’où la prise en compte par la spécification de divers méca-nismes : le couple identifiant/mot de passe, la méthode du jeton de sécurité et celles des certificatsnotamment. "Concrètement, WS-Security définit la manière de décrire au sein d’un message SOAPles droits utilisateur correspondant à ces différents systèmes de sécurité". Comment éviter que laconnexion entre deux Web Services ne soit "sur écoute" ? Ici, entre en jeu le chiffrement et lagestion de l’intégrité des messages, pour lesquels le langage propose un vocabulaire de gestion decertificats : des outils qui peuvent être utilisés aussi bien pour chiffrer un document électroniqueque pour le signer.

page 46 de 48

Chapitre 10

Conclusion

10.1 Apports

Les Web Services possèdent une simplicité de mise en oeuvre : Ils rendent en effet accessiblesdepuis Internet des fonctionnalités d’une application exixtante tout en ne modifiant pas en profon-deur le systeme d’information de l’entreprise.Il s’agit de l’ajout de briques suplémentaires. Pourcela, les Web Services exploitent les standards d’échange Internet.Les services Web avec ses protocoles et ses standards avance vers toujours plus de normalisation.Déjà, le protocole d’échange de messages SOAP et le langage WSDL pour la définition de l’inter-face standardsent la couche de transport. Les Web Services reposent sur des bases solides(SOAP etWSDL)qui ont prouvé leur efficacité et leur maturité même si un normalisation complète n’existepas encore.Cette standardisation permet une grande interopérabilité entre des applications de technologiedifférente : les protocoles SOAP, WSDL et UDDI permettent de simplifier l’utilisation des ser-vices auxquels ils sont liés par l’utilisation de fichiers textuels, donc lisibles par l’utilisateur. Leurcontenu se limitant aux éléments essentiels d’interopérabilité, ces standards assurent une grandeindépendance de l’implémentation par rapport au système d’exploitation, à l’architecture de lamachine ou au standard utilisé.Un des avantages principaux des Web Services est qu’ils sont basé sur Internet qui est on le saitfiable et mature.

10.2 Limites

Les Web Services ont cependant des limites qui sont :– Toutes les normes ne sont pas établies notament en matière de sécurité ;– Les performances sont relativement faibles ;– Des contournements de sécurité sont possibles.

Aucune norme de sécurité n’existe dans les Web Services. En effet les standards qui exitent peuventtrès bien ne pas être utilisés ou peuvent n’assurer qu’une partie des éxigeances se sécurité. De plus,les Web Services utilisent HTTP et héritent des problèmes de celui-ci : Les firewall peuvent êtrecontournés.En ce qui concerne les performances des Web Services, l’échange de messages est particulièrementlent du fait que la quantité d’informations vehiculée est importante.

10.3 Evolution des Web Services

Là où les architectures précédentes demandaient des resources importantes, en terme de déve-loppement comme de déploiement, les Web Services héritent du pragmatisme des technologies du

47

Net, ce qui facilite leur adoption. Mais les Web Services sont encore en cours de stabilisation desstandards.Il sera notament nécesaire de definir des normes de sécurité qui posent un gros problème. Cepen-dant les Web Services gagnent en maturité ce qui peut promettre qu’ils seront adoptés massivementcomme la réponse appropriée aux problématiques d’échanges de données et d’intégration d’appli-cations.Il est donc prévu un augmentation d’utilisation des Web Services par les entreprises dans les annéesà venir.

10.4 Enrichissement personnelCe travail d’études nous a permis d’aborder une nouvelle technologie et d’en étudier divers

aspects : Les principes de fonctionnement et ses mises en oeuvre avec l’étude des differentestechnologies qui accompagnent les Web Services.L’étude des Web Services nous a également permis de mieux comprendre les enjeux dans le domainedu Web dans les entreprises autant sur le plan de l’importance du Web que sur les exigeances quien découlent(sécurité, fiabilité, performances, ...).

page 48 de 48