services web xml - Département d`informatique et de recherche

Transcription

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
Filatova Irina
TABLE DES MATIÈRES
1.
2.
3.
4.
5.
6.
7.
8.
Résumé ………………………………………………………………………. 3
Chapitre 1
Introduction ……… ……………………………………………………. 4
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
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
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
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
Chapitre 6
Outils pour développer de Services Web XML ….………………….. 35
Chapitre 7
Solution de l’intégration de Services Web XML ……..……………... 36
Chapitre 8
Conclusion …………….…………………………………………….….. 37
Bibliographie …….………………………………………………………….. 41
Annexe 1 : Lafarge ………………………………………………………….. 43
Annexe 2 : Algora ……………………………..…………………………….. 44
_____________________________________________________________________________________
Page 2 sur 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
_____________________________________________________________________________________
Page 3 sur 44
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 plateforme 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
2
3
4
5
Hyper Text Transfer Protocol
World Wide Web Consortium
eXtensible Markup Language
HyperText Markup Language
Document Type Definition
_____________________________________________________________________________________
Page 4 sur 44
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 plateforme 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
Simple Object Access Protocol
8
Java 2 Enterprise Edition
9
Universal Description, Discovery and Integration
10
Web Service Description Language
7
_____________________________________________________________________________________
Page 5 sur 44
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
12
13
14
15
Uniform Resource Locator
Common Object Request Broker Architecture
Remote Method Invocation
Distributed Component Object Model
Enterprise JavaBeans
_____________________________________________________________________________________
Page 6 sur 44
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 :
16
•
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.
Standard Generalized Markup Language
_____________________________________________________________________________________
Page 7 sur 44
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
_____________________________________________________________________________________
Page 8 sur 44
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
_____________________________________________________________________________________
Page 9 sur 44
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.
_____________________________________________________________________________________
Page 10 sur 44
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, ..
_____________________________________________________________________________________
Page 11 sur 44
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.
_____________________________________________________________________________________
Page 12 sur 44
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
20
Object Request Broker
Internet InterOrb Protocol
_____________________________________________________________________________________
Page 13 sur 44
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 :
_____________________________________________________________________________________
Page 14 sur 44
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
_____________________________________________________________________________________
Page 15 sur 44
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 :
Dialectes XML
Langage / organisme
XML
eXtensible Markup Language,
W3C
XML Schema,
W3C
Champ d'application
La spécification de base du langage XML qui précise
comment définir la structure des données dans un
document.
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.
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. :
<?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> |
Exemple 4.1.2. Structure de document XML
_____________________________________________________________________________________
Page 16 sur 44
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:
<?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)>
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.
<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>
Exemple 4.1.4. Présentation XML 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.
_____________________________________________________________________________________
Page 17 sur 44
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. :
<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>
Exemple 4.1.5. Présentation XML Namespaces
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
23
24
Uniform Resource Identifier
eXtensible Stylesheet Language
eXtensible Stylesheet Language Transformation
_____________________________________________________________________________________
Page 18 sur 44
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
26
FTP . 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
26
Simple Mail Transfert Protocol
File Transfert Protocol
_____________________________________________________________________________________
Page 19 sur 44
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.
_____________________________________________________________________________________
Page 20 sur 44
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
_____________________________________________________________________________________
Page 21 sur 44
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.
_____________________________________________________________________________________
Page 22 sur 44
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
_____________________________________________________________________________________
Page 23 sur 44
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 "autodescriptifs" :
•
<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 :
_____________________________________________________________________________________
Page 24 sur 44
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
_____________________________________________________________________________________
Page 25 sur 44
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.
_____________________________________________________________________________________
Page 26 sur 44
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
_____________________________________________________________________________________
Page 27 sur 44
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. :
_____________________________________________________________________________________
Page 28 sur 44
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
_____________________________________________________________________________________
Page 29 sur 44
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
_____________________________________________________________________________________
Page 30 sur 44
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
29
30
XML Declarative Description
Electronic Business XML
Web Services Flow Language
_____________________________________________________________________________________
Page 31 sur 44
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].
_____________________________________________________________________________________
Page 32 sur 44
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
WS-Inspection
WS-Refferal
WS-Routing
WS-Transaction
WS-Security
WS-Licensing
Description de spécifications
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-Referral définit de quelle manière les routeurs
SOAP établiront un trajet de messages entre
plusieurs points de services.
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.
XML WS-Transaction est le langage vise à garantir
l'intégrité de transactions exécutées via les Services
Web.
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 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.
_____________________________________________________________________________________
Page 33 sur 44
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
_____________________________________________________________________________________
Page 34 sur 44
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
32
Security Socket Layer
Internet Protocol Security
_____________________________________________________________________________________
Page 35 sur 44
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
SUN
SunONE Studio 4.1 EE
MICROSOFT
Visual Studio
Enterprise developer
IBM
WebSphere Studio AD
Borland
Web Services
Solutions
Commentaires
Gestion de JAX RPC (version Java SOAP), y compris
les attachements. Gestion de WSDL et UDDI. Riches
fonctions de manipulation de flux XML.
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#…)
Gestion de XML, de SOAP et de WSDL. Fourniture
d’un annuaire privé UDDI depuis la version 5 du serveur
d’applications associé.
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 ) :
_____________________________________________________________________________________
Page 36 sur 44
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
_____________________________________________________________________________________
Page 37 sur 44
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.
_____________________________________________________________________________________
Page 38 sur 44
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), WSInspection (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.
_____________________________________________________________________________________
Page 39 sur 44
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
Sybase
Borland
25%
7%
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.]
_____________________________________________________________________________________
Page 40 sur 44
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/webservices/articles/index.html
_____________________________________________________________________________________
Page 41 sur 44
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
_____________________________________________________________________________________
Page 42 sur 44
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).
_____________________________________________________________________________________
Page 43 sur 44
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
_____________________________________________________________________________________
Page 44 sur 44

services web xml - Département d`informatique et de recherche

Transcription

Documents pareils

Web Services en Java

Comparatif des intergiciels présentés

Les Services Web

Objectifs Plan de cours Pré-Requis

Web Services

“1900”de MARIUS FABRE

Services Web - Research web sites

La cuisine est toute ma vie. Ce que j`aime de ce