Publié par

Il y a 10 années -

Temps de lecture 6 minutes

Web Service Interoperability (WS-I)

L’objectif initial des Web Services est de fournir un ensemble de standards permettant d’exposer des services de manière interopérable.
La mode du tout Web Service a rapidement mis en exergue les manques du triptyque de départ (WSDL, SOAP, UDDI) qui n’est plus qu’un diptyque. Par exemple, les aspects transactionnels en sont absents, ce qui impose de gérer des mécanismes de compensation. C’est alors que se sont mis à fleurir les WS-*. Même après consolidation et épuration, la confusion autour de ces standards est palpable et il semble illusoire d’aboutir à un modèle qui soit interpéropérable out-of-the-box.
C’est face à ce constat que s’est créée la Web Service Interoperability Organization (WS-I org.), consortium industriel dont l’objectif est d’établir et de diffuser un ensemble de best practices autour des standards Web Service, en vue de garantir l’interopérabilité des différentes implémentations et utilisations qui sont faites de cette pile de standards.

Dans ce billet, nous reviendrons rapidement sur la galaxie des standards Web Services, avant de présenter la Web Service Interoperability Organization (WS-I org.) et ses travaux.
Nous nous attarderons ensuite sur les profils proposés par le WS-I puis sur les outils qu’il met à disposition.
Nous terminerons avec quelques recommandations quant à l’implémentation de Web Services conformes aux profils du WS-I.

La galaxie des standards Web Services

L’équation de départ se voulait simple :

  • Des standards basés sur XML, un langage autodescriptif que l’on présente comme l’esperanto de l’informatique (il est compréhensible au-delà des limites technologiques et, pour peu qu’il soit bien écrit, reste lisible par une personne sans connaissances en programmation).
  • Un triptyque fournissant :
    • Un protocole d’échange : SOAP
    • Un langage de définition d’interfaces : WSDL (cet IDL fournit un premier pas vers la description de contrats).
    • Un modèle d’annuaire de services : UDDI (d’entrée trop complexe, UDDI a rapidement été mis de côté, même s’il est censé se relever depuis la version 3).

Mais à peine cette première stack adoptée, elle a montré ses limites et de nouveaux besoins se sont fait sentir engendrant une armée de standards (regroupés sous le nom de WS-*).

  • Pour le messaging, avec par exemple, WS-Adressing.
  • Pour la gestion des métadonnées. Citons WS-Policy.
  • Pour la fiabilisation avec WS-Reliability et WS- Reliable-Messaging.
  • Pour la sécurité avec WS-Security et ses add-ons.
  • Pour la gestion transactionnelle avec, entre autres, WS-Coordination et WS-Atomic Transaction.
  • Pour la gestion des ressources.
  • Pour les processus métier avec, par exemple, WS-Choreography Model.
  • Pour la gestion avec WS-Management.

Ajoutez à cela la dépendance entre ces différents standards, nous obtenons une galaxie plutôt dense de standards ou propositions de standards.

ws standards

Ces standards sont poussés par une pléthore d’éditeurs et aboutissent (éventuellement) chez 2 organismes de standardisation : l’OASIS et le W3C.

Chacun fournissant une (ou plusieurs) implémentation(s) de ces standards, on aboutit à un modèle qui a peu de chance d’être interopérable out-of-the-box.

Web Service Interoperability Organization (WS-I org)

C’est face à ce constat que s’est créée la Web Service Interoperability Organization (WS-I org.).

Le WS-I est un consortium qui regroupe plus de 160 sociétés. Son objectif annoncé est de faire progresser l’interopérabilité des Web Services en établissant des bonnes pratiques autour des standards existants. Les travaux du WS-I sont menés en coopération avec les organismes de standardisation OASIS et W3C.

Le constat de départ du WS-I est simple :

  • L’intérêt des Web Services réside dans l’interopérabilité. C’est grâce à elle que les Web Services permettront de répondre aux attentes qu’ils suscitent : Qualité, modularité, évolutivité et surtout réconciliation de Systèmes Techniques hétérogènes.
  • L’adoption des Web Services et leur succès sont directement liés aux technologies qui les supportent.

Répondre à ces enjeux permettra :

  • De réduire les coûts, la complexité et les risques, notamment en donnant confiance dans l’interopérabilité des Web Service.
  • De faciliter les échanges et la collaboration, que ce soit au sein de son propre SI ou avec des Systèmes externes.

Pour arriver à cela, le WS-I élabore et propose trois types de livrables :

  • Des profils qui regroupent des bonnes pratiques d’utilisation des standards en vue d’assurer l’interopérabilité des implémentations.
  • Des exemples mettant en œuvre ces profils.
  • Des outils de tests permettant de vérifier la conformité d’une implémentation à un ou plusieurs profils.

Les profils

Les profils proposés, même si certains sont encore à l’état de draft, couvrent aujourd’hui :

  • La couche transport avec notamment HTTP, HTTPS, …
  • La couche invocation c’est-à-dire XML, SOAP.
  • La couche description de contrats avec entre autres XSD et WSDL, …
  • Et aussi les aspects sécurité et Reliable messaging.

