L architecture des services Web

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 analogie, le renouvellement de l architecture informatique exprime la convergence, à 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 surprenant 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 apparition 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. 13

Services Web avec SOAP, WSDL, UDDI, ebxml Les applications B2B (business-to-business) : applications ou sites Web plutôt destinés au commerce entre entreprises. Les places de marché (marketplaces ou exchanges) : sites Web visant à automatiser les transactions et les échanges entre un grand nombre d entreprises. Les ASP (Application Service Providers) : hébergeurs d applications d entreprise (ERP, messagerie, groupware ), auxquelles une entreprise peut accéder via Internet moyennant un abonnement. Les applications P2P (peer-to-peer) : applications utilisant Internet et les postes clients qui y sont connectés comme support de calcul massivement parallèle pour des traitements complexes (analyse des résultats de 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 finalement discerner qu une forme de baroquisme accompagnant la transformation architecturale fondamentale de l application informatique en service Web. En effet, toutes ces propositions reposent techniquement sur la possibilité 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 les pare-feu, mais plus encore, de les disposer sur tout le Web lui-même, leur confé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, les consommateurs ont un accès pratiquement direct aux informations détenues par les producteurs. De nouveaux canaux de distribution viennent alors se substituer aux intermédiaires traditionnels. Le flot d information croissant, orienté vers les clients et les consommateurs, change la nature des relations entre acheteurs, fournisseurs, distributeurs, partenaires, sous-traitants, etc. Les entreprises qui mettent à profit ces technologies pour fournir, traiter, qualifier et publier cette information seront celles qui bénéficieront au final de ce changement d équilibre dans la chaîne de valeur ajoutée. L exemple de la banque dite de dépôt illustre cette mutation. Après avoir longuement mûri leurs stratégies qui pouvaient être initialement perçues comme incompatibles avec le maintien d un réseau d agences, presque toutes les banques de dépôt offrent aujourd hui à leurs clients l accès à la consultation de leurs comptes par une variété de moyens directs : téléphone, portable WAP, site Web, Minitel. Plutôt que de créer de nouvelles applications pour chacun de ces canaux de diffusion, le département informatique avisé aura mis en œuvre la même application 14

Chapitre 1 L architecture des services Web une application Web au travers d un ou de plusieurs services Web chargés d adapter la présentation de l information au canal de distribution et aux profils des utilisateurs (customization). Ainsi, l utilisateur final dispose de l information dont il a besoin quel que soit son mode d accès. Les technologies des services Web permettent d automatiser cette adaptation, réduisant d autant le coût de la diffusion de l information exigée par le consommateur. Figure 1-1. Application Web déployée sur de multiples canaux de diffusion. Cette approche se révèle même plus avantageuse, puisque, toujours sans 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 commercialisation de produits financiers. Ainsi, un nouveau service Web, à vocation B2B, faisant appel aux mêmes applications que précédemment, pourrait être destiné à des compagnies d assurances partenaires de la banque de dépôt dans la commercialisation de certains produits financiers auprès des particuliers. Cette forme d agrégation de produits et de services est également illustrée par le scénario de l agence de voyages. L agence propose en effet à sesclients 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, des billets de train, des voitures de location, assurances, etc. Les données nécessaires à l élaboration d un voyage personnalisé proviennent de fournisseurs différents (compagnies aériennes, chaînes hôtelières, etc.). Filtrées, choisies, adaptées aux exigences du consommateur et aux tarifications négociées entre les différents partenaires tarifs euxmêmes soumis à des mises à jour, elles servent ensuite de base à la facturation. 15

Services Web avec SOAP, WSDL, UDDI, ebxml Figure 1-2. Application Web comme agrégation de services Web. Dans ce cas, comme dans le précédent, l application Web consultée directement par le client de l agence de voyages résulte de la mise en œuvre de services 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 les services Web automatisent complètement. Une application Web résulte alors de l assemblage de services Web, certains développés en interne et d autres fournis par des partenaires externes. Aux deux extrémités de cette échelle, on trouve le tout interne (intégration d application d entreprises ou EAI) et le tout externe (portail). Pour les applications Web, développer, c est assembler et déployer, c est publier. Évolution et révolution Les caractères révolutionnaires (universalité et ubiquité) d Internet et du Web constituent une étape supplémentaire dans la chaîne évolutive qui a déjà mené, en quelques décennies, l application monolithique du main- 16

Chapitre 1 L architecture des services Web frame, en passant par le client-serveur et l architecture à trois niveaux, aux assemblages d objets répartis (Corba, DCOM et EJB) et à leurs serveurs d application. CORBA Le terme de service apparaît déjà dans le livre blanc Object Management Architecture de l OMG 1 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 protocoles, des langages et des interfaces progressivement plus riches et plus raffinées, ouverts ou jalousement propriétaires, le Web impose des moyens de communication autrement plus rustiques : débit comparativement moins haut, temps de latence, défaillances, protocole HTTP d une sobriété dégrisante après certains «excès» de complexité des protocoles RMI, DCOM ou IIOP. À la fin des années 1980, l industrie du logiciel était agitée par le débat entre les interfaces graphiques riches mais consommatrices de ressources, comme dans Windows, et les pages HTML, peut-être simplistes, mais accessibles à partir d un navigateur Web léger et universel. De même, l heure est aujourd hui à la recherche d un compromis satisfaisant entre les besoins complexes des applications d entreprise et les contraintes de simplicité du Web, garantes de son universalité. Est-il finalement possible de conserver le meilleur des évolutions précédentes et de le mettre en œuvre dans le nouvel environnement? Les premiers déploiements réussis d applications fondées sur les services Web permettent de répondre par l affirmative. OMG (Object Management Group) : consortium de plus de 800 constructeurs, éditeurs, intégrateurs et utilisateurs réunis pour spécifier collectivement une architecture à objets répartis dont est issu Corba. Les fondations de l architecture des services Web L architecture des services Web repose sur un mécanisme de transport d une demande de service entre un client et un serveur, tous deux connectés au réseau. Figure 1-3. Le transport des demandes de services et des résultats de leur exécution est confié à une couche de communication fondée sur HTTP et TCP/IP. 17

Services Web avec SOAP, WSDL, UDDI, ebxml Dans cette architecture, le client peut être soit un navigateur Web (la demande de service résulte alors directement d une intervention humaine), soit une application (la demande de service est alors automatisée). Le rôle du serveur, quant à lui, est joué par une application qui s exécute sur un moteur de scripts interfacé à un serveur HTTP (PHP/ Apache, par exemple) ou sur un serveur d applications J2EE ou.net. Le point crucial est ici l étanchéité entre les clients et les serveurs qui ignorent tout de l implémentation, dite privée, des opérations respectives de leurs correspondants et ne se connaissent et se reconnaissent qu au travers de descriptions publiques, appelées services Web. À partir de ces services Web, on construit soit de nouveaux services Web dérivés des précédents, soit des applications Web, c est-à-dire des assemblages de services Web correspondant à une solution fonctionnelle ou métier de l entreprise. Le service Web est un composant logiciel dans la constitution d applications métier s appuyant sur l infrastructure de communication offerte par le Web. Le mécanisme de communication permettant cette circulation de requêtes et de résultats autorise évidemment la mise en relation de plusieurs clients et de plusieurs serveurs et, bien souvent, d ailleurs, d applications jouant parfois le rôle de client et parfois celui de serveur. Figure 1-4. Un service Web donné peut être, suivant le contexte, aussi bien client que serveur d autres services Web locaux ou distants. Ce «bus de requêtes» est fondé sur TCP/IP et sur HTTP, ce qui permet son utilisation tant sur Internet qu en vue de l intégration d applications au sein du réseau interne de l entreprise ou de la «publication» d applications préexistantes sur le Web à destination des entreprises partenaires. Le service Web est l interface publique de l application dans le réseau intra ou interentreprise. 18

Chapitre 1 L architecture des services Web CORBA DCOM EJB 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 monomachine 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ésultats de requêtes) circulent également au format texte, sous forme de documents codés en XML. XML, la langue maternelle des services Web XML XML est un standard promulgué par le W3C, l organisme chargé de standardiser les évolutions du Web. On retrouve dans XML une généralisation des idées contenues dans HTML et SGML 1. XML permet de définir des balises et de leur associer une interprétation. Dans HTML, on n utilise les balises que pour décrire l aspect graphique que doit revêtir la page dans le navigateur Web. Dans XML, les balises permettent d associer toutes sortes d informations au fil du texte. La norme XML comporte deux parties : XML à proprement parler et les DTD (Document Type Definition) qui définissent les balises qui sont utilisées dans une famille de documents XML. XML a été conçu pour des documents arbitrairement complexes, tout en s 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 documents sortant bruts de fonderie des traitements de texte ou des tableurs, le format XML a été conçu pour en permettre le déchiffrement direct par SGML : Standard Generalized Markup Language. 19

