WebServices / SOAP
Les WebServices
Présentation
Les WebServices est un concept orienté service apparu vers 2000. Il met en place une architecture dans laquelle un client peut demander l'exécution d'une action à un fournisseur, ce dernier pouvant à son tour devenir le client d'un autre fournisseur pour effectuer l'action demandée. Les clients et fournisseurs sont généralement physiquement séparés, le tout formant alors une architecture dite "distribuée" qui se sert d'un ou de plusieurs réseaux informatiques pour pouvoir faire communiquer ses différents composants.
Les clients et fournisseurs sont représentés dans le concept WebService comme des composants applicatifs communicants à l'aide de spécifications Web ouvertes. Cela permet la coexistence de plusieurs implémentations WebService différentes pouvant communiquer de manière transparente entre-elles grâce à l'utilisation de ces spécifications libre d'accès.
De plus, la technologie WebService met en oeuvre des fonctionnalités d'auto-description des fournisseurs et des services qui leurs sont associés. Ainsi, l'utilisation d'un fournisseur WebService peut être gérée de manière dynamique.
En plus de ces fonctionnalités d'auto-description, des mécanismes de découverte sont prévus de manière à pouvoir énumérer, puis déterminer le fournisseur le plus apte à effectuer une action voulue, et cela, de façon totalement autonome de la part des clients.
Enfin, les WebServices reposent forcement sur l'utilisation du langage de description XML.
Avantages
L'utilisation des spécifications Web ouvertes, et notamment celle de la norme HTTP, permet au WebService de pouvoir fonctionner au travers de plusieurs réseaux sans pâtir des dispositifs de sécurité tels les pare-feux ou encore, les serveurs proxy Web. C'est un des problèmes majeurs dans la mise en place d'une application distribuée avec les autres technologies de distribution telles CORBA ou JNI, qui sont obligées de rajouter un module d'adaptation au dessus du protocole HTTP pour pouvoir éviter les restrictions des réseaux à traverser.
Le fait d'utiliser des spécifications ouvertes et identiques entre les composants WebServices permet d'obtenir un couplage lâche où les modifications sur un des composants n'entraînent aucune modifications sur les composants qui l'utilisaient pour pouvoir à nouveau le contacter.
Aussi, le langage XML est un langage textuel facilement compréhensible par un être humain. Cela permet alors de pouvoir détecter plus facilement les erreurs de transmissions et rendre ainsi les deboggages de la chaîne de communication plus simple.
Les capacités d'auto-description et de découverte des WebServices permettent de ne pas être dépendant d'un unique fournisseur pour effectuer une même action (en théorie). Cela réduit alors les dépendances entre clients et fournisseurs, et favorise ainsi la récupération en cas d'erreur, de manière dynamique.
Enfin (et surtout), la technologie WebService est grandement encouragée par les grandes firmes informatiques (telles Microsoft, IBM, BEA, etc.) ce qui permet de la retrouver de plus en plus partout et lui assure une pérennité quasi assurée.
Spécifications
Les WebServices est un concept, ce qui implique qu'aucune implémentation type n'a été donnée à la naissance de l'idée. Ainsi, beaucoup de participants ce sont lancés dans leurs propres implémentations des WebServices, utilisant généralement des techniques propriétaires et incompatibles entre elles au dessus des spécifications ouvertes. Parmi ces participants à avoir proposés des implémentations WebServices, on notera notamment les groupes de normalisation comme le W3C ou OASIS, ainsi que des grands groupes informatiques comme Microsoft, IBM ou BEA.
Ainsi aujourd'hui, il existe plus de 50 spécifications différentes concernant les WebServices, certaines adressant les mêmes problématiques mais de manières incompatibles ce qui empêche alors une des promesses des WebServices, à savoir, l'interoperabilité.
C'est pourquoi il a été nécessaire de créer un organisme unique qui aurait pour tâche de centraliser et de normaliser les spécifications à adopter dans les différentes implémentations WebServices, afin d'en assurer l'interoperabilité: le WS-I.
Web Services Interoperability Organization
C'est un organisme fondé en 2002 par Microsoft, IBM, BEA et Intel dans le but d'aboutir à des spécifications communes à toutes les implémentations WebServices. Il compte aujourd'hui plus de 130 membres et est, de fait, reconnu comme étant l'organisme qui régit et décide des normes WebServices.
Son but premier est d'assurer l'interoperabilité des implémentations WebServices. Pour ce
faire, il définit plusieurs profils que chaque implémentation doit suivre pour pouvoir
être compatible avec une autre implémentation respectant le même profil. Ces profils
correspondent en fait à un ensemble de spécifications à utiliser, et indiquent la
manière d'interpréter ces spécifications quand une ambiguïté dans leur texte existe
pouvant donnée lieu à des implémentations différentes de la même spécification.
Ces spécifications sont toutes ouvertes, et généralement issues de la phase
d'implémentation pré WS-I. Il est à noter que le rôle du WS-I n'est pas de créer des
spécifications WebServices ; il ne fait qu'indiquer celles à utiliser !
Les profils WS-I
Il n'existe actuellement que 4 profils définis par le WS-I:
- Basic profile (v1.1): c'est le profil de base que toute implémentation WebService se doit de respecter si elle veut être compatibles avec les autres. Les trois autres profiles en dépendent.
- Attachments Profile (v1.0): c'est un profil qui indique les spécifications à utiliser pour transmettre de grosse donnée entre des composants WebServices.
- Simple SOAP Binding Profile (v1.0): c'est un profil qui décrit la façon de transporter les messages entre WebServices au dessus du protocole HTTP.
- Basic Security Profile (v1.0 WD): c'est un profile qui définit les mécanismes de sécurité à mettre en oeuvre dans les communications entre les WebServices. Ce profil est encore à l'étant de brouillon actuellement.
Par la suite, nous ne nous intéresserons qu'au profil basique, celui-ci étant essentiel pour comprendre les mécanismes de fonctionnement des WebServices.
Le profil basique
Ce profil se compose de 4 modules obligatoires, et d'un module optionnel:
- Transport: il s'agit de protocole de transport utilisé pour les communications entre les composants WebServices. Dans le profil basique, c'est le protocole HTTP qui est spécifié.
- Représentation: il s'agit du protocole qui permet de décrire les données qui sont envoyées dans les communications entre les composants WebServices. Dans le profil basique, c'est le protocole SOAP v1.1 qui est spécifié.
- Description: il s'agit du protocole de description qui permet à un fournisseur de décrire les actions qu'il permet d'exécuter. Dans le profil basique, c'est le langage de description WSDL v1.0 qui est spécifié.
- Découverte: il s'agit du protocole qui permet la découverte de fournisseurs. Dans le profil basique, c'est le protocole UDDI v2 qui est spécifié.
- Sécurité (optionnel): il s'agit du protocole qui permet d'assurer les sécurité dans les communications et les accès entre composants WebServices. La sécurité n'étant pas l'objectif principal du profil basique, ce dernier spécifie l'utilisation du protocole HTTPS pour assurer les fonctions liées à la sécurité. On notera cependant que la sécurité devrait être assurée à un niveau au dessus normalement (comme c'est le cas dans le profile basique de sécurité).
Le schéma suivant récapitule ces 5 modules, ainsi que le niveau où chaque module fonctionne par rapport aux autres:
On voit ainsi que le protocole SOAP est à la base des spécifications WebServices (après le protocole HTTP, incontournable). C'est ce protocole que nous allons étudier par la suite, avant de nous intéresser aux protocoles des modules Description, puis Découverte.