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
44
Embed
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
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
_____________________________________________________________________________________ Version du jeudi 19 février 2004 Page 2 sur 44
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
_____________________________________________________________________________________ Version du jeudi 19 février 2004 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 :
• 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
_____________________________________________________________________________________ Version du jeudi 19 février 2004 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
_____________________________________________________________________________________ Version du jeudi 19 février 2004 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
_____________________________________________________________________________________ Version du jeudi 19 février 2004 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.
_____________________________________________________________________________________ Version du jeudi 19 février 2004 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, ..
_____________________________________________________________________________________ Version du jeudi 19 février 2004 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.
_____________________________________________________________________________________ Version du jeudi 19 février 2004 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 Object Request Broker 20 Internet InterOrb Protocol
_____________________________________________________________________________________ Version du jeudi 19 février 2004 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 :
_____________________________________________________________________________________ Version du jeudi 19 février 2004 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
_____________________________________________________________________________________ Version du jeudi 19 février 2004 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 :
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.
Exemple 4.3.1.2. Description de Service Web XML par WSDL
_____________________________________________________________________________________ Version du jeudi 19 février 2004 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. :
_____________________________________________________________________________________ Version du jeudi 19 février 2004 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
_____________________________________________________________________________________ Version du jeudi 19 février 2004 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
_____________________________________________________________________________________ Version du jeudi 19 février 2004 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 XML Declarative Description 29 Electronic Business XML 30 Web Services Flow Language
_____________________________________________________________________________________ Version du jeudi 19 février 2004 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].
_____________________________________________________________________________________ Version du jeudi 19 février 2004 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 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.
_____________________________________________________________________________________ Version du jeudi 19 février 2004 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
_____________________________________________________________________________________ Version du jeudi 19 février 2004 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 Security Socket Layer 32 Internet Protocol Security
_____________________________________________________________________________________ Version du jeudi 19 février 2004 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 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 ) :
_____________________________________________________________________________________ Version du jeudi 19 février 2004 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
_____________________________________________________________________________________ Version du jeudi 19 février 2004 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.
_____________________________________________________________________________________ Version du jeudi 19 février 2004 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),