Voici comment s’articulent les différents profils :

  • Le Basic Profile 1.1 constitue le socle des profils.
  • La version 1.2 du Basic Profile, encore à l’état de DRAFT, l’étend en y ajoutant notamment le support de WS-Addressing.
  • Le Basic Security Profile 1.0 y ajoute une dimension sécurité avec la prise en charge de WS-Security 1.0 et de SAML.
  • Afin de suivre l’évolution des standards, un Basic profile 2.0 et un Basic Security Profile 1.1 sont en cours d’élaboration.
wsi profiles

L’objectif à terme est de regrouper l’ensemble de ces profils au sein d’un Reliable Security Profile 1.0 qui couvrira, en plus de ceux adressés dans le Basic Profile 2.0 et le Basic Security Profile 1.1, les standards WS-Reliable Messaging et WS-Secure Conversation.

Les outils

Le WS-I propose deux outils de tests de conformité : Le Monitor et l’Analyzer.

wsi tools
  • Le Monitor fonctionne comme un proxy. Il est configuré pour intercepter les requêtes et les réponses échangées entre un client et un Web Service. Ces requêtes et réponses sont tracées dans une base locale.
  • L’Analyzer permet de tester la conformité à un profil. L’analyse peut porter :
    • Sur une définition de contrat (WSDL, XSD).
    • Sur le contenu d’un annuaire UDDI.
    • Sur les traces générées par le monitor.

Perspectives

Nous l’avons vu, le modèle des WS-* a peu de chance d’être interopérable out of the box. L’utilisation de SOAP / WSDL à elle seule pose des problèmes d’interopérabilité.

L’utilisation des outils du WS-I au plus tôt dans le cycle de développement permet d’éviter de mauvaises surprises au moment de brancher les systèmes, que l’on soit dans la position d’un fournisseur ou d’un consommateur de services.
Chacun devrait au minimum utiliser systématiquement l’Analyzer pour s’assurer de la conformité des WSDL qu’il manipule au WS-I Basic Profile. Que l’on soit dans la position d’un consommateur ou d’un fournisseur de service.
De la même façon, la conformité au Basic Profile des Web Services produits devrait être systématiquement exigée dans un cahier des charges.

Attention cependant. La conformité aux profils du WS-I, même si elle protège de beaucoup de choses, ne garantit pas l’interopérabilité.

À noter également que l’écriture de Web Services en mode Contract First et l’utilisation de contrats orientés documents sont deux bonnes pratiques qui permettent, entre autres, d’écrire des Web Services conformes aux profils du WS-I.

Publié par

Commentaire

5 réponses pour " Web Service Interoperability (WS-I) "

  1. Publié par , Il y a 10 années

    Merci pour cet article qui a permis de m’éclairer dans cette constellation de standards.

  2. Publié par , Il y a 10 années

    Vous semble-t-il nécessaire d’utiliser les outils WS-I même si on utilise un framework qui dit respecter WS-I Basic Profile ? Je pense notamment à Apache CXF.

  3. Publié par , Il y a 10 années

    Bonjour,

    Aujourd’hui, la plupart des frameworks Web Service se déclarent « WS-I BP Compliant » (Apache CXF et Axis2, SpringWS, JBossWS, GlassFish Metro, WebMethods Glue, ASP.NET 2.0, …). Beaucoup d’efforts ont été faits depuis quelques années et certaines règles (les plus problématiques) sont désormais bien respectées.
    Mais même si ces frameworks respectent les recommandations du WS-I, rien ne permet de préjuger de l’utilisation qui en sera faite pour l’implémentation de Web Services. Les frameworks ne peuvent pas empêcher les développeurs de violer les recommandations des profils dans leur implémentation.

    Donc oui, l’utilisation de l’Analyzer me semble indispensable, même si le framework utilisé est « WS-I BP Compliant », non pas pour valider le framework, mais pour valider l’utilisation qui en est faite.
    Le coût de prise en main de l’outil est très faible et permet de se prémunir contre de mauvaises surprises qui à terme peuvent se révéler coûteuses. Il serait donc dommage de s’en priver.

  4. Publié par , Il y a 10 années

    Je me souviens du coup de gueule d’Aurélien. Finalement, cet article montre bien que la solution n’a pas vraiment avancé. La simplicité n’est pas au rendez-vous. Pourtant, à la base le sujet aurait pu être simple car il s’agitssait d’avoir un protocole commun de communication inter applicatif transactionnel et sécurisé. Et que donne le résultat de ces WS-* : tout une série de bricolage intra et inter entreprises, l’éparpillement des technologies de communication (XML, JSON, dérivation vers REST voire même de la simple URL bookmarkable). Quand je pense qu’on est 2009 et qu’on n’est même pas d’accord sur les formats dates entre les technologies… Tout ça me ramène à un adage qui dit : la première règle à appliquer lorsqu’on souhaite adopter une architecture distribuée est « do not distribute’.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.