Les contraintes des Web Services

Interopérabilité des messages XML

Bien que l'objectif d'interopérabilité soit déterminant pour l'usage des web services, dans la pratique des écarts de fonctionnement entre les implémentations SOAP existent. Il faut comprendre les raisons historiques de ces différences afin de les éviter lorsque l'on construit les web services.

De manière générale, plus la représentation en XML Schema des types de données présents dans les messages des opérations est riche plus les risques d’interprétations différentes par les parseurs SOAP sont fortes. A l’inverse, plus les types retenus sont pauvres et plus l’intérêt du WSDL diminue car sa capacité d’expression sémantique est alors réduite. Par exemple, en XML Schema il est intéressant d’utiliser le type «†enum†» pour exprimer une énumération. Si l’on présente ce type dans un WSDL, le consommateur comprend de manière autonome l’existence de cette énumération. Si elle n’est pas présente, il faut alors compléter le WSDL par un commentaire statique ou une documentation ad hoc pour expliquer la présence de l’énumération, ce qui est coûteux en gestion et peu rationnel. Malheureusement, si l’on utilise l’énumération XML Schema on augmente le risque d’incompatibilité du web service selon les parseurs SOAP qui seront employés par les consommateurs.

De nombreuses meilleures pratiques permettent de décider comment modéliser les messages XML Schema en fonction du niveau d’interopérabilité souhaité. A ce titre, le Basic Profile et JAXB contribuent à rationaliser progressivement l’approche.

Performances des Web services

Avant tout il faut savoir juger des besoins d'un projet en terme d'exigences de performance versus d'interopérabilité (voir extrait de la Meilleure pratique Quand faut-il utiliser SOAP-XML ?)

Une fois que SOAP sur HTTP est décidé (ou sur JMS) voici une liste synthétique des axes d'amélioration des performances (au-delà des considérations matériels et réseaux) :

• Utiliser des types de données XML Schema les plus élémentaires afin de réduire le parsing.
• Supprimer la validation de conformité de l'instance XML face au Schema au niveau du parseur.
• Mettre en place des stratégies de caching pour les services en consultation et pour le binding WSDL.
• Plutôt que le chiffrer tout le flux via HTTPS faire du chiffrement sélectif grâce à WS-Security.
• Compresser le flux XML (ZIP).
• Alléger en exploitation le flux SOAP-XML selon les besoins de chaque consommateur (paramétrage).

Si l'interopérabilité est limité à un contexte 'intranet' et Java envisager le SOAP sur JMS.

Meta-type XML

Afin qu’un même type de données présenté dans plusieurs WSDL ne soit pas codifié de manière différente à cause d’implémentations existantes hétérogènes, il est intéressant de prévoir un meta-type associé à un mapping qui est exécuté avant l’exposition et l’utilisation du flux SOAP.

Ce mapping peut se mener soit†:

• Au niveau même du flux XML, c'est-à-dire avant le unmarshalling lors du SOAPRequest (et avant le marshalling lors du SOAPResponse). Il faut alors prévoir des handlers dans le parseur SOAP du serveur. Ces handlers exécutent, par exemple, des directives XSLT.
• Au niveau des façades utilisées pour l’implémentation des opérations. Dans ce cas, le mapping se fait dans le langage d’implémentation par exemple en java.

L’exposition de web services augmente le besoin d’unification des codifications des types de données. Les solutions de data mapping peuvent opérer utilement au niveau des handlers SOAP, à partir des messages XML.

Organisation des namespaces

Plutôt que de définir toute la structure du web service dans un seul WSDL, on préfère le découper en deux ou trois parties distinctes qui correspondent à la définition des types de données, à la définition de la partie abstraite (message, portType) et la définition de la partie concrète (binding, name, port). Afin de supprimer les risques de collision de noms, on retient la mise en place d’un namespace pour chaque partie isolée.

Cette organisation favorise une meilleure réutilisation des types de données entre les web services ainsi qu’une bonne flexibilité si plusieurs définitions concrètes sont nécessaires pour une même définition abstraite.

Dans les principes de codification des fichiers WSDL et XSD on réutilise le concept de catégorie SOA puisque chaque catégorie forme un espace de nommage.

Définition	Fichier	Espace de nommage (*)
Types	http://.../categorie/<Categorie>/<CAT>.xsd	http://.../categorie/<Categorie>/Schema
Abstraite	http://.../webservice/<Ws>/<Ws>Abstract.wsdl	http://.../webservice/<Ws>/definitions
Concrète	http://.../webservice/<Ws>/<Ws>.wsdl	http://.../webservice/<Ws>/service

(*) TargetNameSapce
<Categorie> : libellé de la catégorie UML qui contient les types décrits.
<CAT> : mnémonique discriminant sur 3 caractères de la catégorie.
<Ws> : libellé du web service.

Attention : la dernière mise à jour de nos Meilleures pratiques SOA et Web services retient aussi la stratégie de mapping "WSDL - UDDI" décrite par l'OASIS (TC) et qui prévoit une découpe en trois fichiers WSDL plutôt que deux. C'est un peu plus contraignant mais conforme à l'OASIS : voir aussi le Triptyque SOA en téléchargement libre sur notre site et qui en présente une courte synthèse.

Sécurité

La mise en place des web services en mode de conversation bipolaire, c’est-à-dire que la session ne fait intervenir que deux participants (le fournisseur et le consommateur) ne pose pas de problèmes spécifiques de sécurité. Les mécanismes SSL et de gestion de clefs sont opérationnels.

Par contre, lorsqu’il s’agit d’un mode de conversation multipolaire, c’est-à-dire impliquant plusieurs fournisseurs et/ou plusieurs consommateurs par rebond dans une même conversation, il est nécessaire d’agir directement sur différentes parties du flux XML. Par exemple, le chiffrement peut être adapté selon le participant dans la session. A ce niveau, il faut mettre en úuvre des nouveaux standards de sécurité spécifiques aux web services comme par exemple WS-Security. Ces standards sont encore émergeants.

SOA et Web Services

SOA est un cadre méthodologique alors que les web services sont un ensemble de standards techniques. Les deux sont évidemment complémentaires. On peut pratiquer le SOA sans implémenter les services sous la forme du standard web service. A l’inverse, bien que l’on puisse construire des web services sans démarche méthodologique SOA, ce n’est pas conseillé. En effet, la pertinence du contour fonctionnelle du web service ainsi que la qualité de son implémentation dépendent en partie du respect de la démarche SOA.

Pour rappel, la pile de standards de base utilisée par les web services sont HTTP, WSDL et SOAP.