A lire aussi:
Dossier Web Services, une révolution en marche
Panorama Le puzzle XML

Les grandes entreprises qui vous consultent, vous interrogent-elles sur les Web Services ? Que leur conseillez-vous sur le sujet ?
Rémy Mathieu-Daudet: Nous commençons à avoir quelques questions de clients qui s'interrogent sur l'intérêt des Web Services, par exemple pour développer des fonctions de personnalisation avancées ou encore des bouquets de services sur des portails. De petits services qui s'apparentent à des transactions point à point pour générer quelques données. Fonctionnellement, par rapport à un "portlet" (connecteur capable d'aller puiser des données dans les applications, ndlr) ces premiers Web Services ne permettent pas des choses radicalement nouvelles. Ils permettent avant tout de rationaliser et d'industrialiser ses services. Pour obtenir plus des Web Services, et notamment pour supporter des transactions longues, complexes, partagées entre de nombreuses entreprises, il va falloir faire preuve de patience...

Le canevas technologique semble pourtant se dessiner assez vite...
Le canevas est en effet esquissé mais il est loin d'être stabilisé. Prenons un peu de recul: grosso modo, la matrice technique des Web Services comprend trois couches horizontales et deux services transversaux. A l'horizontal, on trouve la couche transport, puis tout ce qui concerne la sémantique des messages et enfin la gestion des processus. Les services transversaux sont deux grands classiques, à savoir la sécurité et l'intégrité transactionnelle. En fait, au sein de cette matrice, seule la couche transport, avec les protocoles http et SOAP, semble vraiment stabilisée. Le reste est encore bien jeune ou, pire encore, juste en gestation. L'actualité récente en témoigne...

Une allusion au nouveau protocole WS-Inspection proposé par IBM et Microsoft ?
Absolulement. UDDI, destiné à la publication et à l'exploration d'annuaires de Web Services, nous a été présenté initialement comme un pilier fondamental du modèle. Le fait que deux promoteurs d'UDDI s'engagent sur une autre voie montre que ce protocole s'avère finalement trop complexe. Bref, qu'il s'agit d'une usine à gaz. D'où la nécessité, pour ne pas mettre en danger l'édifice, de proposer un dispositif plus souple, plus pragmatique. L'initiative ne me semble pas mauvaise; elle révèle simplement la jeunesse du modèle.

Pour la deuxième couche que vous évoquez, la sémantique des messages, où en sont les travaux?
Dans ce domaine les initiatives sont multiples. D'un côté, les différents corps de métier (Chimie, aéronautique, finance...) poussent chacun plusieurs langages, de l'autre des consortiums comme ebXML et Rosettanet ont aussi ouvert des chantiers. On ne peut pas dire que la route à suivre soit particulièrement claire. Je crois cependant que
Rosettanet, dont les travaux ont commencé assez tôt, dessine un modèle de convergence intéressant...

Si l'on veut utiliser les Web Services pour orchestrer des transactions B to B complexes, il va falloir aussi s'entendre sur un moyen de modéliser ses flux...
Dans ce domaine, il existe des initiatives mais les travaux n'avancent que très lentement. Le consortium BPMI travaille ainsi sur le langage BPML (Business Process Markup Language) mais les implémentations semblent encore bien rares. De plus, d'autres initiatives ont été lancées: WSFL (Web Services Flow Language) d'IBM, XLANG de Microsoft. Difficile dans ces conditions de dessiner des architectures pérennes.

Même souci pour les deux services transverseaux que vous avez mentionnés, la sécurité et l'intégrité transactionnelle ?
Absolument. Pour la sécurité, SAML (Security Assertions Markup Language), destiné aux échanges de données relatifs aux authentifications et aux habilitations, synthétise une partie des travaux précédents. Mais il n'est pas achevé. Enfin, en ce qui concerne les moyens de garantir l'intégrité des transactions exécutées via les Web Services, c'est le grand vide. Le chantier XAML (Transaction Authority Markup Language) paraît abandonner et le protocole BTP (Business Transaction Protocol) lancé par Bea et apparemment soumis à l'Oasis est encore très jeune. Tout cela est assez préoccupant: les transactions longues et complexes ne seront pas à la portée des Web Services tant que nous ne pourront nous appuyer dans ce domaine sur des standards matures.

Au final, l'édifice technique des Web Services, tel que vous le dessinez, semble encore bien fragile...
A l'exception de la couche transport, il reste encore beaucoup de travail. Certes, avec le protocole SOAP nous pouvons déjà faire de petites choses. Mais la vision d'un modèle de relations inter-entreprises reposant sur des Web Services complexes n'est pas prête de prendre corps. Je pense que nous avons encore une bonne année de travail devant nous...