xml decid : Stratégies, marchés, affaires autour de XML.
[xml-decid] INFO : Services Web: batis sur une contradiction
From: redacteurs@xmlfr.org
Date: 15/11/2002 - 11:20
Services Web : batis sur une contradiction
Cherchant a se presenter a la fois comme champions du couplage lache et
comme nouvelle architecture de RPC ( Remote Procedure Call ), les
Services Web SOAP semblent plus que jamais batis sur une contradiction
que le decalage entre les exposes theoriques et les experiences
pratiques presentees lors de ce cinquieme Forum XML met en evidence.
Eric van der Vlist , Dyomedea ( vdv@dyomedea.com ).
---------------
Retrouvez cet article en ligne
(http://xmlfr.org/actualites/decid/021115-0001).
Donnez votre avis !
mailto:xml-decid@xmlfr.org?subject=Re:%20INFO%20:%20Services%20Web:%20batis%20sur%20une%20contradiction
---------------
Le constat n'est pas nouveau. Il prolonge l'article publie lors de la
precedente edition du Forum XML sous le titre "Services Web, a la mode
mais a cote de la plaque? [1] " et il est en quelque sorte confirme par
Jim Green qui, repondant a la question "que sont les Services Web?"
distingue non pas deux mais quatre definitions partiellement
convergentes:
- Pour le Gartner Group, ce sont des composants faiblement couples
qui interagissent grace a des technologies Internet standards.
- Pour les editeurs d'outils de developpement, c'est une technologie
qui permet d'ameliorer leurs outils en facilitant l'integration.
- Pour les editeurs d'applications, c'est une nouvelle facon de
definir des API s.
- Pour les editeurs d' EAI , c'est un moyen de faire communiquer des
systemes.
D'autres presentations confirment une double contradiction entre la
vision theorique de couplage lache en utilisant des technologies
standards et l'implementation physique grace aux technologies
habituellement associees aux Services Web ( SOAP , UDDI , WSDL , ...):
- D'une part, la logique " RPC " de SOAP n'est pas reellement une
logique de couplage lache.
- D'autre part, si la sur couche introduite par SOAP peut
effectivement utiliser les protocoles standards de l'Internet et
notamment HTTP , l'utilisation qui en est faite est telle que les
outils de gestion de ces protocoles doivent etre totalement
repenses pour les Services Web .
Ce point apparait clairement dans les presentations de Cyril Dhenin
"Web Services, quels gains pour quels couts?", Didier Girard
"Architectures et Web Services" et Jean-Philippe Moresmau "La qualite
des Web Services" qui mettent en evidence l'insuffisance des fonctions
d'administration, de supervision et de securite des infrastructures Web
actuelles et la necessite de developper un nouvelle infrastructure
adaptee aux Services Web .
On semble donc se trouver en face de Services Web dont l'atout
principal le couplage lache et l'utilisation de protocoles existants
qui reposent sur une implementation de type RPC a couplage fort et ne
permettent pas de reutiliser l'infrastructure de gestion des protocoles
actuels.
Interroge sur ce point, Cyril Dhenin y voit une nouvelle manifestation
du decalage habituel entre le discours a destination des decideurs et
la realite technique. Une constatation faite de maniere plus nuancee
par Jean-Marie Chauvet qui distingue la vision strategique a long
terme des Services Web qui devraient permettre d'orchestrer les
services de l'entreprise etendue grace a l'exposition de leurs
processus metiers et une vision tactique des Services Web par les
developpeurs qui les utilisent comme des RPC .
Notant que la vision tactique des Services Web est deja bien realisee,
Jean-Marie Chauvet souligne le chemin qui reste a accomplir pour
realiser la vision strategique et notamment le risque de "babelisation"
de Services Web qui ne se comprendraient pas.
Divergence des discours techniques et marketing ou divergence des
visions tactiques et strategiques? Le mot de la fin reviendra peut-etre
aux realisations concretes qui suivent parfois des chemins imprevus.
Trois temoignages furent ainsi presentes lors de la session C07. Si le
temoignage de Side Brahimi pour la DGA a montre une architecture
BizTalk que l'on pourrait qualifier de classique, les temoignages de
Stephane Bidoul pour Elia et de Benoit Marchal et Patrick Bacher
pour France Telecom montrent des architectures echangeant des documents
XML directement sur HTTP preferees a SOAP pour des raisons de
simplicite et de non stabilite de la version actuelle de la
specification SOAP .
L'architecture de ces applications correspond a celle preconisee par
Roger Costello et mentionnee l'annee derniere dans mon article. Elle a
depuis gagne un nom et s'appelle maintenant architecture REST . Comme
SOAP , elle utilise les protocoles existants, mais contrairement a SOAP
elle les utilise de la meme maniere que les utilisateurs humains et
permet de faire l'economie d'une partie de la refonte de
l'infrastructure indispensable au deploiement des architectures
Services Web classiques. De plus, contrairement a SOAP , elle ne
cherche pas a recreer des mecanismes de RPC et est fidele au principe
de couplage lache.
On ne peut bien entendu pas extrapoler les enseignements recueillis sur
trois temoignages, mais il semble indeniable que la plupart des
applications de Services Web deployees actuellement le sont sous forme
d'architectures REST qui s'ignorent et que, loin des feux des
projecteurs braques sur le trio SOAP / WSDL / UDDI , cette architecture
est l'architecture qui domine actuellement les Services Web .
Devant la puissance marketing deployee par des acteurs qui ont pour la
plupart interet a ce que leurs clients renouvellent leurs
infrastructures, on peut neanmoins se demander combien de temps cette
dominance va pouvoir se maintenir.
Autres articles:
- Des Services Web reposants [2] (breve)
- Services Web, a la mode mais a cote de la plaque? [3]
- XML, universel ou Babel? [4]
Copyright 2002 , Eric van der Vlist .
---------------------------------------------------------
References:
[1] http://xmlfr.org/actualites/decid/011120-0001
[2]
http://xmlfr.org/actualites/breves/2002-10-21#1035196291.26949.104.camel@ibook
[3] http://xmlfr.org/actualites/decid/011120-0001
[4] http://xmlfr.org/documentations/articles/011011-0001
---------------------------------------------------------
Mail genere par FormatedTextOutputHandler pour XT
(http://4xt.org/downloads/examples/outputhandlers/formatedtext/).
--
Devenez redacteur <XML>fr et contribuez au developpement
du xml francophone (http://xmlfr.org/infos/redacteurs) !
Liste de diffusion "xml-decid@xmlfr.org" (http://xmlfr.org).
Cette liste est a votre disposition pour discuter en francais de
tout sujet lie a XML.
Pour resilier votre abonnement, envoyez un message contenant la
commande "unsubscribe" a xml-decid-request@xmlfr.org
(mailto:xml-decid-request@xmlfr.org?Subject=unsubscribe)
Archive générée par hypermail 2.1.3 le 28/11/2002 - 10:22 UTC
webmaster@xmlfr.org
| 
