xml decid : Stratégies, marchés, affaires autour de XML.
[xml-decid] Re: WS : REST / SOAP
From: Jean-Jacques Dubray (jjd@eigner.com)
Date: 13/02/2003 - 15:16
Les "RESTifarians" pretendent que la souplesse du web provident du fait
que l'architecture est composee d'un tres faible nombre de verbes (PUT,
GET, POST...) tres rigide et d'une infinite de noms identifies par une
URI. Selon eux, c'est cette architecture qui permet le decouplage le
plus fort entre consommateur et producteur de service.
SOAP de part son architecture permet de creer une infinite de verbes et
de noms. Si le nombre de verbes est grand, intuitivement, cela offre un
plus grand raffinement dans les requetes, mais par contre cela veux dire
aussi que le consommateur et le producteur doivent se mettre d'accord
sur un plus grand nombre de choses en plus du format des donnees. (e.g.
est-ce qu'on est d'accord sur comment traiter un bon de commande?).
Rien n'empeche d'utiliser SOAP avec un nombre limite de verbes. Peut
etre cette liste va apparaitre un jour ou l'autre sous la forme de
"services generic".
La question est donc vraiment, doit on se limiter a un petit nombre de
verbes ou pas? Honetement, je pense que les "restifarians" trichent peu
car les vrais verbes sont encodes dans l'URI des noms e.g.
POST /maCompanie/bonsDeCommande/SuperUrgent/BDC.php
En fait cet "encodage" est beaucoup moins flexible qu'un fragment d'XML
!! (voir point #4 ci-dessous).
Je ne pense pas que le decouplage se situe vraiment ici. Le decouplage
est atteint essentiellement par l'utilisation d'XML qui permet a la meme
URL de traiter des formats differents ou des versions differentes du
meme format (on evite ainsi les problemes de recompilation des clients
lorsque de nouvelles versions apparaissent, le client peu choisir quand
il evolue d'un format a l'autre sans que son application "casse"). C'est
tres dur de faire cela avec du CORBA/DCOM/RMI. Ce decouplage est
indispensable des que le nombre de client passe un certain seuil.
Comment en effet tous les clients pourraient upgrader au meme moment?
Un second niveau de decouplage offert par XML c'est que les donnees XML
sont "semantiquement" accessible, par opposition a structuralement
accessibles. (e.g. peut acceder a l'information //facture/montant sans
connaitre le detail du document facture, par contre un programme (C,
Java, ...) a besoin de connaitre la definition de la structure des
donnees pour atteindre un attribut). Cela veut dire qu'on peut envoyer
beaucoup de formats different au meme service tant que les informations
necessaires sont accessibles.
Un troisieme niveau de decouplage service/client existe au niveau de la
reponse producteur -> consommateur. Les technologies de transformation
type XSLT qui permettent au service de retourner les donnees dans un
format 'consommable' par le consommateur. (Notez que les niveaux 1 et 2
n'aurait pas trop d'utilite si ce troisieme niveau n'existait pas).
Le quatrieme niveau de decouplage offert par XML est bien sur que le
verbe et un grand nombre d'adverbes et d'adjectifs qualificatifs peuvent
etre transmis avec le verbe, voir meme des requetes de traitement tres
complexes. Ce qui est un peu plus difficile a faire dans un environment
objet par le bias de methodes.
Bien sur la puissance d'XML ne peut s'exprimer que si le substrat de
transport est homogene. Si HTTP n'existait pas XML en lui meme n'aurait
que peu de valeur.
Si vous souhaitez aller plus loin, j'ai ecrit une serie de papier il y a
fort longtemps (http://jeffsutherland.com/oopsla99/Dubray/dubray.html
http://www.gca.org/papers/xmleurope2000/papers/s25-03.html )
En fait l'idee de REST/SOAP est je pense une idée qui addresse des
problemes de performance. Cela coute cher de traiter du XML d'ou l'idee
de deffricher un peu les en-tetes SOAP.
Malheureusement, je crois que cette affaire REST/SOAP n'est encore
qu'une manifestation de la volonte (incomprehensible) de SUN de ralentir
la progression les web services.
Jean-Jacques Dubray____________________
Chief Architect
Eigner Precision Lifecycle Management
200 Fifth Avenue
Waltham, MA 02451
781-472-6317
jjd@eigner.com
www.eigner.com
>>-----Original Message-----
>>From: xml-decid-bounce@xmlfr.org [mailto:xml-decid-bounce@xmlfr.org]
On
>>Behalf Of JP Moresmau
>>Sent: Thursday, February 13, 2003 5:59 AM
>>To: xml-decid@xmlfr.org
>>Subject: [xml-decid] Re: WS : REST / SOAP
>>
>>
>>Derrière le nom un peu barbare de REST se cachent des principes assez
>>simples: en fait, REST est une théorisation de certains principes du
Web,
>>mis en form by Roy T. Fielding, un des concepteurs du protocol HTTP.
Sa
>>dissertation
(http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm)
>>explique en détail de quoi il s'agit.
>>En gros, REST dit que toutes les opérations effectués via le web
>>n'utilisent
>>qu'un certain nombre d'opérations: des opérations de lecture (via la
>>méthode
>>HTTP GET) de mise à jour (PUT), d'ajout de données (POST) et de
>>suppression
>>(DELETE). Utiliser un nombre réduit d'opérations défini dans un
protocole
>>permet de facilement reconnaitre les messages: si je "vois" une
requete
>>HTTP
>>GET, je sais qu'il va s'agir d'une lecture de donnée qui va sans doute
>>pouvoir être cachée par un intermédiaire, par exemple. De plus REST
>>indique
>>que chaque "chose" sur le web qui est accessible (REST parle de
resource)
>>doit avoir une URI: un nom unique qui permet de l'identifier, et, dans
la
>>plupart des cas, de s'y connecter.
>>Dans le cadre des Web Services, les supporters de REST disent: REST
nous
>>donne tout ce dont nous avons besoin, pourquoi s'embêter avec SOAP? La
>>vraie
>>intéropérabilité des Web Services n'est pas SOAP, c'est le fait que
les
>>données échangées soient transmises dans un format bien défini, c'est
à
>>dire
>>XML. On n'obtient une intéropérabilité équivalent, sinon meilleure,
avec
>>REST: un web service est representé par une URL et, eventuellement,
des
>>informations qui indiquerait quel type de données passer à ce service.
>>SOAP
>>ne vous dispense pas non plus de cette phase là, elle est juste
simplifiée
>>par la présence d'outils qui font la translation entre SOAP et la
>>représentation dans un langage de programmation des données échangées.
Il
>>est très facile d'avoir des services web qui n'utilisent pas SOAP en
ayant
>>ces outils de translation, par exemple pour transformer du Java en
XML.
>>REST ne vous force pas à utiliser XML: si vous voulez implémenter un
>>service
>>web qui renvoit une image, en SOAP vous êtes obligé soit d'encoder
l'image
>>en XML, soit de l'attacher au message SOAP. En REST, pour pouver
renvoyer
>>l'image via HTTP en indiquant dans l'entête qu'il s'agit d'une image.
De
>>même, le client peut indiquer au service quelles types de données il
>>comprend, de la même manière que votre navigateur indique aux sites
sur
>>lesquels vous surfez qu'il comprend le HTML, le PDF, les images GIF,
>>etc...
>>Autrement dit, avec REST vous pouvez passer toutes les données que
vous
>>voulez sans avoir à les forcer à les faire entrer dans le format SOAP,
>>d'où
>>un gain important en simplicité et en performance.
>>Conceptuellement, REST est plus difficile à saisir que SOAP (qui n'est
>>qu'un
>>protocole de RPC en XML) mais permet de fait des web services en
utilisant
>>la recette qui a permis au Web de rencontrer le succès que l'on sait.
Mais
>>il est à craindre que les grands joueurs de l'industrie du logiciel
>>poussent
>>SOAP et les autres standards, de plus en plus complexes et de moins en
>>moins
>>Web, pour vendre plus de leurs logiciels... La simplicité ne peut pas
se
>>vendre cher...
>>
>>Si vous maitrisez l'anglais, vous trouvere plus d'infos sur
>>http://conveyor.com/RESTwiki/moin.cgi
>>
>>JP
>>
>>
>>Soamaï Jean-Philippe Moresmau - CTO-Directeur Technique 1025 rue Henri
>>Becquerel - 34036 Montpellier cedex 01 - FRANCE Tél : +33(0)4 99 52 65
43
>>-
>>Mob : +33(0)6 72 75 21 27 Std : +33 (0)1 46 08 69 00 - Fax : +33(0)1
46 08
>>69 51 www.soamai.com
>>----- Original Message -----
>>From: "Thierry - listes" <thgalist@natapassion.com>
>>To: <xml-decid@xmlfr.org>
>>Sent: Thursday, February 13, 2003 11:25 AM
>>Subject: [xml-decid] WS : REST / SOAP
>>
>>
>>>
>>> Bonjour,
>>>
>>> Au sujet des Web Sevices (WS), j'ai quelques questions.
>>>
>>> Un des avantages d'avoir une norme comme SOAP est qu'un certain
nombre
>>d'outils de
>>> génération et de parsing automatique existe maintenant.
>>> Par exemple, si je veux faire communiquer d'un côté du PHP avec le
>>package
>>nusoap
>>> et de l'autre côté du Java avec Axis, en principe cela ne pose pas
de
>>soucis et la
>>> tâche du développeur en est grandement facilitée : quelques lignes à
>>écrire pour
>>> appeler ces composants, tant en utilisation cliente qu'en
déploiement de
>>WS.
>>>
>>> SOAP est portable partout, je crois que c'est ça qu'on appelle
>>l'interopérabilité.
>>>
>>> En ce qui concerne, l'architecture REST existe-t-il des possibilités
>>similaires ou
>>> serions-nous condamnés à tout réécrire à chaque développement ?
>>> Depuis peu, le site de Sun fait mention de l'architecture REST comme
>>n'étant pas à
>>> négliger ; il donne l'origine du nom : "Representational State
>>Transfer".
>>Que cela
>>> signfie-t-il ? Qu'est-ce que cela recouvre ?
>>>
>>> Quels sont les avantages et les inconvénients de REST par rapport à
SOAP
>>?
>>> Je n'arrive toujours pas à comprendre en quoi l'architecture REST
permet
>>un
>>> couplage plus lâche que SOAP. De toutes façon le client et le
serveur
>>doivent
>>> comprendre le même langage XML ; n'est-ce pas ?
>>>
>>> bye - Cdlt,
>>>
>>> Thierry GAGNAIRE
>>> mailto:thga@tgagnaire.com
>>>
>>>
>>>
>>> --
>>> 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)
>>>
>>
>>--
>>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)
--
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/02/2003 - 08:02 UTC
webmaster@xmlfr.org
| 