Services Web avec SOAP, WSDL, UDDI, ebxml Figure 1-5. Un document XML et son DTD. l utilisateur comme par les programmes. Le compromis trouvé dans XML est celui de texte contenant des balises ouvrantes et fermantes qui décrivent la nature des données qu elles encadrent, comme dans l exemple <prenom>harry</prenom>. La structure est hiérarchique : un document XML s ouvre sur une balise qui contient toutes les autres. Ainsi, sans (trop) perdre de lisibilité, le document XML permet de représenter des structures de données arbitrairement complexes les hiérarchies de données se trouvent en abondance dans les modèles de données relationnels 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 par une hiérarchie, certains éléments apparaissant imbriqués dans d autres. XML et DTD permettent ainsi une séparation effective du contenu de la structure du document. Les relations entre documents sont au moins aussi importantes que leur structure : cinq documents XML représentant cinq bons de commande et cinq autres représentant des produits ne sont intéressants que si l on sait associer le bon produit au bon de commande. Souvent, en HTML, ces relations figurent explicitement dans la page Web d où d ailleurs la multiplication des messages «HTTP 404 Not found» par des références directes. Dans XML, en revanche, ces relations entre documents sont exprimées en dehors des documents XML eux-mêmes souvent dans d autres documents, eux-mêmes écrits en XML avec d autres vocabulaires. 20

Chapitre 1 L architecture des services Web Enfin, contrairement à HTML, le document XML en soi ne dit rien de l aspect sous lequel il doit être rendu à l écran (ou ailleurs : imprimante, téléphone WAP, etc.). Structure et présentation du document sont conceptuellement séparées. Ainsi le même contenu peut-il être présenté sous différentes formes suivant la nature des utilisateurs. Les documents (en XML!) qui décrivent la présentation à «appliquer» à un document XML Figure 1-6. Transformation d un document XML en page HTML via XSLT. 21

