34
13 Chapitre 1 L’architecture des services Web La combinaison des canons esthétiques et idéaux politiques, reflets de leur époque, et de la généralisation de nouveaux matériaux préside souvent au développement de nouveaux styles d’architecture. Par analo- gie, le renouvellement de l’architecture informatique exprime la conver- gence, à une étape donnée de l’évolution technique, des modèles de l’entreprise, de sa gestion et de ses interactions avec les autres. À l’ère de la décentralisation et de la mondialisation, quoi donc de moins surpre- nant que cette transition d’une informatique centralisée, symbolisée par le mainframe et ses applications « monolithiques », ou isolée, symbolisée par l’utilisateur seul face à son PC, vers une informatique complètement répartie et communicante, tant à l’intérieur de l’entreprise que dans ses interactions avec le réseau qu’elle-même constitue avec toutes les autres ? Ubiquité et universalité du Web Avec la généralisation du Web, nous sommes passés à une étape aussi importante dans l’évolution technique que celle entamée lors de l’appari- tion du PC dans les années 1980. Avec le PC, le matériel devenait une marchandise banalisée (commodity), mettant clairement le logiciel au cœur de l’industrie informatique. Cette transformation se renouvelle aujourd’hui, appliquée cette fois au logiciel lui-même, plaçant le service en ligne au centre des préoccupations des acteurs de l’informatique d’entreprise. Ce changement n’est nulle part plus apparent que dans l’énumération des styles architecturaux « modernes » dont la promotion forcenée a certainement contribué à la bulle financière des « dot com »: • Les applications B2C (business-to-consumer) : applications ou sites Web destinés au grand public. Extrait de l'ouvrage Services Web avec SOAP, WSDL, UDDI, ebXM L... de Jean-Marie Chauvet, © Eyrolles, 2002.

L’architecture des services Web - eyrolles.com · Chapitre 1 – L’architecture des services Web 15 – une application Web – au travers d’un ou de plusieurs services Web

Embed Size (px)

Citation preview

13

Chapitre 1

L’architecturedes services Web

La combinaison des canons esthétiques et idéaux politiques, reflets deleur époque, et de la généralisation de nouveaux matériaux présidesouvent au développement de nouveaux styles d’architecture. Par analo-gie, le renouvellement de l’architecture informatique exprime la conver-gence, à une étape donnée de l’évolution technique, des modèles del’entreprise, de sa gestion et de ses interactions avec les autres. À l’ère dela décentralisation et de la mondialisation, quoi donc de moins surpre-nant que cette transition d’une informatique centralisée, symbolisée par lemainframe et ses applications « monolithiques », ou isolée, symbolisée parl’utilisateur seul face à son PC, vers une informatique complètementrépartie et communicante, tant à l’intérieur de l’entreprise que dans sesinteractions avec le réseau qu’elle-même constitue avec toutes lesautres ?

Ubiquité et universalité du Web

Avec la généralisation du Web, nous sommes passés à une étape aussiimportante dans l’évolution technique que celle entamée lors de l’appari-tion du PC dans les années 1980. Avec le PC, le matériel devenait unemarchandise banalisée (commodity), mettant clairement le logiciel au cœurde l’industrie informatique. Cette transformation se renouvelleaujourd’hui, appliquée cette fois au logiciel lui-même, plaçant le serviceen ligne au centre des préoccupations des acteurs de l’informatiqued’entreprise. Ce changement n’est nulle part plus apparent que dansl’énumération des styles architecturaux « modernes » dont la promotionforcenée a certainement contribué à la bulle financière des « dot com » :

• Les applications B2C (business-to-consumer) : applications ou sites Webdestinés au grand public.

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.

Services Web avec SOAP, WSDL, UDDI, ebXML…

14

• Les applications B2B (business-to-business) : applications ou sites Webplutôt destinés au commerce entre entreprises.

• Les places de marché (marketplaces ou exchanges) : sites Web visant à auto-matiser les transactions et les échanges entre un grand nombre d’entre-prises.

• Les ASP (Application Service Providers) : hébergeurs d’applications d’entre-prise (ERP, messagerie, groupware…), auxquelles une entreprise peutaccéder via Internet moyennant un abonnement.

• Les applications P2P (peer-to-peer) : applications utilisant Internet et lespostes clients qui y sont connectés comme support de calcul massive-ment parallèle pour des traitements complexes (analyse des résultatsde la recherche scientifique) ou comme support d’échanges individuelsà très grande échelle (Napster, Gnutella…).

Dans la multiplication de ces ornements stylistiques, il ne faut finalementdiscerner qu’une forme de baroquisme accompagnant la transformationarchitecturale fondamentale de l’application informatique en service Web.En effet, toutes ces propositions reposent techniquement sur la possibi-lité de répartir données et traitements d’une application non seulement àl’intérieur du réseau informatique interne de l’entreprise, derrière lespare-feu, mais plus encore, de les disposer sur tout le Web lui-même, leurconférant alors ses caractères d’universalité et d’ubiquité.

Applications Web et services Web

Avec l’épanouissement de la technologie client-serveur et du Web, lesconsommateurs ont un accès pratiquement direct aux informations déte-nues par les producteurs. De nouveaux canaux de distribution viennentalors se substituer aux intermédiaires traditionnels. Le flot d’informationcroissant, orienté vers les clients et les consommateurs, change la naturedes relations entre acheteurs, fournisseurs, distributeurs, partenaires,sous-traitants, etc. Les entreprises qui mettent à profit ces technologiespour fournir, traiter, qualifier et publier cette information seront celles quibénéficieront au final de ce changement d’équilibre dans la chaîne devaleur ajoutée.

L’exemple de la banque dite de dépôt illustre cette mutation. Après avoirlonguement mûri leurs stratégies – qui pouvaient être initialementperçues comme incompatibles avec le maintien d’un réseau d’agences –,presque toutes les banques de dépôt offrent aujourd’hui à leurs clientsl’accès à la consultation de leurs comptes par une variété de moyensdirects : téléphone, portable WAP, site Web, Minitel. Plutôt que de créerde nouvelles applications pour chacun de ces canaux de diffusion, ledépartement informatique avisé aura mis en œuvre la même application

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.

Chapitre 1 – L’architecture des services Web

15

– une application Web – au travers d’un ou de plusieurs services Web chargésd’adapter la présentation de l’information au canal de distribution et auxprofils des utilisateurs (customization). Ainsi, l’utilisateur final dispose del’information dont il a besoin quel que soit son mode d’accès. Les techno-logies des services Web permettent d’automatiser cette adaptation, rédui-sant d’autant le coût de la diffusion de l’information exigée par le consom-mateur.

Cette approche se révèle même plus avantageuse, puisque, toujourssans créer de nouvelles applications informatiques, il est imaginable, àmoindre coût, de publier d’autres informations ou d’autres données,destinées à de nouveaux partenaires, par exemple pour la commerciali-sation de produits financiers. Ainsi, un nouveau service Web, à vocationB2B, faisant appel aux mêmes applications que précédemment, pourraitêtre destiné à des compagnies d’assurances partenaires de la banque dedépôt dans la commercialisation de certains produits financiers auprèsdes particuliers.

Cette forme d’agrégation de produits et de services est également illus-trée par le scénario de l’agence de voyages. L’agence propose en effet àses clients un produit, le voyage, qui est en fait un bouquet de services :réservation et émission des billets d’avions, réservation des hôtels, desbillets de train, des voitures de location, assurances, etc. Les donnéesnécessaires à l’élaboration d’un voyage personnalisé proviennent defournisseurs différents (compagnies aériennes, chaînes hôtelières,etc.). Filtrées, choisies, adaptées aux exigences du consommateur etaux tarifications négociées entre les différents partenaires – tarifs eux-mêmes soumis à des mises à jour –, elles servent ensuite de base à lafacturation.

Figure 1-1. Application Webdéployée sur de multiplescanaux de diffusion.

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.

Services Web avec SOAP, WSDL, UDDI, ebXML…

16

Dans ce cas, comme dans le précédent, l’application Web consultée direc-tement par le client de l’agence de voyages résulte de la mise en œuvre deservices Web (recherche dans des catalogues et des tarifs, réservation,fidélisation…). Dans le scénario B2B, les mêmes messages circulent mais,cette fois, entre serveurs plutôt qu’entre client et serveur.

