Serbvices Web XML - Université de Montréalaimeur/cours/ift6261/Presentations... · 2004. 2. 19. · Filatova Irina 2. Chapitre 2 Concept Services Web XML 2.1. Définition de Services

Filatova Irina

Étudiante de Maîtrise (és) en Commerce Électronique FILATOVA IRINA [email protected]

Ce document a été produit dans le cadre du cours IFT6261 Traitement des connaissances Université de Montréal

_____________________________________________________________________________________ Version du jeudi 19 février 2004 Page 1 sur 44

mailto:[email protected]

Filatova Irina


TABLE DES MATIÈRES Résumé ………………………………………………………………………. 3 1. Chapitre 1 Introduction ……… ……………………………………………………. 4 2. Chapitre 2 Concept Services Web XML …………………………………………… 6

2.1. Définition de Services Web XML ……………………………………… 6 2.2. Raisons principales d’utilisation de Services Web XML ……………. 6 2.3. Caractéristiques des Services Web XML …………………………….. 7 2.4. Exemples concrets d’utilisation ……………………………………….. 8

3. Chapitre 3 Architecture de Services Web XML …………………………………. 9

3.1. Fondation de l’architecture de Services Web XML …………………. 9 3.2. Architecture orientée services (SOA) ……………………………….… 10 3.3. Services Web XML et architecture à 5 couches ……………………… 11 3.4. Exemples des architectures ……………………………………………. 13

4. Chapitre 4 Standards de fonctionnement de Services Web XML ………………. 13

4.1. Technologies XML …………………………………………………….. 15 4.2. Services Web XML et Protocole SOAP ………………………………. 19

4.2.1. Description des messages SOAP ……..………………………… 20 4.2.2. Enveloppe de message SOAP …………………………………… 21 4.2.3. Exemple de message SOAP …………………………………….. 22

4.3. Services Web XML et organisation d’un document WSDL …………. 24 4.3.1. Description d’un document WSDL ……………………………. 24 4.3.2. Exemple de la structure d’un document WSDL ……………… 26

4.4. Services Web XML et UDDI ………………………………………….. 28 4.4.1 Description UDDI ………………………………….………….. 28

4.5. Différents standards Services Web XML …………………………….. 30 5. Chapitre 5 Spécifications de Services Web XML ……………………………….… 32

5.1. Recherche de service …………………………………………………… 33 5.2. Création du système fiable ……………………………………………. 34 5.3. Mis en place des systèmes sécurisés ………………………………….. 34

6. Chapitre 6 Outils pour développer de Services Web XML ….………………….. 35 7. Chapitre 7 Solution de l’intégration de Services Web XML ……..……………... 36 8. Chapitre 8 Conclusion …………….…………………………………………….….. 37

Bibliographie …….………………………………………………………….. 41 Annexe 1 : Lafarge ………………………………………………………….. 43 Annexe 2 : Algora ……………………………..…………………………….. 44

Filatova Irina SERVICES WEB XML Résumé

L’Internet, devenu un acteur incontournable de l’économie, s’infiltre au sein des

entreprises du monde entier sans la moindre discrimination. Celles-ci profitent des

nouvelles technologies pour favoriser la communication avec leurs clients, leurs

fournisseurs et leurs partenaires commerciaux. Si, dans le premier temps, les entreprises

ont été quelque peu bousculés par cette intrusion massive des nouvelles technologies, la

tendance s’est inversée et, à présent, c’est la logique économique qui dicte les

transformations nécessaires de l’Internet. Ces Services Web XML se présentent donc

comme la solution permettant aux entreprises de fournir à moindre coût, au travers du

Web, des services de qualité aux entreprises.

A l'image des sites Web classiques qui permettent à des personnes connectées au réseau

d'accéder à des informations ou à des services, les Services Web basant sur la technologie

XML (ci-après nommé Services XML) permettent à des entreprises d'ouvrir leurs

services internes sur le Web et ce, d'une manière uniformisée. L’élément clef qui a permis

le développement des Services Web XML est l’apparition de nouveaux standards

technologiques basés sur XML. Leurs adoptions par les principaux acteurs du marché de

l’Internet ont conduit à la création d’une pléthore de «standards» XML. En fait, XML est

une famille de technologies qui favorisent l’interopérabilité des systèmes et la

pérennisation du patrimoine documentaire et informationnel de l’entreprise.

Dans la suite de cette synthèse des articles on présentera ces standards plus en détail.

Mots-clés : Technologie, Service Web, XML, SOAP, UDDI, WSDL, Spécifications


Filatova Irina

1. Chapitre 1

Introduction

Dans le contexte des transactions nécessaires de l’Internet, l’arrivée des Services Web

XML correspond parfaitement aux attentes formulées par les entreprises. Le Web est, en

fait, considéré comme un cadre de travail totalement indépendant des langages et des

plates-formes où des opérations, appelées Services Web XML, peuvent être effectuées.

Cette indépendance des Services Web XML vis-à-vis des langages et des plates-formes

couplées à des protocoles de communications standardisées, tel que HTTP1, assure aux

applications distribuées une interopérabilité maximale. Ils apportent donc un souffle

nouveau aux entreprises désireuses de proposer leurs services au monde entier.

Beaucoup de chemin a été parcouru depuis 1998, date à laquelle le W3C2 donnait aux

spécifications XML3 le statut de recommandation.

L'avènement du langage HTML4 en parallèle avec le protocole HTTP a engendré une

révolution dans la manière dont les gens partagent l'information. Au-delà a de cette

révolution, une évolution des mentalités est aussi constatée puisque le monde des

réseaux, regorgeant de systèmes propriétaires et de logiciels dépendant de leur plate-

forme d'exécution, s'ouvre enfin aux standards. Néanmoins, les limites du langage

HTML, conçu principalement pour la représentation des données, se font très vite

ressentir. En effet, il est impossible de définir avec rigueur la sémantique des données

présentes au sein d'un fichier HTML. Heureusement, l'apparition du langage XML

permet de remédier à cette carence grâce à l'utilisation de DTD5 ou de « XML Schema. »

XML devient donc un élément de premier choix pour l'échange de données formatées au

travers du Web. En 1998, la firme UserLand Software saisit cette opportunité et utilise

les deux standards XML et HTTP pour définir un protocole de communication permettant

à différentes versions de leur logiciel, tournant distinctement sur des OS Windows et

1 Hyper Text Transfer Protocol 2 World Wide Web Consortium 3 eXtensible Markup Language 4 HyperText Markup Language 5 Document Type Definition


Filatova Irina Mac, de communiquer. Ce protocole, première ébauche de XML-RPC6, fait naître l'espoir

d'une interopérabilité entre plates-formes de toutes origines reliées via l'Internet.

Ensuite, le géant de l'informatique Microsoft décide de continuer les travaux entamés en

définissant un protocole dérivé de XML-RPC appelé SOAP7. Il faudra attendre la version

1.1 de SOAP avant que SUN rejoigne Microsoft et participe activement au sein du

« W3C working group » à la définition de ce protocole. SOAP se présente comme la

solution au problème d'interopérabilité entre la plate-forme .NET de Microsoft et la plate-

forme J2EE8 de SUN. . .

Cependant, la création de Services Web nécessite d'autres types de standards

technologiques que SOAP car celui-ci sont uniquement limité à la communication entre

composants distribués. Il est donc logique de voir apparaître d'autres standards tels que

UDDI9 permettant la découverte des ces services dispersés sur le Web ou WSDL10

permettant la description de ces services.

Les Services Web XML reflètent une approche de conception «orientée», basée sur l’idée

de construire des applications en déployant et en découvrant des services réseau ou en

invoquant des applications pour accomplir des tâches.

L’utilisation de Services Web XML rend possible la réalisation d’environnements

technologiques distribués dans lesquels des applications u des composantes applicatives,

peuvent interagir entre elles, et ce de manière indépendante de la plate-forme physique,

des langages de programmation ou encore des systèmes d’exploitation. Ainsi, un Service

Web XML est un morceau de logique d’affaires, localisé quelque part sur un réseau, qui

est accessible via des normes et standards XML. Utiliser un Service Web XML peut être

aussi simple que de s’habiliter sur un portail ou aussi complexe que d’amorcer une

transaction d’affaires multi organisation. Les Services XML sont en fait des applications

modulaires et indépendantes qui peuvent être décrits, publiées, localisées, et appelées sur

un réseau.

6 eXtensible Markup Language-Remote Procedure Calling 7 Simple Object Access Protocol 8 Java 2 Enterprise Edition 9 Universal Description, Discovery and Integration 10 Web Service Description Language


Filatova Irina 2. Chapitre 2 Concept Services Web XML

2.1. Définition de Services Web XML Les Services Web XML [URL2] sont des processus métiers ou des données accessibles

via Internet par n’importe quel autre tiers quelle que soit sa nature. Les Services Web

