xml decid : Stratégies, marchés, affaires autour de XML.
[xml-decid] Re: Services Web: batis sur une contradiction
From: Eric van der Vlist (vdv@dyomedea.com)
Date: 26/11/2002 - 11:17
Bonjour,
On Tue, 2002-11-26 at 11:36, Thierry - listes wrote:
>
> Bonjour,
>
> Ne serait-il pas utile de s'accorder avant tout sur une définition
> du terme "Web Services" ?
C'est effectivement une bonne remarque.
> - Pour XMLFR, c'est "serices Web" est un (cf http://xmlfr.org/index/object.title/services+web/) :
> "Terme générique pour désigner services utilisables par des applications et accessibles sur le Web".
> Dans ce cas, on ne parle pas forcément de XML, et encore moins de SOAP.
Je donne volontairement une définition qui s'appuye sur la finalité
(utilisation de services accessibles par le web) plutôt que d'imposer
une technologie.
> - Le W3C dit la même chose (en anglais sur http://www.w3.org/2002/ws/)
> sur 2 lignes d'introduction.
> Mais ensuite tout le discours est bâti en fonction de XML,
> et il est rapidement question de SOAP qui est également normalisé par le W3C.
>
> - Un grand nombre de rédacteurs sur ce sujet
> (y compris bien sûr les présentateurs de solutions des éditeurs - Sun, BEA, ...
> je n'ai pas vu Microsoft, mais ce doit être idem)
> définissent d'entrée les WS comme l'utilisation de SOAP, WSDL, UUDI, ebXML.
>
> Ma question est donc :
> aujourd'hui, avons-nous encore le droit de parler de WS sans impliquer l'utilisation
> de SOAP ?
Si ce n'est pas le cas, il faudrait trouver un autre terme pour désigner
des "services accessibles sur le web" et je trouve que ce serait
dommage, un peu comme si on refusait d'appeler "voiture" un objet à
quatre roues propulsé par autre chose qu'un moteur à explosion :-)
A mon sens (mais je sais que cela ne fait pas l'unanimité), un service
"REST" est un service web de la même manière qu'une voiture diesel, GPL
ou électrique est une voiture...
> - puis-je dire que je fais des Web Services si simplement je mets à disposition de mes
> clients une URL dynamiques qui affiche (ou "renvoit" pour être plus précis dans le cas
> de l'attaque de cette URL par programme) un flux de données (au format XML, admettons) ?
> Charge à moi bien sûr d'indiquer les paramètres en entrée nécessaires, et de documenter
> le flux de sortie.
Dans le sens que je donne à cette définition, oui. Dans celui donné par
des consortiums qui tendent à nous imposer l'utilisation de SOAP, non.
> - quelles différences avec SOAP, autres que la définition précise de la structure XML
> du flux de sortie (et éventuellement du flux d'entrée) ?
>
> - s'il n'y a pas d'autres différences, on peut dire que SOAP est simplement un standard
> permettant de rendre plus rigoureux la mise en place des WS,
> et que rien n'interdit au client d'agir comme il l'entend pour décoder les données.
> Dans ce cas sommes-nous contre les standards ?
Je voudrais revenir sur la double contradiction que je mentionne dans un
mail précédent. Il y a d'une part la notion de couplage lâche ou fort
qui ne se réduit pas à SOAP vs REST mais également à l'utilisation qui
en est faite (on peut réaliser des systèmes à couplage lâche avec SOAP
et à couplage fort avec REST, mais SOAP corespond mieux à la
"philosophie" couplage fort et REST à celle du couplage lâche).
La deuxième contradiction est due au fait que l'on empile une couche sur
un protocole (HTTP) qui n'est pas fait pour cela et que l'on ne retire
pas les bénéfices attendus puisque l'on se rend maintenant compte qu'il
faut modifier de manière importante l'infrastructure HTTP existante pour
déployer SOAP.
Si tel est le cas, ne vaut-il pas mieux, soit:
1) Utiliser l'infrastructure existante sans rajouter cette couche
lorsque c'est possible (c'est l'architecture REST).
2) Lorsqu'elle n'est pas adaptée et puisque de toute manière nous savons
maintenant que l'infrastructure ne sera pas réutilisable, utiliser un
protocole réellement adapté tel que BEEP (le standard IETF qui est à
HTTP ce que XML est à HTML).
Dans ce deuxième cas, on peut éventuellement utiliser SOAP sur BEEP,
mais c'est rarement utilisé et dans ce contexte SOAP qui "réinvente la
roue" pour pouvoir utiliser HTTP à contre usage ne permet pas de tirer
partie de tous les avantages de BEEP.
Il me semble que, volontairement ou non, on raisonne faux et on nous
aiguille vers une solution pour le moins un peu bancale avec SOAP :-)
...
Cordialement,
Eric van der Vlist
--
Curious about Relax NG? My book in progress is waiting for your review!
http://books.xmlschemata.org/relaxng/
------------------------------------------------------------------------
Eric van der Vlist http://xmlfr.org http://dyomedea.com
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------
--
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
| 
