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...
|