Notions de base des services web XML
Roger Wolter
Microsoft Corporation
Décembre 2001
Résumé: Vue d’ensemble de la valeur des services Web XML pour les développeurs, avec des introductions à SOAP, WSDL et UDDI. (6 pages imprimées)
Contenu
Qu’est-ce qu’un service web XML ?
SOAP
WSDL
UDDI
Qu’est-ce qu’il reste ?
Qu’est-ce qu’un service web XML ?
Les services web XML sont les éléments fondamentaux du passage à l’informatique distribuée sur Internet. Les normes ouvertes et l’accent mis sur la communication et la collaboration entre les personnes et les applications ont créé un environnement où les services Web XML deviennent la plateforme d’intégration des applications. Les applications sont construites à l’aide de plusieurs services Web XML provenant de différentes sources qui fonctionnent ensemble, quel que soit l’emplacement où elles résident ou la façon dont elles ont été implémentées.
Il existe probablement autant de définitions du service web XML que d’entreprises qui les créent, mais presque toutes les définitions ont ces éléments en commun :
- Les services web XML exposent des fonctionnalités utiles aux utilisateurs Web via un protocole Web standard. Dans la plupart des cas, le protocole utilisé est SOAP.
- Les services web XML permettent de décrire leurs interfaces suffisamment en détail pour permettre à un utilisateur de créer une application cliente pour lui parler. Cette description est généralement fournie dans un document XML appelé document WSDL (Web Services Description Language).
- Les services web XML sont inscrits afin que les utilisateurs potentiels puissent les trouver facilement. Cela s’effectue avec la description et l’intégration de la découverte universelle (UDDI).
Je vais aborder ces trois technologies dans cet article, mais je veux d’abord expliquer pourquoi vous devez vous soucier des services Web XML.
L’un des principaux avantages de l’architecture des services Web XML est qu’elle permet aux programmes écrits dans différents langages sur différentes plateformes de communiquer entre eux d’une manière basée sur des normes. Ceux d’entre vous qui ont fait le tour de l’industrie depuis un certain temps disent maintenant : « Attends une minute ! N’ai-je pas entendu ces mêmes promesses de CORBA et avant ce DCE ? En quoi est-ce différent? » La première différence est que SOAP est beaucoup moins complexe que les approches précédentes, de sorte que la barrière à l’entrée pour une implémentation SOAP conforme aux normes est considérablement plus faible. Paul Kulchenko maintient une liste d’implémentations SOAP à : http://www.soapware.org/directory/4/implementations qui au dernier nombre contenait 79 entrées. Vous trouverez des implémentations SOAP de la plupart des grandes sociétés de logiciels, comme vous pouvez vous y attendre, mais vous trouverez également de nombreuses implémentations qui sont créées et gérées par un seul développeur. L’autre avantage significatif des services Web XML par rapport aux efforts précédents est qu’ils fonctionnent avec des protocoles Web standard ( XML, HTTP et TCP/IP). Un nombre important d’entreprises disposent déjà d’une infrastructure web et de personnes ayant des connaissances et de l’expérience dans la maintenance de celle-ci, donc là encore, le coût d’entrée pour les services Web XML est considérablement inférieur à celui des technologies précédentes.
Nous avons défini un service Web XML en tant que service logiciel exposé sur le Web via SOAP, décrit avec un fichier WSDL et inscrit dans UDDI. La question logique suivante est. « Que puis-je faire avec les services Web XML ? » Les premiers services Web XML ont tendance à être des sources d’information que vous pouvez facilement intégrer dans des applications ( cours boursiers, prévisions météorologiques, scores sportifs, etc.). Il est facile d’imaginer une classe entière d’applications qui pourraient être créées pour analyser et agréger les informations qui vous intéressent et vous les présenter de différentes manières ; par exemple, vous pouvez avoir une feuille de calcul Microsoft® Excel qui résume l’ensemble de votre image financière (actions, 401 000, comptes bancaires, prêts, etc.). Si ces informations sont disponibles via les services Web XML, Excel peut les mettre à jour en permanence. Certaines de ces informations seront gratuites et d’autres peuvent nécessiter un abonnement au service. La plupart de ces informations sont désormais disponibles sur le Web, mais les services Web XML facilitent et fiabilité l’accès par programmation.
L’exposition d’applications existantes en tant que services Web XML permettra aux utilisateurs de créer de nouvelles applications plus puissantes qui utilisent des services Web XML comme blocs de construction. Par exemple, un utilisateur peut développer une application d’achat pour obtenir automatiquement des informations sur les prix auprès de divers fournisseurs, permettre à l’utilisateur de sélectionner un fournisseur, de soumettre la commande, puis de suivre l’expédition jusqu’à ce qu’elle soit reçue. L’application fournisseur, en plus d’exposer ses services sur le Web, peut à son tour utiliser des services Web XML pour case activée le crédit du client, facturer le compte du client et configurer l’expédition avec une société d’expédition.
À l’avenir, certains des services Web XML les plus intéressants prendront en charge les applications qui utilisent le Web pour faire des choses qui ne peuvent pas être effectuées aujourd’hui. Par exemple, un des services que les services web XML rendent possibles est un service de calendrier. Si votre dentiste et votre mécanicien exposent leurs calendriers via ce service Web XML, vous pouvez planifier des rendez-vous avec eux en ligne ou ils peuvent planifier des rendez-vous pour le nettoyage et l’entretien de routine directement dans votre calendrier si vous le souhaitez. Avec un peu d’imagination, vous pouvez envisager des centaines d’applications qui peuvent être créées une fois que vous avez la possibilité de programmer le Web.
Pour plus d’informations sur les services Web XML et les applications qu’ils vous aideront à créer, consultez le Centre de développement des services web MSDN XML.
SOAP
Soap est le protocole de communication pour les services Web XML. Lorsque SOAP est décrit comme un protocole de communication, la plupart des gens pensent à DCOM ou CORBA et commencent à demander des choses telles que « Comment SOAP effectue l’activation d’objet ? » ou « Quel service de nommage SOAP utilise-t-il ? » Bien qu’une implémentation SOAP inclue probablement ces éléments, la norme SOAP ne les spécifie pas. SOAP est une spécification qui définit le format XML des messages, et il s’agit de celle-ci pour les parties requises de la spécification. Si vous avez un fragment XML bien formé placé dans quelques éléments SOAP, vous disposez d’un message SOAP. Simple n’est-ce pas ?
Il existe d’autres parties de la spécification SOAP qui décrivent comment représenter les données du programme au format XML et comment utiliser SOAP pour effectuer des appels de procédure distante. Ces parties facultatives de la spécification sont utilisées pour implémenter des applications de style RPC où un message SOAP contenant une fonction appelante et les paramètres à passer à la fonction est envoyé à partir du client et où le serveur retourne un message avec les résultats de la fonction exécutée. La plupart des implémentations actuelles de SOAP prennent en charge les applications RPC, car les programmeurs habitués à exécuter des applications COM ou CORBA comprennent le style RPC. SOAP prend également en charge les applications de style document où le message SOAP n’est qu’un wrapper autour d’un document XML. Les applications SOAP de style document sont très flexibles et de nombreux nouveaux services Web XML tirent parti de cette flexibilité pour créer des services qui seraient difficiles à implémenter à l’aide de RPC.
La dernière partie facultative de la spécification SOAP définit à quoi ressemble un message HTTP qui contient un message SOAP. Cette liaison HTTP est importante, car HTTP est pris en charge par presque tous les systèmes d’exploitation actuels (et de nombreux systèmes d’exploitation non actuels). La liaison HTTP est facultative, mais presque toutes les implémentations SOAP la prennent en charge, car il s’agit du seul protocole standardisé pour SOAP. Pour cette raison, il existe une idée fausse courante selon laquelle SOAP nécessite HTTP. Certaines implémentations prennent en charge les transports MSMQ, série MQ, SMTP ou TCP/IP, mais presque tous les services Web XML actuels utilisent HTTP, car il est omniprésent. Étant donné que HTTP est un protocole principal du web, la plupart des organisations disposent d’une infrastructure réseau qui prend en charge HTTP et les personnes qui comprennent déjà comment le gérer. L’infrastructure de sécurité, de surveillance et d’équilibrage de charge pour HTTP est disponible dès aujourd’hui.
Une source majeure de confusion lors de la prise en main de SOAP est la différence entre la spécification SOAP et les nombreuses implémentations de la spécification SOAP. La plupart des personnes qui utilisent SOAP n’écrivent pas de messages SOAP directement, mais utilisent un kit de ressources SOAP pour créer et analyser les messages SOAP. Ces boîtes à outils traduisent généralement les appels de fonction d’un type de langage vers un message SOAP. Par exemple, microsoft SOAP Toolkit 2.0 traduit les appels de fonction COM en SOAP et Apache Toolkit traduit les appels de fonction JAVA en SOAP. Les types d’appels de fonction et les types de données des paramètres pris en charge varient avec chaque implémentation SOAP, de sorte qu’une fonction qui fonctionne avec une boîte à outils peut ne pas fonctionner avec une autre. Il ne s’agit pas d’une limitation de SOAP, mais plutôt de l’implémentation particulière que vous utilisez.
De loin, la fonctionnalité la plus intéressante de SOAP est qu’elle a été implémentée sur de nombreuses plateformes matérielles et logicielles différentes. Cela signifie que SOAP peut être utilisé pour lier des systèmes disparates au sein et sans votre organization. De nombreuses tentatives ont été effectuées dans le passé pour trouver un protocole de communication commun qui pourrait être utilisé pour l’intégration des systèmes, mais aucun d’entre eux n’a eu l’adoption généralisée de SOAP. Pourquoi ? Parce que SOAP est beaucoup plus petit et plus simple à implémenter que la plupart des protocoles précédents. L’implémentation de DCE et CORBA, par exemple, a pris des années, de sorte que seules quelques implémentations ont été publiées. SOAP, cependant, peut utiliser des analyseurs XML et des bibliothèques HTTP existants pour effectuer la plupart du travail difficile, de sorte qu’une implémentation SOAP peut être terminée en quelques mois. C’est pourquoi plus de 70 implémentations SOAP sont disponibles. SOAP ne fait évidemment pas tout ce que DCE ou CORBA font, mais le manque de complexité en échange de fonctionnalités est ce qui rend SOAP si facilement disponible.
L’omniprésence de HTTP et la simplicité de SOAP en font une base idéale pour l’implémentation de services Web XML qui peuvent être appelés à partir de presque n’importe quel environnement. Pour plus d’informations sur SOAP, consultez la page d’accueil MSDN SOAP .
Qu’en est-il de la sécurité ?
L’une des premières questions que les nouveaux arrivants posent à SOAP est de savoir comment SOAP traite-t-il la sécurité. Au début de son développement, SOAP était considéré comme un protocole HTTP, de sorte que l’hypothèse a été faite que la sécurité HTTP serait suffisante pour SOAP. Après tout, il existe des milliers d’applications web en cours d’exécution aujourd’hui utilisant la sécurité HTTP, donc cela est certainement suffisant pour SOAP. Pour cette raison, la norme SOAP actuelle suppose que la sécurité est un problème de transport et qu’elle est silencieuse sur les problèmes de sécurité.
Lorsque SOAP s’est développé pour devenir un protocole à usage plus général s’exécutant sur un certain nombre de transports, la sécurité est devenue un problème plus important. Par exemple, HTTP fournit plusieurs façons d’authentifier l’utilisateur qui effectue un appel SOAP, mais comment cette identité se propage-t-elle lorsque le message est acheminé de HTTP vers un transport SMTP ? SOAP a été conçu comme un protocole de bloc de construction. Heureusement, il existe déjà des spécifications en cours d’élaboration pour s’appuyer sur SOAP pour fournir des fonctionnalités de sécurité supplémentaires pour les services Web. La spécification WS-Security définit un système de chiffrement complet.
WSDL
WSDL (souvent prononcé whiz-dull) signifie Web Services Description Language. À nos fins, nous pouvons dire qu’un fichier WSDL est un document XML qui décrit un ensemble de messages SOAP et la façon dont les messages sont échangés. En d’autres termes, WSDL est à SOAP ce qu’IDL est à CORBA ou COM. Étant donné que WSDL est XML, il est lisible et modifiable, mais dans la plupart des cas, il est généré et consommé par un logiciel.
Pour voir la valeur de WSDL, imaginez que vous souhaitez commencer à appeler une méthode SOAP fournie par l’un de vos partenaires commerciaux. Vous pouvez lui demander des exemples de messages SOAP et écrire votre application pour produire et consommer des messages qui ressemblent aux exemples, mais cela peut être source d’erreurs. Par exemple, vous pouvez voir un ID client de 2837 et supposer qu’il s’agit d’un entier alors qu’en fait il s’agit d’une chaîne. WSDL spécifie ce qu’un message de requête doit contenir et à quoi ressemblera le message de réponse en notation non ambiguë.
La notation utilisée par un fichier WSDL pour décrire les formats de message est basée sur la norme de schéma XML, ce qui signifie qu’il est à la fois neutre en langage de programmation et basé sur des normes, ce qui le rend approprié pour décrire les interfaces de services Web XML qui sont accessibles à partir d’un large éventail de plateformes et de langages de programmation. En plus de décrire le contenu des messages, WSDL définit l’emplacement où le service est disponible et le protocole de communication utilisé pour communiquer avec le service. Cela signifie que le fichier WSDL définit tout ce qui est nécessaire pour écrire un programme pour fonctionner avec un service Web XML. Plusieurs outils sont disponibles pour lire un fichier WSDL et générer le code requis pour communiquer avec un service Web XML. Certains de ces outils les plus compatibles se trouvent dans Microsoft Visual Studio® .NET.
De nombreuses boîtes à outils SOAP actuelles incluent des outils pour générer des fichiers WSDL à partir d’interfaces de programme existantes, mais il existe peu d’outils pour écrire WSDL directement, et la prise en charge des outils pour WSDL n’est pas aussi complète qu’elle le devrait. Les outils permettant de créer des fichiers WSDL, puis de générer des proxies et des stubs comme les outils IDL COM, ne devraient pas tarder à faire partie de la plupart des implémentations SOAP. À ce stade, WSDL deviendra la méthode préférée pour créer des interfaces SOAP pour les services Web XML.
Une excellente description de WSDL est disponible, et vous trouverez la spécification WSDL à l’adresse http://www.w3.org/TR/wsdl.
UDDI
La description et l’intégration de la découverte universelle sont les pages jaunes des services Web. Comme pour les pages jaunes traditionnelles, vous pouvez rechercher une entreprise qui offre les services dont vous avez besoin, en savoir plus sur le service offert et contacter quelqu’un pour plus d’informations. Vous pouvez, bien sûr, offrir un service Web sans l’inscrire dans UDDI, tout comme vous pouvez ouvrir une entreprise dans votre sous-sol et compter sur la publicité de bouche à oreille, mais si vous voulez atteindre un marché important, vous avez besoin d’UDDI pour que vos clients puissent vous trouver.
Une entrée de répertoire UDDI est un fichier XML qui décrit une entreprise et les services qu’elle offre. Une entrée se trouve dans le répertoire UDDI en trois parties. Les « pages blanches » décrivent l’entreprise qui offre le service : nom, adresse, contacts, etc. Les « pages jaunes » incluent des catégories industrielles basées sur des taxonomies standard telles que le Système de classification des industries de l’Amérique du Nord et la Classification industrielle standard. Les « pages vertes » décrivent l’interface du service avec suffisamment de détails pour permettre à quelqu’un d’écrire une application afin d’utiliser le service Web. La façon dont les services sont définis se fait par le biais d’un document UDDI appelé modèle de type ou tModel. Dans de nombreux cas, le tModel contient un fichier WSDL qui décrit une interface SOAP à un service Web XML, mais le tModel est suffisamment flexible pour décrire presque n’importe quel type de service.
Le répertoire UDDI comprend également plusieurs façons de rechercher les services dont vous avez besoin pour créer vos applications. Par exemple, vous pouvez rechercher des fournisseurs d’un service dans un emplacement géographique spécifié ou pour une entreprise d’un type spécifié. L’annuaire UDDI fournit ensuite des informations, des contacts, des liens et des données techniques pour vous permettre d’évaluer les services qui répondent à vos besoins.
UDDI vous permet de trouver des entreprises auprès de lesquelles vous souhaiterez peut-être obtenir des services Web. Que se passe-t-il si vous savez déjà avec qui vous voulez faire affaire, mais que vous ne savez pas quels services sont offerts ? La spécification WS-Inspection vous permet de parcourir une collection de services Web XML proposés sur un serveur spécifique pour trouver ceux qui peuvent répondre à vos besoins.
Pour plus d’informations sur UDDI, consultez http://www.uddi.org/about.html.
Qu’est-ce qu’il reste ?
Jusqu’à présent, nous avons parlé de la façon de communiquer avec les services Web XML (SOAP), de la façon dont les services Web XML sont décrits (WSDL) et de la recherche de services Web XML (UDDI). Il s’agit d’un ensemble de spécifications de base qui fournissent la base de l’intégration et de l’agrégation d’applications. À partir de ces spécifications de base, les entreprises créent de véritables solutions et obtiennent de leur part une valeur réelle.
Bien que beaucoup de travail ait été fait pour faire des services Web XML une réalité, il en faut davantage. Aujourd’hui, les gens ont du succès avec les services Web XML, mais il reste des choses qui restent comme un exercice pour le développeur®, par exemple la sécurité, la gestion opérationnelle, les transactions, la messagerie fiable. L’architecture des services web XML globaux aidera à faire passer les services Web XML au niveau supérieur en fournissant un modèle cohérent à usage général permettant d’ajouter de nouvelles fonctionnalités avancées aux services Web XML, modulaires et extensibles.
WS-Security est l’une des spécifications de l’architecture des services web globaux. Les besoins de gestion opérationnelle, tels que le routage des messages entre de nombreux serveurs et la configuration dynamique de ces serveurs pour le traitement, font également partie de l’architecture des services web globaux et sont satisfaits par la spécification WS-Routing et la spécification WS-Referral. À mesure que l’architecture des services web globaux augmente, des spécifications pour ces besoins et d’autres seront introduites.
Vous trouverez plus d’informations sur l’architecture des services web XML globaux.