XML permettent aux applications d’interagir entre elles via le Web. Les Services Web

XML sont des composants logiciels encapsulant des fonctionnalités métier de l’entreprise

et accessibles via des protocoles standards du Web. Un Service Web XML est décrit dans

un document WSDL [URL3], précisant les méthodes pouvant être invoquées, leur

signature, et les points d’accès du service (URL11, port, etc.) Ces méthodes sont

accessibles via SOAP [URL4]: la requête et la réponse sont des messages XML

transportés par HTTP. Un Service Web XML est accessible depuis n’importe quelle

plate-forme ou langage de programmation. On peut utiliser un Service Web XML pour

exporter des fonctionnalités d’une application et les rendre accessibles via des protocoles

standard. Le Service Web XML sert alors d’interface d’accès à l’application, et dialogue

avec elle au moyen de middleware (CORBA12, RMI13, DCOM14, EJB15, etc.) [Girad,

Crusson, 2001]

2.2. Raisons principales d’utilisation de Services Web XML

Les principales raisons d'utiliser les Services Web XML sont de:

• gagner une interopérabilité entre différentes applications distribuées hébergées par

différents serveurs programmées dans des langages différents;

• rendre accessibles des applications à travers firewall en utilisant les protocoles

Internet;

11 Uniform Resource Locator 12 Common Object Request Broker Architecture 13 Remote Method Invocation 14 Distributed Component Object Model 15 Enterprise JavaBeans


Filatova Irina

• offrir un langage de modélisation XML indépendant de la plate-forme ou de la

technologie utilisée qui facilite le développement.

En plus, les Services Web XML doivent respecter les propriétés suivantes:

• être accessibles via Internet;

• se décrire et décrire les services qu'ils proposent par un fichier descriptif de type

XML;

• communiquer avec un client sous forme de message XML transmis sur Internet

via un protocole comme HTTP.

2.3. Caractéristiques des Services Web XML

Cette technologie est basée entre autres sur le standard XML, et est supportée par la

majorité des entreprises en technologie de l’information. XML est le langage neutre

permettant de représenter les données. Il provient de l’évolution du langage SGML16,

permettant aux concepteurs de définir leurs propres marqueurs, dans le but de

personnaliser la structure des données qu’ils comptent présenter. Le support global de ce

standard par les entreprises assure que chaque nouvelle technologie logicielle aura une

stratégie de Services Web XML dans les années à venir.

Un Service Web XML possède les caractéristiques suivantes :

• Représentation de données basée sur XML;

• Interface flexible;

• Habilité d’interagir de manière synchrone ou asynchrone;

• Support des appels de fonctions distantes;

• Support d’échange de documents.

16 Standard Generalized Markup Language


Filatova Irina

2.4. Exemples concrets d’utilisation

Lors de la rédaction du travail de semestre, nous avions abordé des projets tels que .NET

Passport ou .NET My Services développé par Microsoft [URL5]. Aujourd’hui, d’autres

services ont fait leur apparition. Notons Google [URL6], Altavista [URL7], E-Bay

[URL8]. Nous nous rendons compte de l’intérêt que peut apporter un service Web dans

l’utilisation d’une base de données qui est déjà accessible sur Internet. Mais les Services

Web peuvent également permettre d’autres manipulations. Il est maintenant possible

d’envoyer des messages via un service Web, de faire des réservations ou des achats de

tickets de concerts (une organisation américaine ressemblant à Ticket-Corner [URL9]),

de faire traduire du code d’un langage vers un autre (dans ce cas, l’utilisation des

Services Web XML permet une amélioration du produit à tous moments.) Bien d’autre

cas existent actuellement.

Frameworks disponibles. De nombreux langages sont actuellement en cours d’adaptation

pour permettre une communication avec les services Web. L’adaptation consiste en un

développement d’une librairie d’accès aux services Web. Celle-ci se base souvent sur

d’autres libraires, typiquement les librairies de sérialisation XML. Ce cas est bien visible

avec le projet Apache pour Java. Microsoft SOAP Toolkit. Le SOAP Toolkit de Mirosoft

permet de créer des applications (ou de modifier des existantes) développées par exemple

avec Visual Studio. Framework .NET. .NET est un framework élaboré au départ par

Microsoft dans un but quelque peu avoué de combattre Java sur son propre terrain. Ce

framework étant extrêmement récent (le début du développement date de 2000), il a tout

d’été orienté Service Web XML. Ceci en fait un outil tout particulièrement indiqué pour

des entreprises souhaitant débuter un développement de Service Web XML. Monde de

Java. La communauté Java est très productive en librairies pour les services Web.

Borland, Microsoft, IBM et SUN ont chacun développé leur propre librairie payante pour

l’accès aux Services Web XML. D’autres projets permettent également le développement

de service Web, de manière gratuite comme par exemple Apache et JBoss ; dans ces cas

précis, il s’agirait plutôt d’extensions de projets existants. Les solutions gratuites étant

pour l’instant bien plus complexes à mettre en place, tout du moins pour des

développeurs n’utilisant pas les librairies de ces différents projets. Autres. Il est

également possible de développer ou d’accéder à des services Web avec d’autres

langages, tel que Python ou PHP. Dans le cas de ce dernier, la librairie n’en est cependant


Filatova Irina qu’à ses premiers pas : il est encore trop tôt pour savoir quels seront ses avantages et

inconvénients.

3. Chapitre 3 Architecture de Services Web XML

3.1. Fondation de l’architecture de Services Web XML L’architecture des Services Web XML repose sur un mécanisme de transport d ’une

demande de service entre des clients et des serveurs, tous deux connectés au réseau. La

Figure 3.1.1. décrit le mécanisme de transport :

Figure 3.1.1. Mécanisme de transport

Dans cette architecture, le client peut être soit un navigateur Web, 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 ou sur

un serveur d’applications J2EE ou .NET.

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.

Le «bus de requêtes » est fondé sur TCP/IP17 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

17 Transmission Control Protocol/Internet Protocol


Filatova Irina des entreprises partenaires. Le Service Web XML est l’interface publique de l’application

dans le réseau intra ou interentreprises.

Comme HTTP ne transmet que du texte – des pages Web au format HTML, tous les

échanges entre Services Web XML (requêtes et résultats de requêtes) circulent également

au format texte, sous forme de documents codés en XML. La Figure 3.1.2. décrit

l’échange des messages :

Figure 3.1.2. Présentation de Services Web XML

3.2. Architecture orientée services (SOA)

Les Services Web XML reposent sur une architecture orientée services (SOA)18. La base

de l’architecture d’un Service Web XML est clairement définie et reste la même quel que

soit le type de développement provenant des éditeurs.

La Figure 3.2.1. décrit l’architecture qui inclut les 3 types élémentaires d’interactions :

Figure 3.2.1. Architecture SOA

18 Service Oriented Architecture.


Filatova Irina

Fournisseur de Services Web XML. Les fournisseurs de Web Services XML développent

et définissent les Web Services XML pour les publier dans un annuaire de Web Services

XML ou pour les rendre directement accessibles par les consommateurs.

Client de Services Web XML. Les clients de Services Web XML font une recherche soit

dans l’annuaire des Services Web XML soient directement auprès des fournisseurs afin

de trouver les services désirés. Une fois que le service a été localisé, le client se lie

directement aux fournisseurs du service.

Annuaires de Services Web XML. Ils se comportent comme des annuaires centralisés

incluant la description et les méthodes d’accès aux Services Web XML fournisseur ayant

publié leurs descriptions.

3.3. Services Web et architecture à 5 couches Les architectures à base de Services Web sont des architectures multi-applications. Pour

bien coder ces applications Stève Sfartz a proposé le schéma de conception "Architecture

à 5 couches" [URL10] qui présente dans la Figure 3.3.1. :

Figure 3.3.1. Architecture à 5 couches

• La couche Physique correspond à la structure physique des données: SGBD,

annuaire LDAP, Transaction CICS, ..


Filatova Irina

• La couche Mapping réalise les accès vers la couche Physique. Dans le cas d'un

SGBDR, il s'agit d'un outil de mapping relationnel/objet;

• La couche Entreprise correspond aux objets structurants de l'entreprise. Ces

objets n'intègrent aucune notion fonctionnelle. Cette couche regroupe des objets

transversaux à toutes les applications. De plus, la couche Entreprise propose des

services d'accès à ces objets au travers de méthodes de création, recherche,

modification, suppression. Ces méthodes contiennent les règles de gestion

associées aux différentes opérations;

• La couche Application regroupe la logique fonctionnelle d'une application, tel

qu'elle est définie dans les spécifications fonctionnelles détaillées. La couche

Application utilise les services de la couche Entreprise pour réaliser le fonctionnel

spécifié, et présente ce fonctionnel sous la forme de services. Ces services

