Quand faut-il utiliser SOAP-XML ?

La vocation de départ des Web service (SOAP-XML) est l’interopérabilité. C’est la raison pour laquelle la stack de base est composée de standards simples : HTTP pour le transport, une enveloppe SOAP et une représentation XML (XML Schema).

Bien sûr, au-delà de l’interopérabilité la mise en place d’un système réel nécessite d’évaluer les besoins en terme de performance d’exécution (temps de réponse) et de coordination (acquittement des messages, contexte, transaction…). Ici les Web services présentent des contraintes fortes qu’il faut comprendre dans l’instant et estimer dans la distance.

Cette meilleure pratique propose un cadre d’analyse pour juger du niveau de pertinence de l’usage de SOAP-XML face aux autres solutions plus traditionnelles comme RMI/IIOP, DCOM, MOM…

Rappel sur la granularité des services

Une autre meilleure pratique détaille comment appréhender la granularité des services et conduit à une typologie de services qui est la suivante :

• Service métier (à usage métier, fonctionnel ou technique). Ce sont les services de grande maille (coarse grained) identifié au niveau des cahiers des charges fonctionnels et à partir d’une découpe des processus organisationnels (Y compris les processus de type EAI lorsqu’il s’agit d’un besoin d’intégration inter-applicatifs) (exposition d’un périmètre fonctionnel du fournisseur vers les consommateurs). La meilleure pratique fournit des principes méthodologique pour cette découpe et d’autres sur les métriques des messages échangés par les services métiers : pas plus de 100 paramètres élémentaires, maximum de deux niveaux d’héritage après la racine…
• Service attaché à une Catégorie (au sens de Grady Booch, contributeur à UML). Le concept de Catégorie est utilisé pour partitionner le système d’information autour d’entité de gestion majeure qui permettent de découper les services métiers en services attachés aux Catégories. La maille de ces services est celle qui forme l’architecture applicative (medium grained). La meilleure pratique fournit de nombreuses règles pour la découverte des Catégories, la mise en place d’un couplage faible entre les Catégories, l’implémentation sous la forme de Composants dans les serveurs d’application (Factory, Interface…).
• Enfin, chaque service d’une Catégorie est décomposé sous la forme de services rattachés aux classes qui forment la Catégorie (ou ses modules internes si on n’implémente pas en langage objet la Catégorie). Il s’agit ici d’une maille la plus élémentaire (fine grained) du service (équivalent à la méthode dans une Classe).

Aujourd’hui, compte tenu de la vocation des Web service et de la représentation des messages en XML (besoin de parsing), il faut limiter leurs usages aux services métiers, c'est-à-dire la première couche de service que nous venons de décrire rapidement. Un Web service est donc ‘coarse grained’, pas ‘medium grained’ et encore moins ‘fine grained’. C’est évidemment une règle de départ (par défaut) que l’on peut toujours dégrader selon les besoins particulier d’un projet, mais en justifiant les raisons de cette éventuelle variante.

Les différents types de binding

Tout d’abord nous synthétisons dans le tableau suivant les différents types de bindings courants pour le choix du protocole de communication.
Les deux premières colonnes présentent le cas des Web services avec SOAP over HTTP et SOAP over JMS. Une courte analyse synthétique est associée à chaque cas de binding.

Figure 13 : Les différents types de binding

Le terme ‘Coordination’ fait référence aux fonctions nécessaires pour la gestion de l’acquittement des messages, du contexte (maintien d’information entre plusieurs appels de services), des événements (abonnement, notification), des transactions…

Cadre d’analyse pour juger de la pertinence des Web services et de la performance

Le tableau suivant présente les critères majeurs qui contribuent à l’étude d’opportunité d’usage des Web services. Bien sûr, les deux axes principaux sont l’interopérabilité et la performance.

On confirme que l’usage actuel de SOAP over HTTP (cadrant en couleur verte sur le schéma) est légitime lorsque le besoin d’interopérabilité est fort et les performances moyennes.

En cas d’interopérabilité forte et de performance attendue également forte, on peut tenter l’usage de SOAP over HTTP sous condition de déployer des dispositifs qui favorisent les performances :

• Utiliser des types de données XML Schema les plus élémentaires possibles (pas de types étendus) afin de réduire le travail de parsing.
• Supprimer la validation de conformité de l’instance XML face au Schema au niveau du parseur (les contrôles sur les paramètres étant de toute façon assurés au niveau applicatif).
• Mettre en place des stratégies de caching pour les services en consultation et pour le binding WSDL côté consommateur.
• Plutôt que le chiffrer tout le flux via HTTPS faire du chiffrement sélectif grâce à WS-Security.
• Compresser le flux XML (XML binaire) via un système classique de type ZIP (sous condition que le temps de traitement de la compression / décompression ne soit pas plus pénalisant que le gain réseau obtenu).
• Alléger le flux XML en fonction des besoins réels de chaque consommateur : par exemple, ne pas faire circuler des données multimédias pour un consommateur particulier dont la bande passante réseau n’est pas suffisante. Pour plus d’information à ce sujet, se reporter à la meilleure pratique sur le modèle d’architecture par les contextes ou Context-Aware (voir aussi article disponible sur le web : http://www.orchestranetworks.com/fr/developers/article_variantessoa.cfm).

Dans le cas où l’interopérabilité porte sur des environnements Java, il est aussi possible de retenir un binding SOAP over JMS (voir deuxième colonne du tableau).

En plus de la situation ci-dessus, si les besoins de coordination sont importants les standards fondateurs de l’infrastructure EDA (Event Driven Architecture) comme WS-Eventing (ou WS-Notification), WS-ReliableMessaging, WS-CAF, WS-RF… deviennent incontournables mais non encore disponibles aujourd’hui dans les implémentations. Il faudra sans doute attendre 2006/2007 pour envisager un usage industriel de ces protocoles dans un cadre d’interopérabilité.

Par contre, lorsqu’il s’agit de mettre en place une coordination dans un contexte de forte interopérabilité et pour des temps de réponse attendu moyen, il est tout à fait possible d’anticiper les implémentations des standards EDA (voir ci-dessus) en procédant à des implémentations spécifiques qui s’en inspirent. C’est notamment le cas pour l’acquittement des messages (équivalent à WS-ReliableMessaging) ou la gestion d’un contexte de données partagé entre plusieurs Web services (équivalent à WS-Context ou WS-RF).

Figure 14 : Cadre d’analyse pour juger de la pertinence de SOAP-XML