Tag Archives: rest

Slides Ressource Oriented Architecture

Déjà vendredi! Merci aux quelques 200 personnes qui ont vu ma présentation sur l’architecture orientée ressource ce lundi lors du symposium dot net guru. Merci pour les retours très positifs, ça m’encourage à préparer quelques billets plus détaillés sur ce sujet.

En attendant voici les slides

Webcast
Vous pouvez désormais voir ces mêmes slides avec le son sur le site des techdays. Vous aurez besoin de Silverlight.

Vous pouvez aussi pointer un lecteur de vidéo comme vlc vers les url suivantes:

DNG Symposium 2008 – 4 – Resource Oriented Architecture (ROA) 1/3

DNG Symposium 2008 – 4 – Resource Oriented Architecture (ROA) 2/3

DNG Symposium 2008 – 4 – Resource Oriented Architecture (ROA) 3/3

WS-* Bashing

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

Quelqu’un aurait quelquechose de gentil à dire sur les WS-* pour l’équilibre?

Google open social DReaM

chevalier_blanc.gifS’était le sujet phare de l’expo Web2.0 à Berlin: les réseaux sociaux et l’annonce de open social par Google. Google le chevalier blanc armé de son “open API” qui vient libérer le graph social enfermé derrière le bouclier des API propriétaires du méchant Facebook.

barreaux.jpgMalheureusement tout cela n’est qu’un rêve et la réalité est bien différente. Pour comprendre je vais poursuivre ma métaphore entre DRM et Web services.

L’API de facebook contrôle ce que l’on peut faire avec le social graph de Facebook, en particulier elle empêche d’utiliser votre liste d’amis à l’extérieur du site Facebook, en ce sens c’est un DRM, des barreaux, un vérou numérique qui contrôle l’usage que vous pouvez faire d’une donnée.

On pourrait imaginer que pour contrer Facebook, Myspace ou Linkedin fassent de même et proposent leurs propres APIs fermées pour utiliser leur graph sociale. On aurait alors plusieurs DRMs en compétition au détriment des utilisateurs comme pour la musique. Que propose Open social? D’ouvrir ces api? Non, il propose de rendre intéropérables ces DRMs potentiels.

Une application écrite avec open social fonctionnera dans le container Facebook tout comme dans le container Myspace.

Mais Facebook ne s’est pas joint à open social.
Mais le système ne permet toujours pas d’ouvrir les données du graph social et de les utiliser en dehors du site de réseau social d’origine.
Mais open social s’appuie sur Google gadget, il y a donc une dépendance forte avec Google que ce soit open source ou pas.
Un système d’intéropérabilité entre DRM, des containers, un leader qui ne rejoint pas l’initiative, ça me rappel quelque chose, et vous ? C’est la plateforme DReaM de sun qui avait pour objectif l’intéropérabilité des DRMs.

Plus grand monde ne conteste le fait que les DRMs sont une impasse et on a même totalement oublié cette idée saugrenue d’intéropérabilité des DRMs. Ca donne une bonne idée de l’avenir d’open social.

A moins qu’il ne reste un espoir… Open Social est une réponse précipité à la menace Facebook pour Google -Imaginez que demain en s’appuyant sur les données de votre réseau social Facebook donne des résultats de recherche plus pertinents que ceux proposés par Google?- Google a donc dégainé son fusil à pompe sans vérifier les cartouches. Les spécifications et les implémentations open social sont à moitié finies. Ce que j’ai décrit correspond à la partie disponible d’open social, c’est à dire l’API javascript qui repose sur google gadget. Mais open social prévoit une autre API à base de GData, qui respecte les principes de REST, le mp3 des services web 😉 Mais pour l’instant cette open social people Data Api n’existe pas encore. Pourtant cette API répondrait aux souhait de Tim O’Reilly: OpenSocial: It’s the data, stupid. Est-ce que les containers open social l’implémenteront? Pourtant comme le dis O’Reilly le premier à fournir ce social network ouvert va gagner.

Les Web Services sont les DRM du Software as a Service

Les Web Services sont les DRM du Software as a Service (SaaS) et les API Restfull en sont le mp3.

C’est Christian Fauré dans un commentaire sur un billet précédent qui m’a inspiré cette réflexion. Dis comme cela, ça semble un peu cryptique, un décodage s’impose donc.

Pour commencer quelques précisions sur le vocabulaire:

Web services: au sens du w3c ou “big Web services”, avec toute la stack SOAP + WS-*

DRM: Digital Right Management au sens CRAP: Contenu, Restriction, Annulation et Protection Ce sont ces technologies utilisées pour contrôler/limiter l’usage qui est fait de la musique téléchargée en ligne, par exemple pour restreindre la copie.

Software as a Service: Logiciel disponible sous forme de services accessibles en ligne au travers d’une interface web et d’une API.

API RESTfull: Interface de programmation respectant les principes énoncés par REST, en particulier API centrée sur la notion de ressource plutôt que de service.

Les Web Services, bien que se voulant réutilisables, imposent une manière d’accéder aux données au travers de l’interface qu’ils définissent. Ils présupposent certains type d’utilisation. Ce faisant ils limitent/contrôlent ce qu’il est possible de faire avec ces données comme le font les DRM avec la musique.

Les Web Services ne sont pas réellement intéropérable, ils fonctionnent bien sur la plateforme .net ou JEE, ils fonctionnent bien si l’on se sert des outils IBM ou Microsoft, ils fonctionnent péniblement entre .net et JEE, ils ne fonctionnent pas ou mal avec d’autres plateforme: php, ruby, python,… Tout comme un fichier aac d’apple fonctionne bien avec le logiciel itunes et les lecteurs ipod ou les fichiers wma DRMisés de Microsoft fonctionne bien avec les lecteurs “play for sure” et le logiciel windows media player. Mais ils ne marchent pas avec mon lecteur mp3 ou mon OS Linux.

Alors que les fichiers mp3 sont lisibles avec tous les lecteurs du marché et tous les logiciels. Il en va de même avec les services RESTfull, reposant sur des technologies simples et éprouvées: HTTP et XML, ils sont utilisables dans tous les environnements (java, .net, php, ruby, python, perl, script,…) avec n’importe quel outillage (du notepad à eclipse en passant par visual studio).

Enfin une API RESTfull en exposant des ressources plutôt que des services ne présuppose pas de l’utilisation qui sera faite des données exposées. Sans à priori sur les utilisations futures des données une API RESTfull ne limite pas l’usage qui sera fait des données (au contraire des DRM) et maximise les possibilités de réutilisation et de mash-up.

Un service web devrait être un site web navigable par des robots

RESTfull Web services