You are on page 1of 34

Université Claude Bernard Lyon I UFR Informatique

L es services web

Sujet bibliographique par Stéphanie Clapié & Antoine Renard

DESS I nformatique I mages et Réseaux option Réseaux
P r o m o tio n 2 0 0 2 -2 0 0 3

Sujet bibliographique

Les services web

Sommaire

PRÉAMBULE...........................................................................................................................3 PARTIE I..................................................................................................................................4 PRÉSENTATION :...................................................................................................................4 PANORAMA DES WEB SERVICES.....................................................................................4 1. CONTEXTE..........................................................................................................................4 2. DÉFINITIONS.......................................................................................................................6 3. INTÉRÊTS............................................................................................................................8 PARTIE II..............................................................................................................................10 FONCTIONNEMENT :.........................................................................................................10 LES PRINCIPES....................................................................................................................10 1. CONCEPTS DE BASE..........................................................................................................10 2. EXEMPLE..........................................................................................................................14 PARTIE III.............................................................................................................................17 UN MANQUE DE MATURITÉ :..........................................................................................17 LACUNES ET SOLUTIONS.................................................................................................17 1. LE MANQUE DE FIABILITÉ DU RÉSEAU INTERNET.............................................................17 2. LE MANQUE DE SÉCURITÉ.................................................................................................19 3. SOAP EST INADAPTÉ À L’APPROCHE SYNCHRONE............................................................21 PARTIE IV.............................................................................................................................25 AUJOURD’HUI ET DEMAIN :............................................................................................25 ETAT DES LIEUX.................................................................................................................25 1. ACTEURS...........................................................................................................................25 2. PRODUITS..........................................................................................................................26 3. CHIFFRES..........................................................................................................................27 CONCLUSION.......................................................................................................................28 LEXIQUE................................................................................................................................29 RÉFÉRENCES........................................................................................................................30 ANNEXES...............................................................................................................................32

Stéphanie Clapié – Antoine Renard – DESS IIR-R

2

Sujet bibliographique

Les services web

Préambule

A l’heure actuelle, les Services Web (ou Web Services en anglais) sont un sujet dont on entend parler de plus en plus. Ce document est une synthèse des concepts de base régissant les Web Services. Il présente globalement le vocabulaire technique, les principes de fonctionnement et les solutions du marché. Vous trouverez, en page 29, un lexique qui resitue la signification des différentes abréviations employées dans ce document.

Stéphanie Clapié – Antoine Renard – DESS IIR-R

3

Sujet bibliographique

Les services web

PARTIE I
Présentation :
Panorama des Web Services

1. CONTEXTE
Internet est devenu au fil des dernières années un acteur incontournable de l’économie. Malgré les déceptions bien connues du phénomène startup, les nouvelles technologies font désormais partie intégrante de l’économie mondiale. Les nouvelles technologies permettent aujourd'hui de faciliter les échanges et la communication entre tous les acteurs : clients, fournisseurs et partenaires commerciaux. Si, dans un premier temps, les entreprises ont été quelque peu bousculées par cette intrusion massive des nouvelles technologies, la tendance s'est inversée et, à présent, c'est la logique économique du « plus vite, meilleur et moins cher » qui dicte les transformations nécessaires de l'Internet. C’est dans ce contexte que sont apparus les Web Services : l’Internet est en fait un cadre de travail devenu incontournable et dont il faut tirer parti de la manière la plus « économiquement viable ». L’objectif est d’effectuer des opérations sur le web, de manière tout à fait indépendante des plate-formes et langages hétérogènes. Ainsi, les Services Web sont en quelque sort une utilisation « détournée » d’anciens protocoles d’Internet, qui, couplés avec de nouvelles « briques », permettent l’exécution d’applications distribuées. Cette indépendance des Services Web vis-à-vis des langages et des plates-formes couplée à des protocoles de communication standardisés, par exemple HTTP ou encore SMTP, assure aux applications distribuées une interopérabilité maximale.

Stéphanie Clapié – Antoine Renard – DESS IIR-R

4

Sujet bibliographique

Les services web Les promesses des Services Web sont séduisantes. D'un point de vue technologique, ils facilitent l'interconnexion des applications au travers d'internet. Sur le plan économique, ils doivent contribuer à améliorer les échanges entre entreprises.

