En quelques mois, les Web Services sont devenus le nouveau point de convergence technologique de l'ensemble des acteurs du marché de l'informatique.

L'objectif des Web Services est de faciliter l'accès aux applications entre entreprises et ainsi de simplifier les échanges de données. Ils poursuivent un vieux rêve de l'informatique distribuée où les applications pourraient interopérer à travers le réseau, indépendamment de leur plate-forme et de leur langage d'implémentation. Dans ce sens, ils s'inscrivent dans la continuité d'initiatives telles que CORBA (Common Object Request Broker Architecture, de l'OMG) en apportant toutefois une réponse plus simple, s'appuyant sur des technologies et standards reconnus et maintenant acceptés de tous.

Qu'est-ce qu'un Web Service ?

Un Web Service est un composant implémenté dans n'importe quel langage, déployé sur n'importe quelle plate-forme et enveloppé dans une couche de standards dérivés du XML. Il doit pouvoir être découvert et invoqué dynamiquement par d'autres services.

Cette nouvelle technologie, initiée par IBM et Microsoft, puis en partie normalisée sous l'égide du W3C, est maintenant acceptée par l'ensemble des acteurs de l'industrie informatique sans exception. C'est surtout ce point qui fait des Web Services une technologie révolutionnaire.

Les aspects purement technologiques n'ont eux rien de fondamentalement novateurs. Au contraire, l'architecture des Web Services s'est imposée (tout comme le langage XML) grâce à sa simplicité, à sa lisibilité et à ses fondations normalisées.

Le concept des Web Service s'articule actuellement autour des trois acronymes suivants :

• SOAP (Simple Object Access Protocol) est un protocole d'échange inter-application indépendant de toute plate-forme, basé sur le langage XML. Un appel de service SOAP est un flux ASCII encadré dans des balises XML et transporté dans le protocole HTTP.
• WSDL (Web Services Description Language) donne la description au format XML des Web Services en précisant les méthodes pouvant être invoquées, leur signature et le point d'accès (URL, port, etc..). C'est, en quelque sorte, l'équivalent du langage IDL pour la programmation distribuée CORBA.
• UDDI (Universal Description, Discovery and Integration) normalise une solution d'annuaire distribué de Web Services, permettant à la fois la publication et l'exploration. UDDI se comporte lui-même comme un Web service dont les méthodes sont appelées via le protocole SOAP.

Un avantage significatif des Web services, relativement aux autres solutions d'architecture distribuée, est son support des pare-feux (firewalls) : l'utilisation du protocole HTTP sur le port 80, généralement ouvert, leur permet de passer sans encombre ces barrières de l'entreprise. Cette facilité engendre d’autres soucis de sécurité, l’utilisation par défaut de ces caractéristiques est trop permissive et nécessite une prise en compte de la sécurité au niveau des protocoles.

L'infrastructure Web Services

La normalisation actuelle autour des Web Services est cependant un vaste chantier qui va bien au-delà de la simple invocation d'une méthode d'un objet distant. Différents travaux ont ainsi démarré pour tenter de définir une véritable infrastructure distribuée, capable de satisfaire l'ensemble des besoins d'une application distribuée, aussi bien en terme de normalisation des échanges qu'en terme de services transverses.

On peut schématiser cette organisation des comités de normalisation selon le découpage matriciel suivant :

•  Normalisation des services transverses sur trois axes horizontaux:
  - Couche de transport : Définition de la structure des messages utilisés par les applications pour se découvrir et dialoguer entre elles
  - Couche de sémantique : Normalisation des données participant aux échanges selon des critères métier
  - Couche de gestion des processus : Standardisation de la gestion des processus métier qui s'étendent sur plusieurs applications disponibles sur l'Internet
• Normalisation des services transverses sur trois axes verticaux:
  - Service d'annuaire : Standardisation des moyens d'accès à un service à partir d'une requête portant sur le contenu d'un service ou sur un fournisseur
  - Service de sécurité : Normalisation des moyens permettant de couvrir les problématiques d'authentification et de gestion des droits d'accès
  - Service de transaction : Normalisation des moyens permettant de garantir l'intégrité des transactions longues impliquant plusieurs Web Services

Etat de la normalisation

A l'heure actuelle, seule la couche de transport est réellement normalisée et ne souffre d'aucune contestation. Elle s'appuie sur le protocole SOAP pour l'échange des messages et sur le langage WSDL pour la définition du contrat de l'interface.

Les initiatives de définition de la couche de sémantiques des messages sont nombreuses et n'ont pour le moment pas conduit à une quelconque normalisation. Deux types de chantiers sont actuellement ouverts, l'un organisé selon les différents corps de métier, l'autre suivant une approche plus globale autour de consortium tel que OASIS (initiateur de ebXML) ou RosettaNet.

L'orchestration de transactions B2B complexes, fondée sur une modélisation normalisée des flux est également une initiative qui n'avance que très lentement et sur des activités non concertées. On peut citer en exemple BPML (Business Process Modeling Language de BPMI), WSFL (Web Services Flow Language, d'IBM) ou XLang (de Microsoft).

Au niveau des services, on pouvait penser que la proposition d'annuaire UDDI apporterait une solution définitive. On constate qu'il n'en est rien et que le canevas, trop global, du projet ne convient pas à une problématique d'échanges entre entreprises se connaissant. Il se voit maintenant concurrencer par WS-Inspection (proposé par IBM et Microsoft, pourtant à l'origine de UDDI). Moins ambitieux puisque consistant en une simple exposition, par agrégation, des services d'une entreprise, il est toutefois plus adapté à cette seconde problématique.

La gestion de la sécurité et des transactions est actuellement le frein le plus important à la mise en place d'architectures distribuées à base de Web Services. Plusieurs chantiers sont ouverts mais aucun n'est réellement accepté. On peut cependant penser que la norme XACML (eXtensible Access Control Markup Language ) devrait supplanter SAML (Security Assertion Markup Language) au niveau sécurité et s'imposer à terme comme standard de sécurité. En ce qui concerne l'aspect transactionnel, la lutte est plus ouverte, même si BTP (Business Transaction Protocol ) semble plus soutenu actuellement.

Cas Concrets

Que ce soit dans le monde de J2EE ou dans celui de .NET, tous les acteurs majeurs proposent une solution orientée Web Services ainsi que l'intégration imminente des standards associés. Parallèlement, les premières utilisations de cette technologie voient le jour, notamment dans le domaine des solutions de CRM (Sevina ou Onyx), de gestion des ressources humaine (CCMX) ou de mutualisation de contenu (Systeme U, Digiplug).

Est-il urgent d'attendre ?

Les Web Services provoquent un intérêt évident auprès des architectes et des décideurs. La question récurrente concerne leur degré de maturité.

Il est clair que sur une technologie aussi récente, le recul n'existe pas. Mais, même si l'édifice est encore fragile, il repose sur des bases solides (SOAP et WSDL) qui ont prouvé leur efficacité et leur maturité. D'ores et déjà, les Web Services ont quitté le champ des échanges inter-entreprises pour s'accaparer celui du référencement et de la mise à disposition des ressources de l'entreprise, empiétant en ce sens sur les technologies de type EAI. Cette utilisation à elle seule prouve la qualité du modèle et sa pérennité, notamment au niveau des couches les plus basses.

Par contre, la normalisation complète d'une architecture distribuée fondée sur les Web Services n'est pour le moment qu'un rêve annoncé chaque année, pour la fin de l'année suivante ! Par ailleurs, ce modèle n'échappe pas à des problèmes de performance : les données sont transmises en ASCII dans une encapsulation XML elle-même intégrée dans une enveloppe SOAP puis HTTP… Le problème du choix de la bonne granularité du service, commun à toutes les architectures distribuées, se présente dans le cas des Web Services de manière plus aiguë encore.

Même s'ils n'ont pas acquis la maturité nécessaire à leur industrialisation, les Web services s'annoncent plus que jamais comme la réponse appropriée aux problématiques d'échange de données et d'intégration d'applications.

Pour la mise en œuvre des Web Services, SOFTEAM se propose de mettre son expertise et la capitalisation de son expérience à votre disposition au travers de son offre de Conseil, Formation, Ingénierie ou Produits.