Introduction aux Web Services
Un article de ODcWiki.
 Auteur : pguedez.
|
On parle beaucoup des Web Services et de toute la galaxie de standards et de technologies qui gravitent autour. On oublie souvent au passage quelques questions essentielles : Pourquoi adopter les Web Services dans une application ? Quelle est la stratégie à suivre ? Quels sont les écueils à éviter avec SOAP ? Comment échanger de gros documents ou des données binaires ?
Pourquoi adopter les Web Services ?
Au-delà de l’effet de mode, les Web Services apportent une réelle solution technique à un problème récurrent de l’informatique : faciliter l’interconnexion des applications.
Au fil du temps, 4 cas d’utilisation distincts et plus ou moins ambitieux sont apparus :
- Interconnecter des plates-formes hétérogènes ;
- Intégrer des applications existantes ;
- Client / serveur sur Internet ;
- Fournir des services à forte valeur ajoutée métier.
Interconnecter des plates-formes incompatibles
Initialement, les Web Services ont été utilisés pour interconnecter simplement des plates-formes qui auparavant communiquaient mal. La simplicité est apportée dans ce cas, plus par les outils, que par la technologie en elle-même. L’exemple typique est l’interopérabilité Java / .Net.
L’interopérabilité s’appuie ici sur l’utilisation des standards techniques définis par le W3C :
- SOAP (Simple Object Access Protocol ou Service Oriented Architecture Protocol) : le protocole généralement utilisé ;
- WSDL (Web Services Description Language) : langage XML utilisé pour décrire :
- le contrat de services : l’ensemble des opérations disponibles, ainsi que la structure des messages XML échangés (exprimée en XML Schema) ;
- comment, concrètement, transporter les messages XML sur 1 ou plusieurs protocoles (habituellement SOAP) ;
- la localisation des services.
- XML et HTTP qu’on ne présente plus.
Mais très rapidement, de nouveaux cas d’utilisation plus ambitieux sont apparus.
Intégrer des applications existantes
Les Web Services ont très vite servi à intégrer les applications existantes de l’entreprise (legacy applications). Et ainsi faciliter leur réutilisation au sein du système d’information de l’entreprise et leur intégration dans des applications nouvelles (Java / .Net). L’exemple typique est la transformation d’une application existante en entrepôt de données.
L’engouement pour les Web Services, dans ce cas, est sûrement à rechercher dans :
- l’utilisation des standards du Web : HTTP et XML ;
- la démocratisation et l’abondance des serveurs Web.
Client / serveur sur Internet
Autre cas d’utilisation classique : développer une application client / serveur sur Internet. L’intérêt des Web Services réside ici dans :
- la robustesse du protocole HTTP ;
- sa capacité à passer plus facilement les pare-feu qu’un autre protocole.
Fournir des services à forte valeur ajoutée métier
Enfin, dernier cas d’utilisation : la fourniture de services à forte valeur ajoutée métier, construits en fédérant les applications existantes de l’entreprise. On sort ici du cadre des Web Services pour rentrer dans celui des architectures SOA (Service Oriented Architecture). Les Web Services fournissent alors la tuyauterie nécessaire pour interconnecter les applications. Les Web Services sont en cela la pierre angulaire technique des architectures SOA.
Quelle est la stratégie à suivre ?
Phase 1 : Définition d’un contrat de services métier
Dans cette 1ère phase, on ne parle pas technique. On se focalise sur le besoin du client qu’on formalise sous la forme d’un contrat de services métier. Un service métier est un service qui a du sens pour un expert du métier ou pour le client qui va l’utiliser.
Phase 2 : Identification des Web Services → contrat (technique) de Web Services
Cette phase consiste à :
- identifier les Web Services à partir du contrat de services métier ;
- décrire chaque service métier comme l’assemblage d’un ou plusieurs Web Services.
On commence dans cette phase à s’intéresser aux problèmes techniques, notamment aux problèmes de performance : temps de réponse, latence, bande passante, consommation mémoire, …
Pensez : forte granularité / faible couplage
Définissez des Web Services à forte granularité. N’oubliez pas en effet, que l’invocation d’un Web Service coûte cher.
Prenons l’exemple d’une application qui désire récupérer les informations d’une personne. Vous avez la possibilité de définir :
- Soit plusieurs services : getNom, getPrénom, getAdresse ;
- Soit un seul : getPersonne → Personne.
La deuxième approche est la meilleure car :
- Elle minimise le nombre de Web Services appelés ;
- Elle réduit le couplage entre l’application cliente et le serveur.
Préférez les Web Services indépendants du contexte client
Oubliez donc les sessions utilisateur (état du client conservé par le serveur entre deux appels de Web Services). Le but est de supporter plus facilement la montée en charge du nombre de clients (scalability).
Phase 3a : Identifier les Web Services asynchrones
L’objectif de cette phase est de se prémunir contre des blocages et des problèmes de performance éventuels.
Candidats possibles :
- Web Service dont le temps de réponse n’est pas borné dans le temps. Ce sont typiquement les Web Services qui s’appuient eux-mêmes sur d’autres Web Services ;
- Web Services dont le traitement est long.
Certaines plates-formes de Web Services prennent en charge la publication ou la consommation de Web Services asynchrones.
Si ce n’est pas votre cas, vous devrez probablement publier 2 opérations dans le document WSDL par Web Service asynchrone :
- Une première pour envoyer la requête et obtenir en retour un identifiant (le job id) ;
- Une deuxième pour interroger régulièrement le serveur (polling) avec cet identifiant.
Prévoir aussi une opération (commune à tous les Web Services asynchrones) pour annuler un Web Service lancé ou un paramètre supplémentaire lors de l’appel, pour régler un timeout.
Phase 3b : Identifier les Web Services qui échangent de gros documents ou des données binaires
SOAP est un protocole destiné à transporter des messages XML, c’est-à-dire des messages texte. Il est donc inadapté au transport de données binaires. De plus, certains Web Services, qui échangent de gros volumes de données, peuvent être à l’origine de problèmes de consommation mémoire, de bande passante et donc de performance.
L’objectif de cette phase est d’identifier les Web Services qui vont recourir à un mécanisme de pièces jointes (attachment). Voir ci-dessous la partie consacrée aux mécanismes de pièces jointes. Pour le problème de bande passante, la solution consiste à compresser les pièces jointes ou à recourir à la compression HTTP.
Phase 4 : Ecriture du contrat
Il est rare d’écrire directement le document WSDL car son écriture est complexe. Généralement, le contrat est décrit dans un langage de programmation. Et, c’est la plate-forme de Web Services qui se charge de générer (automatiquement) le document WSDL. En Java (JAX-WS 2.0) et en .Net, la plate-forme s’appuie sur des annotations qui viennent compléter le code.
Exemple en Java en utilisant JAX-WS 2.0
@WebService(targetNamespace="http://objetdirect.com/facturation") public class Facturation { @WebMethod public Facture getFacture(String numero) { … } }
Les annotations @WebService et @WebMethod marquent respectivement les classes et les méthodes à publier.
Intéressons-nous maintenant à l’écriture du contrat. Afin de maximiser l’interopérabilité du Web Service, il est important de ne pas lier sa description :
- Au langage de programmation ;
- A son implémentation.
Ne pas se lier au langage de programmation
Limitez-vous aux types suivants :
- Types simples : String, Date, int, float, …
- Langages non objet : structure de données ;
- Langages objet : classes avec propriétés (= JavaBeans en Java) ;
- Tableaux d’éléments ;
Les collections génériques de .Net ou de Java 5, c’est-à-dire les collections typées. Ces contraintes s’appliquent aussi au type des éléments des tableaux, des collections génériques, des propriétés, …
D’une manière générale, évitez :
- Les collections d’objets non typées ;
- La surcharge de méthodes ;
- D’utiliser la classe Object de .Net ou de Java.
Ne pas se lier à l’implémentation du Web Service
Utilisez des interfaces ou des classes abstraites pures pour séparer clairement la définition du contrat de son implémentation. Proscrire la pratique courante qui consiste à transformer n’importe quelle classe en Web Service. Pratique d’autant plus courante en Java ou en .Net où il suffit de décorer la classe par des annotations. Une classe publiable devrait être une classe qui a été pensée et conçue pour être publiée.
Quels sont les écueils à éviter avec SOAP ?
Si le S de SOAP signifie « simple », malheureusement SOAP n’a rien de simple et est souvent à l’origine de nombreux problèmes d’interopérabilité. Nous allons en détailler 2.
Problème de version de SOAP
Il existe 2 versions de SOAP : SOAP 1.1 et SOAP 1.2 incompatibles entre elles. .Net et la plupart des bibliothèques de Web Services Java supportent les 2 versions. Par contre, si vous êtes amenés à travailler sur d’autres plates-formes ou avec des bibliothèques plus anciennes, il se peut que vous soyez obligé de publier vos Web Services en SOAP 1.1. Une autre solution consiste à supporter, dans le document WSDL, les 2 versions du protocole SOAP.
Problème de modèle de messages
SOAP est utilisé pour transporter les messages XML entre 2 applications. La spécification SOAP prévoit deux modèles de messages:
- Les messages de type RPC (Remote Procedure Call) ;
- Les messages de type Document.
Messages de type RPC
Messages XML destinés à représenter, indépendamment du langage de programmation, l’invocation d’un service, ainsi que son résultat éventuel. La structure générale de la requête et de la réponse est imposée par la spécification. Cette dernière aborde aussi les problèmes d’encodage des paramètres, notamment des tableaux et des graphes d’objets : RPC / encoded. Ce modèle de messages est le plus complexe des deux, mais aussi le plus contraignant.
Messages de type Document
La spécification SOAP n’impose, dans ce cas, aucune contrainte sur la structure de ces messages. Le sens des données XML véhiculées est laissé à l’appréciation des applications participant à l’échange. Ce modèle de messages offre plus de liberté, mais peut être à l’origine de problèmes d’interopérabilité.
Notez bien que dans les 2 cas, la structure des messages XML échangés est complètement décrite par le document WSDL. Dans le 1er cas, le serveur est obligé de respecter certaines règles. Dans le 2ème cas, il peut décrire n’importe quelle structure XML.
Le modèle de messages de type RPC est tombé en désuétude :
- Dans SOAP 1.2, seul le support du modèle Document est obligatoire ;
- On constate une évolution similaire en Java avec la dernière API : JAX-WS 2.0 ;
- Quant à .Net, il préconise depuis le début l’utilisation des messages de type Document.
Gare donc aux problèmes d’interopérabilité entre les anciennes applications qui s’appuient sur le modèle RPC et certains nouveaux outils qui ne supportent que le modèle Document.
Pour invoquer un Web Service, les plates-formes s’appuient donc aujourd’hui sur le modèle Document. Mais, comme la structure des messages XML est libre, comment par exemple repérer dans le document XML le nom du service invoqué ?
En fait, pour résoudre ce problème, les plates-formes utilisent généralement le modèle Document/literal wrapped. Ce modèle impose quelques contraintes. Notamment le fait que la balise racine du message XML transporté corresponde au nom de l’opération invoquée.
Comment échanger de gros documents ou des données binaires ?
L’échange de gros documents ou de données binaires requiert l’utilisation d’un mécanisme de pièces jointes (attachment).
Les anciens standards
- DIME : mécanisme proposé par .Net. Requiert l’installation de WSE 2.0 (Web Services Extension) ;
- SOAP With Attachments (W3C / SOAP 1.1) : mécanisme supporté par la plupart des autres plates-formes (Java notamment).
Le nouveau standard : XOP / MTOM (W3C / SOAP 1.2)
Pourquoi un nouveau standard ?
- Rester compatible avec les autres standards (ex : WS-Security)
- Ce n’était pas le cas de DIME ou de SOAP with Attachments.
XOP/MTOM est en passe de devenir LE standard. Il est supporté à la fois par .Net (requiert l’installation de WSE 3.0) et par les nouvelles plates-formes Java.
Conclusion
Il y a encore quantité de choses à dire sur les Web Services. Nous n’avons pas parlé, par exemple, de la sécurisation d’un Web Service. Dans quels cas peut-on s’appuyer sur HTTPS, quand doit-on adopter les standards comme WS-Security ? Il faudrait aussi parler du virage pris par Java avec la nouvelle API JAX-WS 2.0. J’ai cité quelques exemples de problèmes d’interopérabilité. La vision donnée ici reste limitée. J’espère cependant vous avoir donné quelques conseils utiles.
En voici un dernier : avant de commencer un développement, évaluez le risque technique induit par l’utilisation des Web Services. Faites des tests d’interopérabilité, des maquettes, des prototypes pour valider la chaîne entière. Ces tests préalables sont indispensables, notamment si vous envisagez de ne pas vous limiter à SOAP/WSDL.