Agrégation et transformation de l’information sont les tâches que lesservices Web automatisent complètement. Une application Web résultealors de l’assemblage de services Web, certains développés en interne etd’autres fournis par des partenaires externes. Aux deux extrémités decette échelle, on trouve le tout interne (intégration d’application d’entre-prises ou EAI) et le tout externe (portail). Pour les applications Web, déve-lopper, c’est assembler et déployer, c’est publier.

Évolution et révolution

Les caractères révolutionnaires (universalité et ubiquité) d’Internet et duWeb constituent une étape supplémentaire dans la chaîne évolutive qui adéjà mené, en quelques décennies, l’application monolithique du main-

Figure 1-2. Application Web comme agrégation de services Web.

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.

Chapitre 1 – L’architecture des services Web

17

frame, en passant par le client-serveur et l’architecture à trois niveaux, auxassemblages d’objets répartis (Corba, DCOM et EJB) et à leurs serveursd’application.

Le terme de service apparaît déjà dans le livre blanc Object Management Archi-

tecture de l’OMG1 au début des années 1990 pour désigner, dans le contexte

client-serveur, certains objets résidant sur les serveurs.

Mais alors que les maillons de cette évolution s’appuient sur des protoco-les, des langages et des interfaces progressivement plus riches et plusraffinées, ouverts ou jalousement propriétaires, le Web impose desmoyens de communication autrement plus rustiques : débit comparative-ment moins haut, temps de latence, défaillances, protocole HTTP d’unesobriété dégrisante après certains « excès » de complexité des protocolesRMI, DCOM ou IIOP.

À la fin des années 1980, l’industrie du logiciel était agitée par le débat entreles interfaces graphiques riches mais consommatrices de ressources, commedans Windows, et les pages HTML, peut-être simplistes, mais accessibles àpartir d’un navigateur Web léger et universel. De même, l’heure estaujourd’hui à la recherche d’un compromis satisfaisant entre les besoinscomplexes des applications d’entreprise et les contraintes de simplicité duWeb, garantes de son universalité. Est-il finalement possible de conserver lemeilleur des évolutions précédentes et de le mettre en œuvre dans le nouvelenvironnement ? Les premiers déploiements réussis d’applications fondéessur les services Web permettent de répondre par l’affirmative.

Les fondations de l’architecturedes services Web

L’architecture des services Web repose sur un mécanisme de transportd’une demande de service entre un client et un serveur, tous deux connec-tés au réseau.

CORBA

Figure 1-3. Le transport des demandes de services et des résultatsde leur exécution est confié à une couche de communication fondéesur HTTP et TCP/IP.

� OMG (Object Management Group) : consortium de plus de 800 cons-tructeurs, éditeurs, intégrateurs et utili-sateurs réunis pour spécifier collective-ment une architec-ture à objets répartis dont est issu Corba.

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.

Services Web avec SOAP, WSDL, UDDI, ebXML…

18

Dans cette architecture, le client peut être soit un navigateur Web (lademande de service résulte alors directement d’une interventionhumaine), soit une application (la demande de service est alors automati-sée). Le rôle du serveur, quant à lui, est joué par une application quis’exécute sur un moteur de scripts interfacé à un serveur HTTP (PHP/Apache, par exemple) ou sur un serveur d’applications J2EE ou .NET. Lepoint crucial est ici l’étanchéité entre les clients et les serveurs qui ignorenttout de l’implémentation, dite privée, des opérations respectives de leurscorrespondants et ne se connaissent et se reconnaissent qu’au travers dedescriptions publiques, appelées services Web. À partir de ces services Web,on construit soit de nouveaux services Web dérivés des précédents, soitdes applications Web, c’est-à-dire des assemblages de services Webcorrespondant à une solution fonctionnelle ou métier de l’entreprise. Leservice Web est un composant logiciel dans la constitution d’applicationsmétier s’appuyant sur l’infrastructure de communication offerte par leWeb. Le mécanisme de communication permettant cette circulation derequêtes et de résultats autorise évidemment la mise en relation deplusieurs clients et de plusieurs serveurs et, bien souvent, d’ailleurs,d’applications jouant parfois le rôle de client et parfois celui de serveur.

Ce « bus de requêtes » est fondé sur TCP/IP et sur HTTP, ce qui permet sonutilisation tant sur Internet qu’en vue de l’intégration d’applications ausein du réseau interne de l’entreprise ou de la « publication » d’applica-tions préexistantes sur le Web à destination des entreprises partenaires.Le service Web est l’interface publique de l’application dans le réseauintra ou interentreprise.

Figure 1-4. Un service Web donné peut être, suivant le contexte, aussi bien client que serveur d’autres services Web locaux ou distants.

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.

Chapitre 1 – L’architecture des services Web

19

Dans l’architecture Corba, ce rôle est joué par l’ORB (Object Request Broker), qui

transporte les requêtes entre le programme client et les objets sur le serveur.

Depuis la version 2 de la norme Corba, le protocole de communication de l’ORB,

appelé IIOP (Internet InterOrb Protocol), s’appuie sur TCP/IP et peut donc être

employé sur Internet.

Dans l’architecture Microsoft, ce rôle est précisément assuré par le protocole

DCOM (Distributed Component Object Model) qui étend le modèle mono-

machine COM aux réseaux de PC sous Windows.

Dans l’architecture J2EE (Java 2 Enterprise Edition), le protocole RMI (Remote

Method Invocation) permet à un programme Java d’en appeler un autre qui est

exécuté sur une machine virtuelle Java distante.

Comme HTTP ne transmet que du texte – des pages Web au format HTML,par exemple –, tous les échanges entre services Web (requêtes et résultatsde requêtes) circulent également au format texte, sous forme de docu-ments codés en XML.

XML, la langue maternelle des services Web

XML

XML est un standard promulgué par le W3C, l’organisme chargé de stan-dardiser les évolutions du Web. On retrouve dans XML une généralisationdes idées contenues dans HTML et SGML1. XML permet de définir desbalises et de leur associer une interprétation. Dans HTML, on n’utilise lesbalises que pour décrire l’aspect graphique que doit revêtir la page dansle navigateur Web. Dans XML, les balises permettent d’associer toutessortes d’informations au fil du texte.

La norme XML comporte deux parties : XML à proprement parler et lesDTD (Document Type Definition) qui définissent les balises qui sont utiliséesdans une famille de documents XML.

XML a été conçu pour des documents arbitrairement complexes, tout ens’appuyant sur cinq grands principes simples et clairs :

• lisibilité à la fois par les machines et par les utilisateurs ;

• définition sans ambiguïté du contenu d’un document ;

• définition sans ambiguïté de la structure d’un document ;

• séparation entre documents et relations entre documents ;

• séparation entre structure du document et présentation du document.

Contrairement aux formats de fichiers dits « binaires » des documentssortant bruts de fonderie des traitements de texte ou des tableurs, leformat XML a été conçu pour en permettre le déchiffrement direct par

CORBA

DCOM

EJB

� SGML : Standard Generalized Markup Language.

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.

Services Web avec SOAP, WSDL, UDDI, ebXML…

20

l’utilisateur comme par les programmes. Le compromis trouvé dans XMLest celui de texte contenant des balises ouvrantes et fermantes qui décri-vent la nature des données qu’elles encadrent, comme dans l’exemple<prenom>Harry</prenom>. La structure est hiérarchique : un docu-ment XML s’ouvre sur une balise qui contient toutes les autres. Ainsi,sans (trop) perdre de lisibilité, le document XML permet de représenterdes structures de données arbitrairement complexes – les hiérarchies dedonnées se trouvent en abondance dans les modèles de données rela-tionnels et dans les modèles objet, par exemple.

Le contenu d’un document est décrit par une succession d’« éléments »,blocs de texte encadrés par des paires de balises ouvrante et fermante,qui sont les « unités de contenu ». Ces éléments sont liés entre eux parune hiérarchie, certains éléments apparaissant imbriqués dans d’autres.XML et DTD permettent ainsi une séparation effective du contenu de lastructure du document.