retournent des objets de niveau application, qui sont autant de vues sur les objets

entreprises. Les objets de niveau application peuvent, par exemple, masquer

l'information "découvert autorisé" d'un objet Compte de niveau Entreprise.

• La couche Client représente l'interface utilisateur. Elle est amenée à changer

fréquemment dans le cas d'une application WEB.

L'architecture à 5 couches permet de décomposer le système en sous-systèmes. Chacun

de ces sous-systèmes peut être modélisé de façon indépendante, et il est possible

d'affecter des responsabilités aux intervenants du projet sur telle ou telle couche (analyse

/ implémentation.)

Le modèle à 5 couches propose donc un cadre de conception systématique, garantissant

des hauts niveaux :

• d'évolutivité, en dissociant le fonctionnel du transactionnel;

• de maintenabilité, en attribuant des responsabilités par couche;

• de réutilisabilité, en assurant un faible couplage entre les couches.


Filatova Irina Dans le cadre d'une architecture à 5 couches l'utilisation des services se fait naturellement.

Développer l'accès à une application via les Services Web XML revient à développer une

nouvelle couche client. Il y aura ainsi des clients XHTML, WML, XML, et Services

Web d'une application.

Le développement de cette couche client "Services Web " se fera d'ailleurs très

simplement en important la façade de la couche application dans un outil de

développement de Services Web XML.

Le fait qu'une application soit accessible via les Services Web ne doit pas impacter les

développements des couches application et entreprise. Ces couches doivent rester

indépendantes des clients qui les manipulent.

3.4. Exemples des architectures CORBA. Dans l’architecture CORBA, ce rôle est joué par l’ORB19, 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é IIOP20, s’appuie sur

TCP/IP et peut donc être employé sur Internet. .NET .Dans l ’architecture Microsoft, ce

rôle est précisément assuré par le protocole DCOM qui étend le modèle mono-machine

COM aux réseaux de PC sous Windows. J2EE. Dans l’architecture J2EE, le protocole

RMI permet à un programme Java d’en appeler un autre qui est exécuté sur une machine

virtuelle Java distante.

4. Chapitre 4 Standards de fonctionnement de Services Web XML Afin de rendre un Service Web XML exploitable, nous devons avoir la capacité de

définir ce service, de l'enregistrer dans une base de données, de le découvrir grâce à la

19 Object Request Broker 20 Internet InterOrb Protocol


Filatova Irina base de données et finalement de l'invoquer et de l'exécuter. Heureusement, un bon

nombre de standards, basés sur XML, rendant possible l'exploitation des Services Web,

ont été développés: SOAP, WSDL, UDDI… qui ont émergé comme standards Internet:

• «eXtensible Markup Language» (XML), [URL2]

qui est un langage à balise définissant un format universel de représentation, de

description et d'échange de données;

• «Simple Object Access Protocol » (SOAP), [URL4]

qui fournit une structure d’emballage permettant de transporter des documents;

• «Web Service Description Language » (WSDL), [URL3]

qui est utilisé comme méthode de description de services offerts;

• «Universal Description, Discovery and Integration» (UDDI), [URL11]

qui est utilisé comme méthode de publication et de découverte des services par

les utilisateurs.

Vue d’ensemble des Services Web XML. Le rapport entre les technologies, SOAP, WSDL

et UDDI, peut être décrit par scénario suivant : une application agissant en tant que client

a besoin de localiser une autre application ou une composante de logique d’affaires

localisées quelque part sur le réseau. Le client effectue une requête au répertoire UDDI

pour localiser le service offert par l’application. Cette requête peut s’effectuer soit par un

nom, par une catégorie ou par une spécification supportée. Une fois le Service Web XML

localisé, le requérant obtient à partir du répertoire UDDI les renseignements au sujet de

l’emplacement d’un document WSDL.

Le document WSDL contient les renseignements relativement à façon d’invoquer le

Service Web XML et la structure de messages de la requête en format de XML. Le

requérant crée un message SOAP conformément au XML, tel que spécifié par WSDL,

envoie une demande à l’application où le service réside pour finalement être réalisé par

l’application.

La Figure présente 4.1. la vue ensemble de Services Web XML :


Filatova Irina

Figure 4.1. Vue ensemble de Service Web XML

Voyons maintenant un peu plus en détail les principaux standards cachés sous le terme de

Services Web: XML, SOAP, WSDL et UDDI.

4.1. Technologies XML

XML est un standard promulgué par le W3C, l’organisme chargé de standardiser les

évolutions du Web. 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.

On retrouve dans XML une généralisation des idées contenues dans HTML et SGML21.

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.

Au même titre que le langage HTML, XML est un sous-ensemble simplifié du langage

SGML et est destiné à décrire différents types de données à l'aide de «tags. » Le langage 21 Structured Generalized Markup Language


Filatova Irina XML est orienté vers la structuration des données. La puissance du standard XML réside

dans la simplicité avec laquelle il permet de décrire des données. Cette simplicité facilite

l'interopérabilité entre systèmes totalement hétérogènes. Un document XML est constitué

de quatre parties distinctes : la déclaration, les règles, l'instance du document et la feuille

de style. Le tableau 4.1.1. présente les dialectes XML :

Tableau 4.1.1. Dialectes XML pour Services Web

La déclaration permet de définir la version de XML utilisée ainsi que le type d'encodage.

Les règles définissent le type du document en spécifiant notamment les contraintes

structurelles et les valeurs par défaut. Elles sont utilisées pour valider l'instance d'un

document XML et la structure de ce document présente dans l’exemple 4.1.2. :

Exemple 4.1.2. Structure de document XML

Dialectes XML

Langage / organisme Champ d'application

XML eXtensible Markup Language, W3C

La spécification de base du langage XML qui précise comment définir la structure des données dans un document.

XML Schema, W3C

XML Schema spécifie comment décrire et valider une structure de données. A cette fin, XML Schema permet par exemple de "typer" les données (date, chiffre, etc. ) Auparavant, ce travail nécessitait la création d'une DTD.

XML Namespaces, W3C

Les espaces de noms permettent d'appliquer au sein d'un même document XML plusieurs vocabulaires.

XSL/XSLT eXtensible Stylesheet Language W3C

XSL est à XML ce que les feuilles de styles (les fameuses "CSS") sont à HTML: un moyen de formater les documents. Associé à XSLT, XML permet de transformer le format d'un document XML.

<?xml version=’’1.0’’ encoding=’’ISO-8859-1’’?> <! DOCTYPE livre STSTEM ‘’http://abu.cnam.fr/annuaire.dtd’’> <annuaire tipe =’’pages blanches> <entree> <nom>Paul Lafargue</nom> <telephone>06 03 02 01</telephone> </entree> <entree> <nom>Lorédan Larchey</nom> <telephone>05 01 02 03</telephone> </entree> </annuire> |


Filatova Irina Ces règles sont généralement écrites sous la forme d'un DTD qui définissent les balises

qui sont utilisées dans une famille de documents XML. L’exemple 4.1.3. déclare la

structure de DTD et sa présentation dans le document XML:

Exemple 4.1.3. Structure de DTD

Cependant, depuis peu, le W3C propose une alternative aux DTDs : XML Schema. Le

XML Schema qui présente dans l’exemple 4.1.4., au contraire des DTDs, est

intégralement défini selon la syntaxe XML.

Exemple 4.1.4. Présentation XML Schema

<?xml version=’’1.0’’ encoding=’’ISO-8859-1’’?> <! DOCTYPE livre STSTEM ‘’http://abu.cnam.fr/annuaire.dtd’’> <annuaire tipe =’’pages blanches> …….. </annuire> | <?xml version=”1.0”> <!ELEMENT entree (nom, telephone)> <!ELEMENT nom (#PCDATA)> <!ELEMENT telephone (#PCDATA)>

<xsd : schema xmlns :xsd=’’http:///www.w3.org/2001/10/XMLSchema’’ targetNamespace=’’http://www.annuaires.org’’ xmlns=’’http://www.annuaire.org’’ elementFormDefault=”qualified”/> <xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"> <xsd:element name="entree"> <xsd:complexType> <xsd:sequence> <xsd:element name="nom" type="xsd:string" minoccurs=”1” maxoccurs=”1”/> <xsd:element name="telephone" type="xsd:decimal"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema>

XML-Schema est une recommandation du W3C, au même titre que XML. Les

documents XML-Schema permettent de décrire la structure d'un document XML d'une

façon beaucoup plus complète que les DTD. Il est par exemple possible de spécifier la

typologie des données (String, Décimal, etc.) que va contenir le document XML décrit

par le XML-Schema.


Filatova Irina Par ailleurs, il étend considérablement les capacités de ces DTDs : il supporte les XML

Namespaces (xmlns) que nous introduisons dans la suite du document, l’exemple 4.1.5. :