Services Web avec SOAP, WSDL, UDDI, ebxml constituent des feuilles de style XML (XSL pour XML Style Sheets) dont le fonctionnement est semblable à celui des CSS (Cascading Style Sheets) pour le Web. La norme XSLT (XSL Transformation) définit le vocabulaire de ces feuilles de style destinées à transformer un document XML en vue de le pré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 greffe une collection de normes complémentaires à différents stades de normalisation (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 Namespaces 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érations 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 Information Set Octobre 2001 Ensemble de définitions permettant à d autres spécifications de se référer à l information contenue 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 fragments de documents XML (gestion de versions ) 22

Chapitre 1 L architecture des services Web «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énements à des éléments XML Comme le montre la variété des domaines d application dans lesquels il est employé et le nombre des travaux de recherche lancés depuis son adoption en 1998, XML réunit le double avantage d être extensible et de s accommoder de l infrastructure fruste du Web. XML Namespaces XML Namespaces est une recommandation du W3C qui a été rapidement adoptée après XML 1.0, visant à résoudre le problème de l ambiguï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 des documents XML contiennent des balises «réutilisables», c est-à-dire constituées comme de véritables vocabulaires mis en œuvre dans diverses applications. C est d ailleurs tout l enjeu de consortiums tels que ebxml ou RosettaNet qui tentent de définir un vocabulaire XML partagé par le plus grand nombre d acteurs d un secteur industriel donné. Avec cette prolifération, une même balise, <Adresse> par exemple, peut désigner des choses très différentes dans divers documents XML : adresse postale d expédition dans un bon de commande, elle peut aussi bien désigner une adresse de courrier électronique dans une application intranet. Pour résoudre cette ambiguïté, il faut compléter la balise avec une information supplémentaire rendant unique son interprétation. Le namespace XML répond à ce besoin : il s agit d une collection de noms utilisables soit comme types de balises, soit comme noms d attributs de balises. 23

Services Web avec SOAP, WSDL, UDDI, ebxml En pratique, le namespace est un préfixe attaché à la balise ou à l attribut par «:». Ainsi, la notation suivante : <bondecommande:adresse xmlns: bondecommande="http://www.ebxml.org"> Les URL (Uniform Resource Locator) et les URI (Uniform Resource Identifier) sont les conventions qui régissent les adresses et l identification des ressources sur le Web. Elles sont définies par l IETF. fait apparaître le préfixe bondecommande qui est le namespace XML de la balise <adresse>. Ce namespace est identifié de manière unique par la valeur de l attribut réservé xmlns. Pour assurer l unicité des noms de namespaces, on a recours aux URI 1 un moyen standard de nommer et d identifier des ressources Internet mis en place et géré par l IETF. Voici un exemple de document XML contenant deux éléments <adresse> associés à des namespaces différents : <bondecommande:expedition xmlns: 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:expedition xmlns: bondecommande ="http://www.ebxml.org"> <contacts:serviceclient xmlns: contacts ="intranet/contacts/xml"> <contacts:adresse xmlns: contacts ="intranet/contacts/xml"> info@eyrolles.com </contacts:adresse xmlns: contacts ="intranet/contacts/xml"> </contacts:serviceclient xmlns: contacts ="intranet/contacts/xml"> Dans cet exemple, les deux namespaces utilisés (bondecommande et contacts) permettent de distinguer les deux types d adresses utilisés dans le document. La norme définit, de plus, des conventions qui en simplifient l écriture. L exemple précédent peut être en fait récrit sous la forme suivante : <bondecommande:expedition xmlns: bondecommande ="http://www.ebxml.org"> <adresse> 61, bd. St Germain, 75005 Paris </adresse> </expedition> <contacts:serviceclient xmlns: contacts ="intranet/contacts/xml"> <adresse> info@eyrolles.com </adresse> </serviceclient> 24

Chapitre 1 L architecture des services Web L attribution d un namespace est valide pour tous les éléments imbriqués dans 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 applications différentes. En s appuyant sur le dispositif des URI, qui en assure l unicité, et au prix d une écriture un peu plus «bavarde», les balises et les attributs XML sont alors dotés d une interprétation spécifique, non ambiguë. XML Schema La recommandation XML Schema, adoptée après de longues discussions dans les comités techniques du W3C, représente un réel tour de force et une innovation dans l utilisation d XML, rompant tout net avec son usage originel pour la publication de documents. XML Schema précise comment représenter en XML les structures de données en général ce qu on a l habitude d appeler les métadonnées dans le monde des bases de données relationnelles (description des tables, des colonnes, de leurs types, etc.). Alors que le DTD ne définit que la structure d un document XML essentiellement un arbre, XML Schema a vocation à décrire n importe quelle structure de données, depuis les modèles relationnels des bases de données jusqu aux modèles objet des langages de programmation. Reprenant des travaux antérieurs sur XML (XML-Data de Microsoft, RDF 1 du W3C, DCD 2 ) et sur la modélisation des données (SQL3 et ODL/OQL 3 de l ODMG 4 ), XML Schema est adapté à la description des structures de données des documents XML, des bases de données relationnelles, mais également à celle des modèles objet des langages de programmation orienté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 de leurs attributs. L information fournie par le schéma est donc plus riche que 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 Description Framework) : recommandation assez ancienne et manquant de généralité, adoptée par le W3C en 1999. DCD (Document Content Definition) : premier effort de convergence entre RDF et XML-Data visant à remplacer le DTD par XML lui-même. ODL (Object Definition Language), OQL (Object Query Language) : langages de définition et de manipulation de modèles de données objet. ODMG (Object Database Management Group) : sousgroupe de l OMG travaillant sur les bases de données orientées objet. 25

Services Web avec SOAP, WSDL, UDDI, ebxml <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 du texte qu elles encadrent (ici, le type primitif chaîne de caractères, string), permettant éventuellement des vérifications ou des validations impossibles avec la seule DTD. De même, on constate que la définition de l élément est plus précise dans le schéma : on y indique, en particulier, le nombre d occurrences des éléments imbriqués. Dans un document XML Schema, chaque balise peut être associée à un type, dit soit primitif s il fait partie de ceux fournis par la spécification ellemê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 est défini par l utilisateur dans le document XML Schema en question. Il s agit d un véritable système de types au sens des langages de programmation : des types dérivés peuvent être créés soit par extension, soit par restriction, permettant ainsi de capturer sans ambiguïté les modèles, plus complexes, des bases de données et des langages de programmation orientés objet. Ces types abstraits sont eux-mêmes décrits en XML. La spécification définit deux namespaces pour XML Schema : 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 documents XML liés à des schémas. Sa généralité fait la force de XML Schema, aujourd hui adopté par les fournisseurs de bases de données relationnelles comme format d import et 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 composants logiciels constitutifs d une application (l information de configuration), voire comme substitut aux définitions de classes elles-mêmes. De nombreux validateurs de schémas XML existent aujourd hui et permettent 26

