Les services Web XML constituent les éléments de base de l'informatique distribuée sur Internet. Les normes ouvertes et l'accent mis sur la communication et la collaboration entre les utilisateurs et les applications ont créé un environnement dans lequel les services Web XML deviennent la plate-forme d'intégration des applications. Les applications sont construites à l'aide de services Web XML provenant de plusieurs sources différentes qui fonctionnent ensemble, quel que soit leur emplacement ou la manière dont elles sont implémentées.
Il existe autant de définitions de services Web XML que d’entreprises créant des services Web XML. Mais presque toutes les définitions ont les points communs suivants :
Les services Web XML fournissent des fonctionnalités utiles aux utilisateurs Web via des protocoles Web standard. Dans la plupart des cas, le protocole SOAP est utilisé.
Les services Web XML peuvent spécifier leurs interfaces de manière très détaillée, ce qui permet aux utilisateurs de créer des applications client pour communiquer avec eux. Cette description est généralement contenue dans un document XML appelé document WSDL (Web Services Description Language).
Les services Web XML sont enregistrés afin que les utilisateurs potentiels puissent les trouver facilement, ce qui est réalisé via la découverte, la description et l'intégration universelles (UDDI).
Cet article présentera ces trois technologies, mais nous devons d'abord expliquer pourquoi vous devez prêter attention aux services Web XML.
L'un des principaux avantages de l'architecture des services Web XML est qu'elle permet à une variété de programmes écrits dans différents langages sur différentes plates-formes de communiquer entre eux selon des normes. Les utilisateurs qui connaissent ce secteur peuvent immédiatement dire : « Attendez une minute, CORBA et le précédent DCE n'ont-ils pas pris le même engagement ? Quelle est la différence entre celui-ci et eux. La différence la plus importante est la suivante : SOAP est meilleur qu'avant ? L'approche est beaucoup plus simple, il y a donc beaucoup moins d'obstacles à la mise en œuvre d'un SOAP conforme aux normes. Paul Kulchenko fournit une liste des implémentations de SOAP sur http://www.soapware.org/directory/4/implementations (en anglais). Au dernier décompte, la liste contenait 79 éléments. Comme on peut s'y attendre, la plupart des grands éditeurs de logiciels proposent des implémentations SOAP, mais il existe également de nombreuses implémentations créées et maintenues par des développeurs individuels. Un autre avantage majeur des services Web XML par rapport aux solutions précédentes est l'utilisation de protocoles Web standards - XML, HTTP et TCP/IP. De nombreuses entreprises ont déjà mis en place une infrastructure Web et leurs employés possèdent les connaissances et l'expérience nécessaires pour la maintenir. Par conséquent, le coût de l’introduction des services Web XML est bien inférieur à celui des technologies précédentes.
Nous définissons un Service Web XML comme un service logiciel fourni sur le Web via SOAP, décrit à l'aide d'un fichier WSDL et enregistré via UDDI. Vous vous demandez peut-être : « Que pouvez-vous faire avec les services Web XML ? » Les services Web XML d'origine étaient souvent des sources d'informations qui pouvaient être facilement intégrées dans des applications, telles que les cours des actions, les prévisions météorologiques, les résultats sportifs, etc. Il est facile d'imaginer toute une classe d'applications qui pourraient être créées pour analyser et résumer les informations qui vous intéressent, et rendre ces informations disponibles de diverses manières. Par exemple, vous pourriez utiliser une feuille de calcul Microsoft® Excel pour résumer toutes vos données financières ; informations : actions, 401K, dépôts 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 sont gratuites et d'autres peuvent nécessiter un abonnement pour obtenir le service correspondant. Une grande partie de ces informations est déjà disponible sur le Web, mais les services Web XML peuvent rendre l'accès par programmation plus facile et plus fiable.
Les applications existantes sont mises à disposition sous forme de services Web XML, et de nouvelles applications plus puissantes peuvent être créées en utilisant les services Web XML comme éléments de base. Par exemple, un utilisateur peut développer une application d'achat pour obtenir automatiquement des informations sur les prix de différents fournisseurs, lui permettant ainsi de sélectionner un fournisseur, de soumettre une commande, puis de suivre l'expédition des marchandises jusqu'à leur réception. En plus de fournir des services sur le Web, l'application du fournisseur peut également utiliser XML Web Service pour vérifier le crédit des clients, collecter les paiements et gérer les procédures de transport avec les sociétés de transport.
À l'avenir, certaines des applications basées sur les services Web XML les plus intéressantes seront capables d'exploiter le Web pour accomplir des tâches actuellement impossibles. Par exemple, le service de calendrier est l'un des services qui seront pris en charge par le projet Microsoft .NET My Services (anglais). Si vos dentistes et mécaniciens fournissent leurs horaires via ce service Web XML, vous pouvez planifier des rendez-vous avec eux via le Web si vous préférez, ils peuvent également planifier les nettoyages et les dates d'entretien de routine directement sur votre calendrier. Il est facile d'imaginer que si l'on pouvait programmer le Web, on pourrait créer des centaines d'applications.
Pour plus d'informations sur les services Web XML et les applications que vous pouvez créer, consultez la page d'accueil des services Web MSDN (anglais).
SOAP
SOAP est le protocole de communication du Web Service XML. Lorsqu'ils décrivent SOAP comme protocole de communication, la plupart des gens pensent à DCOM ou CORBA et posent des questions telles que « Comment SOAP active-t-il les objets ? » ou « Quel service de nommage SOAP utilise-t-il ? » Bien que les implémentations SOAP puissent inclure ces éléments, ils ne sont pas spécifiés par la norme SOAP. SOAP Une spécification qui définit le format XML des messages - c'est une partie obligatoire de la spécification. Un segment XML bien formé contenu dans une paire d'éléments SOAP est un message SOAP. N'est-ce pas simple ?
D'autres parties de la spécification SOAP décrivent comment représenter les données du programme au format XML et comment utiliser SOAP pour les appels de procédure distante (RPC). Ces parties facultatives de la spécification sont utilisées pour implémenter des applications de style RPC, où le client émettra un message SOAP (contenant une fonction appelable et les paramètres à transmettre à la fonction), et le serveur renverra un message contenant les résultats. de l’exécution de la fonction. Actuellement, la plupart des implémentations SOAP prennent en charge les applications RPC car les programmeurs habitués à développer des applications COM ou CORBA connaissent le format RPC. SOAP prend également en charge les applications de style document, dans lesquelles un message SOAP n'est qu'un wrapper autour d'un document XML. Les applications SOAP basées sur des documents sont très flexibles et de nombreux nouveaux services Web XML tirent parti de cette fonctionnalité pour créer des services difficiles à implémenter à l'aide de RPC.
La dernière partie facultative de la spécification SOAP définit le style des messages HTTP contenant des messages SOAP. Cette liaison HTTP est importante car presque tous les systèmes d'exploitation actuels (et de nombreux systèmes d'exploitation précédents) prennent en charge HTTP. Bien que facultative, la liaison HTTP est prise en charge par presque toutes les implémentations SOAP car il s'agit du seul protocole standard pour SOAP. Pour cette raison, les gens croient souvent à tort que SOAP doit utiliser HTTP. En fait, certaines implémentations prennent également en charge le transport MSMQ, MQ Series, SMTP ou TCP/IP, mais comme HTTP est omniprésent, presque tous les services Web XML actuels l'utilisent. HTTP étant le protocole central du Web, l'infrastructure réseau de la plupart des organisations prend en charge HTTP et les employés savent déjà comment le gérer. Aujourd'hui, l'infrastructure pour la sécurité, la surveillance et l'équilibrage de charge HTTP a été établie.
Lorsque l'on commence à utiliser SOAP, le plus déroutant est la différence entre la spécification SOAP et ses nombreuses implémentations. La plupart des utilisateurs de SOAP n'écrivent pas directement de messages SOAP mais utilisent des boîtes à outils SOAP pour créer et analyser des messages SOAP. Ces boîtes à outils convertissent généralement les appels de fonction d'un langage en messages SOAP. Par exemple, Microsoft SOAP Toolkit 2.0 convertit les appels de fonction COM en SOAP et Apache Toolkit convertit les appels de fonction JAVA en SOAP. Les types d'appels de fonction et les types de données de paramètres pris en charge varient selon chaque implémentation SOAP, de sorte qu'une fonction qui fonctionne pour une boîte à outils peut ne pas fonctionner pour une autre. Il ne s'agit pas d'une limitation de SOAP, mais de l'implémentation spécifique utilisée.
La caractéristique de loin la plus intéressante de SOAP est qu’il peut être implémenté sur de nombreuses plates-formes logicielles et matérielles différentes. Cela signifie que SOAP peut être utilisé pour relier des systèmes disparates à l'intérieur et à l'extérieur de l'entreprise. Diverses approches ont été essayées dans le passé pour parvenir à un protocole de communication commun pouvant être utilisé pour l'intégration de systèmes, mais aucune d'entre elles n'a obtenu l'acceptation généralisée de SOAP. Pourquoi? Parce que SOAP est plus petit et plus facile à mettre en œuvre que de nombreux protocoles antérieurs. Par exemple, la mise en œuvre de DCE et CORBA a pris des années, de sorte que seules quelques implémentations ont été publiées. SOAP peut exploiter les analyseurs XML et les bibliothèques HTTP existants pour effectuer la majeure partie du travail, de sorte qu'une implémentation SOAP peut être achevée en quelques mois. C'est pourquoi il existe aujourd'hui plus de 70 implémentations SOAP. Bien entendu, SOAP ne possède pas toutes les fonctions de DCE ou CORBA. Bien que les fonctions soient réduites, SOAP est plus facile à appliquer car sa complexité est fortement réduite.
La popularité de HTTP et la simplicité de SOAP vous permettent de les appeler depuis presque n'importe quel environnement, ce qui en fait une base idéale pour les services Web XML. Pour plus d'informations sur SOAP, consultez la page d'accueil MSDN SOAP (anglais).
Est-ce sûr ?
Souvent, la première question posée par les nouveaux utilisateurs de SOAP est de savoir comment SOAP résout les problèmes de sécurité. Dans ses premiers stades de développement, SOAP était considéré comme un protocole basé sur HTTP, la sécurité de HTTP était donc considérée comme suffisante pour SOAP. Après tout, il existe actuellement des milliers d'applications Web qui utilisent la sécurité HTTP, ce qui est donc largement suffisant pour SOAP. Par conséquent, la norme SOAP actuelle suppose que la sécurité est un problème de transport et n'est pas traitée comme un problème de sécurité.
À mesure que SOAP se développe en un protocole plus général et s'exécute sur de nombreux transports, les problèmes de sécurité deviennent plus importants. Par exemple, HTTP propose plusieurs méthodes pour authentifier les utilisateurs effectuant des appels SOAP, mais comment cette identité se propage-t-elle lorsque les messages sont acheminés du protocole HTTP vers le transport SMTP ? SOAP a été conçu comme un protocole élémentaire. Heureusement, des spécifications sont en place pour fournir des fonctionnalités de sécurité supplémentaires pour les services Web basés sur SOAP. La spécification WS-Security (anglais) définit un système de cryptage complet et la spécification WS-License (anglais) définit la technologie correspondante pour garantir l'identité de l'appelant et garantir que seuls les utilisateurs autorisés peuvent utiliser les services Web.
WSDL
WSDL (Web Services Description Language) signifie Web Services Description Language. Pour les besoins de cet article, nous pouvons considérer un fichier WSDL comme un document XML qui décrit un ensemble de messages SOAP et comment les échanger. En d’autres termes, WSDL est à SOAP ce qu’IDL est à CORBA ou COM. Le WSDL étant un document XML, il est facile à lire et à modifier, mais dans la plupart des cas, il est généré et utilisé par un logiciel.
Pour visualiser les valeurs du WSDL, imaginez que vous souhaitiez appeler une méthode SOAP fournie par l'un de vos partenaires commerciaux. Vous pouvez demander des exemples de messages SOAP, puis écrire votre application pour générer et utiliser des messages similaires aux exemples, mais il est facile de commettre des erreurs. Par exemple, vous pouvez voir un identifiant client de 2837 et supposer qu'il s'agit d'un nombre entier, alors qu'en réalité il s'agit d'une chaîne. WSDL spécifie via une notation explicite ce que le message de requête doit contenir et à quoi doit ressembler le message de réponse.
La notation utilisée par les fichiers WSDL pour décrire les formats de message est basée sur la norme XML Schema, ce qui signifie qu'elle est indépendante du langage de programmation et basée sur des normes, ce qui la rend adaptée à la description de services Web XML accessibles depuis différentes plates-formes et dans différentes programmations. langues. En plus de décrire le contenu du message, WSDL définit également l'emplacement du service et le protocole de communication utilisé pour communiquer avec le service. Autrement dit, le fichier WSDL définit tout ce qui est nécessaire pour écrire un programme utilisant les services Web XML. Il existe plusieurs outils capables de lire les fichiers WSDL et de générer le code requis pour communiquer avec les services Web XML. Certains des outils les plus puissants se trouvent dans Microsoft Visual Studio® .NET.
Actuellement, de nombreuses boîtes à outils SOAP incluent des outils permettant de générer des fichiers WSDL à partir d'interfaces de programme existantes, mais il existe peu d'outils permettant d'écrire directement du WSDL et la prise en charge des outils pour WSDL est incomplète. Mais bientôt, il y aura des outils pour écrire des fichiers WSDL, suivis par des outils pour générer des proxys et des stubs (un peu comme les outils COM IDL), et ces outils feront partie de la plupart des implémentations SOAP. D'ici là, WSDL deviendra la méthode privilégiée pour créer des interfaces SOAP vers les services Web XML.
Il existe une très bonne description de WSDL ici (en anglais), et vous pouvez également trouver la spécification WSDL sur http://www.w3.org/TR/wsdl (en anglais).
UDDI
Universal Discovery, Description et Integration (UDDI) sont les Pages Jaunes des services Web. Comme les Pages Jaunes traditionnelles, vous pouvez rechercher des entreprises qui offrent les services dont vous avez besoin, lire pour en savoir plus sur les services offerts, puis contacter quelqu'un pour plus d'informations. Bien sûr, vous pouvez fournir des services Web sans les enregistrer dans UDDI, ce qui revient à gérer une entreprise dans votre sous-sol et à compter sur le bouche à oreille. Mais si vous souhaitez élargir votre marché, vous avez besoin d'UDDI pour pouvoir être découvert par vos clients ; clients.
Les entrées du répertoire UDDI sont des fichiers XML qui décrivent les services et services fournis. Une entrée de répertoire UDDI se compose de trois parties. Les « Pages blanches » présentent les entreprises fournissant des services : nom, adresse, coordonnées, etc. ; les « Pages jaunes » incluent les catégories industrielles basées sur des classifications standard (telles que le Système de classification des industries de l'Amérique du Nord et la Classification industrielle standard) ; informations Accédez à l'interface du service afin que les utilisateurs puissent écrire des applications pour utiliser le service Web. La définition d'un service s'effectue via un document UDDI appelé modèle de type (ou tModel). Dans la plupart des cas, le tModel contient un fichier WSDL qui décrit l'interface SOAP permettant d'accéder au service Web XML, mais le tModel est très flexible et peut décrire presque n'importe quel type de service.
Le répertoire UDDI contient également plusieurs méthodes de recherche des services requis pour créer votre application. Par exemple, vous pouvez rechercher des prestataires de services dans une zone géographique spécifique ou rechercher un type d'entreprise spécifique. L'annuaire UDDI vous fournira ensuite des informations, coordonnées, liens et données techniques afin que vous puissiez identifier les services répondant à vos besoins.
UDDI vous permet de trouver des entreprises qui fournissent les services Web dont vous avez besoin. Que faire si vous savez déjà avec qui vous souhaitez faire affaire, mais ne savez pas encore ce que cela peut offrir d’autre ? La spécification WS-Inspection (en anglais) vous permet de parcourir la collection de services Web XML disponibles sur un serveur spécifique pour trouver le service dont vous avez besoin.
Pour plus d'informations sur UDDI, visitez http://www.uddi.org/about.html (en anglais).
Autre contenu
Jusqu'à présent, nous avons expliqué comment communiquer avec les services Web XML (SOAP), comment les services Web XML sont décrits (WSDL) et comment trouver les services Web XML (UDDI). Celles-ci constituent un ensemble de spécifications de base qui constituent la base de l'intégration et de l'agrégation des applications. Sur la base de ces spécifications de base, les entreprises peuvent construire des solutions pratiques et en bénéficier.
Nous avons fait beaucoup de travail pour implémenter les services Web XML, mais il reste encore beaucoup de travail à faire. Aujourd'hui, les gens ont réussi à utiliser les services Web XML, mais pour les développeurs, il reste encore de nombreux liens à améliorer. Par exemple, la sécurité, la gestion des opérations, le traitement des transactions et la messagerie fiable. L'architecture globale des services Web XML aidera les services Web XML à entrer dans la prochaine étape de l'évolution en fournissant un modèle commun et cohérent pour ajouter de nouvelles fonctionnalités avancées aux services Web XML de manière modulaire et extensible.
Les modules de sécurité mentionnés ci-dessus (WS-Security [anglais] et WS-License [anglais]) font partie de la spécification Global Web Services Architecture. Les besoins de gestion opérationnelle (tels que le routage des messages entre plusieurs serveurs et la configuration dynamique de ces serveurs pour le traitement) font également partie de l'architecture globale des services Web via la spécification WS-Routing (en anglais) et la spécification WS-Referral (en anglais) à réaliser. À mesure que l'architecture mondiale des services Web évolue, des spécifications répondant à ces besoins et à d'autres seront introduites.