Les relations entre documents sont au moins aussi importantes que leurstructure : cinq documents XML représentant cinq bons de commande etcinq autres représentant des produits ne sont intéressants que si l’on saitassocier le bon produit au bon de commande. Souvent, en HTML, ces rela-tions figurent explicitement dans la page Web – d’où d’ailleurs la multipli-cation des messages « HTTP 404 Not found » – par des références directes.Dans XML, en revanche, ces relations entre documents sont exprimées endehors des documents XML eux-mêmes – souvent dans d’autres docu-ments, eux-mêmes écrits en XML avec d’autres vocabulaires.

Figure 1-5. Un document XML et son DTD.

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.

Chapitre 1 – L’architecture des services Web

21

Enfin, contrairement à HTML, le document XML en soi ne dit rien del’aspect sous lequel il doit être rendu à l’écran (ou ailleurs : imprimante,téléphone WAP, etc.). Structure et présentation du document sont concep-tuellement séparées. Ainsi le même contenu peut-il être présenté sousdifférentes formes suivant la nature des utilisateurs. Les documents (enXML !) qui décrivent la présentation à « appliquer » à un document XML

Figure 1-6. Transformation d’un document XML en page HTML via XSLT.

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.

Services Web avec SOAP, WSDL, UDDI, ebXML…

22

constituent des feuilles de style XML (XSL pour XML Style Sheets) dont lefonctionnement est semblable à celui des CSS (Cascading Style Sheets) pourle Web. La norme XSLT (XSL Transformation) définit le vocabulaire de cesfeuilles de style destinées à transformer un document XML en vue de leprésenter à son utilisateur (humain ou non).

Les standards dérivés de la norme XML

Autour de la norme XML, promulguée en février 1998 par le W3C, se greffeune collection de normes complémentaires à différents stades de norma-lisation (voir tableau ci-dessous).

Recommandation

Nom Date Descriptif

XML, DTD Février 1998 La norme définissant XML et les DTD (Document Type Definition)

XML Namespa-ces

Janvier 1999 Convention pour l’attribution de noms et pour le groupage des balises

XPath v.1.0 Novembre 1999 Expressions en XML de fragments de documents XML

XSLT v1.0 Novembre 1999 Expressions en XML de transformation et d’opéra-tions sur des documents XML

XHTML v1.0 Janvier 2000 Reformulation en XML de HTML v. 4.0

XML Schema Mai 2001 Expressions en XML des structures de données

XLink v1.0 Juin 2001 Expressions en XML de liens (complexes) entre fragments de documents XML

SMIL, SVG, RDF, MathML

1999-2001 Vocabulaires « verticaux » XML pour le multimé-dia, le graphisme vectoriel, les structures de données et les expressions mathématiques

XSL v1.0 Octobre 2001 Feuilles de style XML

XML InformationSet

Octobre 2001 Ensemble de définitions permettant à d’autres spécifications de se référer à l’information conte-nue dans un document XML

Proposition de recommandation

XML Signature Août 2001 Authentification en XML

Candidat à recommandation

XPointer v1.0 Septembre 2001 Description généralisée de pointeurs en XML

XML Fragment Interchange

Février 2001 Protocole d’échange et de modification de frag-ments de documents XML (gestion de versions…)

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.

Chapitre 1 – L’architecture des services Web

23

Comme le montre la variété des domaines d’application dans lesquels ilest employé et le nombre des travaux de recherche lancés depuis sonadoption en 1998, XML réunit le double avantage d’être extensible et des’accommoder de l’infrastructure fruste du Web.

XML Namespaces

XML Namespaces est une recommandation du W3C qui a été rapide-ment adoptée après XML 1.0, visant à résoudre le problème de l’ambi-guïté éventuelle des balises dans un document XML. En effet, au fur età mesure que se généralise l’usage d’XML, il faut s’attendre que desdocuments XML contiennent des balises « réutilisables », c’est-à-direconstituées comme de véritables vocabulaires mis en œuvre dans diver-ses applications. C’est d’ailleurs tout l’enjeu de consortiums tels queebXML ou RosettaNet qui tentent de définir un vocabulaire XML partagépar le plus grand nombre d’acteurs d’un secteur industriel donné. Aveccette prolifération, une même balise, <Adresse> par exemple, peutdésigner des choses très différentes dans divers documents XML :adresse postale d’expédition dans un bon de commande, elle peut aussibien désigner une adresse de courrier électronique dans une applicationintranet. Pour résoudre cette ambiguïté, il faut compléter la balise avecune information supplémentaire rendant unique son interprétation. Lenamespace XML répond à ce besoin : il s’agit d’une collection de nomsutilisables soit comme types de balises, soit comme noms d’attributs debalises.

« Working drafts » : documents de travail

Nom Date Descriptif

XML Protocol (XMLP)

Mars 2001 Expressions de protocoles de communication en XML

XInclude Mai 2001 Mécanisme d’inclusion destiné à faciliter la fusion de documents XML pour une meilleure modularité

XQuery Juin 2001 Langage de requête permettant d’interroger tout type de données représentées en XML

XForms Août 2001 Nouvelle génération de formulaires Web

SOAP v1.2 Octobre 2001 Protocole de communication basé sur l’échange de documents XML

XML Encryption Octobre 2001 Sécurité des documents XML

XML Events Octobre 2001 Permet d’associer des gestionnaires d’événe-ments à des éléments XML

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.

Services Web avec SOAP, WSDL, UDDI, ebXML…

24

En pratique, le namespace est un préfixe attaché à la balise ou à l’attributpar « : ». Ainsi, la notation suivante :

<bonDeCommande:adressexmlns: bonDeCommande="http://www.ebXML.org">

fait apparaître le préfixe bonDeCommande qui est le namespace XML dela balise <adresse>. Ce namespace est identifié de manière unique parla valeur de l’attribut réservé xmlns.

Pour assurer l’unicité des noms de namespaces, on a recours aux URI1 –un moyen standard de nommer et d’identifier des ressources Internet misen place et géré par l’IETF. Voici un exemple de document XML contenantdeux éléments <adresse> associés à des namespaces différents :

<bonDeCommande:expeditionxmlns: bonDeCommande ="http://www.ebXML.org">

<bonDeCommande:adresse xmlns: bonDeCommande ="http://www.ebXML.org">

61, bd. St Germain, 75005 Paris

</bonDeCommande:adresse xmlns: bonDeCommande ="http://www.ebXML.org">

</bonDeCommande:expeditionxmlns: bonDeCommande ="http://www.ebXML.org">

<contacts:serviceClientxmlns: contacts ="intranet/contacts/xml">

<contacts:adresse xmlns: contacts ="intranet/contacts/xml">

[email protected]

</contacts:adresse xmlns: contacts ="intranet/contacts/xml">

</contacts:serviceClientxmlns: contacts ="intranet/contacts/xml">

Dans cet exemple, les deux namespaces utilisés (bonDeCommande etcontacts) permettent de distinguer les deux types d’adresses utilisésdans le document. La norme définit, de plus, des conventions qui ensimplifient l’écriture. L’exemple précédent peut être en fait récrit sous laforme suivante :

<bonDeCommande:expeditionxmlns: bonDeCommande ="http://www.ebXML.org">

<adresse>

61, bd. St Germain, 75005 Paris

</adresse>

</expedition>

<contacts:serviceClientxmlns: contacts ="intranet/contacts/xml">

<adresse>

[email protected]

</adresse>

</serviceClient>

� Les URL (Uniform Resource Locator)et les URI (Uniform Resource Identifier) sont les conventions qui régissent les adresses et l’identifi-cation des ressources sur le Web. Elles sont définies par l’IETF.

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.

Chapitre 1 – L’architecture des services Web

25

L’attribution d’un namespace est valide pour tous les éléments imbriquésdans l’élément qui y fait référence.

Les namespaces permettent ainsi de résoudre le problème des différenceséventuelles d’interprétation du même document XML par des applica-tions différentes. En s’appuyant sur le dispositif des URI, qui en assurel’unicité, et au prix d’une écriture un peu plus « bavarde », les balises etles attributs XML sont alors dotés d’une interprétation spécifique, nonambiguë.

XML Schema

La recommandation XML Schema, adoptée après de longues discussionsdans les comités techniques du W3C, représente un réel tour de force etune innovation dans l’utilisation d’XML, rompant tout net avec son usageoriginel pour la publication de documents. XML Schema précise commentreprésenter en XML les structures de données en général – ce qu’on al’habitude d’appeler les métadonnées dans le monde des bases de donnéesrelationnelles (description des tables, des colonnes, de leurs types, etc.).