Chapitre 1 L architecture des services Web Figure 1-7. Comment un schéma XML décrit la structure et les types de données d un document XML. 27

Services Web avec SOAP, WSDL, UDDI, ebxml d automatiser la vérification de la conformité d un document XML à un schéma donné, déchargeant d autant le code de l application qui exploite au final ces documents. Figure 1-8. Comment sont utilisés les schémas XML. Nous trouvons ici un premier saut conceptuel important qu il est essentiel de comprendre pour se représenter les fondations techniques des services Web. Alors que les documents XML «habituels» sont des images des objets du monde réel (bons de commande, factures, etc.) sous forme de documents circulant entre applications informatiques, les documents XML Schema, quant à eux, représentent la structure des données véhiculées par ces documents. Messages XML entre applications et services Web Pour les services Web, on utilise systématiquement XML avec les Namespaces et la spécification XML Schema, tous deux indispensables pour exprimer les structures des données habituellement complexes figurant dans les messages échangés. Dans le mécanisme de transport entre services Web, les requêtes, leurs ré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 le service Web et traités sur le serveur en réponse aux demandes. 28

Chapitre 1 L architecture des services Web Fig. 1-9 : L information circule entre services Web sous forme de documents XML. Notons d emblée que le choix de documents XML comme format pour les données circulant entre applications clientes et services Web ou entre services Web présente des avantages sur les middleware de la génération pré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 particuliers que le recours à des RPC 1 ou à de tels middleware imposent aux programmeurs. CORBA EJB 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é,. 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). De plus, en s appuyant sur HTTP, on ne se heurte pas aux problèmes de pare-feu ou de configuration de réseau IP qui rendent parfois difficile le déploiement d applications à objets répartis au-delà du périmètre du réseau d entreprise. Le prix à payer pour cette nouvelle fluidité est celui de la complexité du document XML et corrélativement celui du coût de son traitement. Sur le premier point, il est clair que pour parvenir à la même richesse d expression dans un document texte que dans une requête traditionnelle il faut pouvoir, en XML, décrire la destination exacte de l appel, préciser les arguments éventuels et leur type, la ou les valeurs attendues en retour et leur type, les codes d erreur et, plus généralement, expliciter toute information 29

Services Web avec SOAP, WSDL, UDDI, ebxml de contexte requise par le serveur. Tout cet habillage XML est d autant plus épais que les données passées entre services Web sont a priori complexes (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 à leur réception : ils doivent être analysés avant le déclenchement des traitements. Cette analyse est effectuée par un interpréteur XML, ou parseur, qui dé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ù les phases de compilation supplémentaires évoquées plus haut permettent précisément le lien direct entre le message et le traitement à exécuter. La performance s en ressent donc nécessairement un peu, même si un document XML peut, à lui seul, remplacer une salve d appels RPC traditionnels au travers d un middleware. Classification des services Web La facilité d emploi d XML et sa flexibilité dans la représentation de toutes sortes de données ont donné lieu à une prolifération de développements autour des interpréteurs XML et des scénarios d usage des documents XML depuis la fin des années 1990. On peut distinguer grossièrement deux natures de travaux : d une part, au sein du W3C, un effort collectif de standardisation technique et de stabilisation des technologies XML au moyen d un processus discipliné de soumission et de ratification et, d autre part, des initiatives au départ commerciales, regroupant plusieurs acteurs industriels d un secteur donné, pour s entendre sur un formalisme XML adapté à leurs domaines d activité. Le W3C promulgue des recommandations, fruit d un travail de réflexion et de standardisation technique, qui sont des spécifications techniques publiques souvent adoptées rapidement par les éditeurs de logiciels (qui participent également à leur élaboration dans les comités techniques de l organisation). XML, les Namespaces et XML Schema, précédemment cités, sont des exemples de telles recommandations. Ces spécifications sont toutes techniques en ce qu elles précisent comment XML peut et doit être utilisé dans les applications informatiques réparties sur le Web pour représenter et manipuler les abstractions indispensables mais indépendantes du secteur d application. Par contraste, les initiatives industrielles proposent souvent des vocabulaires XML pour des usages spécifiques dans tel ou tel secteur ; elles n ont d ailleurs de force que celle de leurs membres industriels, dont les intérêts commerciaux, variant avec le temps, peuvent conduire aussi bien à leur renforcement qu à leur affaiblissement. Ainsi de nombreuses initiatives de standardisation lancées précipitamment au début des efforts de 30

Chapitre 1 L architecture des services Web stabilisation d XML ont rapidement périclité. D autres, qui ont réuni un plus grand nombre de participants comme BPMI 1 ou qui ont mutualisé les efforts de grands acteurs comme ebxml 2, sont aujourd hui à l avant-garde des services Web. 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 Management Initiative) : large consortium réuni autour de la spécification en XML des processus métier intra et interentreprises, comptant fin 2001 plus de 80 membres. ebxml (Electronic Business XML) : ensemble de spécifications fondées sur XML, destinées à faciliter le commerce électronique interentreprise. En suivant donc à la fois l évolution de cet historique récent de la généralisation d XML dans l industrie informatique et le modèle largement répandu de l architecture à objets répartis, nous sommes amené à distinguer trois classes générales de services Web pour lesquelles XML est employé avec, pour chacune, des visées différentes : Les services de communication et de transport (SOAP), véritable système nerveux dans lequel circulent les données à l intérieur de messages XML. Les services techniques : des services utilitaires indispensables au bon fonctionnement de l assemblage des services Web, comme les annuaires UDDI, par exemple. Les services métier : des services spécifiques soit à des applications verticales dans un secteur d activité donné (RosettaNet), soit à des scénarios mutualisés entre applications (ebxml), comme le paiement électronique. Cette classification reflète, à l échelle des entreprises connectées sur le Web, l architecture des applications internes connectées au réseau local 31