Exemple 4.1.5. Présentation XML Namespaces

<organisation> <xmls : entreprise=’’http://www.entreprise.org’’ <xmls : personne = ‘’http://www.personne.org’’> <entreprise :nom » Bizib onc.</entreprise :nom> <personne:nom> <personne:nomDeFamille>Lafargue</personne :nomDeFamilli> <personne:prenom>Paul</personne :prenom> </personne :nom> <personne : fonction PDG> </personne :fonction> </organisation>

Les XML Namespaces sont spécifiés dans une recommandation du W3C. Ils permettent :

• de mélanger du vocabulaire XML provenant de plusieurs grammaires,

• d’identifier de manière unique les balises XML.

C’est l ‘objectif des espaces de nommage, ou XML Namespace. Le principe est d’associer

une URI22 à un nom. Par exemple l’espace de nommage "personne" peut être déclaré de

la façon suivante :

xmlns:personne="http://www.personne.org".

Ce nom est ensuite utilisé pour caractériser les balises. Par exemple <personne:nom>

signifie que la balise <nom> appartient à l’espace de nommage "personne". L’URI de

xmlns (http://www.entreprise.org et http://www.personne.org) peut être fictive : elle

n’est pas vérifiée, toutefois elle pointe généralement sur la grammaire de l'espace de

nommage. L’utilisation d’espaces de nommage permet de préciser que des éléments d’un

document XML sont associés à une grammaire, et de donner l’URI où la grammaire est

spécifiée.

Enfin, la feuille de style définit la présentation XSL23 associée au document XML. Il

existe un mécanisme de transformation XSLT24 permettant d'obtenir la présentation

22 Uniform Resource Identifier 23 eXtensible Stylesheet Language 24 eXtensible Stylesheet Language Transformation


Filatova Irina d'un document XML en vue de le présenter à son utilisateur. Un document XSLT qui

présente dans l’exemple 4.1.6. peut être vu comme une succession de template. Un

template étant du code XSLT qui permet de sélectionner une partie du document XML et

de lui apporter une transformation. Il permet de sélectionner un "livre" et d'appliquer une

transformation qui génère du HTML. La transformation est située entre les balises de

début et de fin du template (xsl:template). Il existe de multiples instructions XSLT

(xsl:when, xsl:otherwise, xsl:if,...) qui assurent à ce langage une grande puissance de

transformation.

<xsl:stylesheet xmlns:xsl=""> <xsl:template match="livre"> <html> <body> <p> <b> <xsl:value-of select="auteur"/> </b> <xsl:value-of select="titre"/> </p> </body> </html> </xsl:template> </xsl:stylesheet>

Exemple 4.1.6. Présentation XSLT

4.2. Services Web XML et Protocole SOAP

« SOAP provides the first piece of the puzzle: a means for one piece of code to

communicate with another piece of code » [Clark, Fletcher, Hanson, Irani,

Watehouse, Theli, 2001.]

SOAP fournit une structure d’emballage standard XML permettant de transporter des

documents sur une variété de technologies Internet, comprenant SMTP25, HTTP et

FTP26. En fait, ce protocole de communication permet l’interopérabilité des applications à

travers l’Internet. L’interopérabilité implique qu’un programme opérant sur un système

ouvert fonctionne également sur un autre système. SOAP associe les protocoles HTTTP,

25 Simple Mail Transfert Protocol 26 File Transfert Protocol


Filatova Irina SMTP et FTP à la flexibilité et l’extensibilité du langage XML, pour faciliter la

communication entre différents modèles de développement, dont CORBA, DCOM,

J2EE. Il permet aux développeurs de réaliser des Services Web XML et de relier des

composantes hétérogènes sur Internet.

4.2.1. Description des messages SOAP

Le principe général de SOAP définit un mécanisme simple et léger pour échanger de

l’information structurée et typée entre entités dans un environnement distribué

l’information structurée en utilisant le langage XML. Les messages échangés via le

protocole SOAP jouissent donc les avantages qui lui procurent le langage XML pour

structurer les données. Le standard HTTP, défini à l’origine pour transporter du texte, se

présente comme le protocole idéal. En effet, le système de requête et réponse de SOAP

correspond parfaitement au système de requête et réponse de HTTP.

Le développement d'un Service Web XML ne présente donc pas de difficultés techniques

puisque la technologie utilisée est parfaitement maîtrisée. On retrouve donc la logique

client-serveur bien connue des développeurs de sites Web. Le client SOAP a pour rôle

d'encoder les requêtes destinées à un service distant sous le format XML et de les

envoyer via HTTP. Le serveur SOAP, quant à lui, est à l'écoute des messages SOAP qu'il

interprète et convertit dans un langage compréhensible par l'objet auquel est destinée la

requête.

Ensuite, le serveur peut renvoyer la réponse encodée au format XML via HTTP. Ce

processus permet donc à des applications écrites dans n'importe quel langage et exécutées

sur n'importe quelle plate-forme de communiquer; les efforts de traduction étant laissés

au client et au serveur SOAP. Bien entendu, ces deux rôles ne sont pas exclusifs et il est

tout à fait envisageable de rencontrer une application distribuée jouant à la fois le rôle de

serveur et de client SOAP.


Filatova Irina

4.2.2. Enveloppe de message

Message SOAP définit à la fois les règles d'encodage des données qui traverseront les

réseaux et les conventions de représentation des appels de procédure à distance. Il définit

également l'enveloppe du message et fournit un mécanisme pour lier le message avec le

protocole sous-jacent. Les règles utilisées pour la sérialisation au sein d'un message

SOAP sont généralement dictées sur base d'un «XML Schema. » Il est important de

souligner que l'encodage des données selon ce «XML Schema » n‘est absolument pas

obligatoire et que les clients et serveurs sont libres d'utiliser des conventions différentes.

Il existe également un mécanisme permettant de donner explicitement le type de chacune

des données utilisées.

Le message SOAP, entièrement défini au format XML, est contenu dans une enveloppe

divisée en trois parties : un élément racine appelé Enveloppe et deux autres éléments

intégrés à l'enveloppe, appelés En-tête et Corps.

L'enveloppe doit obligatoirement contenir un élément Corps. S'il contient également un

élément En-tête, non obligatoire, il ne doit contenir que ce seul En-tête. L'en-tête doit

obligatoirement être placé avant le Corps. La Figure 4.2.2.1. présente de la structure de

l’enveloppe SOAP :

Figure 4.2.2.1. Structure de l’enveloppe SOAP

L'en-tête utilise un code XML valide, bien formé et qualifié par un XML Namespace

pour décrire le contenu et le mode de traitement du message. Chaque élément contenu

dans l'En-tête est appelé Bloc d'en-tête. Ces blocs d'informations fournissent des


Filatova Irina renseignements sur la forme des structures de données incluses, sur l'application de

sécurité, sur l'identité de l'expéditeur et sur le routage souhaité. Le Corps peut contenir

autant de noeuds inférieurs que nécessaire. Le contenu de cet élément Corps est le texte

actuel du message en code XML "well-formed".

Ce code doit être qualifié par un espace de noms et ne doit contenir aucune instruction

XML, ni aucune référence à une DTD (définition de type de document.) La Figure

4.2.2.2. présente un exemple le contenu de l’enveloppe SOAP :

Figure 4.2.2.1 Structure de l’enveloppe SOAP

4.2.3. Exemple de message SOAP

L’exemple 4.2.3.1. présente un message SOAP envoyé à un Service Web XML. Dans le

cas présent, la requête interroge un service météorologique en lui transmettant un code

postal (zipcode) afin d'obtenir en retour la température associée à ce code postal.


Filatova Irina

<?xml version='1.0' encoding='UTF-8'?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xlmsoap.org/soap/envelope" SOAP :ENV : encodingStyle="http://schema.xlmsoap.org/soap/encoding" <SOAP-ENV:Header> <ms1: transaction xmlns:ms1=”soap-transaction” SOAP-ENV: mustUnderstand=”true”> <transactionID>1234</transactionID> </ms1: transaction> </SOAP-ENV:Header> <SOAP-ENV:Body> <m:getWeather xmlns:m=”http://weather.com/messageweather”> <zipcode xsi:type="xsd:string">10016</zipcode> </m:getWeather> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Exemple 4.2.3.1. Requête SOAP L’élément « Envelope » est la racine de ce document XML. Pour construire un appel de

procédure distante au sein du corps du message SOAP, on doit disposer les trois

informations; l’URI de l’objet cible représentant la destination sut laquelle la méthode

sera invoquée, le nom de la méthode et l’ensemble de paramètres de cette méthode.

L’URI est utilise comme « namespace », présentant comme l’URI

« http://schemas.xlmsoap.org/soap/envelope », pour qualifier l’élément représentant la

méthode. Dans notre exemple, l’objet distant est présente par l’URI

«http://weather.com/messageweather/. » La procédure distante est ainsi modélisée sous

forme d’une structure XML tout à fait indépendante du message SOAP.

L’exemple 4.2.3.2. suivant présente le message SOAP retourné en réponse à la requête

ci-dessus. La valeur de retour contenue dans ce message est un simple chiffre (la

température actuelle.) Nous constatons ici que la réponse ne contient pas nécessairement

un En-tête, puisque cet élément est optionnel. <?xml version='1.0' encoding='UTF-8'?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2001/09/soap-envelope" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <SOAP-ENV:Body> <ns1:getWeatherResponse xmlns:ns1="urn:examples:weatherservice" SOAP-ENV: encodingStyle="http://www.w3.org/2001/09/soap-encoding"> <return xsi:type="xsd:int"> 65 </return> </ns1:getWeatherResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Exemple 4.2.3.2. Réponse SOAP


Filatova Irina

Les messages SOAP peuvent être expédiés par l'intermédiaire des protocoles HTTP,

SMTP, TCP/IP ou autres. Dans la pratique, les transferts par HTTP sont largement

majoritaires.

4.3. Services Web XML et organisation d’un document WSDL

« WSDL is the XML-based format in which a publisher describes their Web

Services » [Clark, Fletcher, Hanson, Irani, Watehouse, Theli, 2001.]

L’adoption des formats d’emballage SOAP a suscité le besoin de décrire les

renseignements opérationnels de manière plus structurée. WSDL a ainsi été introduit afin

d’adresser ces besoins. WSDL qui est standard base sur la technologie XML qui décrit

d’un Service Web XML sous la forme d’un ensemble de points finaux appelés ports.

En autres mots, le langage WSDL est une syntaxe XML utilisée pour définir l'interface

générale des Services Web XML. Ce fichier contient le chemin d’accès au serveur, mais aussi

les prototypes des méthodes qui servent de points d’entrées et la description des types complexes.

Cette définition intègre les composants fondamentaux suivants :

• Informations sur toutes les fonctions disponibles publiquement;

• Définitions abstraites des données à transmettre;

• Informations sur le type de données pour tous les messages XML;

• Informations obligatoires sur le protocole de transfert à utiliser spécifiquement;

• Informations de type Adresse pour localiser le service à spécifier.

4.3.1. Description d’un document WSDL Les définitions WSDL facilitent l'application des Services Web en les rendant "auto-

descriptifs" :

• <definitions> : Cet élément contient la définition du service qui est la racine de

tout document WSDL. <definitions> contient trois types d’éléments :


Filatova Irina

o <message> et <portType> : Ces éléments définissent les opérations

offertes par le service, leurs paramètres d’entrée et de sortie, etc. En

particulier, un <message> correspond à un paramètre d’entrée ou de sortie

d’une <operation>. Un <portType> définit un ensemble d’opérations. Une

<operation> définit un couple message entrée / message sortie. Par

exemple, dans le monde Java, une opération est une méthode et un

portType une interface;

• <binding> : Cet élément associe les <portType> à un protocole particulier. Les

bindings possibles sont SOAP, CORBA ou DCOM. Actuellement seul SOAP est

utilisé. Il est possible de définir un binding pour chaque protocole supporté;

• <service> : Cet élément précise les informations complémentaires nécessaires

pour invoquer le service, et en particulier l’URI du destinataire. Un <service> est

modélisé comme une collection de ports, un <port> étant l’association d’un

<binding> à un URI.

Il est aussi possible de définir des types de données complexes dans une balise <types>

juste avant la balise <message>. Enfin, chaque élément WSDL peut être documenté à

l’aide de l'élément <documentation>. Cet élément contient des informations liées à la

compréhension du document par les utilisateurs humains du service.

Autrement dit, WSDL permet aux Services Web de décrire ce qu'ils font, comment ils le

font et comment les clients peuvent les exploiter. Dans notre exemple 4.3.1.1., la

définition abstraite de l'opération « getDayWeather » est décrite de la façon suivante :

<definition> <message name = ‘’getWeather’’> <part name =”body” element=”zipcode”> </message> <portType name = StockDayWeatherPortType> <operation =”getDayWeather” > <input message = “getNineDayWeatherInput”> <output message = “getNineDayWeatherOutput”> </opreration> </portType> </definition>

Exemple 4.3.1.1. Structure de la définition d’un document WSDL


Filatova Irina L’opération est donc décomposée en deux messages; la requête et la réponse. La

définition des données échangées dans ces messages est décrite au préalable dans « XML

Schema ». Ce « XML Schema » définit également le «namespace », en l’occurrence

« http://weather.com/messageweather», représente le contexte de l’opération.

Ensuite, l’opération est liée avec le protocole de communication HTTP, et dans l’exemple

4.3.1.2. présente sa structure : <binding name=”StockDayWeatherSoapBinding” type=”StockDayWeatherPortType”> <soap:binding transport=”http://schemas.xlmsoap.org/soap/http”>| </binding>

Exemple 4.3.1.2. Structure de binding d’un document WSDL

Finalement, le nouveau port ainsi crée est attaché à notre Service Web XML en spécifiant

le point de communication (une URL pour HTTP, une adresse e-mail pour SMTP..)

nécessaire pour accéder à cette opération, qui présente dans l’exemple 4.3.1.3. :

<service name=”StockDayWeatherQuoteService” > <port name =”StockDayWeatherQuotePort” binding=”StockDayWeatherSoapBinding”> <soap:address location =”http://stockquoteserver.com/StockQuote”>| </port> </service>

Exemple 4.3.1.3. Structure de service d’un document WSDL

La location correspond à l’adresse à laquelle on a installé le serveur SOAP.

4.3.2. Exemple de la structure d’un document WSDL

En continue, WSDL décrire des Services Web sous la forme d'un ensemble de points

finaux appelés ports. Un port est décomposé en deux parties distinctes. La première partie

contient la définition abstraite des opérations ainsi que des messages contenus dans ces

opérations. Une opération est ainsi considérée comme une action dont on peut extraire

deux types de messages : une requête et une réponse.


Filatova Irina Tandis que la seconde partie lie les messages à un protocole de communication concret.

Cette distinction entre partie abstraite et concrète est requise afin de favoriser la

réutilisabilité de cette définition en combinaison avec d'autres protocoles. Un port est

donc décomposé en un ensemble d'opérations. Chaque port est lié à un protocole de

communication comme par exemple SOAP ou SMTP.

Enfin, le port représente une adresse à laquelle on peut joindre l'entité supportant les

opérations définies. L’exemple 4.3.2.1. est la description du service « Echo » précédemment

défini :

1. <definition 2. xmlns:xsd="http://www.w3.org/1999/XMLSchema" 3. xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"> 4. 5. <message name="echoInput"> 6. <part name="expression" type="xsd:string"/> 7. </message> 8. 9. <message name="echoOutput"> 10. <part name="expression" type="xsd:string"/> 11. </message> 12. 13. <portType name="EchoPortType"> 14. <operation name="echo"> 15. <input message="echoInput"/> 16. <output message="echoOutput"/> 17. </operation> 18. </portType> 19. 20. <binding name="EchoSoapBinding" type="tns:EchoPortType"> 21. <soap:binding style="document" 22. transport="http://schemas.xmlsoap.org/soap/http"/> 23. <operation name="echo"> 24. <soap:operation soapAction="urn:ServiceEcho"/> 25. <input> 26. <soap:body use="encoded" 27. encodingStyle= 28. "http://schemas.xmlsoap.org/soap/encoding/"/> 29. </input> 30. <output> 31. <soap:body use="encoded" 32. encodingStyle= 33. "http://schemas.xmlsoap.org/soap/encoding/"/> 34. </output> 35. </operation> 36. </binding> 37. 38. <service name="EchoService"> 39. <port name="EchoSoap" binding="tns:EchoSoapBinding"> <soap:address location="http://www.improve.fr/ServiceEcho"/> 42. </port> 43. </service> 44. </definition>

Exemple 4.3.1.2. Description de Service Web XML par WSDL


Filatova Irina L'opération est donc décomposée en deux messages : la requête et la réponse. La

définition des données échangées dans ces messages est décrite au préalable dans un

« XML Schema". Ce « XML Schema » définit également le «Namespace » représentant

le contexte de l'opération.

4.4. Services Web XML et UDDI « UDDi describes a registry in which Web Services can be advertized» [Clark,

Fletcher, Hanson, Irani, Watehouse, Theli, 2001.]

Un autre standard à l’invocation des Services Web XML est UDDI qui a été créé par

IBM, Microsoft et Ariba. C’est une architecture répartie qui permet aux fournisseurs de

Services Web XML (Business providers), d’enregistrer leurs services, et aux applications

de rechercher les services correspondant à leurs besoins, de façon normalisée. Il fournit

donc le mécanisme de publication et de recherche ces services. UDDI est donc un

annuaire distribué de Services Web XML et d’entreprises (Business/Service Registry).

UDDI s’appuie sur les standards tels que HTTP, SOAP et WSDL.

UDDI définit un ensemble de spécifications : une spécification de l’interface d’un

registre définissant environ une trentaine des messages SOAP pouvant être utilisée pour

effectuer des requêtes et publier des services, une définition de la structure XML des

données contenues dans ces messages, une description du processus de réplication des

données contenues un registre…

4.4.1. Description du principe UDDI

Un registre (UDDI Business Registry), est décomposé en pages blanches, jaunes et vertes

qui sont présentent dans la Figure 4.4.1.1. :


Filatova Irina

Figure 4.4.1.1 UDDI Business Registry

• Pages blanches : noms, adresses, contacts, identifiants,… des entreprises

enregistrées. Ces informations sont décrites dans des entités de type Business

Entity. Cette description inclut des informations de catégorisation permettant de

faire des recherches spécifiques dépendant du métier de l’entreprise ;

• Pages jaunes : détails sur le métier de l’entreprise, les services qu’elle propose.

Ces informations sont décrites dans des entités de type Business Service ;

• Pages vertes : informations techniques sur les services proposés. Les pages vertes

incluent des références vers les spécifications des Services Web XML, et les

détails nécessaires à l’utilisation de ces services : interfaces implémentées,

information sur les contacts pour un processus particulier, description du

processus en plusieurs langages, catégorisation des processus.

La Figure 4.4.1.2. présente un scénario classique d’utilisation d’UDDI :

Figure 4.4.1.2. Utilisation UDDI


Filatova Irina

• Les fournisseurs de Services Web XML s’enregistrent auprès de l’UDDI Business

Registry (sur les pages blanches et jaunes) et ajoutent leurs services (en

complétant les pages jaunes et en renseignant les détails techniques sur ces

services dans les pages vertes.) En principe, un seul enregistrement d’un service

sur un référentiel est nécessaire. UDDI étant un service distribué sur Internet,

toutes les actions sont automatiquement répercutées sur les autres référentiels.

• Un utilisateur recherche une entreprise fournissant un service donné, et obtient

une description de l’entreprise qui le fournit par le biais des pages blanches et

jaunes, et des détails de l’invocation du service offert par des pages vertes ;

• L’utilisateur peut alors invoquer le Service Web XML distant en utilisant SOAP.

4.5. Différents standards Services Web XML

De nouveaux langages dédiés aux Services Web XML sont régulièrement proposés par

les organismes de recherche industriels et universitaires. Il ne faut pas perdre de vue que

la plupart des langages présentés sont complémentaires et ne répondent pas aux mêmes

besoins. On va donc présenter les objectifs et les fonctionnalités des principaux langages

et les standards consacrés aux services sur le Web.

XL27 [URL12] est un langage destiné aux Services Web, axée sur XML, utilisant un

langage propre de haut niveau, et prenant en compte les technologies du W3C (WSDL,

SOAP) afin de permettre une interopérabilité des applications XL avec d’autres

applications écrites dans un langage autre que XL. La principale motivation de XL est de

créer une plate-forme qui permette aux programmeurs d’implémenter rapidement des

Services Web XML en permettant une réutilisabilité maximale. Le langage de requête est

un langage déclaratif et peut donc être optimisé de manière automatique. De plus, comme

ce langage est de haut niveau, il permet une composition facilitée des services. XL

intègre également une politique de sécurité basée sur J2EE, et met l’accent sur le

traitement des instructions en mode pipeline, afin d’être plus réactive face à des sources

XML importantes ou continues. Cependant, même si XL permet de manipuler 27 XML Langage


Filatova Irina relativement facilement des Services Web XML, il ne permet pas de les décrire autrement

que par des entrées/sorties XML.

XDD28 [URL13] est un langage capable de décrire toute la sémantique d’une ressource

Web en ajoutant un langage déclaratif à la syntaxe XML. Une description utilisant XDD

est un ensemble d’éléments XML classiques, d’éléments XML étendus à l’aide de

variables, et de relations entre les éléments XML sous forme de clauses. XDD peut

également représenter tous les langages balisés basés sur XML, ebXML29. Il peut de plus

représenter de manière simple toutes les applications XML ayant des conventions

standardisées pour un certain nombre de domaines spécifiques, tels que :

• Wireless Markup Language ( WML);

• Mathematical Markup Language (MathML);

• Resource Description Framework (RDF).

XDD permet dès lors la convergence entre la sémantique et la syntaxe de ces langages,

accentuant l’interopérabilité et le développement indépendant des produits.

WSFL30 est un langage XML de description de flow, pour permettre la composition

récursive de Web Services XML. WSFL est une proposition de standard offrant deux

styles de composition de Services Web XML :

• description explicite de la succession des étapes et de l’enchaînement des appels

aux opérations des Services Web XML;

• modèle d’interactions de Services Web XML. C’est le premier cas qui se

rapproche le plus de la procédure au sens des langages de programmation.

WSFL utilise l’expression modèle de flux (flow model) pour désigner ce style de

spécification qui s’apparente à la programmation dans un langage de script. Le second

cas, appelé modèle global (global model) dans WSFL, décrit une collection de liens entre

opérations de services Web (en WSDL), prises deux à deux, sans indiquer de structure

de contrôle explicite. La métaphore employée ici est celle du contrat liant deux parties

dans l’univers commercial. WSFL permet de créer des modèles récursifs : une

28 XML Declarative Description 29 Electronic Business XML 30 Web Services Flow Language


Filatova Irina composition de services Web est elle-même considérée comme un service Web, utilisable

à son tour dans d’autres compositions. Enfin, WSFL propose des modèles d’interactions

dit hiérarchique et de pair à pair, reflétant des modes d’organisation différente.

5. Chapitre 5 Spécifications de Services Web XML Bon nombre d'entreprises vont s'aventurer dans le remaniement de leur infrastructure

pour qu'elle prenne en charge les Services Web XML. IBM, Microsoft, Sun et d'autres

membres du W3C ont défini les spécifications techniques majeures (dont le protocole

SOAP et le langage XML) indispensables pour que cet environnement s'épanouisse.

Néanmoins, il reste du chemin à parcourir pour que les Services Web XML deviennent

une plate-forme Internet viable pour les communications entre applications. De

nombreux directeurs informatiques s'inquiètent de la fiabilité et de la sécurité. Mais

maintenant que les standards progressent rapidement, les responsables informatiques

peuvent au moins commencer à développer des systèmes internes au sein desquels ces

problèmes peuvent être plus facilement gérés en attendant que les standards publics

soient finalisés. Le moment venu, il sera plus simple d'élaborer des systèmes capables

d'interagir avec l'extérieur, au-delà du pare-feu (Firewall) de l'entreprise.

IBM et Microsoft ébauchent et présentent la plupart des nouvelles propositions du W3C

en matière de Services Web XML. Jusqu'à présent, six nouveaux projets ont été soumis

et sont en cours de révision :

• Web Services Inspection (WS-Inspection) [URL15];

• Web Services Referral (WS-Referral) [URL16];

• Web Services Routing (WS-Routing) [URL17];

• Web Services Transaction (WS-Transaction) [URL18];

• Web Services Security (WS-Security) [URL19];

• Web Services Licensing (WS-Licensing) [URL20].


Filatova Irina Étudions les spécifications existant dans la structure des Services Web XML dans le

tableau 5.1., et la manière dont ces nouvelles spécifications visent à les pallier.

Spécification Description de spécifications

WS-Inspection WS-Inspection se charge d'agréer les pointeurs vers les WS qu'une entreprise souhaite exposer, puis d'interroger le document Web résultant de cette agrégation.

WS-Refferal WS-Referral définit de quelle manière les routeurs SOAP établiront un trajet de messages entre plusieurs points de services.

WS-Routing WS-Routing est un protocole fondé sur SOAP, définissant l’échange de messages unidirectionnels entre un émetteur et un récepteur au travers d’un certain nombre d’intermédiaires.

WS-Transaction XML WS-Transaction est le langage vise à garantir l'intégrité de transactions exécutées via les Services Web.

WS-Security Conçu pour intégrer diverses spécifications tierces (SAML, XKMS, XrPM, etc.), WS-Security -qui est en cours d'élaboration - offre des fonctions d'autorisation d'accès et de chiffrement des échanges.

WS-Licensing WS-Licensing décrit quant à elle le processus de codage des justificatifs d'identification à utiliser avec WS-Security

Tableau 5.1. Spécifications de Services Web XML

5.1. Recherche des services

La spécification WS-Inspection repose sur un modèle totalement distribué afin d'offrir

des informations afférentes aux services. Les descriptions des services sont stockées au

point de délivrance, et les demandes d'informations sont acheminées vers les sites qui

offrent les services. WS-Inspection est un format XML qui permet à une application

appelante d'interroger un site connu pour obtenir les services disponibles proposés.

Elle définit une série de règles spécifiant de quelle manière les sites doivent exposer leurs

informations aux systèmes appelants qui émettent une requête. En outre, les documents

WS-Inspection proposent des méthodes pour regrouper les références aux documents

préexistants de description de services, quel que soit le format d'origine dans lequel ils

ont été rédigés. Les informations sur le service renvoyées par une requête utilisent des

standards existants, tels que le langage WSDL. Ainsi, le système appelant peut exploiter

les informations renvoyées sur les Services Web XML sans avoir besoin de les modifier.


Filatova Irina

5.2. Création du système fiable

Les implémentations initiales du protocole SOAP sont des appels unidirectionnels

simples entre deux systèmes. Les spécifications WS-Referral et WS-Routing apportent la

technologie fondamentale qui aidera les architectes de systèmes à créer des systèmes plus

robustes. Ces deux spécifications fonctionnent conjointement pour définir le concept d'un

routeur SOAP. Les développeurs et architectes de systèmes peuvent utiliser ce routeur

pour développer des Services Web XML tels que l'équilibrage de charge, la mise en

miroir, la mise en mémoire cache et l'authentification des clients. Par exemple, un

Service Web XML peut céder des portions de son traitement à des services tiers et les

résultats peuvent être renvoyés aux utilisateurs d'origine de ce service sans que ces

derniers soient jamais au courant de cette passation. La spécification WS-Referral définit

de quelle manière les routeurs SOAP établiront un trajet de messages entre plusieurs

points de services.

Pour sa part, WS-Routing explique comment décrire le trajet d'un message. Elle permet

également de définir un trajet inverse: il est alors possible de mettre en place des modèles

d'échange bidirectionnel tels que transmission sur requête, conversations peer-to-peer et

envoi d'accusés de réception de messages et d'avis d'erreurs. Ces capacités accroissent la

fiabilité générale d'un système bâti sur la plate-forme SOAP.

C'est notamment le cas WS-Transaction est conçu par Microsoft, ce protocole qui semble

assez proche pour but de gérer les transactions longues et complexes initiées entre deux

composants Web Services XML. "En cas de plantage d'un des deux serveurs ou

applicatifs impliqués, WS-Transaction est conçu pour stabiliser le système de gestion des

échanges", résume un porte-parole de Microsoft France [URL5 ].

5.3. Mis en place des systèmes sécurisés

Les systèmes existants reposant sur le protocole SOAP transmettent leurs informations

sous forme de chaînes de texte XML. Bien que cette méthode permette à deux systèmes


Filatova Irina de communiquer quelle que soit leur architecture, elle soulève de graves inquiétudes en

matière de sécurité.

Les standards existants permettent de crypter les données lorsqu'elles transitent dans le

canal (au moyen de SSL31 sur HTTP) ou bien de crypter le canal lui-même (à l'aide du

standard IPSec.32) En effet, à moins que les deux extrémités de la communication ne se

mettent d'accord sur les formats de sécurisation du message en soi, il est impossible

d'appliquer des méthodes de sécurité davantage granulaires.

Les spécifications WS-Security et WS-License permettent conjointement d'améliorer la

sécurité granulaire des systèmes basés sur le protocole SOAP. WS-Security définit

l'aptitude à échanger les justificatifs d'identification, vérifier l'intégrité d'un message et

mettre en vigueur la confidentialité d'un message. Elle peut être utilisée individuellement

ou en combinaison. Avec WS-Security, les messages sont associés à des licences (par

exemple, les certificats X.509 ou les tickets Kerberos).

La spécification WS-License décrit quant à elle le processus de codage des justificatifs

d'identification à utiliser avec WS-Security. Cette dernière inclut des instructions pour

garantir l'intégrité des messages (à l'aide de WS-License) ainsi que la confidentialité. La