Stéphanie Clapié – Antoine Renard – DESS IIR-R

5

Sujet bibliographique

Les services web

2. DÉFINITIONS
Qu’est-ce qu’un Web Service ? Les services web sont des applications modulaires autonomes qui peuvent être publiées et invoquées à travers un réseau (comme le web). Les services web proposent des interfaces bien définies qui décrivent les services fournis. Un Service Web est un composant programmé dans n'importe quel langage et enveloppé dans une couche de standards, la plupart dérivés de XML. Grâce à cette enveloppe, le composant peut dialoguer avec d'autres applications qui, elles-mêmes se conforment aux standards des Web Services. Les services web sont conçus pour permettre un couplage flexible entre client et serveur. C'est-à-dire que l'implémentation du serveur n'impose pas au client l'utilisation d'une plate-forme ou d'un langage de programmation spécifique. Non seulement les interfaces sont définies en restant neutre quant au langage, mais elles sont également conçues pour utiliser différents mécanismes de communication. Résultat, deux plates-formes distantes (un poste d'utilisateur et un serveur) peuvent donc dialoguer, et ceci indépendamment du système d'exploitation et des langages de programmation exploités de part et d'autre. Les Web Services représentent donc un moyen de répartir les traitements à travers le Net et de mutualiser les services applicatifs.

Ne pas confondre Si à l’origine le terme « Web Service » correspondait globalement à un service disponible via le web, par la suite il a été assimilé à une technologie bien particulière. En effet, lorsqu’on parle de Web Services, on ne doit penser à un service offert sur Internet (une messagerie électronique en ligne par exemple) mais bien à une multitude d’acronymes tels que SOAP, XML, HTTP, WSDL, ou UDDI (et bien d’autres encore).

Stéphanie Clapié – Antoine Renard – DESS IIR-R

6

Sujet bibliographique

Les services web

Concept du publier, trouver, lier Les Web Services sont placés au devant de la scène en tant que nouvelles technologie qui va révolutionner la manière dont les applications distribuées coopèrent. L’architecture orientée services sous-jacente aux Web Services est basée sur le mécanisme « publier, trouver et lier » qui existe déjà au sein de CORBA depuis des années.

Service Registry

PUBLISH

FIND

Service Provider

BIND

Service Consume r

Figure 1 : Architecture des Web Services

Stéphanie Clapié – Antoine Renard – DESS IIR-R

7

Sujet bibliographique

Les services web

3. INTÉRÊTS

Cette technologie des Web Services voit son utilité dans un contexte d’architecture distribuée. Les applications réparties existent depuis bon nombre d’années et les Web Services semblent être présentés comme l’aboutissement de leur évolution. Comparés à des technologies comme CORBA, RPC ou les EJB, les Web Services présentent de nombreux avantages. Notamment en termes de facilité de mise en place, de passage de firewall et de flexibilité.

Un engouement soudain Les objets CORBA publient leurs services dans des « Naming » et « Trader Services » grâce auxquels d’autres objets peuvent trouver ces services et ensuite délivrer des requêtes aux objets correspondants. Le phénomène de mode dont ont fait l’objet les Services Web ont une explication : la réelle révolution réside dans l’emploi des standards HTTP et XML et surtout dans la simplification du processus de communication. S’ils tiennent leurs promesses, l’intérêts des Web Services est donc considérable puisqu’ils permettraient l’uniformisation et l’homogénéisation des échanges entre environnements différents.

Stéphanie Clapié – Antoine Renard – DESS IIR-R

8

Sujet bibliographique

Les services web

Ce schéma illustre le fait que les échanges effectués par SOAP sur http traversent les firewalls de manière plus directe. Ainsi, des processus métiers ne nécessitent pas obligatoirement l’ouverture de ports supplémentaires. De plus, au même titre que CORBA ou les EJB, les Web Services permettent d’interconnecter des applications écrites à l’aide de langages de programmation totalement différents.

Stéphanie Clapié – Antoine Renard – DESS IIR-R

9

Sujet bibliographique

Les services web

PARTIE II
Fonctionnement :
Les principes

1. CONCEPTS DE BASE
Origines En 1998, la firme UserLand Software utilise les deux standards XML et HTTP pour définir un protocole de communication permettant à différentes versions de leur logiciel, tournant distinctement sur des OS Windows et Mac, de communiquer. Ce protocole, première ébauche de XML-RPC, fait naître l'espoir d'une interopérabilité entre plates-formes de toutes origines reliées via l'Internet. Ensuite, Microsoft décide de continuer les travaux entamés en définissant un protocole dérivé de XML-RPC appelé SOAP. Il faudra attendre la version 1.1 de SOAP avant que SUN rejoigne Microsoft et participe activement au sein du W3C « working group » à la définition de ce protocole. SOAP se présente comme la solution au problème d'interopérabilité entre la plate-forme .NET de Microsoft et la plate-forme J2EE de SUN... Cependant, la création de Services Web nécessite d'autres types de standards technologiques que SOAP car celui-ci est uniquement limité à la communication entre composants distribués. Il est donc logique de voir apparaître d'autres standards tels que UDDI permettant la découverte des ces services dispersés sur le Web ou WSDL permettant la description de ces services.

Stéphanie Clapié – Antoine Renard – DESS IIR-R

10

Sujet bibliographique

Les services web

Service Registry

UDDI WSDL

Service Provider

Service Consumer

SOAP

En novembre 1999, une initiative de plus grande envergure ayant pour mission de fournir une infrastructure ouverte, basée sur XML et facilitant l'échange d'informations électroniques parmi des partenaires commerciaux, voit le jour. Il s'agit de ebXML. Contrairement à ce que bon nombre de personnes imaginent, SOAP n'est pas un concurrent de ebXML, tout au contraire, il complète idéalement les travaux menés par les organisations UN/CEFACT et OASIS. En effet, ebXML est une suite de spécifications dans laquelle s'intègre parfaitement SOAP.

La pile de protocoles des Web Services

Stéphanie Clapié – Antoine Renard – DESS IIR-R

11

Sujet bibliographique

Les services web

Comme on peut le remarquer, le stack de protocoles des Web Services se situe au niveau applicatif (couche 7) du modèle standard OSI. De ce fait, une fois de plus, les Services Web sont un niveau au-dessus par rapport à des technologies comme CORBA. En effet, les échanges de données ne seront pas binaires mais « lisibles par un être humain ».

Fonctions des principaux protocoles XML Métalangage basé sur des balises personnalisables et une hiérarchisation arborescente des données

SOAP Reposant sur le langage de balisage XML, SOAP définit la structure des messages échangés par les applications via Internet.

Figure 2 : Structure d’un message SOAP

Stéphanie Clapié – Antoine Renard – DESS IIR-R

12

Sujet bibliographique

Les services web UDDI Standard pour la localisation et la publication du Service Web. Permet d'enregistrer de l'information concernant les types de services disponibles et les personnes pouvant utiliser ces services. Il fournit donc un mécanisme de publication et de recherche de services. UDDI s'appuie sur des standards tels que HTTP, SOAP et WSDL. Il existe des registres publics, suivant le standard UDDI, où, à la fois, des fournisseurs de services peuvent publier leurs services et des demandeurs de services peuvent trouver ces services. Un registre UDDI est décomposé en pages blanches, jaunes et vertes. Les pages blanches incluent des informations tels que le nom et l'adresse d'une entreprise. Les pages jaunes catégorisent les entreprises en fonction du type d'affaires qu'elles effectuent. Finalement, les pages vertes décrivent le genre de services offerts ainsi que les techniques de communication à employer pour joindre ces services. WSDL Définition des ports et services utilisés par le Service Web. Le langage WSDL est exploité par le fournisseur de services pour donner une description technique de ses services. Cette description peut être interprétée, sans la moindre intervention humaine, par une entité distribuée désireuse de trouver et ensuite d'invoquer un service particulier. WSDL se base sur le format XML pour décrire des Services Web sous la forme d'un ensemble de points finaux appelés ports. Un port est décomposé en deux parties distinctes. La première partie contient la définition abstraite des opérations ainsi que des messages contenus dans ces opérations. Une opération est ainsi considérée comme une action dont on peut extraire deux types de messages : une requête et une réponse. Tandis que la seconde partie lie les messages à un protocole de communication concret. Cette distinction entre partie abstraite et concrète est requise afin de favoriser la réutilisabilité de cette définition en combinaison avec d'autres protocoles. Un port est donc décomposé en un ensemble d'opérations. Chaque port est lié à un protocole de communication comme par exemple SOAP 1.1 ou SMTP. Enfin, le port représente une adresse à laquelle on peut joindre l'entité supportant les opérations définies.

Stéphanie Clapié – Antoine Renard – DESS IIR-R

13

Sujet bibliographique

Les services web

2. EXEMPLE
Pour schématiser le principe de fonctionnement d’un Service Web, on peut utiliser les figures suivantes :

Après mise en place de Web Services, ils sont inscrits dans un (ou des) annuaires UDDI privés ou publics. Le format WDSL décrit le service et la manière avec laquelle on peut y accéder et l’exploiter. Chaque Service Web est en fait l’accès « visible » sur le réseau (Internet ou Intranet) au système interne de l’entreprise. Au niveau de l’UDDI, l’ensemble des Services Web sont référencés et classés dans trois bases selon leur catégorie : • • • Pages blanches Pages Jaunes Pages vertes

Stéphanie Clapié – Antoine Renard – DESS IIR-R

14

Sujet bibliographique

Les services web

Un client voulant utiliser un des Services Web référencés à l’étape précédente se connecte sur l’annuaire UDDI. Il récupère la description WSDL du service voulu. Il dispose ensuite des informations nécessaires pour pouvoir accéder puis utiliser le Service Web.

Stéphanie Clapié – Antoine Renard – DESS IIR-R

15

Sujet bibliographique

Les services web L’échange SOAP peut alors commencer : il est initié par une requête SOAP envoyée par le client à destination d’un des Services Web. La requête SOAP est acheminée (par exemple sur le protocole HTTP ou encore SMTP). Cette requête SOAP contient l’ensemble des données qui sont passées en paramètre au Service Web distant. Une fois le traitement effectué par le Service Web, une réponse SOAP sera renvoyée au client, qui contiendra la réponse.

Mais en y regardant bien, les Web Services s’ils sont incontestablement une évolution ne constituent pas pour le moment une vraie révolution. Dans le sens où ils sont basés sur des protocoles et des technologies pré-existantes. De plus, SOAP correspond le plus souvent à des messages XML transportés sur de l’HTTP. Et par ce dernier point, on peut trouver certaines imperfections aux Web Services.

Stéphanie Clapié – Antoine Renard – DESS IIR-R

16

Sujet bibliographique

Les services web

PARTIE III
Un manque de maturité :
Lacunes et solutions

1. LE MANQUE DE FIABILITÉ DU RÉSEAU INTERNET
Le problème L'interopérabilité et la qualité de service sont les deux pré-requis indispensables à un développement durable des Services Web. La réelle menace de failles d'interopérabilité a incité un groupe de fournisseurs (IBM, Microsoft, BEA, etc.) à créer en début d'année l'organisme Web Services Interoperability Organization (WSIO), censé, à terme, y mettre fin. En raison des problèmes inhérents à la qualité du réseau IP (Best Effort), et a fortiori de HTTP, il n’existe aucun mécanisme permettant de garantir la qualité de service d’un service web. Or, dans une architecture de type RPC (Remote Procedure Call), les Services Web établissent une connexion point à point afin de s'échanger des messages SOAP selon un dialogue « Requête / Réponse » synchrone. Dans ce modèle (le plus répandu dans les entreprises françaises), l'appel d'une méthode distante bloque l'exécution du programme client jusqu'à ce que la réponse lui soit parvenue : les temps de latence dus à la traversée du réseau Internet, ajoutés aux problèmes de QoS, peuvent ainsi ralentir de manière inacceptable l’exécution des processus. L'absence de fiabilité du protocole HTTP ne permet en aucune façon de savoir si l'appel a bien été transmis au serveur et si ce dernier a bien renvoyé sa réponse. Impossible, dans ces

Stéphanie Clapié – Antoine Renard – DESS IIR-R

17

Sujet bibliographique

Les services web conditions, d'orchestrer l'appel successif à plusieurs Services Web au sein d'un même processus synchrone.

Les solutions actuelles La première consiste à court-circuiter Internet en mettant en place une liaison spécialisée entre l'entreprise et son partenaire. Sans être parfaite, cette solution assure un minimum de contrôle sur la QoS. Dans la même logique, des WSVN (Web Services Value Networks) ont récemment vu le jour. Les réseaux à valeur ajoutée de Flamenco Networks et de Grand Central ne sont pas sans rappeler ceux de l'EDI traditionnel. Ils routent et transforment les messages de l'expéditeur au destinataire, s'engagent sur une qualité de service et prennent en charge la gestion de l'authentification des partenaires. Reste que certaines entreprises comme Météo France, Ineas ou la banque SBE se satisfont de la qualité de service Internet, car les Services Web qu'ils proposent n'exigent pas des temps de réponse serrés et ne sont pas impliqués dans des transactions critiques.

Les solutions à venir Face à cette problématique, IBM propose d'étendre HTTP par HTTPR (HTTP Reliable). Ce protocole garantit que les paquets sont bien acheminés en renvoyant un accusé de réception. L'éditeur souhaiterait également étendre le rôle de WSDL en y ajoutant des contrats de service grâce à WSEL (Web Services Endpoint Language). Pour l'heure, ces deux spécifications ne sont pas encore implémentées, et les entreprises se tournent donc vers d'autres solutions, plus efficaces à court terme.

Stéphanie Clapié – Antoine Renard – DESS IIR-R

18

Sujet bibliographique

Les services web

2. LE MANQUE DE SÉCURITÉ

Le problème En exposant des Services Web, l'entreprise permet à n'importe qui de manipuler ses applications directement depuis Internet. D'autant que l'API de chaque service est parfaitement décrite dans un fichier WSDL. La mise en place d'un dispositif de sécurité et d'authentification est donc un enjeu capital. La sécurisation n’est pour l’instant pas implémentée directement au sein du protocole SOAP. Il faut donc trouver des parades permettant de sécuriser l’authentification des utilisateurs ainsi que les échanges de données.

Les solution actuelles Pour l'heure, la majorité des projets applique donc les recettes des sites marchands aux Services Web. L'authentification est prise en charge au niveau applicatif (login et mot de passe), et les échanges sont sécurisés au niveau du transport : SSL fournit un premier niveau de confidentialité. Certaines sociétés renforcent ce dispositif à l'aide de certificats côté client. Ce mécanisme en place, les entreprises ne craignent plus les attaques traditionnelles. Le principal danger vient des pilleurs de données. Dans ce domaine, plusieurs approches permettent de limiter les risques. La première consiste à ajouter des règles dans son pare-feu et à filtrer les adresses IP pour ne laisser passer que ses partenaires, mais l’installation de règles de filtrage complexifie grandement la mise en place mais surtout l’exploitation et la maintenance des Services Web. La seconde approche repose sur un filtrage des messages SOAP en fonction de règles métier. On peut, par exemple, limiter le nombre d'appels possibles d'une méthode dans un laps de temps donné. Les premiers pare-feu dédiés à cette tâche sont récemment apparus chez des Stéphanie Clapié – Antoine Renard – DESS IIR-R 19

Sujet bibliographique

Les services web fournisseurs tels que Reactivity, Westbridge, Vordel ou Quadrasis. Coupe-feu et filtrage des paquets SOAP sont toutefois inefficaces face à une attaque par déni de service (DoS), qui, dans le cas d'une interconnexion de composants applicatifs, peut avoir de lourdes conséquences. Heureusement, les Services Web actuellement déployés reposent, pour la plupart, sur une architecture asynchrone à base de middleware orienté messages (MOM) et ne représentent qu'une infime partie des accès aux composants sous-jacents. La couche des Services Web est une façade derrière laquelle se situent les applications de l'entreprise, et donc susceptible de jouer le rôle de fusible : elle s'écroulera sous la charge, mais n'aura pas d'impact sur le fonctionnement global des services exposés, les appels s'accumulant dans la pile du MOM.

Solutions à venir Proposée par IBM, Microsoft et Verisign, WS-Security permet à deux partenaires d'échanger des messages SOAP en toute sécurité sur l'internet grand public en les cryptant à l'aide de XML Encryption, et en les signant à l'aide de XML Signature, de tickets Kerberos ou de certificat X509. Soutenu par l'Oasis, WS-Security propose de transporter le contexte de sécurité dans les en-têtes SOAP afin de pouvoir authentifier et sécuriser le message. Mais les produits qui supportent cette spécification restent peu nombreux.

Stéphanie Clapié – Antoine Renard – DESS IIR-R

20

Sujet bibliographique

Les services web

3. SOAP EST INADAPTÉ À L’APPROCHE SYNCHRONE

Le problème Les transactions SOAP ne permettent pas la mise en place de transactions de type synchrones : il est en effet impossible de connaître le temps d’exécution ainsi l’état d’avancement d’un traitement. De plus, le protocole HTTP ne fournit pas la fiabilité et la stabilité requises au niveau du transport pour gérer convenablement des transactions fortement couplées, qui nécessitent une qualité de service très élevée.

La solution actuelle L'orchestration de processus asynchrones pallie l'impossibilité de réaliser des transactions SOAP. La méthode consiste à découper fonctionnellement le processus en trois temps. Les entreprises recourent à une architecture asynchrone à base de middleware orienté message (MOM). C'est le cas notamment de Météo France, d'Eastman Chemicals et de B2Boost. Le découpage fonctionnel est toujours le même :

?
ID

Demande du service ? État d’ avancement du processus Envoi Du résultat

Client
% ? Résultat

Stéphanie Clapié – Antoine Renard – DESS IIR-R

21

Sujet bibliographique

Les services web L'invocation du premier service (la prise de commande, par exemple) s'effectue via un appel RPC synchrone. Ce dernier ne renvoie pas la réponse à la requête, mais un identifiant. Un deuxième service fournit au client l'état d'avancement du traitement sous-jacent (la commande est prête ou non) grâce à cet identifiant. Ce découplage permet à la fois de mieux monter en charge et de prendre en compte le fait que certains traitements exposés par des Services Web peuvent parfois nécessiter plusieurs heures, voire plusieurs jours de calcul. Lorsque ce traitement est achevé, un troisième Service Web récupère le résultat de la requête. Le déclenchement de la récupération du résultat auprès du troisième Service Web s'effectue toujours grâce au deuxième, qui fournit l'état de la commande. On peut soit l'interroger régulièrement, soit lui demander d'envoyer une alerte lorsque le résultat est prêt. Bien qu'un moteur d'orchestration ne soit pas toujours nécessaire pour gérer cet asynchronisme, l'offre ne manque pas dans ce domaine, de Biztalk à Web Service Orchestration Server de Collaxa, en passant par les produits de Cape Clear, d'Avinon, d'Intalio, d'Instansis ou de Cypress Logic. Ces moteurs sont chargés de deux tâches très importantes. La première consiste à orchestrer les appels asynchrones aux différents services. Ils appellent l'ensemble des services, stockent les résultats en base ou dans une pile du MOM, puis continuent d'exécuter le processus lorsqu'ils le peuvent. Leur seconde mission est de gérer des mécanismes de compensation qui équivalent peu ou prou au " rollback " d'une transaction traditionnelle. En fait, chaque compensation n'annule pas les actions qui ont déjà eu lieu, mais propose plutôt une nouvelle action censée corriger les erreurs générées. Une compensation n'étant rien d'autre qu'un processus.

Stéphanie Clapié – Antoine Renard – DESS IIR-R

22

Sujet bibliographique

Les services web Les solutions à venir Pour décrire précisément la nature des messages SOAP que vont s'échanger les Services Web composant un processus, diverses propositions de standards s'affrontent, parmi lesquelles WSFL d'IBM, WSCL de HP et XLANG de Microsoft. Toutes ces propositions reposent sur XML et sont décrites à l'aide de DTD ou de schémas spécifiques. Ceux-ci sont notamment utilisés pour décrire le type des données échangées entre services distants. Les trois propositions permettent de spécifier des logiques d'enchaînement arbitrairement complexes de services Web, assemblés de manière statique, à l'instar des processus caractéristiques de l'univers du workflow. Des structures de contrôle (boucles, blocs conditionnels, sauts, alternatives...), inspirées des langages traditionnels de programmation structurée, enrichissent ces propositions et permettent de décrire des assemblages conditionnels pilotés par des événements ou dépendant de l'état général du processus au moment de son exécution. La dynamique des applications s'intéresse à la synchronisation des échanges (messages, données...) et à la définition de transactions impliquant potentiellement de nombreux services hétérogènes et distribués. Elle fait l'objet de descriptions spécifiques. Les architectures à base de Services Web s'appuient sur un environnement technique d'exécution n'intégrant aucun dispositif simple de gestion des états transactionnels : à titre d'exemple, HTTP est un protocole sans état. Pourtant, les applications à mettre en place sont, par essence, de nature transactionnelle. Les propositions WSCL, XLANG et WSFL permettent de décrire sommairement ces structures dynamiques et de définir des transactions distribuées.

Stéphanie Clapié – Antoine Renard – DESS IIR-R

23

Sujet bibliographique

Les services web

De plus, si les Web Services ont connu dès 2001 un engouement remarquable, les éditeurs semblent ne pas réussir à se mettre d’accord sur les protocoles à utiliser. En ce sens aussi les Web Services sont encore immatures. Dans le domaine du workflow, par exemple, aucune solution ne semble faire l’unanimité : IBM propose WSFL, Microsoft privilégie XLang, HP pense au WSCL et un consortium d’entreprises de l’EAI et du B-to-B penche pour le BPML… Ainsi la plupart des produits de développement présents sur le marché proposent des outils permettant l’implémentation et la mise en place de Web Services. Ce qui peut poser des problèmes de compatibilité entre versions.

Stéphanie Clapié – Antoine Renard – DESS IIR-R

24

Sujet bibliographique

Les services web

PARTIE IV
Aujourd’hui et demain :
Etat des lieux
1. ACTEURS

D’une part, on peut distinguer les organismes normalisateurs et les entreprises informatiques d’autre part. Les groupes de travail relatifs aux Web Services sont les suivants : • • W3C : World Wide Web Consortium

Il a pour but de mettre en place des normes. WSIO : Web Services Interoperability Organization

Issu d’un partenariat de IBM, Microsoft et BEA, a pour objectif de promouvoir les Web Services.

Concernant les Web Services, on peut se placer selon différents points de vue : • • Comme fournisseur du service Comme utilisateur du service

Stéphanie Clapié – Antoine Renard – DESS IIR-R

25

Sujet bibliographique

Les services web

2. PRODUITS

Apache SOAP (Apache project) • Servlet permet de déployer les services • Appel servlet depuis SOAP

Web Services Toolkit (IBM, alphaWorks) • Générateur WSDL à partir de classe Java ou EJB • Générateur de Proxy client Java

SunOne • Produit similaire de SUN annoncé • Version bêta en démonstration

Autres • BEA, Broadvision, etc…

Presque tous les éditeurs de progiciels de développement proposent à l’heure actuelle des outils permettant l’utilisation des Web Services.

Stéphanie Clapié – Antoine Renard – DESS IIR-R

26

Sujet bibliographique

Les services web

3. CHIFFRES

Progiciel de gestion Logistique Commerce électronique C to C Relation Client Commerce électronique B to B 0 10 20 30 40 50 60 70 80

Résultats d’une enquête sur les attentes des entreprises

100 000 € Investissement moyen évalué par Benchmark Group à partir des projets menés en France 5 pour 75% des web services Nombre de plate-formes de développement 58% Pourcentage des entreprises du tertiaire en France s’étant déjà lancés 43% Pourcentage des sondés attendant un meilleur niveau de sécurité des web services

Stéphanie Clapié – Antoine Renard – DESS IIR-R

27

Sujet bibliographique

Les services web

Conclusion

Ainsi, pour tirer une conclusion de nos recherches, nous pensons pouvoir affirmer que les Web Services ne constituent pas une révolution. En effet, ils sont basés sur des technologies qui étaient déjà employées et après un fort phénomène de mode, il semblerait que les Web Services subissent le contre-coup du ralentissement de l’économie et de l’effondrement des valeurs de la net-économie. Malgré un bon « plan marketing », les responsables informatiques commencent à relativiser l’intérêt d’investir dans les Web Services et n’ont plus la même tendance à foncer tête baissée dans un paradigme dont les normes se font attendre. Au bout du compte, il semblerait que les Web Services finissent par trouver leur place en tant qu’intégrateur entre les différentes technologies CORBA, J2EE, .NET…

Stéphanie Clapié – Antoine Renard – DESS IIR-R

28

Sujet bibliographique

Les services web

Lexique

A.P.I. : Application Program Interface C.O.R.B.A. : Common Object Request Broker Architecture DoS : Deny of Service E.A.I. : Enterprise Application Integration E.D.I. : Echange de Données Informatique E.J.B. : Enterprise Java Bean ebXML : electronic business XML H.T.T.P. : Hyper Text Transfer Protocol I.P. : Internet Protocol O.O. : Object Oriented O.A.S.I.S. : Organization for the Advancement of Structured Information Standards QoS : Quality of Service R.P.C. : Remote Procedure Call S.M.T.P. : Simple Mail Transfer Protocol S.O.A.P. : Simple Object Access Protocol S.S.L. : Secure Sockets Layer U.D.D.I. : Universal Description Discovery and Integration UN/CEFACT: United Nations Centre for Trade Facilitation and Electronic Business W.S.D.L. : Web Services Description Language W.S.I.O. : Web Services Interoperability Organization W.S.V.N. : Web Services Value Networks W3C : World Wide Web Consortium X.M.L. : eXtensible Mark-up Language

Stéphanie Clapié – Antoine Renard – DESS IIR-R

29

Sujet bibliographique

Les services web

Références

Livres XML Elke Niedermair, Éditions Micro Application, 2001 Serveurs d’applications Thierry Brethes - François Hisquin - Pierre Pezziardi, Éditions Eyrolles, 2000 Programming Web Services with SOAP James Sneff, O’Reilly Web Services essentials O’Reilly Web Services Business Strategies and Architectures Kapil Apshankar, Peter Fletcher, 2002 Services Web avec SOAP, WSDL, UDDI, ebXML... Jean-Marie Chauvet, Eyrolles éditions, 2002

Internet http://www.w3.org/TR/SOAP Site du World Wide Web Consortium (documentation sur le protocole SOAP) http://www.01net.com Site du groupe 01 http://www.journaldunet.com Site d’information spécialisé dans les nouvelles technologies http://www.xmethods.com Site diffusant une liste de Web Services accessibles http://www.uddi.org

Stéphanie Clapié – Antoine Renard – DESS IIR-R

30

Sujet bibliographique

Les services web

Usenet Microsoft.public.webservices Newsgroup

Documentation technique Borland Delphi6 pour Windows Guide du développeur

Magazines et Revues professionnelles Le Monde Informatique 01Réseaux

Stéphanie Clapié – Antoine Renard – DESS IIR-R

31

Sujet bibliographique

Les services web

ANNEXES

Stéphanie Clapié – Antoine Renard – DESS IIR-R

32

Sujet bibliographique

Les services web

Annexe 1 : Code XML d’un exemple de communication SOAP

Request SOAP envelope <SOAP-ENV:Envelope xmlns:SOAP-ENV="..."> <SOAP-ENV:Header> non functional </SOAP-ENV:Header> <SOAP-ENV:Body> <m:GetLastTradePrice xmlns:m="Some-URI"> <symbol>MACHIN</symbol> </m:GetLastTradePrice> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Response SOAP envelope <SOAP-ENV:Envelope xmlns:SOAP-ENV="..."> <SOAP-ENV:Body> <m:GetLastTradePriceResponse xmlns:m="Some-URI"> <Price>34.5</Price> </m:GetLastTradePriceResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Stéphanie Clapié – Antoine Renard – DESS IIR-R

33

Sujet bibliographique

Les services web

Annexe 2 : Détail des champs d’un registre UDDI

Pages blanches (businessEntity) o BusinessKey o Name o Description o CategoryBag o BusinessServices

Pages jaunes (businessService) o ServiceKey o BusinessKey o Name o Description o CategoryBag o BindingTemplates

Pages vertes (bindingTemplates) o BindinKey o ServiceKey o Description o AccessPoint

Stéphanie Clapié – Antoine Renard – DESS IIR-R

34