Services Web avec SOAP, WSDL, UDDI, ebxml API (Application Programming Interface) : interfaces de programmation au travers desquelles on pilote les applications. de l entreprise. La similarité de cette architecture de l informatique interentreprise 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 applications conçues antérieurement au Web. Au prix de la traduction des API de ces applications en XML, on rénove à bon marché les logiciels préexistants sans remettre en cause leur rôle, tout en leur permettant de se joindre au chœur des nouveaux services Web dédiés aux activités en ligne. Figure 1-11. Au niveau du système d information de l entreprise et à celui des échanges interentreprises, les architectures sont similaires. On peut mettre en parallèle l architecture de composants logiciels (ayant d ailleurs elle-même émergée des travaux sur les langages de programmation orientés objet puis sur les systèmes d objets répartis) et l architecture des services Web. Les services Web sont les «nouveaux» composants logiciels dans un système d interactions fondé sur le Web. La nature particulière de cette infrastructure Web (hétérogénéité du réseau, protocole de communication simpliste, problèmes de sécurité et d authentification, nature ad hoc des interactions par opposition à des relations systématiques entre nœuds du réseau, etc.) impose des contraintes à ces nouveaux 32

Chapitre 1 L architecture des services Web composants logiciels et justifie des modes d assemblage particuliers, tous relativement différents de celles et de ceux employés dans les composants logiciels et les serveurs d applications de l échelon directement inférieur. Néanmoins, les composants logiciels (Corba, DCOM, EJB) et leurs plates-formes d assemblage et d exécution, les serveurs d application au sens le plus large, sont les meilleurs outils d implémentation des services Web. En liaison avec le W3C et diverses initiatives visant à définir les services Web, et, en particulier, leur représentation dans les standards XML, les constructeurs et les fournisseurs comme Microsoft, IBM ou Sun se sont activement lancés dans le développement de plates-formes d assemblage et d exécution de services Web, visant à implémenter les nouveaux composants logiciels à l aide des anciens. C est le sens des annonces telles que.net de Microsoft, SunONE de Sun ou des évolutions récentes de WebSphere d IBM et de WebLogic de BEA. Figure 1-12. Des objets répartis aux services Web, une superposition de systèmes à base de composants logiciels. 33

Services Web avec SOAP, WSDL, UDDI, ebxml Les services de communication et de transport Comme nous l avons vu, le transport de données sur le Web doit s accommoder de protocoles moins riches que ceux des middleware employés au sein des réseaux internes de l entreprise. Dans cette couche de transport, XML est utilisé pour décrire la structure des messages échangés entre services Web. Le message est constitué de l identifiant de son destinataire et du nom de l opération invoquée, de la liste des arguments éventuels et des valeurs de retour attendues, ainsi que des paramètres supplémentaires optionnels nécessaires à son traitement du côté du serveur. CORBA 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 également d invocation dans les protocoles RPC classiques comme RMI ou objet comme DCOM. Les premières tentatives, comme XML-RPC, ont rapidement convergé au sein du W3C autour de SOAP (Simple Object Access Protocol) devenu un standard 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 architecture.net et se trouve progressivement adopté par les autres grands acteurs de l industrie comme Sun après de fortes réticences initiales ou le consortium ebxml, par exemple. Figure 1-13. SOAP décrit la structure des messages XML échangés entre services Web. SOAP est un protocole léger d échange de données et de structures de données entre nœuds d un réseau (de client à serveur ou de serveur à serveur) en XML. La spécification SOAP précise : 34

Chapitre 1 L architecture des services Web Les en-têtes des messages, ou «enveloppes» : quel est le message et qui est le destinataire. Les règles de codage des types de données : comment représenter un entier, un tableau, un graphe d objets, etc. Des conventions pour la représentation d appels de procédures distants et 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 utilisent les URL et les URI ; pour le protocole régissant le dialogue entre l émetteur et le récepteur, les messages SOAP sont transportés dans des requêtes HTTP classiques ; pour la description des types des données constituant les arguments, SOAP s appuie sur XML Schema et les Namespaces. Bien que dans l esprit des concepteurs les messages SOAP soient 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 Source Apache offre aussi, par exemple, une implémentation de SOAP sur SMTP. SOAP est donc au cœur de l échange des messages entre applications sur le Web, orchestrant données en XML et protocole de communication avec HTTP. Il peut également être utilisé pour la communication entre applications à l intérieur de l entreprise sur le réseau local, par exemple, pour lier un portail d entreprises aux informations gérées par d autres applications déjà en place. Il existe d autres standards et couches de transport de message importantes pour les services Web. Alors que SOAP est utilisé pour échanger des messages XML circulant sur le Web, d autres middleware peuvent également être employés par les services Web, souvent dans le cas d une application intranet. L invocation de composants logiciels EJB via RMI est utilisable pour connecter un service Web à une application existante, développée en Java. Les middleware orientés messages traditionnels comme MQ Series d IBM ou MSMQ dans l architecture.net de Microsoft peuvent aussi être employés à la place de SOAP et de HTTP ce qui est probablement plus pertinent pour une application intranet. De plus, certains services métier offrent eux-mêmes une gestion de messages parfois spécifique (comme RNIF dans RosettaNet), ou encore une spécialisation 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 électroniques ente serveurs via Internet. 35