spécification exploite le cryptage pour coder tout ou partie d'un message tout en

fournissant aux systèmes récepteurs le moyen de décoder les informations.

6. Chapitre 6 Outils pour développer des Services Web XML Réalité technologique, les architectures distribuées à base de Services Web XML font

leur entrée dans les outils de développement. Un Service Web XML est un composant

logiciel qu’il convient de développer pour l’intégrer dans une chaîne de traitements.

L’ergonomie de l’outil constitue un critère de choix majeur. La génération de code

(WSDL, XML, Java …) est désormais classique. 31 Security Socket Layer 32 Internet Protocol Security


Filatova Irina

Ainsi SOAP est le véhicule pour échanger entre composants et permet d’exploiter de

nombreux protocoles de transport : HTTP, SMTP, FTP…Un document WSDL décrit

chaque Service Web en XML. UDDI permet de construire l’annuaire des Services Web

disponibles. Potentiellement réparti sur plusieurs sites, cet annuaire offre une vue logique

consolidée de services afin de bâtir des applications distribuées.

Une fois développée, un composant destiné à devenir un Service Web XML doit être

testé et intégré au sein d’une architecture plus complète. L’outil de développement de

Services Web XML doit fournir des possibilités de génération automatique

d’environnements de tests et faciliter cette intégration, le tableau présente certaines

