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