At this point I realize I’m flogging a dead horse. The folks I know from across the industry who have to build large scale Web services on the Web today at Google, Yahoo!, Facebook, Windows Live, Amazon, etc are using RESTful Web services. The only times I encounter someone with good things to say about WS-* is if it is their job to pimp these technologies or they have already “invested” in WS-* and want to defend that investment.
Dare Obasanjo Program Manager, Windows Live Platform group
Nowadays, all the distributed systems development I do is REST-oriented. I know from significant first-hand experience what both sides of the coin look like, and there’s no question that REST-oriented systems are easier and less expensive to develop, and far less costly to extend and manage. Like Dare said, anyone who thinks otherwise is either so emotionally or monetarily attached to WS-* that they can’t be objective, or they don’t actually write any code or build or maintain any actual systems. It’s no contest, really.
Steve Vinoski senior member of the IEEE
WS-* is where CORBA was circa 1997: it will be used to implement some good systems, but there will also be some high profile failures. A number of the specs will likely never be adopted by the mainstream (see WS-CDL, WS-Eventing), though some will definitely improve some ridiculous vendor interoperability disputes (e.g. WS-TX, WS-RM). Plenty of pundits (now bloggers) sing of its imminent triumph (channelling Orfali, Harkey and Edwards), but overall, the framework will not help solve the problem that was used to sell its adoption in the first place: increased agility, reuse, and visibility in IT. I think many WS-* tools actively hinder an SOA architect from achieving these goals.
Stu Charlton Enterprise Architect for BEA
Now that I’m working for IBM’s WebAhead group, building and supporting applications that are being used by tens of thousands of my fellow IBMers, I haven’t come across a single use case where WS-* would be a suitable fit.
James M. Snell write software for IBM
Show me the interoperable, full and free implementations of WS-* in Python, Perl, Ruby and PHP. You won’t see them, because there’s no intrinsic value in WS-* unless you’re trying to suck money out of your customers. Its complexity serves as a barrier to entry at the same time that it creates “value” that can be sold.
Mark Nottingham web expert at Yahoo
Oui moi …. euh non j’ai oublié.
Ah si, çà me revient ! Il faut faire du SOA + de la gouvernance, parce qu’au moins quand tu t’enlises tu sais gérer ton enlisement et mesurer ta “progression”.
çà marche comme çà ? … Non ?
Ah mince…
🙂
Il va falloir que je télécharge rapidement les spécifications … avant qu’elles ne disparaissent des serveurs.
D’ici un a deux ans tout le monde niera avoir jamais touché a ces normes !
Pingback: Christian Fauré » Blog Archive » REST in peace SOAP
Heu, non désolé.
Il faut tout de même reconnaitre que SOAP porte bien son nom (depuis qu’il a été reconnu qu’il n’était plus si “Simple” et qu’il ne reflétait plus son acronyme originel : “the SOAP name was an acronym. This is no longer the case.” cf. http://www.w3.org/TR/soap12-part1/#intro ) : SOAP fait depuis référence à la la pente “savonneuse” des services webs.
Allez, je me mouille, la partie interop avec Microsoft .Net 3.0 (WCF) de GlassFish est un des points les plus vendeurs en entreprise.
Difficile de faire de la fiabilité avec HTTP ou de la sécurité du message (et non du protocole). Pour ceux qui en ont besoin bien entendu. Pour les autres il y a JSR 311 (et on implémentation http://Jersey.dev.java.net)
Merci Alexis de positiver!
C’est vrai que c’est vendeur, mais est-ce que .net 3.1 SP2 et Glassfish 2.1.3 build 3456 seront eux aussi intéropérables? Et si je veux faire du php ? du ruby? De l’erlang?
Pour une techno qui au départ se voulait indépendantes des languages de programmation, se limiter à java et .net c’est pas terrible.
Je m’y étais essayé il y a quelques temps, arguant du fait que SOAP offre, via WSDL, un moyen de décrire dans une syntaxe normalisé et indépendante des applications (XML pour ne pas le nommer) les différentes procédures, ce qui me paraissait intéressant dans le cadre de la conservation de documents numériques, car indépendant du langage de programmation pour l’implémenter.
Finalement, plus j’investis dans ma découverte des technos du Web sémantique, plus il n’existe qu’un protocole qui trouve grâce à mes yeux : SPARQL (surtout si on utilise sparqUL pour gérer l’insertion, la mise à jour et la suppression, cf http://arc.semsol.org/docs/v2/endpoint).
Donc, finalement, bah, non rien pour contre-balancer.
Aurelien:
je ne pensais pas que les Francais se laisseraient berner par les conneries qu’on trouve sur REST. Comme quoi tout le monde peut se tromper. Je serais tres curieux de savoir ce que le camp des RESTifarians Francais pensent de mon post sur “REST creates strong Coupling” (http://www.ebpml.org/blog/40.htm).
Hors-mis le fait que tu n’as rien compris, ou tu n’as pas lu le post, peux tu me dire comment tu les code les “actions” (et les trans-actions) en REST? Parce que quand on pose cette question qui semble facher on a deux reponses:
a) pas de reponse
b) ah, les resources ont bien sur des actions, mais on les code au dessus d’HTTP (par du mapping degueulasse), mais on n’a pas besoin de declarer d’interfaces.
C’est quoi ta reponse?
JJ-
>je ne pensais pas que les Francais se laisseraient berner par les conneries qu’on trouve sur REST. Comme quoi tout le monde peut se tromper. Je serais tres curieux de savoir ce que le camp des RESTifarians Francais pensent de mon post sur “REST creates strong Coupling” (http://www.ebpml.org/blog/40.htm).
J’ai lu ton billet, plusieurs fois, j’ai en même lu pas mal d’autres. J’ai aussi lu ton bouquin: “Composite Software Construction”
Mon sentiment est que sur le fond on peut tomber d’accord sur pas mal de chose. D’ailleurs dans “Composite Software Construction” tu reprends la pluspart des contraintes d’architectures énoncées par REST.
Mais globalement il y a deux choses qui me dérange:
– Le ton très aggressif, limite irrespectueux, à l’encontre des “RESTafarians”. J’imagine que c’est en réaction à des billets pro-REST/anti-WS-* pas toujours très tendre eux aussi.
– Une rhétorique parfois douteuse et souvent complexe qui fait qu’on a rarement le courage de dépenser le temps nécessaire à la comprendre pour en extraire les sophismes.
Concernant ton billet:
On est à moitié d’accord sur le REST + WS-* plutôt que REST ou WS-*
REST n’est pas le silver bullet magique qui fait tout. Il a donc besoin d’autre chose. Mais pitié, non, pas WS-*.
D’un côté on a un style d’architecture précisément défini (la thèse de Roy) qui est issu d’une implémentation (le web) qui démontre ses qualités tous les jours depuis 10 ans. Ce sont des fondations solides.
De l’autre des tonnes de specs que personne, pas même IBM ou Microsoft, n’arrive à implémenter correctement. Du design by commity dans sa plus grande splendeur. Certaines mauvaises langues pensent que le seul but de ces specs est de créer du lock-in et de vendre plus de softs et de services. Ce sont des sables mouvants.
Quelle idée de vouloir construire un système d’information la-dessus. Et quelle idée d’appeler celà “web services”, où est le web dans tout ça? Qu’est venu faire le w3c dans cette galère?
REST-*? Pourquoi pas. Mais à la mode des RFC, d’abord une implémentation, du code qui fonctionne, puis la spec.
>Hors-mis le fait que tu n’as rien compris,
Il semblerait que je ne soit pas le seul à n’avoir rien compris, il y a deux explications:
a) Nous sommes tous des cretins
b) La démonstration gagnerait à être plus simple et claire.
Même sans le comprendre je peux affirmer que ton raisonnement est falacieux:
“REST create strong coupling”
=> Le Web est une implémentation des principes de REST. Il y a des milliers de mash-up sur le web, des milliers de widgets intégrés dans des millions de pages, je n’ai pas l’impression que l’on observe de gros problème de couplage fort.
>ou tu n’as pas lu le post, peux tu me dire comment tu les code les “actions” (et les trans-actions) en REST? Parce que quand on pose cette question qui >semble facher on a deux reponses:
>a) pas de reponse
>b) ah, les resources ont bien sur des actions, mais on les code au dessus d’HTTP (par du mapping degueulasse), mais on n’a pas besoin de declarer d’interfaces.
>C’est quoi ta reponse?
C’est quoi la question? Allez je vais essayer de répondre en posant d’autres questions:
A quoi servent les actions? Modifier des données, non?
Qu’est qu’une ressource? Une vue abstraite sur des données.
En manipulant les ressources par le bias de leurs représentation on modifie les données. (L’interface uniforme simplifie les implémentations, garantie l’intéropérabilité et le couplage faible)
La boucle est bouclée, on obtient le même résultat qu’avec des actions. L’approche est différente, ce n’est pas le même mode de pensée.
En exposant les données sous forme de ressources plutôt que de services on augmente la surface de contact de l’application, on augmente les possibilités de réutilisation des données, on favorise l’innovation. Dans l’approche service on redéfini à chaque fois les actions possibles et on ne peut faire de la réutilisation que dans les limites de ce qui a été prévu par le concepteur du service. Ca donne plus de contrôle au fournisseur du service. Ce n’est ni mieux ni moins bien, juste différent, tout dépend des propriétés que l’on cherche à donner au système.
Aurelien:
merci pour ta reponse. Je pense qu’on peut discuter. Je te demande juste de prendre un peu de temps pour comprendre ce que j’explique si tu le veux bien.
Dans le billet sur “REST creates strong coupling” j’explique pourquoi precisement REST est la technologie/le concept qui a permi au web d’etre ce qu’il est. Je demontre que lorsque on est dans une logique user-browser-server le couplage est presque nul. C’est la force de REST.
Le probleme, et je pense que tu ne comprends pas cela c’est que quand on passe a une inter-action server-server REST n’a plus aucune utilite, au contraire, REST cree un couplage extremement fort.
La raison est tres simple, comme tu l’expliques REST modelise les interactions comme des changement de contenu, il n’a y pas de notion d’etat de la resource et donc d’actions applicables a la resource.
Le probleme c’est que lorsque deux composants ont ete developpes chacun de leur cote, on fait comment pour les assembler en REST?
Mon propos n’est pas de dire que les applications qui impliquent les utilisateurs n’existent pas, pas du tout, j’essaie de comprendre comment REST me permet de creer un modele d’application composite qui inclue des inter-actions utilisateur-composant et composant-composant.
Mon seul propos est de dire que le “Remoting” ne marche pas. Ca fait 30 ans qu’on essaie de faire du Remoting: RPC, CORBA, EJB… maintenant ce que tu nous dis c’est que: REST marche pour le Web, donc on peut faire du Remoting avec REST (c’est ce que tu as ecris en expliquant que: “En manipulant les ressources par le bias de leurs représentation on modifie les données”
Ce qui est tragique dans cette histoire c’est qu’on ne peut pas melanger les concepts de changement d’etat et de contenu. Si on fait cela, on n’a plus de point de composition. Tu composes les changements d’etat pas de contenu. Pour le contenu GET et PUT marchent tres bien, pour les changements d’etat c’est la catastrophe. C’est de la que vient le couplage fort.
Mon propos est de demontrer que:
a) le Remoting doit etre abandonne
b) il faut creer un model applicatif qui integre la notion d’inter-action
c) d’inter-action entre quoi? entre resource bien sur.
C’est pour ca que je suis un peu fache avec la communaute REST. Vous avez d’un cote une technologie absolument extraordinaire et de l’autre vous recommandez de l’utiliser comme on le faisait dans les annees 70.
Tu l’as bien note, je ne suis pas anti-REST, bien au contraire, mais je m’oppose totalement a la vision que “En manipulant les ressources par le bias de leurs représentation on modifie les données” contenu d’accord (du cote WS on a SDO qui est une techno super), conne etat et evenements, c’est le retour a la pre-histoire.
Est ce qu’on se comprend mieux?
(Desole pour la forme de mes commentaires, j’espere que le fond est plus attractif).
JJ-
Juste pour clarifier la conversation (faudra que je mette ça à plat dans un billet plus détaillé) il y a trois niveau de conversation concernant REST:
– REST le style d’architecture: la thèse de Roy. C’est très abstrait, mais permet de bien conceptualiser les choses et d’expliquer pourquoi et dans quel contexte ça marche ou pas.
– Ressource Oriented Architecture: l’architecture du web qui respecte les principes de REST. Cette architecture est décrite dans les docs du w3c(http://www.w3.org/TR/webarch/) mais aussi dans le bouquin RESTfull Webservices. Comme toute achitecture elle évolue, en particulier avec l’irruption massive des technos Ajax.
– HTTP/XML qui sont les technos utilisées au niveau implémentation
> La raison est tres simple, comme tu l’expliques REST modelise les interactions comme des changement de contenu, il n’a y pas de notion d’etat de la resource et donc d’actions applicables a la resource.
Au contraire la notion d’état des ressources est centrale dans REST => on effectue une “action” sur une ressources en transférant une nouvelle representation.
Au niveau implémentation en http/xhtml les liens et formulaire donnent des indices sur les “actions” possibles. Mais il n’y a pas de secret pour interargir correctement il faut lire la doc. Quoi que, si le service est bien fait un humain va deviner le fonctionnement. Un programme ne le fera pas automatiquement bien sûr. Je ne crois pas un instant à la découverte et à l’utilisation automatique d’un service sans une intervention humaine
> Le probleme c’est que lorsque deux composants ont ete developpes chacun de leur cote, on fait comment pour les assembler en REST?
=> RTFM 😉
=> Intervention humaine mais avec des technos simples, efficaces et eprouvées
> Mon propos n’est pas de dire que les applications qui impliquent les utilisateurs n’existent pas, pas du tout, j’essaie de comprendre comment REST me permet de creer un modele d’application composite qui inclue des inter-actions utilisateur-composant et composant-composant.
> Mon seul propos est de dire que le “Remoting” ne marche pas. Ca fait 30 ans qu’on essaie de faire du Remoting: RPC, CORBA, EJB…
Là on est 100% d’accord, la faillite de RPC, CORBA, EJB est d’avoir voulu faire du remoting transparent. Vouloir s’abstraire du réseau est une erreur si l’on veut faire un système distribué (http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing)
>maintenant ce que tu nous dis c’est que: REST marche pour le Web, donc on peut faire du Remoting avec REST (c’est ce que tu as ecris en expliquant que: “En manipulant les ressources par le bias de leurs représentation on modifie les données”
Oui la pluspart des principes enoncés par REST sont des contraintes destinées à pouvoir faire du remoting sans ignorer le réseau.
> Ce qui est tragique dans cette histoire c’est qu’on ne peut pas melanger les concepts de changement d’etat et de contenu. Si on fait cela, on n’a plus de point de composition. Tu composes les changements d’etat pas de contenu. Pour le contenu GET et PUT marchent tres bien, pour les changements d’etat c’est la catastrophe. C’est de la que vient le couplage fort.
REST ne mélange pas les concepts de changement d’état et de contenu.
Le contenu c’est ta data dans ton filesystem ou ta base de donnée, éventuellement la représentaiton d’une ressource simple. La ressource est une vue sur 0-* contenu, c’est elle qui porte un état. Les changements d’état se font en manipulant les représentations des ressources. Le couplage en REST est sémantique (les url des ressources et le choix des représentations).
Au niveau ROA on ajoute deux contraintes:
– URI are opaque (l’url ne doit pas permettre de deviner le type de contenu machin.html, truc.pdf,… c’est le content/type qui décide ou un paramètre ajouté à l’url)
– cool URI don’t change. Ou de manière plus générique: on ne retire jamais, on ne modifie jamais une interface que l’on a publié on ne peut que les enrichir.
Les URLs + les représentations sont l’interface/le contrat des services RESTfull.
D’où l’intérêt des représentations Xml par nature extensible.
> Mon propos est de demontrer que:
> a) le Remoting doit etre abandonne
> b) il faut creer un model applicatif qui integre la notion d’inter-action
> c) d’inter-action entre quoi? entre resource bien sur.
>
> C’est pour ca que je suis un peu fache avec la communaute REST. Vous avez d’un cote une technologie absolument extraordinaire et de l’autre vous recommandez de l’utiliser comme on le faisait dans les annees 70.
>
> Tu l’as bien note, je ne suis pas anti-REST, bien au contraire, mais je m’oppose totalement a la vision que “En manipulant les ressources par le bias de leurs représentation on modifie les données” contenu d’accord (du cote WS on a SDO qui est une techno super), conne etat et evenements, c’est le retour a la pre-histoire.
>
> Est ce qu’on se comprend mieux?
Je pense que oui.
REST est effectivement très bien adapté pour la gestion du contenu, après tout c’est un style d’architecture de système hypermedia distribué. Ce qui permet déjà de faire beaucoup de chose (le web). Avec la notion “hypermedia as the engine of application state” on peut gérer les états, ce n’est sans doute pas parfait mais les sites de commerce électronique arrive à gérer pas mal de chose comme ça. Par contre la gestion des évenements n’est pas prise en compte dans le style d’architecture REST (Bien sûr on y arrive mais on sort du cadre de REST). Pour cette problématique il y a le style MEST (http://morenews.blogspot.com/2004/11/mest-architecture.html) à creuser…
Aurelien:
j’ai oublie de te remercier pour avoir pris le temps de lire mon livre.
Ce qui a de bien quand on discute avec des Francais c’est qu’on a les deux pieds dans la logique. Au US c’est toujours la mauvaise foi qui passe d’abord (d’ou mon ton un peu polemique parfois pour neutraliser ce genre d’attitude).
La notion d’etat, transition et action est beaucoup plus claire en France qu’aux Etat-Unis (:-). J’ai rencontre tres peu de developpeurs et Architectes qui maitrisaient c’est notions aussi bizarre que cela puisse paraitre.
>> Au contraire la notion d’état des ressources est centrale dans REST => on effectue une
>> “action” sur une ressources en transférant une nouvelle representation.
Bien sur, je comprends tres bien comment cela marche quand un utilisateur est en face de la representation. Par contre quand un composant recoit la representation, comment fait il la distinction entre un lien vers une autre resource, une action sur la resource existante, un changement de contenu de la resource existante…? Pour un humain la distinction est naturelle (a condition qu’ils parlent le meme language), pour un composant c’est beaucoup plus complique.
Tu ne peux pas reifier toutes les semantiques d’un modele applicatif derriere la notion de lien. Une fois encore, Roy, Tim… sont des genis. Avoir trouve un modele applicatif aussi compact a ete la clef de la reussite du Web.
Je souhaite simplement exprimer que ce modele applicatif doit etre etendu pour pouvoir l’utiliser de maniere attractive dans l’architecture des SI. Quand tu dis “les sites de commerce électronique arrive à gérer pas mal de chose comme ça” tu perpetues le probleme de l’architecture des SI. WS tout seul ou REST tout seul n’offrent pas de perspectives valable. Quand je dis REST + WS-* c’est pour eviter de mettre a la poubelle des concepts tres importants comme les interfaces bidirectionelle (WSDL) ou les languages d’orchestration, ou les languages d’assemblage, ou meme les proprietes d’extensibilite d’XML.
Je ne dis pas que WS est parfait, facile a utiliser… loin de la. C”est pour cela que je me suis mis a travailler sur wsper (http://www.wsper.org), pour expliquer qu’il existe un model applicatif unifie.
Un dernier point: le vrai probleme n’est pas “Vouloir s’abstraire du réseau est une erreur si l’on veut faire un système distribué”. Les systemes “distribues” on sait faire depuis 10 ans. La distribution de la charge, le fail-over… tout ca c’est du gateau maintenant, enfin presque.
Ce dont je parle c’est faire des systemes “connectes” pas seulement “distributes”. La question que j’essaie de resoudre c’est comment est ce que je peux developper des composants et les assembler (pas dynamiquement) apres qu’ils aient ete developpe.
a) sans casser ce qui marche
b) sans changer l’implementation, ou si je la change je reste dans le cadre defini par a)
c) avec un minimum d’assemblage
Une fois encore dans le contexte human-browser-server, y a pas photo REST est extraordinaire.
Mais dans le cas composant-composant, crois tu vraiment qu’une interface definie a l’interieur de plusieurs representations soit vraiment la bonne methode. Comment ca marche quand deux resources doivent inter-agire? (je ne parle meme pas du traitement des exceptions) Ca te parait pas un peu complique? Est ce qu’une interface bi-directionelle pour chaque composant ne simplifierait pas l’assemblage (manuel)?
Pour pouvoir creer plusieurs assemblages pour le/les meme(s) composant(s), il faut vraiment definir (ce que j’appelle) la surface du composant. Les aleas du reseau sont des pre-occupations mineures (certes reelles mais mineures). Ils sont traites en fonction de l’etat dans lequel les resources doivent se retrouver.
Ce qu’il faut bien comprendre c’est qu’il faut partir sur la base d’un modele applicatif (certes simple et general) pour pouvoir construire des systemes connectes. C’est ce que REST a fait entre parantheses, ils ont definit un modele applicatif de base et ils ont ensuite construit le middleware autour pour que ca marche. Construire le modele applicatif et le middleware separement est une erreur fondamentale qui en fait a tres peu a avoir avec les aleas du reseau.
Maitenant, je ne te dis pas que WS est un modele applicatif. C’est pour cela que j’essaie de construire un modele applicatif sans casser WS ou REST.
Je pense qu’il est facile de comprendre que le modele applicatif de REST peut etre etendu sans en perdre les benefices et permettre la realisation de SI composites.
oui, non, peut-etre?
> Mais dans le cas composant-composant, crois tu vraiment qu’une interface definie a l’interieur de plusieurs representations soit vraiment la bonne methode. Comment ca marche quand deux resources doivent inter-agire? (je ne parle meme pas du traitement des exceptions) Ca te parait pas un peu complique? Est ce qu’une interface bi-directionelle pour chaque composant ne simplifierait pas l’assemblage (manuel)?
Effectivement REST ne prévoit pas de “conversation” ou d’interface bidirectionnelle entre les composants, c’est la première contrainte: le client/serveur. Il y a un composant à l’origine des requêtes et l’autre qui y répond. Cette contrainte existe dans un souci de simplification et de robustesse, elle est importante pour pouvoir monter en charge à l’échelle du web. On peut bien sûr simuler la conversation avec 2 couples client/serveur mais ils doivent rester indépendant (si on fait du REST).
Si deux ressources doivent inter-agir c’est effectivement compliqué, et si c’est compliqué la montée en charge est limité. Maintenant l’échelle de l’entreprise n’est pas la même que celle du web. Dans un context précis pour répondre à ce besoin de “conversation” et si il est appuyé par un cas d’utilisation métier il est sans doute pertinent de renoncer à cette contrainte client/serveur en étant conscient des conséquences.
C’est que j’apprecie le plus dans la démarche REST, il y a un cadre théorique très solide qui permet de comprendre les conséquences des choix d’architecture.