solutions :

Classification Commentaires SUN SunONE Studio 4.1 EE

Gestion de JAX RPC (version Java SOAP), y compris les attachements. Gestion de WSDL et UDDI. Riches fonctions de manipulation de flux XML.

MICROSOFT Visual Studio Enterprise developer

Bonne gestion de XML, SOAP, WSDL et UDDI (fourniture d’un annuaire privé.) Seuls des composants .NET peuvent être développés dans l’un des langages proposés(VB,C#…)

IBM WebSphere Studio AD

Gestion de XML, de SOAP et de WSDL. Fourniture d’un annuaire privé UDDI depuis la version 5 du serveur d’applications associé.

Borland Web Services Solutions

Gestion complète de XML, SOAP, WSDL et UDDI. Offre de développement multiplate-forme, compatible J2EE et .NET. Solution disponible pour C+, Delphi et Java

Tableau 6.1. Présentation les outils de Services Web XML

7. Chapitre 7

Solution de l’intégration de Services Web XML

En 2001, Lafarge, le leader français des matériaux de construction, lance trois portails

Web à l'attention de quelques-unes unes de ses cibles de prédilection (Annexe 1, Annexe

2 présente de même portail d’E-Learning des entreprises Algora, BestFormation,

Onlineformapro ) :


Filatova Irina

