Bonjour,
Encore une fois, je pense que nous sommes tous d'accord sur le fait que
SOAP constitue un mécanisme de RPC interessant à mettre en oeuvre pour
certains types d'applications.
C'est plus sur la manière de présenter les Services Web comme un nouvel
Eldorado et une solution à tous nos problèmes que je m'interroge.
Remy Mathieu-Daudé wrote:
> FYI, SOAP supporte le mode asynchrone : SOAP With Attachments, pour l'envoi
> de pièces jointes (XML, MIME...).
> C'est d'ailleurs ce mode qui est utilisé dans les frameworks ebXML et
> RosettaNet pour l'échanges de messages. Il permet de travailler en couplage
> lache (pas de RPC), dans un mode orienté document (indispensable au niveau
> de transactions B2B), tout en bénéficiant de la valeur ajoutée de SOAP par
> rapport à HTTP/SMTP (enrichissement du Header de l'enveloppe notamment).
Je suis content que vous citiez ebXML qui me semble apporter de l'eau à
mon moulin.
Il y a eu pendant très longtemps une bataille de clocher entre ebXML et
SOAP dont les déclarations enflammées [1] de Jon Bosak lors de XML 2000
ont constitué le point d'orgue. A l'époque, ebXML était parti sur un
protocole XML spécifique nécessaire compte tenu de l'impossibilité de
gérer des pièces jointes avec les premières versions de SOAP.
Ce point de blocage ayant été levé par la publication [2] d'une note
W3C, il n'a pas fallu bien longtemps à ebXML pour intégrer SOAP [3]
comme protocole utilisable dans son framework ni à RosettaNet pour le
suivre sur cette voie [4].
Je pense que cela montre bien que SOAP n'est qu'un mécanisme de base
relativement mineur dans des architectures comme ebXML ou RosettaNet qui
peuvent changer de protocole RPC en quelques semaines et que les
véritables problèmes à résoudre pour échanger ou intégrer des
informations se situent à un autre niveau.
Sur un plan plus "métaphysique", l'informatique n'a pas attendu SOAP
pour savoir faire des RPC et cela n'a pas pour autant permis à des
concepts comme le "net computing" ou les "ASP" qui sont conceptuellement
similaires aux Web Services de se développer.
Ne devrait-on pas se demander pourquoi ces modèles ont échoué? Dire que
c'est uniquement parce que Microsoft et les autres n'avaient pas réussi
à se mettre d'accord sur un protocole me semble simpliste. N'y aurait-il
donc aucune autre raison technique (sémantique notamment), économique ou
juridique?
Pour continuer sur le ton provocateur qui a su susciter vos
commentaires, les Web Services pourraient bien être une nouvelle
"solution qui cherche encore son problème" et se précipiter vers les Web
Services c'est peut être avancer sur une voie parce qu'elle est facile à
mettre en oeuvre techniquement sans se poser les "vraies" questions...
et donc sans trop savoir où elle va!
Eric van der Vlist
[1] http://xmlfr.org/actualites/decid/001207-0001
[2] http://xmlfr.org/actualites/tech/001212-0002
[3] http://xmlfr.org/actualites/decid/010223-0001
[4] http://xmlfr.org/actualites/decid/010502-0002
>
> Rémy MATHIEU-DAUDE
> OCTO Technology
>
--
See you in Orlando for XML 2001.
http://www.xmlconference.net/xmlusa/
------------------------------------------------------------------------
Eric van der Vlist http://xmlfr.org http://dyomedea.com
http://xsltunit.org http://4xt.org http://examplotron.org
------------------------------------------------------------------------
--
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)
Received on Fri Nov 23 03:25:53 2001