Alors que le DTD ne définit que la structure d’un document XML – essen-tiellement un arbre –, XML Schema a vocation à décrire n’importe quellestructure de données, depuis les modèles relationnels des bases dedonnées jusqu’aux modèles objet des langages de programmation.Reprenant des travaux antérieurs sur XML (XML-Data de Microsoft, RDF1

du W3C, DCD2…) et sur la modélisation des données (SQL3 et ODL/OQL3

de l’ODMG4), XML Schema est adapté à la description des structures dedonnées des documents XML, des bases de données relationnelles, maiségalement à celle des modèles objet des langages de programmationorientés objet comme Java ou C++.

Un schéma XML définit, d’une part, l’imbrication des éléments entre eux– ce qui s’apparente aux DTD – et, d’autre part, le type des éléments et deleurs attributs. L’information fournie par le schéma est donc plus richeque celle trouvée dans le DTD. À titre d’exemple, le DTD suivant :<!ELEMENT Livre (Titre, Auteur, Date, ISBN, Editeur)><!ELEMENT Titre (#PCDATA)><!ELEMENT Auteur (#PCDATA)><!ELEMENT Date (#PCDATA)><!ELEMENT ISBN (#PCDATA)><!ELEMENT Editeur (#PCDATA)>

devient le schéma suivant :

<xsd:element name="Livre"> <xsd:complexType> <xsd:sequence> <xsd:element ref=" Titre " minOccurs="1" maxOccurs="1"/>

� RDF (Resource Des-cription Framework) : recommandation assez ancienne et manquant de généra-lité, adoptée par le W3C en 1999.

� DCD (Document Content Definition) : premier effort de con-vergence entre RDF et XML-Data visant à remplacer le DTD par XML lui-même.

� ODL (Object Defi-nition Language), OQL (Object Query Language) : lan-gages de définition et de manipulation de modèles de don-nées objet.

� ODMG (Object Database Manage-ment Group) : sous-groupe de l’OMG travaillant sur les bases de données orientées objet.

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.

Services Web avec SOAP, WSDL, UDDI, ebXML…

26

<xsd:element ref=" Auteur " minOccurs="1"

maxOccurs="1"/>

<xsd:element ref="Date" minOccurs="1"

maxOccurs="1"/>

<xsd:element ref="ISBN" minOccurs="1"

maxOccurs="1"/>

<xsd:element ref=" Editeur " minOccurs="1"

maxOccurs="1"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="Titre" type="xsd:string"/>

<xsd:element name="Auteur" type="xsd:string"/>

<xsd:element name="Date" type="xsd:string"/>

<xsd:element name="ISBN" type="xsd:string"/>

<xsd:element name="Editeur" type="xsd:string"/>

Dans le schéma, l’information associée aux balises identifie la nature dutexte qu’elles encadrent (ici, le type primitif chaîne de caractères,string), permettant éventuellement des vérifications ou des validationsimpossibles avec la seule DTD. De même, on constate que la définition del’élément est plus précise dans le schéma : on y indique, en particulier, lenombre d’occurrences des éléments imbriqués.

Dans un document XML Schema, chaque balise peut être associée à untype, dit soit primitif s’il fait partie de ceux fournis par la spécification elle-même (booléens, entiers, réels, chaînes de caractères, mais aussi dates,entités, processing instructions et notations des DTD, etc.), soit composé s’il estdéfini par l’utilisateur dans le document XML Schema en question. Ils’agit d’un véritable système de types au sens des langages deprogrammation : des types dérivés peuvent être créés soit par extension,soit par restriction, permettant ainsi de capturer sans ambiguïté lesmodèles, plus complexes, des bases de données et des langages deprogrammation orientés objet. Ces types abstraits sont eux-mêmesdécrits en XML. La spécification définit deux namespaces pour XMLSchema :

• xsd�ou�xs�associé�à l’URI�http://www.w3.org/2001/XMLSchema �

• xsi�associé à l’URI�http://www.w3.org/2001/XMLSchema-instance�

Ces deux namespaces sont utilisés abondamment dans les documentsXML liés à des schémas.

Sa généralité fait la force de XML Schema, aujourd’hui adopté par lesfournisseurs de bases de données relationnelles comme format d’importet d’export des métadonnées et, surtout dans le monde Java, par leséditeurs de serveurs d’applications pour décrire la structure des compo-sants logiciels constitutifs d’une application (l’information de configura-tion), voire comme substitut aux définitions de classes elles-mêmes. Denombreux validateurs de schémas XML existent aujourd’hui et permettent

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.

Chapitre 1 – L’architecture des services Web

27

Figure 1-7. Comment un schéma XML décrit la structureet les types de données d’un document XML.

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.

Services Web avec SOAP, WSDL, UDDI, ebXML…

28

d’automatiser la vérification de la conformité d’un document XML à unschéma donné, déchargeant d’autant le code de l’application qui exploiteau final ces documents.

Nous trouvons ici un premier saut conceptuel important qu’il est essen-tiel de comprendre pour se représenter les fondations techniques desservices Web. Alors que les documents XML « habituels » sont des imagesdes objets du monde réel (bons de commande, factures, etc.) sous formede documents circulant entre applications informatiques, les documentsXML Schema, quant à eux, représentent la structure des données véhicu-lées par ces documents.

Messages XML entre applications et services Web

Pour les services Web, on utilise systématiquement XML avec les Name-spaces et la spécification XML Schema, tous deux indispensables pourexprimer les structures des données habituellement complexes figurantdans les messages échangés.

Dans le mécanisme de transport entre services Web, les requêtes, leursrésultats et les erreurs éventuelles résultant de leur invocation sont tousécrits en XML. Ce sont donc des documents émis par le client vers leservice Web et traités sur le serveur en réponse aux demandes.

Figure 1-8. Comment sont utilisésles schémas XML.

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.

Chapitre 1 – L’architecture des services Web

29

Notons d’emblée que le choix de documents XML comme format pour lesdonnées circulant entre applications clientes et services Web ou entreservices Web présente des avantages sur les middleware de la générationprécédente tels que Corba, RMI ou DCOM. Il n’y a pas de programmationà proprement parler et l’on est loin des mécanismes de compilation parti-culiers que le recours à des RPC1 ou à de tels middleware imposent auxprogrammeurs.

Dans Corba, par exemple, les spécifications de l’objet Corba sont écrites en IDL

pour être compilées en un fragment de programme exécuté sur le poste client

(le stub) et un fragment résidant sur le serveur (le skeleton).

Dans l’architecture EJB, l’usage de RMI requiert une phase de pré-compilation

du code source écrit en Java par un compilateur spécialisé, ����.

De plus, en s’appuyant sur HTTP, on ne se heurte pas aux problèmes depare-feu ou de configuration de réseau IP qui rendent parfois difficile ledéploiement d’applications à objets répartis au-delà du périmètre duréseau d’entreprise.

Le prix à payer pour cette nouvelle fluidité est celui de la complexité dudocument XML et corrélativement celui du coût de son traitement. Sur lepremier point, il est clair que pour parvenir à la même richesse d’expres-sion dans un document texte que dans une requête traditionnelle il fautpouvoir, en XML, décrire la destination exacte de l’appel, préciser les argu-ments éventuels et leur type, la ou les valeurs attendues en retour et leurtype, les codes d’erreur et, plus généralement, expliciter toute information

Fig. 1-9 : L’information circule entre services Web sous forme de documents XML.

CORBA

EJB

� RPC (Remote Procedure Call) : appel via un réseau d’une procédure ou d’un programme exécuté sur une machine distante (ou dans un espace d’adresses différent sur la même machine).

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.

Services Web avec SOAP, WSDL, UDDI, ebXML…

30

de contexte requise par le serveur. Tout cet habillage XML est d’autantplus épais que les données passées entre services Web sont a prioricomplexes (références à d’autres messages, types de données complexes,pointeurs, etc.). Sur le second point, indépendamment de la complexitééventuelle des messages XML, ceux-ci restent néanmoins interprétés à leurréception : ils doivent être analysés avant le déclenchement des traite-ments. Cette analyse est effectuée par un interpréteur XML, ou parseur, quidécode les balises XML et qui exécute les commandes correspondantes.Cette étape d’interprétation n’existe pas dans le cas du middleware où lesphases de compilation supplémentaires évoquées plus haut permettentprécisément le lien direct entre le message et le traitement à exécuter. Laperformance s’en ressent donc nécessairement un peu, même si un docu-ment XML peut, à lui seul, remplacer une salve d’appels RPC traditionnelsau travers d’un middleware.

Classification des services Web

La facilité d’emploi d’XML et sa flexibilité dans la représentation detoutes sortes de données ont donné lieu à une prolifération de dévelop-pements autour des interpréteurs XML et des scénarios d’usage des docu-ments XML depuis la fin des années 1990. On peut distinguer grossière-ment deux natures de travaux : d’une part, au sein du W3C, un effortcollectif de standardisation technique et de stabilisation des technolo-gies XML au moyen d’un processus discipliné de soumission et de ratifi-cation et, d’autre part, des initiatives au départ commerciales, regroupantplusieurs acteurs industriels d’un secteur donné, pour s’entendre sur unformalisme XML adapté à leurs domaines d’activité.

Le W3C promulgue des recommandations, fruit d’un travail de réflexion et destandardisation technique, qui sont des spécifications techniques publi-ques souvent adoptées rapidement par les éditeurs de logiciels (qui parti-cipent également à leur élaboration dans les comités techniques del’organisation). XML, les Namespaces et XML Schema, précédemmentcités, sont des exemples de telles recommandations. Ces spécificationssont toutes techniques en ce qu’elles précisent comment XML peut etdoit être utilisé dans les applications informatiques réparties sur le Webpour représenter et manipuler les abstractions indispensables mais indé-pendantes du secteur d’application.

Par contraste, les initiatives industrielles proposent souvent des vocabu-laires XML pour des usages spécifiques dans tel ou tel secteur ; elles n’ontd’ailleurs de force que celle de leurs membres industriels, dont lesintérêts commerciaux, variant avec le temps, peuvent conduire aussi bienà leur renforcement qu’à leur affaiblissement. Ainsi de nombreuses initi-atives de standardisation lancées précipitamment au début des efforts de

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.

Chapitre 1 – L’architecture des services Web

31

stabilisation d’XML ont rapidement périclité. D’autres, qui ont réuni unplus grand nombre de participants comme BPMI1 ou qui ont mutualisé lesefforts de grands acteurs comme ebXML2, sont aujourd’hui à l’avant-gardedes services Web.

En suivant donc à la fois l’évolution de cet historique récent de la généra-lisation d’XML dans l’industrie informatique et le modèle largementrépandu de l’architecture à objets répartis, nous sommes amené à distin-guer trois classes générales de services Web pour lesquelles XML estemployé avec, pour chacune, des visées différentes :

• Les services de communication et de transport (SOAP), véritable sys-tème nerveux dans lequel circulent les données à l’intérieur de mes-sages XML.

• Les services techniques : des services utilitaires indispensables au bonfonctionnement de l’assemblage des services Web, comme lesannuaires UDDI, par exemple.

• Les services métier : des services spécifiques soit à des applications ver-ticales dans un secteur d’activité donné (RosettaNet), soit à des scéna-rios mutualisés entre applications (ebXML), comme le paiementélectronique.

Cette classification reflète, à l’échelle des entreprises connectées sur leWeb, l’architecture des applications internes connectées au réseau local

Figure 1-10. Trois classes de services Web génériques (transport, technique et métier) pour les applications de l’entreprise.

� BPMI (Business Process Manage-ment Initiative) : large consortium réuni autour de la spécification en XML des processus métier intra et inter-entreprises, comp-tant fin 2001 plus de 80 membres.

� ebXML (Electronic Business XML) : ensemble de spécifi-cations fondées sur XML, destinées à faci-liter le commerce électronique interen-treprise.

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.

Services Web avec SOAP, WSDL, UDDI, ebXML…

32

de l’entreprise. La similarité de cette architecture de l’informatique inter-entreprise et du système d’information interne peut d’ailleurs être mise àprofit pour l’intégration d’applications ou pour la mise en ligne d’applica-tions conçues antérieurement au Web. Au prix de la traduction des API deces applications en XML, on rénove à bon marché les logiciels préexis-tants sans remettre en cause leur rôle, tout en leur permettant de se join-dre au chœur des nouveaux services Web dédiés aux activités en ligne.

On peut mettre en parallèle l’architecture de composants logiciels (ayantd’ailleurs elle-même émergée des travaux sur les langages de programma-tion orientés objet puis sur les systèmes d’objets répartis) et l’architecturedes services Web. Les services Web sont les « nouveaux » composantslogiciels dans un système d’interactions fondé sur le Web. La nature parti-culière de cette infrastructure Web (hétérogénéité du réseau, protocole decommunication simpliste, problèmes de sécurité et d’authentification,nature ad hoc des interactions par opposition à des relations systémati-ques entre nœuds du réseau, etc.) impose des contraintes à ces nouveaux

Figure 1-11. Au niveau du système d’information de l’entreprise et à celui des échanges interentreprises, les architectures sont similaires.

� API (Application Programming Interface) : interfaces de programmation au travers desquelles on pilote les applica-tions.

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.

Chapitre 1 – L’architecture des services Web

33

composants logiciels et justifie des modes d’assemblage particuliers,tous relativement différents de celles et de ceux employés dans lescomposants logiciels et les serveurs d’applications de l’échelon directe-ment inférieur. Néanmoins, les composants logiciels (Corba, DCOM, EJB)et leurs plates-formes d’assemblage et d’exécution, les serveurs d’applica-tion au sens le plus large, sont les meilleurs outils d’implémentation desservices Web. En liaison avec le W3C et diverses initiatives visant à définirles services Web, et, en particulier, leur représentation dans les standardsXML, les constructeurs et les fournisseurs comme Microsoft, IBM ou Sunse sont activement lancés dans le développement de plates-formesd’assemblage et d’exécution de services Web, visant à implémenter lesnouveaux composants logiciels à l’aide des anciens. C’est le sens desannonces telles que .NET de Microsoft, SunONE de Sun ou des évolutionsrécentes de WebSphere d’IBM et de WebLogic de BEA.

Figure 1-12. Des objets répartis aux services Web, une superpositionde systèmes à base de composants logiciels.

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.

Services Web avec SOAP, WSDL, UDDI, ebXML…

34

Les services de communication et de transport

Comme nous l’avons vu, le transport de données sur le Web doit s’accom-moder de protocoles moins riches que ceux des middleware employés ausein des réseaux internes de l’entreprise. Dans cette couche de transport,XML est utilisé pour décrire la structure des messages échangés entreservices Web. Le message est constitué de l’identifiant de son destina-taire et du nom de l’opération invoquée, de la liste des arguments éven-tuels et des valeurs de retour attendues, ainsi que des paramètres supplé-mentaires optionnels nécessaires à son traitement du côté du serveur.

Dans le langage de la norme Corba, ce message est une requête qui invoque

une opération donnée sur un objet localisé sur un serveur distant. On parle éga-

lement d’invocation dans les protocoles RPC classiques comme RMI ou objet

comme DCOM.

Les premières tentatives, comme XML-RPC, ont rapidement convergé ausein du W3C autour de SOAP (Simple Object Access Protocol) devenu un stan-dard de facto pour l’expression de messages en XML entre services Web.SOAP, dont Microsoft est à l’origine, est l’un des piliers de son architec-ture .NET et se trouve progressivement adopté par les autres grandsacteurs de l’industrie comme Sun – après de fortes réticences initiales –ou le consortium ebXML, par exemple.

SOAP est un protocole léger d’échange de données et de structures dedonnées entre nœuds d’un réseau (de client à serveur ou de serveur àserveur) en XML. La spécification SOAP précise :

CORBA

Figure 1-13. SOAP décrit la structure des messages XML échangés entre services Web.

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.

Chapitre 1 – L’architecture des services Web

35

• Les en-têtes des messages, ou « enveloppes » : quel est le message et quiest le destinataire.

• Les règles de codage des types de données : comment représenter unentier, un tableau, un graphe d’objets, etc.

• Des conventions pour la représentation d’appels de procédures distantset pour le renvoi du résultat ou des erreurs de leur exécution.

• Des règles pour transporter les messages SOAP sur le protocole HTTP.

Pour l’adressage ou le routage des messages, les en-têtes SOAP utilisentles URL et les URI ; pour le protocole régissant le dialogue entrel’émetteur et le récepteur, les messages SOAP sont transportés dans desrequêtes HTTP classiques ; pour la description des types des donnéesconstituant les arguments, SOAP s’appuie sur XML Schema et lesNamespaces. Bien que dans l’esprit des concepteurs les messages SOAPsoient plutôt véhiculés par HTTP, rien ne s’oppose dans la spécification àce que d’autres protocoles soient employés. Le projet Open SourceApache offre aussi, par exemple, une implémentation de SOAP sur SMTP.

SOAP est donc au cœur de l’échange des messages entre applications surle Web, orchestrant données en XML et protocole de communication avecHTTP. Il peut également être utilisé pour la communication entre applica-tions à l’intérieur de l’entreprise sur le réseau local , par exemple, pour lierun portail d’entreprises aux informations gérées par d’autres applicationsdéjà en place.

Il existe d’autres standards et couches de transport de message importan-tes pour les services Web. Alors que SOAP est utilisé pour échanger desmessages XML circulant sur le Web, d’autres middleware peuvent égale-ment être employés par les services Web, souvent dans le cas d’une appli-cation intranet. L’invocation de composants logiciels EJB via RMI est utili-sable pour connecter un service Web à une application existante,développée en Java. Les middleware orientés messages traditionnelscomme MQ Series d’IBM ou MSMQ dans l’architecture .NET de Microsoftpeuvent aussi être employés à la place de SOAP et de HTTP – ce qui estprobablement plus pertinent pour une application intranet. De plus,certains services métier offrent eux-mêmes une gestion de messagesparfois spécifique (comme RNIF dans RosettaNet), ou encore une spécia-lisation de SOAP comme BizTalk de Microsoft, mais, là encore, en XML.

� SMTP (Simple Mail Transfer Protocol) : protocole le plus répandu pour l’envoi de messages électro-niques ente serveurs via Internet.

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.

Services Web avec SOAP, WSDL, UDDI, ebXML…

36

Les services techniques

Les services Web, qualifiés ici de techniques, sont les composants indis-pensables au bon fonctionnement des échanges entre services et applica-tions sur le Web. XML est ici utilisé pour les fonctions suivantes :

• décrire et nommer les services ;

• sécuriser et authentifier l’accès aux services ;

• exprimer les relations entre services ;

• classer et rechercher les services dans des annuaires.

Chacune de ces opérations est codifiée dans des documents XML, chaqueclasse de fonctions étant associée à un jeu de balises spécifique par unDTD approprié.

Ces services Web techniques rappellent évidemment les CorbaServices de

l’architecture de l’OMG. Ces derniers peuvent naturellement être employés dans

l’implémentation des services Web techniques.

CORBA

Figure 1-14. Les services Web techniques mettent en œuvre des langages XML spécialisés. Ils visent souvent soit à décrire les structures de données échangées, soit la dynamique même de ces échanges

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.

Chapitre 1 – L’architecture des services Web

37

Les standards les plus importants pour ces services Web techniques sontles suivants :

• WSDL (Web Service Description Language), pour définir précisément un ser-vice Web (quelconque) : son adresse et son identité, les opérations quel’on peut invoquer et leurs arguments (types des données, valeurs deretour, codes d’erreur), etc.

• UDDI (Universal Description, Discovery and Integration) pour créer et interrogerdes annuaires contenant la description des services Web eux-mêmes.

• DSML (Directory Services Markup Language) pour créer des annuaires deressources internes à l’entreprise en XML, compatibles, notamment,avec la norme LDAP1.

• BPML (Business Process Modelling Language) et BPQL (Business Process QueryLanguage) pour décrire des processus métier complets mettant éventuel-lement en jeu plusieurs entreprises connectées et plusieurs autres ser-vices Web distants.

• Les langages de contrat définissant les relations statiques (participants,rôles et responsabilités) entre services Web, souvent couplés à BPMLpour couvrir la dynamique du processus métier. Citons les deux DTDconcurrents XLANG, pour le serveur BizTalk de l’architecture .NET, etWSFL (Web Services Flow Language) d’IBM.

Certains services en cours de formalisation comme XKMS (XML KeyManagement Specification) – une note du W3C soumise par Verisign,Microsoft et WebMethods – pour l’enregistrement et la distribution declés PKI2 ; XAML (XML Transaction Authority) pour la description de transac-tions en XML entre serveurs ; WSUI (Web Services User Interface) pour laprésentation et la description des interactions entre utilisateurs et servi-ces Web.

On trouve également des services techniques faisant presque doubleemploi avec certains de ceux que nous venons de lister, dans des dévelop-pements XML propriétaires de certains éditeurs ou dans des propositionsantérieures aux standards précités. Citons par exemple BizTalk de Micro-soft, e-speak de H.P. ou encore ebXML pour le commerce électronique.L’heure est néanmoins à la compatibilité entre ces standards et ces initia-tives indépendantes – voire à la mise en conformité avec la suite SOAP,UDDI, WSDL, DSML, BPML.

Dans l’architecture de services Web, WSDL joue un rôle comparable à l’IDL de

la norme Corba, employé pour décrire l’interface publique des objets ; UDDI et

DSML peuvent être comparés aux Naming et Trader Services.

L’analogie avec l’architecture DCOM à objets répartis sous Windows est moins

claire. On trouve néanmoins dans DCOM un langage de description d’interfaces

des objets (IDL), des conventions pour les identifiants des objets (UUID3) com-

parables à WSDL, LDAP lui-même, etc.

CORBA

DCOM

� LDAP (Lightweight Directory Access Protocol) : l’API stan-dard d’accès aux annuaires des res-sources informati-ques internes de l’entreprise (machines, profils des utilisateurs, groupes et privilèges, etc.).

� PKI (Public Key Infrastructure) : infrastructure de chif-frement de données à clés publiques d’usage maintenant généralisé.

� UUID (Universal Unique Identifier) : numéro unique de 128 bits associé à chaque objet DCOM.

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.

Services Web avec SOAP, WSDL, UDDI, ebXML…

38

Dans le cas de l’architecture EJB, le langage de description d’interfaces est Java

lui-même et les services techniques fonctionnellement équivalents se trouvent

dans les bibliothèques constituant la plate-forme J2EE1.

L’hétérogénéité intrinsèque du Web et la complexité des transactionsWeb, liant a priori de multiples participants, entraînent une séparationplus fine des niveaux de représentations, chacun se trouvant doté de sonbalisage XML propre. On distingue ainsi plusieurs échelons dans l’empi-lement (le stack) des protocoles :

• La description en WSDL du service lui-même, c’est-à-dire des opéra-tions et de leurs signatures, dont le serveur est responsable.

• La description du serveur lui-même, « enrobant » la description du ser-vice d’informations supplémentaires sur le contexte et les scénariosd’usage du service – par exemple, de paramètres ayant trait à la qualitéde service, à la nature transactionnelle ou non des opérations du ser-vice, aux informations de trace et d’audit disponibles, etc. Ces descrip-tions font habituellement partie des documents WSDL liés au serviceconsidéré.

• La description de la mise en œuvre de différents services sur le Web envue d’une application ou d’un processus métier particulier. On parlealors d’orchestration ou de chorégraphie, tout comme dans un concertou dans un ballet ! Là encore, on distingue habituellement deux sous-niveaux : celui décrivant les messages échangés par les différents ser-vices à orchestrer – ce sont des spécifications comme XLANG chezMicrosoft ou WSFL chez IBM – et celui décrivant les séquences d’envoiet de réception de ces messages, les aspects de synchronisation et detransactions entre services – c’est le royaume de BPML pour la capturedes processus métier intra ou interentreprises.

Tous ces services sont compatibles avec SOAP, même si certains d’entreeux, WSDL en particulier, peuvent se contenter d’un simple canal HTTP oud’échanges au format MIME (Multipurposes Internet Mail Extensions). Dans desconfigurations intranet, tous peuvent également employer lesmiddleware précédemment évoqués (Corba-IIOP, DCOM, RMI) commeservice de transport et de communication.

Les services métier

De même qu’il est intéressant de mutualiser un ensemble de fonctionstechniques indispensables aux applications réparties sur le Web sousforme de services indépendants et standards, il peut être également avan-tageux de partager des services ayant trait à certaines grandes fonctionsde l’entreprise, quel que soit son secteur d’activité. Ces fonctions sont

EJB

� J2EE (Java 2 Enterprise Edition) : plate-forme Java incluant tous les bibliothèques néces-saires au développe-ment d’applications d’entreprise.

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.

Chapitre 1 – L’architecture des services Web

39

généralement liées au commerce électronique et visent finalement àreproduire dans le monde virtuel les transactions commerciales dumonde réel (transactions, contrats, facturation, paiement, etc.).

Ce qui ne va pas sans rappeler bien sûr les fonctions des ERP (progiciels de ges-

tion intégrés), dont, de façon concomitante, les éditeurs sont tous engagés dans

la course à la mise en ligne de leurs produits (portails mySap.com de SAP ou

sales.com de Siebel, par exemple). Ces concepts rappellent également le projet

San Francisco lancé il y a de cela quelques années par IBM pour engager les

éditeurs de progiciels proches du géant d’Armonk à une récriture en Java de

leurs offres.

Les services Web métier mettent à la disposition des développeursd’applications Web tout un ensemble de spécifications et de moteursd’exécution facilitant le déploiement d’applications Web réparties dansdes secteurs particuliers ou pour des processus métier verticauxidentifiés :

• citons à nouveau BPML et BPQL du consortium BPMI, dont une partiedes spécifications couvre la synchronisation et la mise en parallèle detraitements dans les processus métier traversant plusieurs entreprises(comme la gestion de la relation client ou la chaîne logistique) ;

• e-speak de H.P. dont l’un des points intéressants est l’accent porté surla mise en ligne d’applications préexistantes et l’habillage XML d’API etde bibliothèques de programmation ;

• BizTalk de Microsoft, dont l’objectif est de formaliser les échanges élec-troniques de documents professionnels (factures, bons de com-mande…) entre applications Web réparties ;

• ebXML et RosettaNet, spécifications protéiformes visant à formaliser enXML une infrastructure complète pour le commerce électronique.

Dans l’architecture à objets répartis de l’OMG, les services Web métier sont com-

parables aux CorbaFacilities et aux Domain Services.

Comme les différents efforts de spécification des services Web métier ontparfois commencé avant ceux de standardisation du W3C sur les aspectstechniques, on détecte de nombreuses zones de recouvrement entre servi-ces Web métier et techniques. Du coup, on assiste aujourd’hui soit à unemise en conformité des uns avec les autres (BizTalk, par exemple, dans saseconde livraison a été rendu compatible avec SOAP), soit à une absorp-tion pure et simple (ebXML récupérant tpaML ou des membres de Roset-taNet déclarant vouloir se conformer aux spécifications ebXML).

EJB

CORBA

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.

Services Web avec SOAP, WSDL, UDDI, ebXML…

40

Le développement des services Web

À cette étape de la présentation de l’architecture des services Web, il fautrappeler que celle-ci, rendue nécessaire par l’appropriation rampante desprotocoles du Web par l’informatique d’entreprise, se place délibérémentdans la lignée des réflexions et de l’élaboration des systèmes à objetsrépartis et, à la génération suivante, de l’architecture à composants logi-ciels.

Cet alignement peut en effet être qualifié de volontaire puisqu’il est en faitanimé, avec des visées évidemment commerciales, par ces mêmes acteursde l’industrie informatique qui avaient auparavant investi dans les objetsrépartis et dans les composants logiciels. Pour la plupart de ces acteursindustriels, les services Web sont, en effet, présentés comme une étape

Figure 1-15. Les spécifications XML des services Web métier.

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.

Chapitre 1 – L’architecture des services Web

41

supplémentaire dans l’évolution naturelle des composants logiciels. Ce« positionnement » apparaît d’autant plus légitime que le Web est, paressence, le nec plus ultra de l’infrastructure répartie. De plus, les services enligne ou les applications Web ont probablement été développés indépen-damment les uns des autres, dans une cacophonie de technologies dontles protocoles Web constituent, en quelque sorte, le plus petit commundénominateur (TCP/IP, le format texte HTTP et XML). Ils ont été mis enservice à des moments différents, et seront certainement mis hors ligneou remplacés de manière imprévisible.

Le développement de services Web ou d’applications Web exige donc,plus encore que pour les applications client-serveur ou que pour les appli-cations à objets répartis, un processus formel et une discipline d’exécu-tion des plus précises. Les méthodologies et les outils créés dans lesannées 1990 pour les applications réparties se trouvent ici particulière-ment adaptés à la nouvelle architecture. UML et la méthodologie à basede cas d’utilisation (use cases), par exemple, sont particulièrement utilesdans l’analyse et la conception d’applications Web réparties ; l’insistanceméthodologique sur la réutilisation correspond directement à l’impor-tance centrale de la notion de service Web.

D’autres notations graphiques sont également devenues populaires pour« dessiner » les processus métier ou le workflow entre services Web, portéespar la diffusion du BizTalk Server de Microsoft (reprenant l’interface deVisio, le produit de la société éponyme rachetée par Microsoft) et parl’adoption de la spécification BPML dans le monde hors .NET. La repré-sentation des services Web, ainsi que celle des échanges de messages etde leurs séquences sont ainsi codifiées graphiquement pour engendrerautomatiquement les documents WSDL, BPML, XLANG ou WSFL corres-pondants.

Le déploiement des services Web

Le déploiement de services Web s’accommode aussi bien d’une plate-forme légère, un serveur Apache et quelques extensions par exemple, quede serveurs d’applications d’entreprises pour des applications plus impor-tantes. Au cœur des unes et des autres se trouve le moteur ou « parseur »XML, capable de déchiffrer les documents XML.

Parmi les solutions légères souvent mises en œuvre pour construire desservices Web et des applications Web, on trouve, par exemple :

� UML(Unified Modeling Language) : la nota-tion graphique stan-dard employé dans les méthodologies de développement orienté objet.

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.

Services Web avec SOAP, WSDL, UDDI, ebXML…

42

Bien sûr, la prolifération d’implémentations aisément accessibles – laplupart sont sous la licence GPL Open Source – facilite l’expérimentationet l’apprentissage de ces nouveaux standards. Notons quand même quele niveau de support de la norme SOAP (version 1.0, 1.1 ou 1.2) varie bienévidemment d’une implémentation à l’autre et que ces dernières n’offrentpas toujours de garanties de mises à jour.

L’autre approche du déploiement de services et d’applications Webs’appuie sur des serveurs d’applications, comme WebSphere d’IBM,WebLogic de BEA, iPortal d’IONA, ou sur des plates-formes d’exécutionde composants logiciels comme .NET de Microsoft, J2EE/EJB et ONE deSun ou encore sur des implémentations de la norme Corba.

Le développement et l’implémentation de services Web sont en effet faci-lités par le recours à l’architecture technique à base de composants logi-ciels. Le « grain » des composants logiciels, comme les EJB ou les objetsCorba, correspond finalement assez bien à celui d’un service écrit enWSDL, et de son accès via SOAP.

Produit/projet Descriptif

Apache SOAP Module dotant le serveur Web Apache de l’infrastructure nécessaire à l’envoi et à la réception de messages SOAP

SOAP::Lite, UDDI::Lite, XMLRPC::Lite

Collection de modules Perl pour l’implémentation de SOAP, de UDDI et de XML-RPC

Classes PHP pour SOAP, PHPSOAP, SOAPx4

De divers projets Open Source, des bibliothèques PHP pour la réalisation de serveurs SOAP

SOAP for Python, SOAP.py, SOAPy

Diverses bibliothèques SOAP pour le langage Python

WebService for ZOPE Un développement Open Source visant à étendre l’outil de gestion de contenu Zope pour SOAP, WSDL et les autres standards des services Web

WSTK d’IBM Web Services Toolkit d’IBM

SOAP Toolkit de Microsoft Permet indifféremment l’emploi de Visual Basic, C++ ou C# pour développer des services Web

WhiteMesa SOAP for RPC, Business Integration Plat-form (Shinka Technologies)

Bibliothèques C++ pour client SOAP et serveur SOAP comme service sous NT. Met également en œuvre WSDL.

SOAP for Ada Implémentation de SOAP en Ada

Smalltalk Web Services Implémentation Open Source de SOAP et WSDL dans le langage de programmation orienté objet Smalltalk

Autres outils De nombreuses autres implémentations de SOAP/WSDL pour Java, C, C++ sont disponibles sur le Web : voir par exemple le site www.soapclient.com, rubrique Toolkits.

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.

Chapitre 1 – L’architecture des services Web

43

De plus, la participation des grands acteurs de l’industrie, dont Microsoft,à l’élaboration de ces standards (au design SOAP en particulier) garantitque l’intégration aux architectures techniques des constructeurs ne serapas le parent pauvre de leurs efforts de développement. De même, l’OMGtravaille aujourd’hui à l’utilisation de SOAP en conjonction avec la séman-tique des appels entre programmes et objets Corba, et à XMI1 pour échan-ger les modèles de données entre services Web.

Enfin, l’environnement réparti dans lequel sont exécutés les applicationset les services Web met naturellement en avant des besoins de gestion dela concurrence d’accès, de gestion des transactions, courtes ou longues,de persistance de l’état des échanges, de sécurité et d’authentification desacteurs de ces échanges Web, etc. Ces services, de nature technique, cons-tituent l’infrastructure nécessaire minimale à l’exécution de services Web.Ils sont aujourd’hui fournis par les serveurs d’applications. Nombreux sontainsi les acteurs industriels dont les efforts visent à donner à leursproduits la fonctionnalité de serveur d’applications Web. Une classifica-tion (non exhaustive !) rapide permet de distinguer :

• Les éditeurs de bases de données, essentiellement relationnelles, cons-truisant autour de SGBD transactionnels l’infrastructure technique XMLrequise pour l’intégration dans l’architecture UDDI/WSDL/DSML/SOAP(Oracle est l’exemple typique, mais IBM avec le rachat d’Informix en2001, ou Sybase avec celui de NEON illustrent la même stratégie).

• Les grands éditeurs de middleware traditionnels (moniteurs transac-tionnels ou message queuing) adoptant XML pour l’intégration auxapplications Web (BEA, Vitria, Tibco, sont des exemples de cette caté-gorie, mais IBM avec MQSeries ou Progress avec Sonic également).

• Les éditeurs de systèmes d’exploitation, Sun, IBM et Microsoft, parexemple, cherchant à généraliser leur plate-forme d’exécution d’appli-cations réparties à l’échelon supérieur du Web en intégrant à leurs ser-vices préexistants la génération et l’interprétation d’XML et desstandards qui en dérivent (c’est le passage de COM à DCOM puis à .NETchez l’éditeur de Redmond et l’évolution de J2EE et EJB vers ONE chezSun, par exemple).

• Les éditeurs de logiciels de la sphère d’influence Corba, poursuivantl’adaptation des implémentations Corba au réseau et aux protocoles duWeb (citons des sociétés comme Iona ou CapeClear).

• Une nouvelle génération de start-up dont les produits sont directementconçus comme architecture de services Web et n’ayant pas à s’embar-rasser de l’adaptation de produits antérieurs (citons, ici aussi sansexhaustivité, BowStreet, Intalio, CapeClear, etc.).

Cette activité effrénée pourrait laisser une impression de désordreporteuse de menaces pour l’adoption de cette nouvelle architecture. Iln’en est rien car le Web étant déjà en place et poursuivant son développe-ment, dans l’architecture Web, plus encore que dans l’architecture à

� XMI : XML Meta-data Interchange Format.

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.

Services Web avec SOAP, WSDL, UDDI, ebXML…

44

composants logiciels, chacun a, d’un point de vue économique, intérêt àse rendre compatible avec le plus grand nombre (l’effet réseau), et, parconséquent, à respecter les protocoles et standards – d’ailleurs soushaute surveillance du W3C ou de l’OMG.

Les moteurs XML

La clé de voûte de l’édifice architectural des services Web se trouve, bienentendu, dans le moteur XML capable d’interpréter les documents auxdifférents formats standardisés. Ce moteur est générique : il accepte toutdocument XML et écrit un document XML suivant tous les formats etstandards précédemment mentionnés.

Il existe deux implémentations différentes du moteur XML :

• Les parseurs de type SAX (Simple API to XML), dans lesquels chaque baliselue dans le document XML déclenche l’exécution d’une procédure dansle programme.

• Les parseurs de type DOM (Document Object Model) construisant, au con-traire, une image complète du document en mémoire sur laquelle leprogramme vient ensuite travailler.

SAX est une API normalisée dont les bibliothèques de programmationsont disponibles pour de nombreux langages. SAX est dit piloté par les événe-ments (event driven). Avec SAX, le programmeur n’écrit que les procédures etles fonctions à exécuter lorsque le parseur rencontre une balise donnée. Àchaque classe de documents XML correspond alors un jeu de procédureset de fonctions.

Dans le cas de DOM, une API également formalisée mais par le W3C,l’approche est différente : la lecture du document XML crée en mémoireune représentation hiérarchique du document et de l’imbrication de sesbalises, sous forme d’une structure de données arborescente. Leprogramme peut ensuite examiner et modifier cette structure arbores-cente et, éventuellement, écrire automatiquement un document XML quila reflète.

SAX DOM

Accès séquentiel au document XML Conversion en objets du langage de programmation

Piloté par les événements Séquence : lecture, traitements, écriture

Callbacks API

Pas de représentation en mémoire Document XML entièrement en mémoire

Léger Lourd (CPU, mémoire)

Serveurs, filtre de données Applications, environnements auteur, administration

Programmation délicate Programmation traditionnelle

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.

Chapitre 1 – L’architecture des services Web

45

Les avantages et les inconvénients de chaque type de parseur sont clairset le choix de l’un ou de l’autre dépend du compromis à trouver pour uneapplication donnée. Notons que la plupart des éditeurs ou des construc-teurs précédemment mentionnés fournissent des parseurs XML, souventdotés des deux API, pour une grande variété de langages de programma-tion, ce qui en facilite la diffusion. Il existe également de nombreuxmoteurs XML Open Source ou à télécharger en ligne.

Les serveurs d’applications

L’implémentation des services Web repose finalement sur la bonne inté-gration technique de moteurs XML aux serveurs d’application. Le traite-ment des documents XML bénéficie ainsi de toutes les propriétés (tran-saction, sécurité, persistance, etc.) requises pour des applications Webintranet ou interentreprises.

C’est précisément parce qu’elle ouvre un tout nouveau champ de dévelop-pement aux fournisseurs d’infrastructure d’applications d’entreprise que

Figure 1-16. L’architecture globale des services Web.

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.

Services Web avec SOAP, WSDL, UDDI, ebXML…

46

cette intégration de moteurs XML, couplée à la stabilisation des stan-dards, donne lieu à de grandes manœuvres marketing et commercialesdestinées à attirer programmeurs et utilisateurs. L’architecture .NET deMicrosoft, l’architecture ONE de Sun/iPlanet, e-speak de HP ou WebS-phere d’IBM sont les icônes de ces nouveaux développements.

Les passerelles entre l’architecture de services Web et l’infrastructuretechnique des serveurs d’applications constituent un secteur en pleineeffervescence. Diverses initiatives visent à élever une « façade » communeaux bases de données, aux annuaires, aux traitements et aux documentsdans une tentative, non pas d’uniformisation, mais de complète interopé-rabilité sur le Web.

Il n’en reste pas moins que les normes techniques Corba, EJB ou DCOMsont aujourd’hui bien plus complètes avec une plus grande disponibilitécommerciale que leurs équivalents XML. Le succès des applications etdes services Web repose, pour une grande part, sur la qualité techniquede l’infrastructure sous-jacente dans les entreprises. Il n’est donc passurprenant que les questions d’intégration d’applications et de choix deserveurs d’applications soient plus que jamais au centre des préoccupa-tions de l’entreprise.

Extraitdel'ouvrageServicesWebavecSOAP,WSDL,UDDI,ebXML...deJean-MarieChauvet,©Eyrolles,2002.