• premier est destiné aux entrepreneurs en construction;

• deuxième aux négociants en matériaux;

• troisième aux prescripteurs et architectes en bâtiments.

Chacun intégrant classiquement des services et informations métier spécifiques.

Dès l'origine, le groupe fait appel à l'offre de contenu éditorial de l'agence Web CVOO

des "packs" touchant aux ressources humaines, à l'informatique, au marketing et à la

gestion principalement. Des articles et autres dossiers qu'il choisit de recevoir

initialement sous forme de pages HTML personnalisées. Lors d'une demande utilisateur,

la plate-forme de Lafarge (Broadvision) commence par envoyer une requête XML vers le

centre de données de CVOO. Interprétée par le biais d'une interface standardisée

(WSDL), celle-ci invoque alors les composants EJB du serveur d'applications sous-jacent

(BEA WebLogic Server.)

En retour, les contenus correspondants sont transmis à Lafarge sous forme de flux XML

avant d'être analysés sur place puis traduite en HTML aux couleurs du site - via une

feuille de style (XSL.) Ainsi convertis, ces éléments sont intégrés pour finir aux pages

Web de manière dynamique (JSP33.)

8. Chapitre 8

Conclusion

En conclusion, les concepts et les modèles élaborés dans cette synthèse des articles

guident donc tout naturellement aujourd’hui les travaux du W3C autour d ’XML et se

reflètent pratiquement à l’identique dans le développement d’applications à base de

Services Web.

Pendant dix ans, on a cherché à intégrer entre elles les applications internes au système

d’information de l’entreprise ; pendant les dix prochaines années, on cherchera de la 33 Java Server Pages


Filatova Irina même façon à intégrer les entreprises via le réseau d’information du Web. Une différence

importante est toutefois notable. Alors que dans le modèle d’applications réparties

fondées sur DCOM, EJB ou CORBA, il fallait que leurs champions imposent à la fois

l’infrastructure et les modèles composants/assemblages nécessaires à ces applications,

dans l ’évolution qui s’annonce vers les services Web, l’infrastructure est déjà en place –

continuant d’ailleurs à croître et s’enrichir – et, devant la globalité des enjeux, tous les

acteurs industriels partagent une base commune (XML confiée au «sanctuaire » W3C)

que chacun individuellement et tous collectivement ont intérêt à adopter.

Ainsi, contrastant vivement avec les querelles d’incompatibilité qui, tout au long de la