Services Web avec SOAP, WSDL, UDDI, ebxml Les services techniques Les services Web, qualifiés ici de techniques, sont les composants indispensables au bon fonctionnement des échanges entre services et applications 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, chaque classe de fonctions étant associée à un jeu de balises spécifique par un DTD approprié. CORBA 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. 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 36

Chapitre 1 L architecture des services Web Les standards les plus importants pour ces services Web techniques sont les suivants : WSDL(Web Service Description Language), pour définir précisément un service Web (quelconque) : son adresse et son identité, les opérations que l on peut invoquer et leurs arguments (types des données, valeurs de retour, codes d erreur), etc. UDDI (Universal Description, Discovery and Integration) pour créer et interroger des annuaires contenant la description des services Web eux-mêmes. DSML (Directory Services Markup Language) pour créer des annuaires de ressources internes à l entreprise en XML, compatibles, notamment, avec la norme LDAP 1. BPML (Business Process Modelling Language) et BPQL (Business Process Query Language) pour décrire des processus métier complets mettant éventuellement en jeu plusieurs entreprises connectées et plusieurs autres services Web distants. Les langages de contrat définissant les relations statiques (participants, rôles et responsabilités) entre services Web, souvent couplés à BPML pour couvrir la dynamique du processus métier. Citons les deux DTD concurrents XLANG, pour le serveur BizTalk de l architecture.net, et WSFL (Web Services Flow Language) d IBM. Certains services en cours de formalisation comme XKMS (XML Key Management Specification) une note du W3C soumise par Verisign, Microsoft et WebMethods pour l enregistrement et la distribution de clés PKI 2 ; XAML (XML Transaction Authority) pour la description de transactions en XML entre serveurs ; WSUI (Web Services User Interface) pour la présentation et la description des interactions entre utilisateurs et services Web. On trouve également des services techniques faisant presque double emploi avec certains de ceux que nous venons de lister, dans des développements XML propriétaires de certains éditeurs ou dans des propositions antérieures aux standards précités. Citons par exemple BizTalk de Microsoft, e-speak de H.P. ou encore ebxml pour le commerce électronique. L heure est néanmoins à la compatibilité entre ces standards et ces initiatives indépendantes voire à la mise en conformité avec la suite SOAP, UDDI, WSDL, DSML, BPML. LDAP (Lightweight Directory Access Protocol) : l API standard d accès aux annuaires des ressources informatiques internes de l entreprise (machines, profils des utilisateurs, groupes et privilèges, etc.). PKI (Public Key Infrastructure) : infrastructure de chiffrement de données à clés publiques d usage maintenant généralisé. CORBA DCOM 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 (UUID 3 ) comparables à WSDL, LDAP lui-même, etc. UUID (Universal Unique Identifier) : numéro unique de 128 bits associé à chaque objet DCOM. 37

Services Web avec SOAP, WSDL, UDDI, ebxml J2EE (Java 2 Enterprise Edition) : plate-forme Java incluant tous les bibliothèques nécessaires au développement d applications d entreprise. EJB 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 J2EE 1. L hétérogénéité intrinsèque du Web et la complexité des transactions Web, liant a priori de multiples participants, entraînent une séparation plus fine des niveaux de représentations, chacun se trouvant doté de son balisage XML propre. On distingue ainsi plusieurs échelons dans l empilement (le stack) des protocoles : La description en WSDL du service lui-même, c est-à-dire des opérations et de leurs signatures, dont le serveur est responsable. La description du serveur lui-même, «enrobant» la description du service d informations supplémentaires sur le contexte et les scénarios d usage du service par exemple, de paramètres ayant trait à la qualité de service, à la nature transactionnelle ou non des opérations du service, aux informations de trace et d audit disponibles, etc. Ces descriptions font habituellement partie des documents WSDL liés au service considéré. Ladescription de la mise en œuvre de différents services sur le Web en vue d une application ou d un processus métier particulier. On parle alors d orchestration ou de chorégraphie, tout comme dans un concert ou dans un ballet! Là encore, on distingue habituellement deux sousniveaux : celui décrivant les messages échangés par les différents services à orchestrer ce sont des spécifications comme XLANG chez Microsoft ou WSFL chez IBM et celui décrivant les séquences d envoi et de réception de ces messages, les aspects de synchronisation et de transactions entre services c est le royaume de BPML pour la capture des processus métier intra ou interentreprises. Tous ces services sont compatibles avec SOAP, même si certains d entre eux, WSDL en particulier, peuvent se contenter d un simple canal HTTP ou d échanges au format MIME (Multipurposes Internet Mail Extensions). Dans des configurations intranet, tous peuvent également employer les middleware précédemment évoqués (Corba-IIOP, DCOM, RMI) comme service de transport et de communication. Les services métier De même qu il est intéressant de mutualiser un ensemble de fonctions techniques indispensables aux applications réparties sur le Web sous forme de services indépendants et standards, il peut être également avantageux de partager des services ayant trait à certaines grandes fonctions de l entreprise, quel que soit son secteur d activité. Ces fonctions sont 38