longue élaboration des applications réparties à base de composants logiciels, ont risqué

de miner les développements techniques, l’interopérabilité est une caractéristique

importante des applications et des Services Web, s’imposant par l’ubiquité et

l’universalité du Web à une industrie qui trouve enfin son intérêt dans la coopération sur

des protocoles communs, la Figure 8.1 présente le Service Web XML[URL21] :

Figure 8.1. Présentation de Service Web XML

Si l ’on suit cette analyse il faut admettre la nécessité d’un bouleversement technique

profond de l’architecture du système d ’information pour mettre l ’Internet et le Web bien

plus au cœur de l’informatique d ’entreprise. Cette transformation, précisément articulée

autour des services Web, n’est et ne sera évidemment pas instantanée. Rendue possible

par la généralisation de l ’adoption généralisée d’XML comme le langage de niveau haut

des Services Web, cette reconstruction est maintenant la grande affaire de l’informatique

d ’entreprise et interentreprises.


Filatova Irina L’élément clef qui a permis le développement des Services Web est l’apparition de

nouveaux standards technologiques basés sur XML (eXtensible Markup Language) tel

que SOAP (Simple Object Access Protocol), WSDL (Web Services Description

Language) et UDDI (Universal Description, Discovery and Integration.) On n’entre pas

dans le détail de ces standards, en espérant avoir fait comprendre clairement que

l’infrastructure de base des Services Web est assurée par XML, par le langage de

définition de Schémas et par SOAP. UDDI et WSDL, ainsi que plusieurs autres normes,

sont en cours de développement pour permettre l’utilisation des Services Web entre

différentes entreprises plutôt qu’uniquement au sein d’une même entreprise.

Pour qu’une application propre à l’entreprise bénéficie des avantages de l’inter

fonctionnement promis par les Services Web, le recours à XML, aux Schémas et à SOAP

comme principales normes est suffisant. En effet, au sein d’une même entreprise, les

noms de réseaux, les définitions de données et d’adresse sont normalement connues de

tous les développeurs, concepteurs et opérateurs.

Mais lorsque plusieurs entreprises doivent faire dialoguer leurs systèmes, un mécanisme

doit être mis en place pour référencer tous les noms, adresses et définitions liés aux

services mis en oeuvre. C’est là qu’interviennent UDDI et WSDL.

Ces normes permettent en effet de définir et de référencer un Service Web avec son

Schéma et son adresse de réseau associé. Elles sont encore en cours de définition et

pourraient intégrer des spécifications supplémentaires, notamment : XL (XML Langage),

XDD (XML Declarative Description), WSFL (Web Services Flow Language), WS-

Inspection (Web Services Inspection), WS-Referral (Web Services Referral), WS-Routing

(Web Services Routing), WS-Transaction (Web Services Transaction), WS-Security

(Web Services Security), WS-Licensing (Web Services Licensing).

Les Services Web et les standards XML sur lesquels ils sont bâtis sont aujourd’hui le

premier produit de ce vaste mouvement collectif. Ainsi tout le secteur de l’informatique

d’entreprise se trouve-t-il aujourd’hui à la veille d’engendrer un bouleversement profond

de ses modes opératoires et de ses équilibres économiques.


Filatova Irina Selon tous les manageurs, l’utilisation des Services Web devrait aller en s’accroissant. Ils

ne sont cependant pas d’accord sur les chiffres : certains parlent de 40 % des projets de

2003-2004, alors que d’autres annoncent des chiffres plus fous atteignant les 90%.

Les acteurs jugés importants du segment des plates-formes de déploiement de Web

Services XML présentent dans le tableau suivant [URL] :

Microsoft 72%

IBM 49%

Oracle 46%

Sun 40%

Open Source 40%

BEA 25%

Sybase 7%

Borland 4% Enfin,

« XML-based Web Services are an ideal technology for integrating diverse

application and systems as they allow application to communicate across the

Internet in a platform – and language independent fashion.» [Clark, Fletcher,

Hanson, Irani, Watehouse, Theli, 2001.]


Filatova Irina Bibliographie [Girad, Crusson, 2001] Dider Girad, Tanguy Crusson, “XML pour l’entreprisre”,

pp.70, 2001, ce document disponible à l’adresse suivante : http://www.applications-servers.com/livresblancs/xml

[Clark, Fletcher, Hanson, Irani, Wattheure, Thelin, 2001] Mike Clark, J.Jeffrey Hanson, Romin Irani, Mark Waterhouse, Jorgen Thelin, “Web Services Buisness Strategies and Architectures”, 2001, ce document disponible à l’adresse suivante :

http://www.webservicesarchitect.com/book.asp

[Chauvet, 2002] Jean-Marie Chauvet, “Services Web avec SOAP, WSDL, UDDI, ebXML…”, 2002, ce document disponible à l’adresse suivante :

http://www.webservicesarchitect.com/book.asp [Randel, Skonnard, 1999] Randel B., Skonnard A, “A Guide to XML and Its

Technologies”, 1999, ce document disponible à l’adresse suivante : http://www.msdn.microsoft.com/library/default.asp

[URL1] W3C, World Wide Web Consortium, http://www.w3c.org [URL2] XML, http://www.w3.org/tr/xml [URL3] WSDL, http://www.w3.org/tr/wsdl [URL4] SOAP, http://www.w3.org/tr/soap [URL5] Microsoft, http://www.microsoft.com [URL6] Google, http://www.google.com [URL7] Altavista, http://www.altavista.com [URL8] E-Bay, http://www.ebay.com [URL9] Ticket-Corner, http://www.ticket-corner.com [URL10] The Web Services Technology Stack,

http://www.perfectxml.com/Xanalysis/TSG/WebServices.asp [URL11] UDDI, http://uddi.org [URL12, 13, 14] XL, XDD, WSFL http://www.service-architecture.com/web-

services/articles/index.html


http://www.applications-servers.com/livresblancs/xml



http://www.msdn.microsoft.com/library/default.asp

http://www.w3c.org/

http://www.w3.org/tr/xml

http://www.w3.org/tr/wsdl

http://www.w3.org/tr/soap

http://www.microsoft.com/

http://www.google.com/

http://www.altavista.com/

http://www.ebay.com/

http://www.ticket-corner.com/

http://www.perfectxml.com/Xanalysis/TSG/WebServices.asp

http://uddi.org/

http://www.service-architecture.com/web-services/articles/index.html

http://www.service-architecture.com/web-services/articles/index.html

Filatova Irina [URL15] WS-Inspection, http://msdn.microsoft.com/ws/2002/01/Inspection [URL16] WS-Referral, http://msdn.microsoft.com/ws/2002/01/Referral [URL17] WS-Routing, http://msdn.microsoft.com/ws/2002/01/Routing [URL18] WS-Transaction, http://msdn.microsoft.com/ws/2002/01/Transaction [URL19] WS-Transaction, http://msdn.microsoft.com/ws/2002/01/Security [URL20] WS-Transaction, http://msdn.microsoft.com/ws/2002/01/Licensing [URL21] Source Peerstone Research and InformationWeek, ce document disponible à l’adresse suivante : http://solutions.journaldunet.com/dossiers/indicateurs/infrastructure/webservices_monde.shtml


http://msdn.microsoft.com/ws/2002/01/Inspection

http://msdn.microsoft.com/ws/2002/01/Referral

http://msdn.microsoft.com/ws/2002/01/Routing

http://msdn.microsoft.com/ws/2002/01/Transaction

http://msdn.microsoft.com/ws/2002/01/Security

http://msdn.microsoft.com/ws/2002/01/Licensing

http://solutions.journaldunet.com/dossiers/indicateurs/infrastructure/webservices_monde.shtml

http://solutions.journaldunet.com/dossiers/indicateurs/infrastructure/webservices_monde.shtml

Filatova Irina Annexe 1 : Lafarge Trois portails Web des matériaux de construction :

• premier est destiné aux entrepreneurs en construction (Batissor.com);

• deuxième aux négociants en matériaux (Matixel.com);

• troisième aux prescripteurs et architectes en bâtiments (Creargos.com).


http://www.batissor.com/

http://www.matixel.com/

http://www.creargos.com/

Filatova Irina Annexe 2: Algora: Trois portals Web d’E-Learning:

• premier est Algora, http://ressources.algora.org/index.asp

• http://www.bestformation.com/fr/e-learning/e-learning_f.htm

• http://www.onlineformapro.com/index.htm


http://ressources.algora.org/index.asp

http://www.bestformation.com/fr/e-learning/e-learning_f.htm

http://www.onlineformapro.com/index.htm

Documents

Serbvices Web XML - Université de Montréalaimeur/cours/ift6261/Presentations... · 2004. 2. 19. · Filatova Irina 2. Chapitre 2 Concept Services Web XML 2.1. Définition de Services