Chapitre 1 L architecture des services Web généralement liées au commerce électronique et visent finalement à reproduire dans le monde virtuel les transactions commerciales du monde réel (transactions, contrats, facturation, paiement, etc.). EJB Ce qui ne va pas sans rappeler bien sûr les fonctions des ERP (progiciels de gestion 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éveloppeurs d applications Web tout un ensemble de spécifications et de moteurs d exécution facilitant le déploiement d applications Web réparties dans des secteurs particuliers ou pour des processus métier verticaux identifiés : citons à nouveau BPML et BPQL du consortium BPMI, dont une partie des spécifications couvre la synchronisation et la mise en parallèle de traitements 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é sur la mise en ligne d applications préexistantes et l habillage XML d API et de bibliothèques de programmation ; BizTalk de Microsoft, dont l objectif est de formaliser les échanges électroniques de documents professionnels (factures, bons de commande ) entre applications Web réparties ; ebxml et RosettaNet, spécifications protéiformes visant à formaliser en XML une infrastructure complète pour le commerce électronique. CORBA Dans l architecture à objets répartis de l OMG, les services Web métier sont comparables aux CorbaFacilities et aux Domain Services. Comme les différents efforts de spécification des services Web métier ont parfois commencé avant ceux de standardisation du W3C sur les aspects techniques, on détecte de nombreuses zones de recouvrement entre services Web métier et techniques. Du coup, on assiste aujourd hui soit à une mise en conformité des uns avec les autres (BizTalk, par exemple, dans sa seconde livraison a été rendu compatible avec SOAP), soit à une absorption pure et simple (ebxml récupérant tpaml ou des membres de RosettaNet déclarant vouloir se conformer aux spécifications ebxml). 39

Services Web avec SOAP, WSDL, UDDI, ebxml Figure 1-15. Les spécifications XML des services Web métier. Le développement des services Web À cette étape de la présentation de l architecture des services Web, il faut rappeler que celle-ci, rendue nécessaire par l appropriation rampante des protocoles du Web par l informatique d entreprise, se place délibérément dans la lignée des réflexions et de l élaboration des systèmes à objets répartis et, à la génération suivante, de l architecture à composants logiciels. Cet alignement peut en effet être qualifié de volontaire puisqu il est en fait animé, avec des visées évidemment commerciales, par ces mêmes acteurs de l industrie informatique qui avaient auparavant investi dans les objets répartis et dans les composants logiciels. Pour la plupart de ces acteurs industriels, les services Web sont, en effet, présentés comme une étape 40

Chapitre 1 L architecture des services Web supplémentaire dans l évolution naturelle des composants logiciels. Ce «positionnement» apparaît d autant plus légitime que le Web est, par essence, le nec plus ultra de l infrastructure répartie. De plus, les services en ligne ou les applications Web ont probablement été développés indépendamment les uns des autres, dans une cacophonie de technologies dont les protocoles Web constituent, en quelque sorte, le plus petit commun dénominateur (TCP/IP, le format texte HTTP et XML). Ils ont été mis en service à des moments différents, et seront certainement mis hors ligne ou 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 applications à objets répartis, un processus formel et une discipline d exécution des plus précises. Les méthodologies et les outils créés dans les années 1990 pour les applications réparties se trouvent ici particulièrement adaptés à la nouvelle architecture. UML et la méthodologie à base de cas d utilisation (use cases), par exemple, sont particulièrement utiles dans l analyse et la conception d applications Web réparties ; l insistance méthodologique sur la réutilisation correspond directement à l importance 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ées par la diffusion du BizTalk Server de Microsoft (reprenant l interface de Visio, le produit de la société éponyme rachetée par Microsoft) et par l adoption de la spécification BPML dans le monde hors.net. La représentation des services Web, ainsi que celle des échanges de messages et de leurs séquences sont ainsi codifiées graphiquement pour engendrer automatiquement les documents WSDL, BPML, XLANG ou WSFL correspondants. UML (Unified Modeling Language): la notation graphique standard employé dans les méthodologies de développement orienté objet. Le déploiement des services Web Le déploiement de services Web s accommode aussi bien d une plateforme légère, un serveur Apache et quelques extensions par exemple, que de serveurs d applications d entreprises pour des applications plus importantes. 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 des services Web et des applications Web, on trouve, par exemple : 41

Services Web avec SOAP, WSDL, UDDI, ebxml Produit/projet Apache SOAP SOAP::Lite, UDDI::Lite, XMLRPC::Lite Classes PHP pour SOAP, PHPSOAP, SOAPx4 SOAP for Python, SOAP.py, SOAPy WebService for ZOPE WSTK d IBM Descriptif Module dotant le serveur Web Apache de l infrastructure nécessaire à l envoi et à la réception de messages SOAP Collection de modules Perl pour l implémentation de SOAP, de UDDI et de XML-RPC De divers projets Open Source, des bibliothèques PHP pour la réalisation de serveurs SOAP Diverses bibliothèques SOAP pour le langage Python Un développement Open Source visant à étendre l outil de gestion de contenu Zope pour SOAP, WSDL et les autres standards des services Web 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 Platform (Shinka Technologies) SOAP for Ada Smalltalk Web Services Autres outils Bibliothèques C++ pour client SOAP et serveur SOAP comme service sous NT. Met également en œuvre WSDL. Implémentation de SOAP en Ada Implémentation Open Source de SOAP et WSDL dans le langage de programmation orienté objet Smalltalk 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. Bien sûr, la prolifération d implémentations aisément accessibles la plupart sont sous la licence GPL Open Source facilite l expérimentation et l apprentissage de ces nouveaux standards. Notons quand même que le 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 offrent pas toujours de garanties de mises à jour. L autre approche du déploiement de services et d applications Web s appuie sur des serveurs d applications, comme WebSphere d IBM, WebLogic de BEA, iportal d IONA, ou sur des plates-formes d exécution de composants logiciels comme.net de Microsoft, J2EE/EJB et ONE de Sun ou encore sur des implémentations de la norme Corba. Le développement et l implémentation de services Web sont en effet facilités par le recours à l architecture technique à base de composants logiciels. Le «grain» des composants logiciels, comme les EJB ou les objets Corba, correspond finalement assez bien à celui d un service écrit en WSDL, et de son accès via SOAP. 42

Chapitre 1 L architecture des services Web De plus, la participation des grands acteurs de l industrie, dont Microsoft, à l élaboration de ces standards (au design SOAP en particulier) garantit que l intégration aux architectures techniques des constructeurs ne sera pas le parent pauvre de leurs efforts de développement. De même, l OMG travaille aujourd hui à l utilisation de SOAP en conjonction avec la sémantique des appels entre programmes et objets Corba, et à XMI 1 pour échanger les modèles de données entre services Web. Enfin, l environnement réparti dans lequel sont exécutés les applications et les services Web met naturellement en avant des besoins de gestion de la concurrence d accès, de gestion des transactions, courtes ou longues, de persistance de l état des échanges, de sécurité et d authentification des acteurs de ces échanges Web, etc. Ces services, de nature technique, constituent l infrastructure nécessaire minimale à l exécution de services Web. Ils sont aujourd hui fournis par les serveurs d applications. Nombreux sont ainsi les acteurs industriels dont les efforts visent à donner à leurs produits la fonctionnalité de serveur d applications Web. Une classification (non exhaustive!) rapide permet de distinguer : Les éditeurs de bases de données, essentiellement relationnelles, construisant autour de SGBD transactionnels l infrastructure technique XML requise pour l intégration dans l architecture UDDI/WSDL/DSML/SOAP (Oracle est l exemple typique, mais IBM avec le rachat d Informix en 2001, ou Sybase avec celui de NEON illustrent la même stratégie). Les grands éditeurs de middleware traditionnels (moniteurs transactionnels ou message queuing) adoptant XML pour l intégration aux applications 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, par exemple, cherchant à généraliser leur plate-forme d exécution d applications réparties à l échelon supérieur du Web en intégrant à leurs services préexistants la génération et l interprétation d XML et des standards qui en dérivent (c est le passage de COM à DCOM puis à.net chez l éditeur de Redmond et l évolution de J2EE et EJB vers ONE chez Sun, par exemple). Les éditeurs de logiciels de la sphère d influence Corba, poursuivant l adaptation des implémentations Corba au réseau et aux protocoles du Web (citons des sociétés comme Iona ou CapeClear). Une nouvelle génération de start-up dont les produits sont directement conçus comme architecture de services Web et n ayant pas à s embarrasser de l adaptation de produits antérieurs (citons, ici aussi sans exhaustivité, BowStreet, Intalio, CapeClear, etc.). Cette activité effrénée pourrait laisser une impression de désordre porteuse de menaces pour l adoption de cette nouvelle architecture. Il n en est rien car le Web étant déjà en place et poursuivant son développement, dans l architecture Web, plus encore que dans l architecture à XMI : XML Metadata Interchange Format. 43

Services Web avec SOAP, WSDL, UDDI, ebxml 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, par conséquent, à respecter les protocoles et standards d ailleurs sous haute surveillance du W3C ou de l OMG. Les moteurs XML La clé de voûte de l édifice architectural des services Web se trouve, bien entendu, dans le moteur XML capable d interpréter les documents aux différents formats standardisés. Ce moteur est générique : il accepte tout document XML et écrit un document XML suivant tous les formats et standards 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 balise lue dans le document XML déclenche l exécution d une procédure dans le programme. Les parseurs de type DOM (Document Object Model) construisant, au contraire, une image complète du document en mémoire sur laquelle le programme vient ensuite travailler. SAX est une API normalisée dont les bibliothèques de programmation sont disponibles pour de nombreux langages. SAX est dit piloté par les événements (event driven). Avec SAX, le programmeur n écrit que les procédures et les fonctions à exécuter lorsque le parseur rencontre une balise donnée. À chaque classe de documents XML correspond alors un jeu de procédures et 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émoire une représentation hiérarchique du document et de l imbrication de ses balises, sous forme d une structure de données arborescente. Le programme peut ensuite examiner et modifier cette structure arborescente et, éventuellement, écrire automatiquement un document XML qui la reflète. SAX Accès séquentiel au document XML Piloté par les événements Callbacks Pas de représentation en mémoire Léger Serveurs, filtre de données Programmation délicate DOM Conversion en objets du langage de programmation Séquence : lecture, traitements, écriture API Document XML entièrement en mémoire Lourd (CPU, mémoire) Applications, environnements auteur, administration Programmation traditionnelle 44

Chapitre 1 L architecture des services Web Les avantages et les inconvénients de chaque type de parseur sont clairs et le choix de l un ou de l autre dépend du compromis à trouver pour une application donnée. Notons que la plupart des éditeurs ou des constructeurs précédemment mentionnés fournissent des parseurs XML, souvent dotés des deux API, pour une grande variété de langages de programmation, ce qui en facilite la diffusion. Il existe également de nombreux moteurs 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 traitement des documents XML bénéficie ainsi de toutes les propriétés (transaction, sécurité, persistance, etc.) requises pour des applications Web intranet ou interentreprises. C est précisément parce qu elle ouvre un tout nouveau champ de développement aux fournisseurs d infrastructure d applications d entreprise que Figure 1-16. L architecture globale des services Web. 45

Services Web avec SOAP, WSDL, UDDI, ebxml cette intégration de moteurs XML, couplée à la stabilisation des standards, donne lieu à de grandes manœuvres marketing et commerciales destinées à attirer programmeurs et utilisateurs. L architecture.net de Microsoft, l architecture ONE de Sun/iPlanet, e-speak de HP ou WebSphere d IBM sont les icônes de ces nouveaux développements. Les passerelles entre l architecture de services Web et l infrastructure technique des serveurs d applications constituent un secteur en pleine effervescence. Diverses initiatives visent à élever une «façade» commune aux bases de données, aux annuaires, aux traitements et aux documents dans 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 DCOM sont aujourd hui bien plus complètes avec une plus grande disponibilité commerciale que leurs équivalents XML. Le succès des applications et des services Web repose, pour une grande part, sur la qualité technique de l infrastructure sous-jacente dans les entreprises. Il n est donc pas surprenant que les questions d intégration d applications et de choix de serveurs d applications soient plus que jamais au centre des préoccupations de l entreprise. 46